Begin met Logisch databaseontwerp

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. Relationele databases: het einde van een tijdperk? Relationele databases: ook in 2003 Zoveelste einde van een tijdperk Begin met Logisch database ontwerp De voordelen van elementaire database management systemen Ongestructureerd opslaan Spelregels voor metadata moeten vastliggen Gebruik vooral relationele databases Stap vooruit op basis van relationeel Koester transacties Relationeel, maar zonder samenhang Spijtig voor Teeuwen Zie ook: http://www.computable.nl/relationeel

In het artikel 'Relationele databases: einde van een tijdperk?' (Computable, 13 december) trekt Peter Teeuwen een aantal vreemde conclusies doordat logische datamodellering en fysieke gegevensopslag met elkaar verward worden. Het is inderdaad zo dat computergeheugen minder schaars is, maar computers worden ook steeds sneller. De bewering echter dat prestatieproblemen te maken hebben met de logische datamodellering, getuigt niet echt van veel kennis van zaken. Prestatieproblemen dienen opgelost te worden op het niveau van de fysieke dataopslag. Dit kan door het aanmaken van extra indexen of het clusteren van gegevens. Dit laatste is het fysiek bij elkaar opslaan van gegevens uit gerelateerde tabellen. Dit heeft dan uiteindelijk het zelfde effect als de tabel in figuur 1 bij het artikel van Teeuwen.
Mocht dit niet voldoen, dan kan er ook gekozen worden voor een gedenormaliseerde gegevensopslag. (Ja, een relationele database kan ook niet-genormaliseerde gegevens opslaan!) Helaas ken ik nog geen databasemanagementsystemen die zo'n automatische denormalisatie van het logische databaseontwerp in de fysieke gegevensopslag ondersteunen met behoud van consistentie. Er zijn mij dan ook geen systemen bekend die 'zo geavanceerd (zijn) dat inconsistenties automatisch vermeden worden'. Om deze reden wordt er vaak weinig aandacht besteed aan de normalisatie van het logisch databaseontwerp, hetgeen tot veel fouten in de implementatie van informatiesystemen leidt. De praktijk van alle dag leert ook dat er nog genoeg grote instellingen zijn die klantgegevens meerdere malen in gescheiden systemen opslaan.

Logisch modelleren

Verder verkondigt het artikel de tegenwoordig veelgehoorde, maar helaas incorrecte mening dat het mogelijk is om ongestructueerde gegevens automatisch te verwerken. De meeste huidige relationele databasesystemen bieden al jaren de mogelijkheid voor het opslaan van 'binary large objects' (blob's). Hiermee zijn plaatjes, geluidsfragmenten en/of documenten op te slaan. Helaas is het dan niet mogelijk om op een eenvoudige manier een 'query' uit te voeren op de inhoud van deze blob's. Het is echter wel goed denkbaar dat er een index aangelegd kan worden van woorden die voorkomen in een text die als blob is opgeslagen. Een relationele database leent zich erg goed voor het aanleggen van zulke indexen. Het zou me niets verbazen als verschillende internet-zoekmachines gebaseerd zijn op relationele databases. Je kunt echter alleen iets met gegevens doen als de structuur en de semantiek van deze gegevens bekend zijn.
Het is inderdaad zo dat huidige implementaties van relationele databases niet echt goed zijn in het opslaan van gegevens met een complexe structuur in een enkele tabel en dat complexe data meestal weergegeven moeten worden in een verzameling van gerelateerde tabellen. (Iedere datastructuur kan afgebeeld worden op het logische relationele datamodel!)
Dit leidt ook vaak tot complexe 'queries'. Tegenwoordig wordt regelmatig gesuggereerd dat het gebruik van XML voor het opslaan van complexe data in een enkele tabel de oplossing is. Er is inmiddels al een aantal databases die dit ondersteunt.
XML beoogt data met zijn structuur als platte tekst weer te geven. Het biedt echter weinig mogelijkheden om data logisch te modelleren, het ondersteunt namelijk alleen de boomstructuur. (XML sucks!, maar dat is een ander verhaal.)
Het is inderdaad mogelijk om gegevens uit figuur 1 bij het artikel op te slaan in een tabel met twee kolommen: de naam van het boek en een XML-string met alle gegevens uit dat boek. Hiermee zijn dan snel alle gegevens van een boek te vinden. Als je dan echter wilt weten welke boeken een schrijver geschreven heeft, moet de volledige tabel doorgelezen worden en alle XML-strings gelezen en geanalyseerd worden. In een traditionele database zou voor deze vraagstelling maar één record via één index uit één tabel gelezen hoeven te worden.

Eerste stap

Bij het ontwerp van iedere database begin je altijd met het maken van een logisch datamodel waarin alle aspecten worden vastgelegd die automatisch bewerkt moeten kunnen worden. (Grote blokken ongestructureerde informatie die men niet door het systeem wil laten bewerken, zijn als een atomaire entiteit te beschouwen.) Pas dan kun je beginnen met het bepalen van de fysieke opslag van de gegevens. Daarbij moet vooral gekeken worden naar de frequentie en het soort bewerkingen en vraagstellingen die erop uitgevoerd moet worden. En pas dan valt te zeggen of gekozen moet worden voor een file-systeem, een traditionele relationele database, een objectgeorienteerde database, een 'rich-content' (XML) database of een combinatie van deze.
Het echte probleem is niet zozeer dat we een tekort hebben aan beschikbare technologieën (er zijn vele verschillende databasesystemen met even zoveel sterke en zwakke punten), maar dat er nog steeds geen goede tools bestaan om logische datamodellen af te beelden op fysieke gegevensopslagsystemen. Daardoor begint men vrijwel altijd met het inrichten van de fysieke databasestructuur en slaat men de stap van het logisch modelleren over. Het ultieme gevolg hiervan is dat er veel mensen zijn die het onderscheid tussen het logische en het fysieke niveau niet meer zien en denken dat normalisatie te maken heeft met de fysieke opslag van gegevens. Er bestaan geen goede afbeeldings-tools (van logisch naar fysiek), omdat dat niet in het belang is van databaseleveranciers. Daarmee zou de klantenbinding immers sterk verminderen.

 
Frans Faase Beugelhoek, Enschede