Onze datamodellen zijn duurzamer te maken door consequent many-to-many-relaties te modelleren. Waarom maken we onze datamodellen dan niet bestand tegen alle veranderingen in de maatschappij?
Met de opkomst van relationele databases in de jaren tachtig, ontstond een behoefte om de complexe werkelijkheid in een (data-)model vast te leggen.
Grofweg waren er twee denkrichtingen:
- We modelleren de werkelijkheid zo veel mogelijk in entiteiten, relaties en attributen. Hiermee hanteren we het principe dat je de werkelijkheid eventjes kunt “platslaan” in een relationele structuur (tabellen, rijen, kolommen, primary keys, foreign keys).
- We modelleren de werkelijkheid op basis van constructies in natuurlijke taal, waarbij we een onderscheid maken tussen niet-lexicale objecten (“dingen” zoals een fiets, een varken, een bedrijf of een persoon) en lexicale objecten (een getal, een naam, een telefoonnummer et cetera).
Een methode als erm valt in de eerste categorie, terwijl een methode als niam tot de tweede categorie behoort.
Volgens de hoogleraar bij wie ik in 1991 ben afgestudeerd (Prof. R. Meersman), woedde er binnen Oracle destijds een hevige discussie of men in de Oracle Case-tools (Computer Aided Software Engineering: het automatiseren van het software-engineeringproces, een concept dat we tegenwoordig low-code noemen) de eerste of tweede denkrichting moest volgen. Oracle koos voor de eerste richting, vermoedelijk vanuit commercieel oogpunt. De tweede denkrichting was – waarschijnlijk door de afkomst van Prof. Nijssen, de grondlegger van niam – alleen in Nederland en België populair. Daarnaast vond men niam in de VS en Engeland te ingewikkeld…
Bij beide denkrichtingen was het overigens nog een flinke uitdaging om constraints/business rules goed te modelleren. (Ook daarvan hebben we anno 2023 nog veel last, maar daarover meer in een volgende blog.)
Binaire relaties
Er zijn sinds de jaren tachtig allerlei ontwikkelingen geweest in datamodellering, maar in eerste instantie waren relaties tussen entiteiten/objecten altijd binair. Zoals een relationele database in principe ook alleen binaire relaties toestaat (een foreign key verwijst naar één primary key). Ook waren attributen ‘atomair’. Dit betekent dat de waarde van een veld (de kruising van een rij en een kolom) in principe maar één waarde kan bevatten.
Voorbeelden? Een werknemer kan – op één moment in de tijd – voor één afdeling werken. Op dit achterhaalde idee is het klassieke emp- en dept-voorbeeld van Oracle gebaseerd. Of een persoon kan – op één moment in de tijd – één naam en één burgerlijke staat (vrijgezel, gehuwd, gescheiden, etc.) hebben. En een persoon heeft als geslacht man of vrouw, en dit verandert nooit.
Heel veel systemen die in de goede oude tijd zijn ontwikkeld, zijn gebaseerd op deze verouderde principes. Daar ondervinden we nog steeds last van, want de maatschappij is veel ingewikkelder geworden.
Flexibel
We leven nu in een tijd waarin alles open en flexibel is. Zo kan een persoon op hetzelfde moment voor meerdere afdelingen of meerdere bedrijven werken. En een persoon kan in de loop der tijd verschillende burgerlijke staten hebben, en het is de vraag of een persoon met meerdere nationaliteiten op één moment ook verschillende burgerlijke staten kan hebben (sommige burgerlijke staten worden in het ene land wél, en in het andere land niet erkend). Ook kan een persoon van geslacht veranderen, maar is op één moment in de tijd man, vrouw of binair.
In een datamodel betekent dit dat we attributen zoals geslacht en burgerlijke staat moeten ‘objectiveren’ tot een entiteit. En vervolgens een many-to-many-relatie tekenen van de entiteit ‘persoon’ naar de entiteit ‘geslacht’ of ‘burgerlijke staat’. Wanneer de many-to-many-relatie zelf weer eigenschappen heeft, maken we er in de meeste methodes een intersectie-entiteit van. Kun je me niet meer volgen? Ga dan een cursus volgen bij Transfer Solutions.
Stokoud
Het probleem is dat veel stokoude (erp- of maatwerk-)systemen niet kunnen omgaan met de nieuwe werkelijkheid. Veel systemen zijn gebaseerd op een datamodel dat twintig of dertig jaar geleden een goede afspiegeling was van de werkelijkheid op dát moment, maar kunnen niet omgaan met de werkelijkheid van 2023. Je merkt dit op allerlei manieren.
Nog meer voorbeelden. Het systeem van de fietsenmaker in mijn woonplaats gaat ervan uit dat er op één fysiek adres maar één persoon of gezin woont. Er is geen rekening gehouden met het concept ‘verhuizing’, en meerdere gezinnen op één adres lijkt ook niet te kunnen. Het systeem van een bekend landelijk it-blad kan er niet mee omgaan dat je als persoon bij verschillende bedrijven werkt. Gevolg: ik krijg alle (papieren) post twee keer. Niet echt duurzaam. Zelf heb ik vier verschillende relaties (medewerker, partner, klant, leverancier) met het bedrijf Pipple. Het is onmogelijk om dat goed in Afas vast te leggen.
Je zou kunnen stellen een professionele inrichting van master data management dergelijke problemen kan oplossen. Deze oplossing geldt echter alleen voor de hogere lagen van een data-architectuur. De problemen zijn vaak echter fundamenteel, de oorzaak is het verouderde datamodel van het bronsysteem. Dat ga je met bijvoorbeeld een datawarehouse niet oplossen.
Oproep
De oude datamodellen waren dus niet altijd duurzaam. Jij – gewaardeerde lezer – hebt vast ook diverse voorbeelden van systemen die te star zijn gemodelleerd. We gaan het verleden niet veranderen, met (bewuste) redundantie en het nodige pleisterwerk houden we ons stokoude systemen vast wel draaiend.
Ik hoop dat we nieuwe datamodellen wél duurzaam kunnen maken, zodat ze kunnen omgaan met alle maatschappelijke veranderingen die nog gaan komen. De oproep is daarom om vanaf nu de many-to-many-relatie meer aandacht te geven.
