Database under press

Database under press

Relasjonsdatabasen blir utfordret. Data i sammenkoblede tabeller passer bare forretningsbehov.

For 25 år siden var modellering av data høyeste mote. Data skulle lagres i tabeller som refererte til andre tabeller, derav navnet relasjonsdatabase. It-fagfolk måtte lære tredje normalform. Den krevde at data ikke var dublert.

Istedenfor å skrive postnummer og sted på hver kunde, skulle man bare notere postnummer. Ved fakturautskrift ble sted skaffet ved å slå opp i poststedstabellen ved hjelp av postnummer. Det medførte et stort arbeid med å modellere data. Glemte man noen, kunne det få store konsekvenser.

LES OGSÅ: Relasjonsdatabaser - nei takk!

Kraftige verktøy skulle så tilrettelegge dataene i tabellene og fremskaffe resultater ved forespørsler og rapporter. Det startet med fjerde generasjonsspråkene og fortsatte med Case-verktøyene. Lite ble det ut av det. Hjelpemidlene var ikke gode nok.

Flere og flere virksomheter innså at det var bedre å anskaffe forretningssystemer enn å utvikle dem selv. Med forretningssystemene fulgte det en tabellstruktur for relasjonsdatabaser. Dernest var det bare å velge sin favoritt: Oracle, DB2 og SQL Server har klort seg fast.

Oracle først

Oracle var først. Til tross for at IBMs forsker Edward Codd definerte grunnlaget, var Larry Ellison først med en relasjonsbase for Digitals datamaskiner. Samtidig jobbet professor Michael Stonebraker med en tilsvarende base for maskiner med Unix.

Stonebrakers Ingres var bedre teknisk, men Larry var en bedre selger enn Stonebraker. Informix overtok Stonebrakers neste prosjekt for håndtering av geografiske data. Dermed hadde relasjonsmodellen fått sitt første skudd for baugen.

Kombinasjonen av transaksjonsdata og geografisk data fikk Ellison til beskrive Informix som et skip som forsøkte å fly. Men det gikk ikke lang tid før Oracle kopierte teknologien. Binære objekter løste behovet for bilder, lyd og geografiske data. Siden ble det analysestrukturer. Nå er det XML-skjemaer som lagres. Nytt er evnen til å tolke innholdet.

Databasene har dermed skiftet karakter. De har blitt rigide. Ny funksjonalitet i forretningssystemene medfører vanskelige endringer i basemodellene.

Relasjonsdatabase R.I.P

Derfor mener Michael Stonebraker at relasjonsdatabasens dager er talte. Tabellene må snus nitti grader. Radene med data som danner det horisontale elementet i databasen må løses opp. Det gir raskere lesing. Ulempen er lenger tid for skriving.

Loddrette baser er ikke nytt. Siste er Google som bruker det aktivt i sin Bigtable. Først ute var Pick som var en kombinasjon av operativsystem og database, men Pick manglet markedsføring til tross for at det var tilpasset mange konkurrerende datamaskiner.

Siden har Sybase innsett at loddrette data er mer effektive for forretningsanalyse i sin Sybase IQ, siden data skrives bare en gang.

Fremtidens databaser bør vurdere kolonner med alle slags typer data. De som er nødvendige for forretningssystemer kombineres i virtuelle tabeller i kombinasjon med metadata som beskriver dataene.

Les om:

Enterprise