Må arkivet bygges om?

Må arkivet bygges om?

Relasjonsdatabasen har regjert i 20 år. Nå blir det stadig vanskeligere å forsvare bruken.
Oracle avsluttet siste kvartal av finansåret 2005 med en vekst på 26 prosent. Resultatet kom på 1,02 milliarder dollar av en omsetning på 3,88 milliarder.

Det er tydeligvis ikke noe galt med databasekongen, men veksten kom først og fremst fra applikasjoner.

For enkle transaksjonsbehov er relasjonsdatabasen glimrende, for mer komplekse tar indeksene vel så stor plass som dataene. Grunnen er at data kan settes sammen i en uendelighet av nye konstellasjoner avhengig av formål.

Databasen har derfor blitt stadig mer kompleks, med stadig mer funksjonalitet, tilsvarende en utvikling av kontorsystemer, som Microsoft Office. Brukerne føler ikke de blir mer effektive med nye versjoner.

Fagfolk hevder derfor at databaseadministrasjon er i krise, fordi relasjonsmodellen bryter sammen under sin egen vekt når alle mulige arkiveringsbehov skal samles under én paraply.

At databaseadministrasjon er komplekst fikk alle Netcoms mobilkunder erfare i juni. Da klarte Siemens indiske eksperter å få Netcoms database til nærmest å sovne med den konsekvens at kundene ble avvist istedenfor å få kontakt.

Det er relasjonsmodellen som tar knekken på store databaser. Den ble opprinnelig utviklet for virksomhetenes transaksjonsbehov. Ideen var å beskrive alle sammenhenger mellom ansatte, kunder, leverandører, produkter, tjenester og økonomi.

Databasetilhengerne trodde at med en detaljert databasemodell trengtes det bare registreringsmoduler, litt beregning og rapportering for å få alle nødvendige svar. Fjerde generasjons programmering skulle fikse prosesseringsbehovene.

Et overordnet krav var at data bare skulle lagres én gang, for å unngå forskjellige versjoner og på grunn av kostbar lagringskapasitet.

Konsekvensen ble ekstra tabeller og normalisering. Tredje normalform var et minimum.

Relasjonsdatabasen har en nær tilknytning til ideen om én datamaskin. I store virksomheter ble det brukt én stormaskin, i mindre, én minimaskin. Sistnevnte har utviklet seg til en tjenestemaskin med Unix som maskinmiljø. IBMs DB2 er tuftet på stormaskin, Oracles database på Unix.

Ulempen er at ideen med én smuldret opp for 15 år siden. Da kom de mange små tjenestemaskinene, dedikert til hver sin oppgave. Noen ble også brukt for databaseoppgaver, eksempelvis med Microsoft SQL Server.

Tilsynelatende mye rimeligere, men ikke når det blir mange maskiner, slik at det krever mange fagfolk for administrasjon.

De seneste års konsolidering har medført nye utfordringer for databasen. Oracle har tatt utfordringen på strak arm, men 10g egner seg best for konsolidering av transaksjonsbehov. Til det er den overlegen.

Samling av alle former for data i en database ble opprinnelig latterliggjort av Oracles grunnlegger Larry Ellisson. I dag ønsker Oracle seg alt.

"Jeg har så mye data, men jeg får så lite informasjon", uttalte en administrerende direktør i Linjegods for nærmere 20 år siden. Siden da har datamengdene eksplodert.

Transaksjonsdataene betyr stadig mindre. De er viktige for å holde den operative virksomheten i gang, men er lite brukbare for beslutninger. Analyse kan imidlertid bidra ved hjelp av nye datasammenstillinger. Stjerneskjemaer er godt hjelpemiddel.

Det som trengs er sammenstilling av data fra en rekke forskjellige kilder. Da hjelper det ikke med én database. Grunnen er at andre typer data er dannet med applikasjoner som benytter andre former for arkivering. Post lagres ikke i databasetabeller med relasjoner.

Derfor kreves det nye datatjenester, tjenester som kan sammenstille data fra ulike typer arkiver. Alle ønsker seg avansert sammenkoblingsteknologi. XML istedenfor SQL vil spille en større rolle.

I tillegg vil kringkastning og avanserte søkemekanismer i datakildene få større betydning.

Den som kan skape effektive datasøk i kombinasjon med enkle databaser vil ha et fortrinn, for alle streber etter datamaskiner og tjenesteprogramvare med lavere pris. MySQL kan bli en vinner.