Vraag aan een zaal vol met automatiseerders of ze bekend zijn met het begrip normaliseren en minimaal de helft zal positief antwoorden. Vraag je vervolgens of iemand de definitie van één van de bijbehorende normaalvormen kent, dan zal er een pijnlijke stilte vallen.
In de gunstigste situatie gooit een enkeling er een prachtige volzin uit. De rest zal dan ademloos luisteren. Deze normaalvormen, die al vele jaren geleden bedacht zijn, vormen nog steeds de belangrijkste ontwerpregels die we tijdens gegevensmodellering hanteren. Eigenlijk staat de evolutie op dit gebied nagenoeg stil.
Normaalvormen zijn fundamentele ontwerpregels. We kunnen met deze regels bepalen of onze gegevens goed gestructureerd zijn. Kort samengevat, toepassing van alle bekende normaalvormen garandeert dat elk gegeven slechts één keer geregistreerd wordt. De meeste van deze regels zijn, ondanks hun hoge leeftijd, nog steeds relevant. De eerste drie normaalvormen zijn aan het einde van de jaren zestig ontworpen en de andere in een aansluitende periode van ongeveer vijftien jaar.
Die ontwerpregels pasten prima bij de toenmalige stand van de databasetechnologie, hardware, opslagtechnologie en bij het soort applicaties dat toen gemaakt werd: transactiegeoriënteerde systemen. Elk gegeven slechts één keer opslaan leidde tot een zuinig gebruik van de schaarse en dure technologie. Ook pasten diezelfde ontwerpregels goed bij de modelleringtechnieken die in die tijd gebruikt werden. Bijvoorbeeld, de concepten ofwel bouwstenen waaruit de oervorm van erm (‘entity-relationship modeling’) is opgebouwd, waren zeer technisch van aard. De ontwerpregels zijn ook nog steeds gedefinieerd in de terminologie van dit soort technieken. Bijvoorbeeld, termen als relatie (ofwel tabel) en attribuut (ofwel kolom) werden hierbij gebruikt.
Later realiseerde men zich dat er tijdens modellering beter met concepten gewerkt kan worden die dichter bij de belevingswereld van de gebruiker liggen. In de jaren tachtig ontstonden daardoor vele zogenaamde semantische modelleringtechnieken, zoals Niam (Nijssen’s Informatie Analyse Methode), Infomod, OMT (Object Modeling Technique) en UML (Unified Modeling Language). Steeds meer concepten, die we tegenwoordig als objectgeoriënteerd zouden aanduiden, werden toegevoegd. Men had het over entiteiten, klassen, objecten, attributen en variabelen. In sommige technieken, die pretendeerden nieuw te zijn, werden slechts de symbolen veranderd: geen rechthoeken maar cirkels. Alsof dat helpt!
Ook is er veel onderzoek uitgevoerd naar wat de beste manieren zijn om de informatiebehoeften uit de hoofden van de gebruikers te krijgen en te vertalen naar de modelleringconcepten. Sommige technieken, zoals Niam, orm (‘object-role modeling’) en fco-im (volledig communicatie-georiënteerde informatiemodellering), zochten de oplossing in de linguïstiek. Andere bedachten hiervoor formele stappenplannen: eerst doet u dit en vervolgens dat.
Ondanks al dit onderzoek en deze stortvloed van nieuwe modelleringtechnieken bleven de ontwerpregels onaangetast. Misschien dat namen als de ’tweede normaalvorm’ gecamoufleerd werden met chiquere namen, misschien dat de definities van de ontwerpregels aangepast werden zodat ze de namen van de nieuwe concepten gebruikten, maar wezenlijk anders was het niet. Natuurlijk moesten de definities wel vertaald worden naar de concepten en bouwstenen van die nieuwe technieken, maar de essentie bleef: elk gegeven slechts één keer registreren.
Vooral het ontwerpen van gegevenspakhuizen en de toenemende behoefte aan het ontwikkelen van flexibele databases hebben onze ogen geopend. De bestaande ontwerpregels zijn niet fout, maar ze zijn niet meer toereikend. Er zijn meer ontwerpregels nodig. Maar die zijn er niet.
Een flexibele gegevenstructuur impliceert niet dat een structuur makkelijk aan te passen is. Het betekent dat een verandering in de gegevensbehoeften opgevangen kan worden zonder dat de structuur aangepast hoeft te worden. Om dit te realiseren dienen bepaalde ontwerpregels gevolgd te worden. En dit zijn niet de bekende ontwerpregels van vroeger.
Ook voor het ontwerpen van gegevenspakhuizen is gebleken dat de bestaande ontwerpregels te kort schieten. Ze geven ons geen houvast wat betreft het correct modelleren van historie, het weergeven van snel wijzigende categorie-indelingen en het omgaan met kunstmatige sleutels. De klassieke ontwerpregels geven ons geen antwoord op wat we moeten doen en vertellen ons niet of wat we doen correct is.
Momenteel wordt het ‘class-diagram’ van UML gezien als de standaard techniek om gegevensbehoeften vast te leggen. Het is prima dat we één gestandaardiseerde techniek hebben, maar het is jammer dat dit het ‘class-diagram’ is, want al jaren geleden hebben we betere technieken gezien. In ieder geval, zelfs met de komst van UML zijn geen nieuwe ontwerpregels toegevoegd.
Helaas moeten we concluderen dat sinds de introductie van de normaalvormen, wat op zich een doorbraak was, de evolutie van ontwerpregels voor gegevensmodellering al die jaren stil heeft gestaan. We hebben ons gestort op nieuwe concepten, nieuwe notatietechnieken en nieuwe analysetechnieken, maar het belangrijkste, het definiëren van ontwerpregels die aangeven of de structuur goed is, hebben we verwaarloosd. We hebben eigenlijk om het meest essentiële heen gedraaid. Hopelijk staat er binnenkort weer iemand op om dit werk voort te zetten, want het is hard nodig.
Rick F. van der Lans is onafhankelijk adviseur, een internationaal bekend spreker en auteur van diverse boeken, tevens gespecialiseerd in softwareontwikkeling, datawarehousing en internet.
