Modelleerpatronen (1): Primitieven in tijd en ruimte

 
13 maart 2011

Modellering is een moeilijk vak. Aangezien ik er vaak met diverse mensen over discussieer en tevens ook wel de nodige ervaring mee heb deel ik via deze weg een aantal praktisch toepasbare patronen die ik heb gevonden de afgelopen jaren. Tevens biedt dit een mooi medium om hierover in bredere context door te discussiëren natuurlijk :).

Titel: Privitieven in tijd en ruimte

Doel: Expliciteren van je model, beter aansluiten op de werkelijkheid

Motivatie: Bij modelleren wordt erg vaak gegrepen naar abstracte / administratieve termen. Denk aan ‘factuur’, ‘bon’, ‘opdracht’, ‘tijdregistratie’. Veel van deze termen zijn terug te voeren op een meer natuurlijk passend concept zoals tijd en ruimte. Locaties zijn bijvoorbeeld formeel veel duidelijker vast te leggen als een primitief type van twee getallen die een geografische locatie aanduiden dan een meer ‘fuzzy’ concept als een Adres. Daarnaast kunnen adressen wisselen van opmaak, denk aan hernummering van postcodes, huisnummeringen of plaatsnamen. Met een volgens standaarden gedefinieerd concept als ‘locatie’ in je model kan je daar ook veel makkelijker zonder veel translaties van het ene naar het andere locatiestelsel views op definiëren (denk aan het kleuren van kaarten in GIS systemen).

Toepasbaarheid: Abstracte concepten die raken aan concrete primitieven, zoals locatie en tijdstip/datum (die laatste wordt vaak al automatisch ‘goed’ gedaan), maar denk ook aan meer volwassen en generieke standaarden als Burger Servicenummer bij personen en KvK nummer bij bedrijven. Daarnaast kunnen er heel goed primitieven zijn per branche, denk bijvoorbeeld aan bankrekeningnummers.

Voorbeeld van een model voor het toepassen van dit patroon:
primitivesbefore

Als hier een standaard genormaliseerd datamodel onder gelegd wordt betekent dit ofwel verlies van infomratie bij het verhuizen van een klant, ofwel veel dubbelingen van adresgegevens in de databases (elke order moet zijn eigen associatie of kopie krijgen naar het adres).

Voorbeeld van toepassing van dit patroon op de diverse associaties:
primitivesapplied

In het bovenstaande plaatje zien we dat we tijd en locatie heel expliciet hebben meegenomen in de modellering. Dit betekent dat met met name locatie een eigen ‘natural key’ wordt en dat we desnoods de fysieke coördinaten kunnen meenemen in diverse andere entiteiten.


Werken met ?
Kijk dan bij onze mogelijkheden voor zowel starters als ervaren engineers.


Categorieën: Development


Reacties (10)

  • Matthijs Mast schreef:

    Andre,

    Al eens nagedacht om dit in MCASO te verwerken?

    Geplaatst op 22 maart 2011 om 8:52 Permalink

    • Matthijs,

      Zeker, dit gaat wel een onderwerp worden voor een meer geavanceerde training. We houden je op de hoogte :).

      Geplaatst op 18 juli 2011 om 21:21 Permalink

  • @peter: kort samengevat is mijn stelling eigenlijk precies wat je omschrijft, echter we zijn het niet eens over de betekenis van het woord ‘essentie’. Jij beschouwt dat in context van je te automatiseren systeem, terwijl ik juist zeg dat je de essentie daarachter zou moeten zoeken. Automatisering is slechts een hulpmiddel om iets handiger te doen en te bereiken en bevat in zichzelf dus in mijn optiek geen essentiële egenschappen maar moet die juist uit de werkelijkheid meenemen. Anders dreigt het gevaar dat je abstracties gaat introduceren zodat systemen ineens eigen definities gaan bevatten zoals ‘bon’ of ‘regel’, terwijl het om transportbewegingen of aankopen ging. Dit werkt extreem verwarrend, niet zozeer bij greenfield automatisering maar juist bij uitbouw of herbouw, waarbij de essentie ineens in abstracties van een eerder systeem overgedragen wordt.

    Adres is misschien niet het beste voorbeeld: een set gegevens als postcode, straatnaam, huisnummer en plaatsnaam kan ook als primitieve data behandeld worden. Het is echter een inconsistente abstractie van de werkelijkheid om een coördinaat op de wereld aan te duiden, vandaar dat ik dit voorbeeld gebruikte. Overigens is het geenszins lastig om van coördinaten naar adressen te converteren, tik maar eens in in http://maps.google.com : 52.102626,5.175734

    Mijn stelregel blijft echter: zoveel mogelijk bij de werkelijkheid blijven, ook al is dat in eerste instantie voor jouw systeem niet direct relevant. Het wordt namelijk altijd wel relevant. Uitzonderingen daarop heb ik nog niet gezien.

    Geplaatst op 20 maart 2011 om 14:32 Permalink

  • matthijs schreef:

    Komt ineens bij mij de volgende stelling op:

    De mate waarin het nuttig is om terug te voeren op primitieve hangt af van de moeilijkheid van de conversie tussen die primitieven en de abstracte begrippen waar de domeinexpert mee te maken heeft.

    In het voorbeeld van de bibliotheek app is het een vrij “lastig” conversietraject van GPS coordinaten naar een adres. In het geval van datum en leeftijd is het zeer winstgevend om datum in plaats van leeftijd te gebruiken.

    Geplaatst op 15 maart 2011 om 7:21 Permalink

  • Peter schreef:

    Nadenken over de essentie van je data is zeker een goed idee, helemaal mee eens!

    Ik denk echter dat de essentie altijd afhankelijk is van de context, en niet zozeer van de (veel grotere) werkelijkheid. De essentie van het adres in de bibliotheek-applicatie (en veel andere systemen) lijkt me dat je klanten wil kunnen bereiken.

    De leeftijd is een interessant voorbeeld. Hier is de essentie de leeftijd zelf, niet de geboortedatum. Toch zou het hier beter zijn om de geboortedatum vast te leggen. We weten dat iemands leeftijd volgens een vast patroon verandert, en dat de “sleutel” tot iemands leeftijd op ieder moment de geboortedatum is. Hier maak je dus handig gebruik van extra kennis die je over de essentiële data zelf (de leeftijd) weet.

    Soms kan extra kennis heel handig zijn om een datamodel robuuster of flexibeler te maken, maar de essentie komt volgens mij altijd vanuit de context van het systeem.

    Geplaatst op 14 maart 2011 om 18:45 Permalink

  • Interessante discussie. Wat ik juist probeer te zeggen is dat je moet doordenken naar de essentie van dingen, en dat het uitkleden van concepten totdat je een fysieke grens tegenkomt daarvoor erg nuttig kan zijn. Het is niet per definitie van toepassing, maar ik denk wel dat je juist zoveel mogelijk in je model terug moet gaan naar de essentie – en dus de werkelijkheid. Zodra je in je kernmodel al mappings gaat maken naar abstracties wordt het al snel heel verwarrend.

    Dit heeft overigens niets met de gebruikersinterface te maken. Die vertaalt de essentiele modelprimitieven uiteraard naar voor de gebruiker relevante concepten, zoals inderdaad een adres of een stip op een kaart. Juist door die vertaling eenduidig een plaats te geven kan je ook ineens heel veel verschillende views op hetzelfde concept aan terwijl de kern ondubbelzinnig vastligt.

    Laat ik een ander voorbeeld geven: als je in een applicatie in eerste instantie slechts geïnteresseerd bent in de leeftijd van een persoon, leg je die dan vast in je model of toch de geboortedatum?

    Geplaatst op 14 maart 2011 om 17:31 Permalink

  • Peter schreef:

    Ik denk dat Matthijs gelijk heeft. Theoretisch is het zoeken naar “primitieven” interessant, maar in de praktijk wil je gegevens modelleren op een niveau dat niet zozeer aansluit bij de werkelijkheid maar bij de directe context van een systeem.

    In de meeste software is een adres niet zozeer een locatie, maar (heel pragmatisch bekeken!) niets meer dan een manier om een persoon/klant te kunnen benaderen. De fysieke locatie valt in die gevallen buiten de relevante context.

    Geplaatst op 14 maart 2011 om 15:49 Permalink

  • Matthijs schreef:

    Jan Martijn,

    Dat ben ik met je eens. Echter denk ik dat het feit of een dergelijke oplossing handig is grotendeels afhangt van het programma dat je wilt schrijven.
    Als er bijvoorbeeld een bibliotheek app geschreven moet worden die alleen bijhoud welke boeken er in de bibliotheek aanwezig zijn en kijkt welke klant welke boeken heeft. Misschien wil de bibliotheek af en toe de klant een brief sturen als deze zijn of haar boek nog niet teruggebracht heeft. In dat geval is een adres voldoende en lijkt een GPS systeem (oid) mij enigszins overkill.

    Geplaatst op 14 maart 2011 om 11:02 Permalink

  • Jan Martijn schreef:

    Het voordeel van de locatie laag er tussen te stoppen is dat je informatie makkelijker kan afleiden van een locatie dan van een adres. Een locatie zegt gewoon meer dan een adres. Je kan bijvoorbeeld sneller afleiden welk land je zit en of het daar dag/nacht is.

    Er zitten natuurlijk wel wat problemen tussen de relatie adres en locatie. Maar het zal minder veranderen dan Customer – Adres. Ook is het invullen van locatie gegevens lastiger dan adres gegevens, maar dat kan dan wel weer op een slimme manier geautomatiseerd worden. Denk aan op een kaart klikken, afleiden van adres, gps systeem koppelen.

    Geplaatst op 14 maart 2011 om 10:47 Permalink

  • Matthijs Mast schreef:

    Andre,
    Worden deze natural keys ook ingevuld door gebruikers (mensen die, de order in dit geval, invoeren of mensen van bijvoorbeeld een bibliotheek die een nieuwe klant invoeren)?
    In dit geval lijkt het gebruik van gps coordinaten mij enigszins overkill.
    Deze mensen hebben immers altijd een adres nodig omdat het nederlandse postsysteem hier mee werkt. Als een klant verhuist betekent het trouwens ook dat de gps coordinaten wijzigen dus waarom niet gewoon het adres invullen?

    Geplaatst op 14 maart 2011 om 7:55 Permalink