Rijtjes leren

“Zijn, worden, blijven, blijken, schijnen, heten, dunken en voorkomen.” “Der, dem, den en das.” Rijtjes leren. Iedereen kan waarschijnlijk nog wel zo’n rijtje, dat klassikaal opgedreund moest worden, uit zijn jeugd herinneren. Ook binnen de automatisering kennen we enkele rijtjes, zoals dat van de normaalvormen voor het ontwerpen van databases: “Eerste normaalvorm, tweede normaalvorm, derde normaalvorm, vierde normaalvorm en vijfde normaalvorm.” Maar hoe staat het eigenlijk met dit rijtje? Is er in de afgelopen jaren veel veranderd?

Deze normaalvormen hebben betrekking op het ontwerpen van de tabelstructuren van relationele databases. Met andere woorden, het zijn de eisen die we stellen aan tabelstructuren: welke kolom hoort in welke tabel? Hoe groter het aantal eisen ofwel normaalvormen waaraan een tabel voldoet, hoe beter het ontwerp is.

De eerste normaalvormen zijn aan het einde van de zestiger jaren gedefinieerd door Tedd Codd, de uitvinder van de relationele theorie, nu al meer dan dertig jaar geleden. In de daarop volgende jaren druppelden er nog enkele normaalvormen binnen. Maar de laatste, algemeen geaccepteerde dateert alweer van meer dan twintig jaar geleden. In al die jaren zijn er geen nieuwe normaalvormen bijgekomen.

De databases die we tegenwoordig ontwerpen, zien er natuurlijk wel anders uit dan die van twintig jaar geleden. Behalve dat ze qua aantal rijen en aantal tabellen veel groter zijn, stellen we ook geheel andere eisen aan onze databases. Enkele voorbeelden: 

Datawarehousing heeft ons bijvoorbeeld geleerd dat het erg nuttig kan zijn om oude gegevens niet meteen met nieuwe gegevens te overschrijven. We zien liever dat alle oude gegevens bewaard blijven voor historische analyses. Maar het modelleren van historie kan op vele manieren gebeuren, dus wat is nu de beste manier? We zouden dat moeten kunnen aangeven met een vuistregel, en die regel zouden we moeten kunnen verwoorden als een normaalvorm. 

Een ander voorbeeld betreft de hogere eisen die we tegenwoordig aan de flexibiliteit van een databaseontwerp stellen. Let wel, met flexibiliteit bedoelen we niet dat het ontwerp eenvoudig aan te passen is, maar dat als de informatiebehoeften van de gebruikers veranderen, het ontwerp ook voor de nieuwe wensen te gebruiken valt. Dus zonder dat ze aangepast moet worden! Een techniek om dat bijvoorbeeld te realiseren, is door primaire sleutels te kiezen waarin kunstmatig gecreëerde waarden voorkomen. Of met andere woorden, sleutels die betekenisloos zijn. Ook deze regel zouden we kunnen verwoorden als een normaalvorm.

Objectoriëntatie bracht ons onder andere het begrip overerving. Met behulp van overerving kunnen we expliciet aangeven dat er binnen een bepaalde verzameling zich een bepaalde deelverzameling bevindt, die de moeite waard is om te onderscheiden van de rest. Bijvoorbeeld, binnen de verzameling vervoersmechanismen identificeren we de deelverzameling fietsen. Door toepassing van overerving kunnen we hele boomstructuren identificeren van verzamelingen en deelverzamelingen. De vraag is echter wanneer we zo’n boomstructuur nu wel en wanneer niet correct opgezet hebben. Harde vuistregels treffen we nog niet aan in de literatuur. De concepten zijn er wel, maar hoe we ze moeten hanteren, dat weten we nog niet. 

We kunnen ons ook nog afvragen of we overerving wel binnen een database moeten toepassen, want soms botst dat met het principe van flexibiliteit. In ieder geval zijn normaalvormen nodig op dit gebied.

Er zijn nog meer voorbeelden te geven, waarmee aan te tonen is dat we twintig jaar stil hebben gestaan met ons rijtje normaalvormen. Dat in de statische Duitse taal de rijtjes niet zo snel veranderen, dat weten we. En daar is ook niets mis mee. Maar het is logisch dat in ons vakgebied, waar zoveel nog verandert, de rijtjes wel snel wijzigen en soms ook langer worden. Dus laten we proberen de rijtjes die we hebben wel bij te houden. Laten we na zoveel jaar eens proberen om een zesde, een zevende en een achtste normaalvorm te definiëren, want het is hoog tijd!