Norsk selskap bak revolusjonerende databaseteknologi

I ti år har Olaf Vethe tenkt ut hvordan en database kan konstrueres uten tabeller og indekser - og samtidig være både kompakt og rask. Teknologien hans, IceBreaker, omfatter 40 ulike patentkrav, og er endelig klar til lansering.

Jeg er blant dem som er vokst opp i en verden av tabeller, indekser, nøkler og relasjoner. Det Vethe snakker om, er noe helt nytt, blant annet fordi det går bakom tabellbegrepet. Vethe betrakter en tabell som en måte å presentere data på, ikke som en måte å lagre data på. IceBreaker handler om hvordan data organiseres i lagringsmediet - hvordan den vises har med applikasjonen å gjøre.

- Jeg kaller IceBreaker for en sentral kjerneteknologi, sier Vethe. - Den vises ikke på skjermen til sluttbrukeren. Den har med dataorganisering og styring å gjøre.

Vethe oppsummerer IceBreakers fremste egenskaper i fem punkter:

  • Alle søk foregår i minnet, uavhengig av databasens størrelse. Ytelsen på søk er følgelig ikke avhengig av aksesstider på lagringsmediet, men bare av hvor raske minne- og sentralenhetene er. En database på CD-ROM blir like rask som en database på disk.
  • Program og data er helt uavhengige av hverandre. De kan blant annet oppdateres og utvikles hver for seg, mens databasen kjøres og brukes.
  • Gamle feltverdier lagres fortløpende og automatisk. Ifølge Vethe gir dette en "uendelig rekke historikk i kronologisk rekkefølge". Denne egenskapen er ofte ettertraktet, for eksempel for å kartlegge utviklingen av et kundeforhold, men er svært krevende å kode i tabellbaserte databaser.
  • Metoden er skapt for å håndtere universelle datatyper i svært komplekse strukturer. Vethe mener han har svaret på alle de utfordringene leverandører som Oracle, Sybase og Informix strir med når de skal forene avanserte datatyper med sin eksisterende tabellstruktur. Metoden hans håndterer blant annet arv mellom objekter, innkapsling og polymorfi.
  • Det trengs ingen indekser. Disse erstattes av en søkestruktur med kun originaldata. Siden det ikke finnes indekser, finnes det heller ingen nøkler.

- SQL er ikke noe problem, sier Vethe. - Tvertom. Vi betrakter SQL som en av flere mulige tilgangsmetoder, ved siden av OODB, html og andre. Det er bare snakk om tilgang til IceBreakers programmeringsgrensesnitt (API). Kjernen i IceBreaker ligger under API-et. Det sluttbrukeren ser, det vil si programmet og brukergrensesnittet, ligger på nivået over tilgangsmetoden, altså over SQL, html eller andre metoder.

For å beskrive IceBreaker, gjør Vethe bruk av en spesiell terminologi. Det er han nødt til, siden han har erstattet ting som tabeller og poster, ikke med andre ord, men med helt andre begreper. En kort forklaring kan kanskje formidle det grunnleggende i det IceBreaker bygger på.

Det minste og grunnleggende elementet kaller Vethe atom. Det finnes tre former for atomer:

  • Et typeatom eller bare type svarer nærmest til begrepet felt i en tabelldatabase. En type har en intern struktur med blant annet typenavn (f.eks. navn, fødselsdato, id-nummer) og typeunderlag som forteller hvordan data av denne typen skal fremstilles i databasen, det vil si som tekst, dato, heltall osv.
  • Et innholdsatom inneholder en verdi, for eksempel en tekststreng eller et tall. Ingen verdi lagres mer enn én gang. En telefonkatalog organisert etter IceBreakers prinsipper vil bare inneholde ett eksemplar av strengen "Hansen Per" uansett hvor mange forskjellige mennesker det finnes med dette navnet i katalogens område.
  • et forekomstatom eller bare forekomst er bindeleddet mellom type og innhold. En forekomst forteller f.eks. at en bestemt streng forekommer som navn i databasen, eller at en bestemt dato forekommer som fødselsdato.

Forekomster kan knyttes sammen med pekere for å skape kjeder av ulike forekomster kalt indre relasjoner. En slik kjede har visse likhetstrekk med tabelldatabasenes begrep post. En forekomst der typen er "navn" og innholdet er "Hansen Per" kan knyttes til en annen forekomst der typen er "fødselsdag" og innholdet er "1. april 1950". I en indre relasjon kalles den første forekomsten for eier, de øvrige for medlemmer.

En indre relasjon kan inneholde en forekomst der typen er en peker og der innholdet er en verdi i en forekomst som opptrer i en annen indre relasjon. Den indre relasjonen som representerer personen Per Hansen (med forekomster som navn, personnummer, adresse, telefonnummer osv) kan utvides med en forekomst som forteller at Per Hansen har en datter, og at denne datteren finnes i databasen ved en indre relasjon som representerer personen Kari Nordmann. En slik relasjon etableres mellom en pekerforekomst i én indre relasjon og en eierforekomst i en annen, og kalles ytre relasjon. Ved utstrakt bruk av ytre relasjoner kan man representere svært kompliserte datastrukturer.

Dette er de grunnleggende begrepene i IceBreaker. Siden han begynte å arbeide systematisk med disse idéene for ti år siden, har Vethe utvidet dem fra skisse til demonstrerbare anvendelser. I denne prosessen har han forfinet en rekke prinsipper. Et eksempel kan nevnes - den gjelder representasjonen av amerikanske Social Security Numbers, altså det nisifrede tallet som brukes i det amerikanske trygdevesenet for å entydig identifisere medlemmene. Normalt ville et nisifret tall kreve et datagrunnlag på en milliard tall. Vethe deler i stedet tallstrengen i tre tresifrede strenger. I stedet for én forekomst med en milliard mulige verdier, får han tre forekomster som hver peker en gang mot en verdi i den samme mengden av ett tusen mulige verdier. Denne teknikken kalles datasplitting.

En viktig fordel ved datasplitting er at søking foregår i minnet. Skal du hente opp en person som svarer til et bestemt nisifret tall, foretas tre søk på en datamengde på 1000 tall, og du får opp pekere til indre relasjoner der de ønskede tallene opptrer som henholdsvis første, andre og tredje tallgruppe. Den pekeren som opptrer i alle tre grupper, viser den personen du søker etter.

- Mangelen på indekser betyr at det blir langt lettere å administrere databasen, sier Vethe.

- At data bare lagres én gang, minsker lagringsbehovet drastisk. At universelle datatyper og all slags strukturer kan representeres, gjør at IceBreaker er forberedt på vår tids databaseoppgaver. Lagringsbehovet blir mindre, responstiden reduseres, trafikken over nettet minskes, og alt dette fører til billigere drift og eierskap.

Til toppen