Tweeluik over het werk van William Kent: 1. Data and Reality (het waarom) · 2. Fact-Based Data Analysis and Design (het hoe, dit artikel).
“We start with one record per fact, rather than one record per entity.”William Kent, Fact-Based Data Analysis and Design, 1983
In Data and Reality liet Kent zien waarom een datamodel de werkelijkheid nooit helemaal vangt. Vijf jaar later gaf hij het praktische antwoord: begin niet bij de tabellen, maar bij de feiten, en laat het ontwerp zich daaruit afleiden. Dit is deel twee van het tweeluik: van de filosofie naar de methode.
In het kort
Eén record per feit, niet één record per ding
De meeste ontwerpmethodes beginnen bij de “belangrijke dingen” (de entiteiten) en hangen daar velden aan. Kent draait het om: noteer eerst de losse feiten die je wilt bijhouden, en voeg die daarna samen tot records. Het resultaat is hetzelfde soort database, maar de weg ernaartoe is eenvoudiger en objectiever.
En je krijgt nette tabellen cadeau
Omdat je opbouwt uit elementaire feiten in plaats van grote brokken achteraf op te knippen, komen de tabellen vanzelf in genormaliseerde vorm uit de methode rollen. Normaliseren als losse opschoonstap is dan niet meer nodig.
Het ongemak uit deel één, nu praktisch
Is “afdeling” een eigenschap van een werknemer, of een verband?
In deel één zagen we dat het onderscheid tussen een eigenschap (attribuut) en een verband (relatie) niet wezenlijk is. Kent wrijft het er in dit stuk nog eens in: “If you’re paying attention, you should be confused at this point. How did we decide that an employee’s department was a fact about the employee, rather than a fact connecting two things?… I don’t know the answer to that, and I don’t think anyone else can give you a really effective answer either” (Kent, Fact-Based Data Analysis and Design, 1983).
Het hoeft niet uit te maken
En dan komt de bevrijdende zin: “It doesn’t have to matter“. Je hoeft die knoop helemaal niet door te hakken. In plaats van eindeloos te bakkeleien of iets een attribuut of een relatie is, behandel je het gewoon allebei hetzelfde. Dat is het hele idee onder de methode.
Begin bij de feiten, niet bij de dingen
Behandel elk feit als een verband tussen dingen
Kents truc is om alles als een verband te zien: “We can avoid the question altogether by treating all facts as connections between things” (Kent, Fact-Based Data Analysis and Design, 1983). Een salaris? Beschouw dat bedrag als een ding, en “verdient” als het feit dat een werknemer aan dat bedrag koppelt. Een geboortedatum, een lengte, een afstand: stuk voor stuk dingen, met een feit dat ze aan iets anders verbindt. Eén soort bouwsteen voor alles, en de vraag “is dit een eigenschap of een relatie?” verdampt.
Een feit is een zin met een vaste vorm
In de praktijk noteer je je feiten als korte zinnen: “werknemers zijn toegewezen aan afdelingen”, “werknemers verdienen geld”, “afdelingen hebben een naam”. Bij elk feit hoort hoe vaak het mag voorkomen (één afdeling per werknemer, maar veel werknemers per afdeling). Meer heb je om te beginnen niet nodig. Vragen over identificatie en opslag schuif je bewust naar het eind.
De methode in een paar stappen
Van losse feiten naar tabellen
De kern van de methode is verrassend mechanisch:
- Schrijf de feiten op, als verbanden tussen dingen, met per feit hoe vaak het mag voorkomen.
- Geef elk feit een eigen mini-tabel (Kent noemt dat een “pseudo-record”): in eerste instantie krijgt elk feit zijn eigen regeltje.
- Bepaal de sleutel van elk mini-tabelletje: waar gaat dit feit eigenlijk over?
- Voeg samen wat dezelfde sleutel deelt: alle enkelvoudige feiten over hetzelfde ding (de naam, de afdeling, het salaris van een werknemer) klappen samen tot één record. Elk veel-op-veel-verband houdt zijn eigen record.
- Kies pas nu de representatie: welk nummer, welke code identificeert een ding? Dat beslis je laat, als je weet waar je het echt nodig hebt.
- Benoem de velden en de tabellen, en overweeg alternatieven.
Waarom dat beter werkt
Je hoeft vooraf niet te beslissen wat “belangrijk” is en wat “detail”, en niet of iets een entiteit of een subtype is. Je behandelt alles in één homogeen proces, en je mag zo vaak itereren als je wilt. Het model sluit zo aan op hoe de business de wereld ziet, niet op hoe de data toevallig gestructureerd raakt.
Normaalvormen krijg je cadeau
Opbouwen in plaats van opknippen
Veel methodes normaliseren als een opschoonstap achteraf: je maakt eerst lompe records en hakt die daarna in nette stukken. Kents aanpak is “synthetisch”: “We construct normalized records directly” (Kent, Fact-Based Data Analysis and Design, 1983). Omdat je vertrekt vanuit losse, elementaire feiten, zitten de tabellen al goed in elkaar. Kent stelt zelfs dat de uitkomst in de vijfde normaalvorm zit, en dus ook in de eerste vier. Wie de normaalvormen zelf wil doorgronden, leze zijn “A Simple Guide to Five Normal Forms” (1983).
Van Kent naar FCO-IM
Dezelfde gedachte, tot methode gerijpt
Wat Kent hier in 1983 schetst, is precies de kiem van de feitgeoriënteerde modellering zoals die later in Nederland volwassen werd: FCO-IM, voluit Fully Communication Oriented Information Modeling, in de familie van NIAM en ORM. Kent zegt het zelf bijna: hij weigert het onderscheid attribuut/relatie, behandelt alles als een feit, en leidt de tabellen daaruit af. FCO-IM maakt daar een strakke methode van.
Waar FCO-IM verder gaat
In FCO-IM bestaat het attribuut op conceptueel niveau helemaal niet: alles is een feit, een rol-relatie tussen objecttypen, en dat feit verwoord je eerst in gewone taal (“de werknemer met nummer 7 is toegewezen aan de afdeling Verkoop”). Uit die verwoorde feiten leidt een vast algoritme de tabellen af, net als Kents samenvoegstap, maar volledig uitgewerkt en met gereedschap eromheen. Kents “pseudo-records samenvoegen” en FCO-IM’s groeperen zijn in de kern dezelfde beweging. Niet toevallig erkent het Metamodel Informatiemodellering (MIM) deze hoek met een taalbinding naar Fact-Based Modeling.
Een rechte lijn van 1978 tot vandaag
Zo loopt er een rechte lijn: de filosofie van Data and Reality (1978), de methode van dit stuk (1983), en de werkende praktijk van FCO-IM, ORM en MIM (vandaag). Kent vat de verwantschap zelf bescheiden samen als convergentie met het entity-relationship-werk, de “irreducible relations” en de synthetische ontwerpscholen.
Wat het oplevert
Een conceptueel model als bijvangst
Omdat je je feiten formuleert in termen van begrippen en verbanden, bouw je en passant de kern van een conceptueel model op: een beschrijving van de business in haar eigen taal, los van de techniek. Datzelfde model documenteert meteen wat je gegevens betekenen.
En een eerlijke spiegel
Kent sluit af met een rake test: “If you have trouble organizing your requirements in the form of such facts, then either the application is not suitable for implementation in a database, or you do not adequately understand the application” (Kent, Fact-Based Data Analysis and Design, 1983). Lukt het je niet om je behoefte als heldere feiten op te schrijven, dan snap je de toepassing nog niet goed genoeg. De methode dwingt je dus tot begrip, en dat is misschien wel de grootste winst.
Vragen die vanzelf opkomen
Moet ik nu al mijn modellen omgooien?
Nee. Het is vooral een manier van denken: noteer eerst de feiten, beslis later over sleutels en opslag. Je kunt het op je volgende model loslaten zonder iets bestaands te slopen.
Is dit niet gewoon normaliseren met andere woorden?
Het verschil zit in de richting. Normaliseren knipt achteraf slechte tabellen op; deze methode bouwt vooraf goede tabellen op uit losse feiten. De uitkomst lijkt op elkaar, de route is omgekeerd en een stuk minder foutgevoelig.
Verder lezen op valorix.nl
- Data and Reality: waarom je database de werkelijkheid niet wordt, deel één van dit tweeluik.
- Je datamodel is geen data pipeline: scheid betekenis van techniek.
- Leen geen gegevens, leen een sleutel: het sleutelbospatroon.
Bron
William Kent, “Fact-Based Data Analysis and Design”, in Entity-Relationship Approach to Software Engineering (North-Holland, 1983); ook in Journal of Systems and Software 4(2,3), 1984, en als IBM Technical Report TR03.235 (1983). Online via bkent.net.