Ted Codd heeft weer gelijk

Lang, lang geleden, toen Java nog niet bestond, internet hooguit iemands droom was, Bill Gates nog niet zijn eerste miljoen had verdiend en het mainframe nog op aarde regeerde, was er een man die in zijn eentje de relationele theorie bedacht. Ted Codd, in die tijd onderzoeker bij IBM, was eind jaren zestig zijn tijd hiermee ver vooruit. Nu zijn bijna alle informatiesystemen voor gegevensopslag volledig afhankelijk van zijn theorie. Het was namelijk de grondslag voor de succesvolle databasetaal SQL.

In zijn eerste artikelen introduceerde hij de bouwstenen waarmee wij allemaal nu zo bekend zijn, zoals tabel, kolom en primaire sleutel. Daarnaast bedacht hij vele andere begrippen, waaronder 'data independence' ofwel gegevensonafhankelijkheid. Hiermee bedoelde Codd dat voor elke databaseserver die pretendeert de relationele theorie te ondersteunen, geldt dat de buitenwereld (lees de applicaties) tabellen en kolommen ziet, maar vrij is in het kiezen van een opslagstructuur. Hij voorzag toen al de voordelen van een scheiding tussen de werkelijke opslagstructuur en de logische presentatievorm.
Toch zijn jarenlang de leveranciers niet erg creatief geweest met het bedenken van speciale opslagstructuren. Er heeft altijd een hechte band bestaan tussen de manier waarop gegevens liggen opgeslagen en die waarop ze aan de applicaties gepresenteerd worden. Pas sinds enkele jaren stappen sommige leveranciers hiervan af, met alle voordelen van dien.
Databaseservers als Alterian, Nucleus en Sybase IQ bijvoorbeeld zijn aan de buitenkant gewone SQL-producten. Kijken we echter onder de motorkap, dan zien we iets anders; zij slaan hun gegevens kolomgeoriënteerd op. Anders geformuleerd, in plaats van dat ze per tabel een groot aantal records bestaande uit een beperkt aantal kolomwaarden opslaan, slaan ze alle waarden van één kolom gescheiden op. Zeker voor applicaties die eerder de gegevens kolomgeoriënteerd dan rijgeoriënteerd manipuleren levert dit een prestatieverbetering op; alleen de gevraagde kolomwaarden worden van schijf gehaald. Dit verbetert aanzienlijk de verwerkingssnelheid van de zware queries in datapakhuizen, want deze zijn erg kolomgeoriënteerd.
Een ander voorbeeld betreft de fameuze taal xml. Voor het opslaan van xml-documenten bieden diverse databaseleveranciers oplossingen. In Release 2 van Oracle9i is Oracle met een conceptueel elegante oplossing gekomen. De hiërarchische xml-documenten worden in 'geneste' tabellen opgeslagen. Genest betekent dat tabellen binnen tabellen worden opgeslagen. Hiermee is de hiërarchische structuur van een xml-document na te bootsen. Het grote voordeel hiervan is dat, als er bepaalde applicaties zijn die de xml-documenten ook hiërarchisch willen verwerken, dat ook kan. Omdat geneste tabellen zelf weer tabellen zijn, kunnen we er ook op de klassieke manier naar kijken: als platte tabellen. Dus ook hier een scheiding.
Datzelfde Oracle is nu ook in staat om enkele tabellen fysiek op te slaan als een multidimensionale kubus. De SQL-vragen die afgevuurd worden op de tabellen, worden onder de motorkap gewoonweg vertaald naar de kubus. Wederom: de buitenwereld ziet tabellen, maar onder de motorkap zien we een geheel andere structuur.
Eindelijk is het dus zover. Leveranciers hebben ontdekt wat de voordelen kunnen zijn van Codds gegevensonafhankelijkheid. Hopelijk blijven ze creatief, zodat er meer verschillende soorten opslagstructuren verschijnen waarmee bepaalde applicaties te versnellen zijn. De komst van vele opslagstructuren zal echter wel het fysieke databaseontwerp proces bemoeilijken. Welke opslagstructuur kies je nu voor welke tabel? Maar dat is een prijs die we allemaal graag betalen.
Codd heeft weer bewezen zijn tijd ver voor te zijn. Jammer dat hij al door zovelen vergeten is. < BR>
 
Rick F. van der Lans is onafhankelijk adviseur, een internationaal bekend spreker en auteur van diverse boeken, tevens gespecialiseerd in softwareontwikkeling, datawarehousing en internet.