Teken de relaties
Ook beschikbaar in 28 talen
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Module 2 van 6 in het hoofdstuk Data modelleren naar betekenis, hoofdstuk 2 van de cursus Data Architect. Elke module staat op zichzelf. Vorige: Luister naar de zelfstandige naamwoorden · Volgende: Bouw het logische model
De vraag die deze module beantwoordt: Hoe maak ik van kandidaat-entiteiten een conceptueel datamodel?
We hebben zelfstandige naamwoorden op het bord. Nu wil ik iets weten over de lijnen tussen de vakjes, want een verzameling entiteiten is nog niet echt een datamodel. In de relaties zit veel van de betekenis. Een retailpartner heeft distributiecentra. Een vrachtlijst somt leveringen op. Een levering gaat naar een ontvanger. Een ploeg rijdt een vrachtwagen. Elk van die uitspraken vertelt me iets over het bedrijf, en elk geeft me nog een vraag om te stellen.
Begin met de taal van de business
Section titled “Begin met de taal van de business ”Ik wil het nog steeds niet over Salesforce hebben. Ik vraag niet of dit een opzoekrelatie of een hoofd-detailrelatie moet worden, denk niet na over Salesforce-koppelobjecten, en beslis niet wat er gebeurt als een parentrecord wordt verwijderd. Ik probeer de bedrijfsrelatie te begrijpen.
Neem “een retailpartner heeft distributiecentra.” Het klinkt eenvoudig. Maar kan een retailpartner één DC hebben of veel? Bij Steve Trucking heeft elke retailpartner een regionaal distributiecentrum in elke regio die Steve Trucking bedient, dus veel. Kan een DC bij meer dan één retailpartner horen? Doet een DC er op zichzelf toe, met eigen personeel en historie, of is het gewoon een adres? Als een retailpartner vertrekt, geven we dan nog om zijn DC’s?
Dat zijn geen Salesforce-vragen. Het zijn bedrijfsvragen, en de antwoorden kunnen het model volledig veranderen.
Lees de lijnen
Section titled “Lees de lijnen ”Voordat we dieper gaan, wil ik je de taal geven die we vanaf nu op elk diagram gebruiken. Het is een kleine taal. Een lijn tussen twee blokken zegt dat de twee dingen gerelateerd zijn, en de markeringen aan de uiteinden zeggen hoeveel.
Begin met een gewone lijn, zonder markeringen. Daar begin ik op het whiteboard: ik weet dat deze twee zelfstandige naamwoorden gerelateerd zijn, ik heb alleen nog niet gevraagd hoe. Dan krijgen de uiteinden markeringen. Eén streepje dwars op de lijn betekent één. De kraaienpoot, het uiteinde dat zich als een vogelpoot in drieën splitst, betekent veel. Verderop in deze module zie je een tweede markering naast de eerste verschijnen, een streepje of een rondje, en die beantwoordt een andere vraag: kan het er geen zijn?
De ene regel om te onthouden: je leest elke markering bij het blok dat ze raakt. De markering het dichtst bij het blok is het maximum; de markering daarbuiten is het minimum.
Zit, Blijf, Modelleer
Section titled “Zit, Blijf, Modelleer ”Vóór Steve Trucking eerst terug naar de honden uit module 1. We hadden vijf vakjes: Eigenaar, Fokker, Hond, Ras en Kunstje. Nu vraag ik naar de lijnen ertussen.
Eén of veel? Een eigenaar kan meer dan één hond hebben; Ana heeft er twee. Een hond heeft één eigenaar, in ons model tenminste. Dat is een-op-veel: een streepje bij de Eigenaar, een kraaienpoot bij de Hond. De fokker heeft dezelfde vorm: één fokker fokt veel honden.
Kan er geen zijn? Max kwam uit het asiel, dus hij heeft helemaal geen fokker. Het uiteinde bij de Fokker krijgt een cirkeltje: een hond heeft nul of één fokker. Elke hond heeft wel een eigenaar, dus dat uiteinde krijgt een tweede streepje: precies één.
Veel-op-veel? Een hond kent veel kunstjes, en een kunstje, zeg Zit, wordt door veel honden gekend. Dat is veel-op-veel, en precies daar ga ik zoeken naar een verborgen concept. Is er iets over deze hond die dit kunstje kent? Hoe goed ze het doet, en wanneer ze het leerde. De relatie heeft eigen feiten, dus ze wordt een eigen ding: Hondkunstje, met de hond voorop, omdat de hond het stuurt.
Wat betekent elke lijn? Een eigenaar bezit een hond. Een fokker fokt hem. Een hond kent zijn kunstjes. Geef de lijnen een naam, en iedereen kan het model aan je teruglezen.
Nu, of over tijd? Geeft iemand erom hoe goed Bella vandaag is in Zit, of hoe ze daar kwam? Als een trainer haar om de paar maanden test, is elke test een eigen record: een Kunstjebeoordeling, met de datum, het niveau en wie de test deed, onder het Hondkunstje waar ze bij hoort. Zelfs een relatie die een ding werd, kan een eigen historie hebben.
Ras laat ik voorlopig los staan. Het is nog steeds de vraag uit module 1: een eigen vakje of een woord op de hond. Module 4 beslecht het.
Elk van die vragen werkt op dezelfde manier bij een echt bedrijf. Laten we ze nu aan Steve Trucking stellen.
Vraag: “één of veel?”
Section titled “Vraag: “één of veel?” ”Een van de eerste dingen die ik over een relatie wil begrijpen, is de kardinaliteit. Dat is de databaseterm; de vraag is veel eenvoudiger: hoeveel van deze kunnen gerelateerd zijn aan hoeveel van die? Op conceptueel niveau zijn er drie basispatronen.
Dit is een belangrijke stap in het proces: neem twee verschillende zelfstandige naamwoorden en begrijp hun relatie. In de meeste situaties is het een-op-veel, of veel-op-een. Alleen in zeldzame gevallen kom je een een-op-een tegen.
Een-op-veel is overal. Eén retailpartner heeft veel distributiecentra. Eén vrachtlijst bevat veel leveringen. Eén route heeft ongeveer tien stops. Als ik zo’n taal hoor, begin ik de lijn te tekenen.
En nu krijgt de lijn haar markeringen. Elk uiteinde vertelt je hoeveel van het blok dat het raakt: het streepje voor één, de kraaienpoot voor veel. Lees het vanuit elk blok: één retailpartner heeft veel distributiecentra.
Een-op-een-relaties bestaan, maar ze zijn zeldzaam, en als ik er een vind, stel ik een paar vragen. Zijn dit echt twee verschillende zelfstandige naamwoorden, of hetzelfde? Als ze verschillen, wat is dan de een-op-een-relatie tussen hen? En blijft het altijd een-op-een, of is het alleen op dit moment een-op-een? Dat zijn belangrijke vragen bij het ontwerpen van het datamodel. Een ploeg en een vrachtwagen lijken op elke willekeurige ochtend een-op-een: twee mensen, één vrachtwagen, één route. Over een maand zijn ze dat niet, en daar verstopt zich de interessantste relatie in dit model.
Veel-op-veel-relaties zijn extra interessant, omdat ze ons vaak vertellen dat er nog een concept in de business zit. Kan een ploeg in de loop van de tijd op meer dan één vrachtwagen rijden? Ja. Kan een vrachtwagen door meer dan één ploeg gereden worden? Over zijn levensduur zeker. Ploegen en vrachtwagens hebben dus een veel-op-veel-relatie. Maar nu wil ik meer weten. Geeft de business erom wanneer een ploeg een vrachtwagen had? Voor welke route, op welke dag? Wie heeft de toewijzing gedaan? Als de relatie zelf informatie bevat waar we om geven, hebben we een ander bedrijfsconcept ontdekt: de ploegtoewijzing.
Dat is een belangrijke modelleergewoonte. Soms is het interessantste niet een van de zelfstandige naamwoorden die we eerst hoorden. Het verstopt zich in de relatie tussen twee zelfstandige naamwoorden.
Relaties kunnen dingen worden
Section titled “Relaties kunnen dingen worden ”Dit is een van de plekken waar ik wil dat admins anders gaan denken. In Salesforce zijn we gewend te praten over objecten en velden, dus het is makkelijk de blokken als het belangrijke deel te zien en de lijnen als leidingwerk. Maar de relatie zelf kan betekenis voor de business hebben.
Neem een levering en de producten erop. Een levering kan meerdere producten bevatten, een wasmachine en een droger bijvoorbeeld. Een product, hetzelfde koelkastmodel, komt op duizenden leveringen voor. Makkelijk genoeg. Maar wat als ik moet weten hoeveel van dat product op deze levering staan, of het geïnstalleerd wordt, of dat het oude exemplaar wordt afgevoerd? Dan interesseert me niet alleen meer een relatie tussen Levering en Product. Dan interesseert me een leveringsitem, en dat concept verdient een eigen entiteit.
Als je uit Salesforce komt, denk je misschien al: “Dat is een koppelobject.” Je hebt geen ongelijk. Maar ik wil daar niet beginnen. Een leveringsitem is een bedrijfsconcept voordat het een Salesforce-koppelobject (Salesforce Junction Object) is. Eerst de business, dan de implementatie.
Een paar gewoonten van mij voor deze relatie-entiteiten, waar ze uiteindelijk ook gebouwd worden.
Geef het een naam. Als de business er al een woord voor heeft, gebruik het hare. Zo niet, neem dan de namen van de twee parents en zet ze samen. Denk aan een order en een product. Het ding ertussen is de orderregel (Order Item): de order, en het artikel op de order. Het is een child van beide parents, en in Salesforce wordt het misschien een Salesforce-koppelobject. Maar welke naam komt eerst: Item Order of Order Item? Kijk naar wat voor soort data elke parent is. Het product is referentiedata; de order is transactioneel, en het is de order die het aanstuurt. Dus wordt het Order Item, of Order Product, net zoals Salesforce Opportunity Product heeft. Bij Steve Trucking is het het leveringsitem (Delivery Item). De sturende naam komt eerst, en het record staat in elke lijst die je ooit bekijkt naast zijn eigenaar.
Geef het een eigen sleutel. Het is verleidelijk om te zeggen dat een leveringsitem wordt geïdentificeerd door Levering plus Product, en het daarbij te laten. Dat is een samengestelde sleutel, en samengestelde sleutels zijn veel lastiger: elk systeem dat naar het record verwijst moet beide helften meedragen. Geef de relatie-entiteit een eigen identificator, en houd Levering plus Product als regel over uniciteit, niet als identiteit.
Kijk wat er niet op staat: een serienummer. Een aantal en een serienummer horen niet op hetzelfde record. Een aantal telt meerdere exemplaren van iets; een serienummer identificeert één specifiek exemplaar. Als de business serienummers nodig heeft, wordt elk exemplaar een eigen record, en vijf koelkasten zijn vijf records. Ik zie geen reden voor een leveringsitem met een leveringsitemdetail eronder. Het is het een of het ander: een totaal met een aantal, of één record per exemplaar. Hier is het het aantal.
Let op attributen die historie willen. Sommige relatie-entiteiten liggen vast zodra ze zijn aangemaakt: de wasmachine op deze levering blijft de wasmachine op deze levering. Andere blijven veranderen. Een ploeg heeft deze week vrachtwagen 117, en volgende week gaat die vrachtwagen naar een andere ploeg. Als de relatie verandert en de business geeft om hoe ze vroeger was, heeft de relatie-entiteit datums nodig, en de ploegtoewijzing is degene om in de gaten te houden. Vraag vroeg of de business geeft om nu of om door de tijd heen; daar komen we zo op terug.
Relaties hebben meer betekenis dan kardinaliteit
Section titled “Relaties hebben meer betekenis dan kardinaliteit ”“Een-op-veel” is niet genoeg om een relatie te begrijpen. Ik wil ook weten wat de relatie betekent.
Een levering heeft een locatie. Welke? Het distributiecentrum waar ze vertrekt? Het huis van de ontvanger waar ze heen gaat? Die zijn niet uitwisselbaar. Twee modellen kunnen precies dezelfde blokken en dezelfde kardinaliteit hebben, en de lijnen kunnen toch iets totaal anders betekenen. Daarom is een goed model niet alleen blokken verbonden door lijnen. De lijnen hebben namen nodig. Als ik een andere architect mijn diagram geef, moet die niet hoeven raden wat een relatie betekent, en als ik het aan de business laat zien, moet het taal gebruiken die zij herkennen.
Optionaliteit doet er ook toe
Section titled “Optionaliteit doet er ook toe ”Er zit nog een vraag verstopt in “hoeveel?”: is de relatie verplicht? Kan een levering bestaan voordat ze op een route is gezet? Dat moet: de vrachtlijst komt een of twee dagen voor de levering binnen, en routes worden de avond ervoor definitief gemaakt. Kan een levering bestaan zonder retailpartner? Nee; elke levering komt van de vrachtlijst van een partner. Dat is optionaliteit.
Spring ook hier niet meteen naar een Salesforce-vinkje Verplicht. Er is verschil tussen zeggen “elke levering moet een retailpartner hebben” en zeggen “Salesforce moet het veld Retailpartner verplicht stellen als het record wordt aangemaakt”. Misschien worden ze dezelfde implementatie, maar het is niet dezelfde uitspraak. De eerste is een bedrijfsregel; de tweede is één manier om die af te dwingen. Als architecten willen we de eerste begrijpen voordat we de tweede beslissen.
Op het diagram is optionaliteit de tweede markering aan elk uiteinde. De markering het dichtst bij het blok is het maximum: het streepje voor één, de kraaienpoot voor veel. De markering daarbuiten is het minimum: nog een streepje betekent minstens één, een rondje betekent dat het nul kan zijn. Elke levering staat dus op precies één vrachtlijst, en een vrachtlijst bevat één of meer leveringen. Een levering hoort bij nul of één stop, geen zolang ze nog niet op een route staat, en bij een stop worden nul of meer leveringen afgeleverd.
De tijd verandert relaties
Section titled “De tijd verandert relaties ”Dit is een vraag die ik vaak stel: bedoel je nu, of bedoel je door de tijd heen?
Een ploeg rijdt op een vrachtwagen. Nu? Voor de route van vandaag? Zolang die twee mensen samenwerken? Dat levert verschillende modellen op. Als de business alleen geeft om welke vrachtwagen een ploeg vandaag heeft, kan het model eenvoudig blijven. Als ze elke vrachtwagen moet kennen waarop een ploeg reed, wanneer en op welke route, hebben we historie nodig, en dan wordt die ploegtoewijzing die we ontdekten ineens heel belangrijk.
Dit is een veelvoorkomende bron van modelleerfouten. We modelleren de huidige toestand omdat we die op het scherm kunnen zien. Dan, weken later, dient een retailpartner een schadeclaim in en vraagt iemand: “Welke ploeg had vrachtwagen 117 op 17 maart?” En we ontdekken dat we het antwoord elke keer hebben overschreven als de toewijzing veranderde.
Een manier om die historie te bewaren is van de toewijzing een eigen record te maken. Als een ploeg wordt toegewezen, maken we een ploegtoewijzing aan met een begindatum. Als de toewijzing verandert, zetten we een einddatum op het oude record en maken we een nieuw record aan met een eigen begindatum. Nu is “wie had die toewijzing zes maanden geleden?” een simpele vraag, in plaats van graafwerk in veldhistorie of een logboek van datawijzigingen. En zodra een ploeg veel toewijzingen heeft gehad, vraagt iemand welke de huidige is, dus ik zou ook een vlag Actief toevoegen.
Dus als iemand me over een relatie vertelt, vraag ik niet alleen hoe de dingen samenhangen. Ik vraag: verandert die relatie, en geven we om haar historie?
Teken voordat je configureert
Section titled “Teken voordat je configureert ”Ons model van Steve Trucking wordt bruikbaar. We weten welke relaties een-op-veel zijn, waar een veel-op-veel een ander concept verbergt, welke relaties optioneel zijn en welke door de tijd veranderen. En we hebben nog steeds geen Salesforce-object gemaakt. Dat is met opzet.
Dit diagram moet iets zijn wat ik de business kan voorleggen, en ze moeten Salesforce niet hoeven kennen om me te vertellen of het klopt. Als ze het niet kunnen valideren omdat het vol Salesforce-termen staat, ben ik te snel naar het fysieke ontwerp gegaan.
Wat een architect hier beslist
Section titled “Wat een architect hier beslist ”Als ik de relaties in een conceptueel model doorwerk, beslis ik:
- Hoe de belangrijkste bedrijfsentiteiten met elkaar samenhangen.
- Of elke relatie een-op-een, een-op-veel of veel-op-veel is, nu en door de tijd heen.
- Of elke relatie verplicht of optioneel is.
- Of een veel-op-veel-relatie een zinvol bedrijfsconcept verbergt.
- Of de relatie door de tijd verandert, en of we haar historie nodig hebben.
Lookup of master-detail, de configuratie van koppelobjecten, cascadegedrag en sharing zijn fysieke beslissingen; daar komen we nog. Op dit moment beantwoorden we nog steeds de belangrijkere vraag: hoe werkt dit bedrijf eigenlijk? Zodra we de entiteiten en de relaties ertussen begrijpen, kunnen we de details gaan toevoegen die ze beschrijven. Dan begint ons conceptuele model een logisch datamodel te worden.