Relationele databases: het einde van een tijdperk?

Relationele databases waren zeer succesvol in het bieden van oplossingen die nauw aansloten bij de toenmalige problemen. De tijden zijn echter veranderd. Computergeheugen is niet langer een schaars goed en redundantie niet meer een gruwel. En deze tijd vraagt om het omgaan met ongestructureerde informatie. Relationele databases voldoen hierin nog maar ten dele.

Het einde van relationeel?
Zelden heeft een verhaal zoveel discussie opgeroepen als de bijdrage over relationele databases van Peter Teeuwen. De auteur ventileert daarin zijn ernstige twijfel of dergelijke databases nog wel een plaats verdienen in deze veranderde tijden. De lezers lopen hiertegen te hoop.

Zie ook:
https://www.computable.nl/relationeel

Als we om ons heen kijken en zien wat voor ontwikkelingen er gaande zijn, dan kan ik me niet aan de indruk onttrekken dat we opnieuw op een breukvlak staan in het it-tijdperk. De afgelopen decennia werden ongetwijfeld gedomineerd door de relationele systemen. Zij waren een goed antwoord op de vragen in de markt, namelijk transactieverwerkende systemen. De laatste paar jaren zien we dat andere systemen hun opwachting maken. Natuurlijk is transactieverwerking nog steeds heel belangrijk. Maar door nieuwe technieken zoals het inlezen van documenten en bewerkingen met ocr, of het steeds verder digitaal worden van de input aan de voordeur ( denk maar aan het aanleveren van documenten met behulp van e-mail ), ontstaat er een nieuw soort informatiesysteem; een dat veel meer gericht is op het verwerken van documenten en documentstromen, hetzij digitaal hetzij gedigitaliseerd.
Voor deze nieuwe trend van informatieverwerking lijkt de transactieverwerking in een relationele database niet het beste middel.

Voorkomen van redundantie

Het succes van de relationele database viel te verklaren uit het feit dat de oplossingen die geboden werden nauw aansloten bij de problemen die toentertijd golden. Computergeheugen was een schaars goed en redundantie een gruwel. Databasemanagementsystemen waren toen nog niet zo geavanceerd dat inconsistentie automatisch vermeden werd. Het was dus zaak om gegevens zo efficiënt mogelijk op te slaan, het liefst maar één keer, mede doordat met name in het begin nog veel met de hand werd ingevoerd (data entry). Wie herinnert zich niet de gruwel dat je naw-gegevens op drie verschillende manieren voorkwamen bij één organisatie en dat die deelsystemen daardoor keurig langs elkaar heen werkten, met alle gevolgen van dien?
De oplossing van deze beide problemen werd gevonden in het concept van normalisering van gegevens. Hierbij werden informatiebehoeften net zolang uit ‘elkaar geplozen’ tot er geen redundantie meer aanwezig was. Het resultaat was dan ook dat vrijwel alle gegevens maar één keer voorkwamen in de te vormen database. Op deze manier werd dus redundantie en inconsistentie van data voorkomen. Doordat alles maar één keer werd opgeslagen, kon aanzienlijk ruimte worden bespaard. Aangezien schijfcapaciteit duur was, was dat een niet te onderschatten pluspunt!
De informatie moest ook zoveel mogelijk gestructureerd zijn, omdat er allerlei combinaties van gegevens mogelijk moesten zijn. De term relationele database stond dus garant voor een consistente, economische, gestructureerde dataopslag.
Het succes van de relationele database was zo groot, dat veel mensen momenteel vergeten zijn welk doel het systeem diende en in welke situaties het een goede oplossing kan zijn. Veel it-ers, maar ook velen buiten dit vakgebied, denken bij een betrouwbaar en efficiënt systeem als opslagmedium direct aan een relationele database.
Maar is dat wel juist? Is het paradigma niet verschoven? Gaan we niet weer terug naar een systeem dat documenten verwerkt in plaats van transacties uitvoert? Zijn andere zaken niet minstens zo belangrijk, zoals: terugvindbaarheid, toegankelijkheid, prestaties, proceskoppelingen (workflow), onderhoudbaarheid van procesgegevens, enzovoort? En �s redundantie wel zo verkeerd? Is het verkeerd om twee feiten vast te leggen die gedeeltelijk dezelfde gegevens hebben, maar door hun onderlinge samenhang als feit uniek zijn? Hoe staat het dán met de kwaliteit die geleverd wordt door een relationele database?
En wat te denken van ontwikkelingen als kennismanagement, of het wereldwijd ontsluiten van informatie via het worlwide web? Wat voor oplossingen biedt een relationele database dan?

Kortere zoektijd

Doordat iedereen tegenwoordig informatie kan verzamelen via allerlei kanalen, wordt het ontsluiten van informatie steeds belangrijker. In tegenstelling tot de relationele opslagstructuur is deze informatie dan vaak ongestructureerd, bijvoorbeeld platte tekst (full text format) of tabellen met informatie.
Voor het ontsluiten van dit soort informatie is een relationeel systeem eigenlijk niet geschikt.
Er zal veel inspanning gedaan moeten worden om de samenhang tussen de gegevens te bewaren; hierbij werkt de techniek van normalisatie, het uiteenpluizen van gegevens eerder averechts. Niet alleen is de samenhang moeilijk te waarborgen, ook het opvragen van feiten is een moeizame zaak. Dit zit hem met name in het feit dat de gegevens opgesplitst zijn en met verwijzingen via ‘foreign keys’ aan elkaar gekoppeld zijn. Dit verhoogt namelijk de zoektijd immens. Een klein voorbeeld moge dit verduidelijken.
Stel je hebt een informatiesysteem met boeken, schrijvers en uitgevers. Een boek kan meerdere schrijvers en meerdere edities hebben en een schrijver kan meerdere boeken hebben geschreven. Ook kan een schrijver meerdere uitgevers hebben, en een uitgever meerdere schrijvers. Dat levert in een relationele database een tabel Boek, een tabel Schrijver, een tabel Uitgever, een relatietabel Boek/Schrijver, een relatietabel Uitgever/Schrijver.

Wanneer nu een ‘eenvoudige’ vraag beantwoord dient te worden als bijvoorbeeld:
Welke schrijvers zijn betrokken geweest bij dit boek en wie was de uitgever? Dan is dat bijvoorbeeld als volgt te realiseren.
Je begint bij Boek, daar haal je de boekgegevens op. Via Boek/Schrijver vind je de bijbehorende schrijvers. Je moet nog wel de gegevens van de schrijver ophalen uit de tabel Schrijver. Tenslotte kun je via de relatie Uitgever de bijbehorende uitgevergegevens vinden.
Voor zo’n eenvoudige vraag moeten in totaal dus vier tabellen worden geraadpleegd.
In een niet-relationeel systeem kan dezelfde informatie in één tabel worden gevat. Die zou er bijvoorbeeld kunnen uitzien als in figuur 1. Het zal duidelijk zijn dat met het tweede systeem de zoekvraag over het algemeen veel sneller te beantwoorden is.
Wanneer de vragen die gesteld worden minder structuur bevatten, wordt het voor een relationeel systeem des te moeilijker om de informatie binnen een acceptabele tijd te vinden en te tonen; áls de informatie al überhaupt te vinden is!

Samenhang

Ging het in de transactieverwerking om het opslaan van gegevens (data), heden ten dage gaat het meer om het opslaan van gehele documenten met hun gegevens en eventueel toegevoegde gegevens (metadata), en om de samenhang tussen deze gegevens.
De huidige techniek van het opslaan in een relationele database voldoet daar maar ten dele aan. Er zullen andere oplossingen moeten komen, die meer in staat zijn om met ongestructureerde informatie om te gaan. Deze manier van opslaan zal wellicht veel hiërarchischer van aard zijn, zoals in het bovenstaande voorbeeld.
Dit alles duidt erop dat we op de drempel staan van de zoveelste revolutie in de it-wereld. Wie had tien jaar geleden gedacht dat er wellicht een eind zou kunnen komen aan het tijdperk van de relationele databases?

Boek 1	Schrijver 1 Schrijver 2 Uitgever Naam boek Editie 1 Editie 2	Naam Naam Naam Toelichting Toelichting	Geb. datum Geb. datum NAW Aantal verkocht Aantal verkocht	NAW NAW
Boek 2	Schrijver 1 Schrijver 3 Naam boek Editie 1 Editie 2	Naam Naam Toelichting Toelichting	Geb. datum Geb. datum Aantal verkocht Aantal verkocht	NAW NAW