Tegn relationerne
Findes også på 28 sprog
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Modul 2 af 6 i kapitlet Modellér data for betydning, kapitel 2 i kurset Data Architect. Hvert modul står på egne ben. Forrige: Lyt efter navneordene · Næste: Byg den logiske model
Spørgsmålet, dette modul besvarer: Hvordan gør jeg kandidater til entiteter til en konceptuel datamodel?
Vi har navneord på tavlen. Nu vil jeg vide noget om stregerne mellem kasserne, for en samling entiteter er ikke rigtig en datamodel endnu. Det er i relationerne, meget af betydningen bor. En detailpartner driver distributionscentre. Et manifest oplister leveringer. En levering går til en modtager. Et team kører en lastbil. Hvert af de udsagn fortæller mig noget om forretningen, og hvert af dem giver mig endnu et spørgsmål at stille.
Start med forretningens sprog
Sektion kaldt “Start med forretningens sprog ”Jeg vil stadig ikke tale om Salesforce. Jeg spørger ikke, om det her skal være en lookup-relation eller en master-detail-relation, jeg tænker ikke på forbindelsesobjekter i Salesforce (Salesforce Junction Objects), og jeg beslutter ikke, hvad der sker, når en overordnet post bliver slettet. Jeg prøver at forstå forretningsrelationen.
Tag »en detailpartner driver distributionscentre«. Det lyder enkelt. Men kan en detailpartner have ét DC eller mange? Hos Steve Trucking driver hver detailpartner et regionalt distributionscenter i hver region, Steve Trucking betjener, så mange. Kan et DC høre til mere end én detailpartner? Betyder et DC noget i sig selv, med sit eget personale og sin egen historik, eller er det bare en adresse? Hvis en detailpartner stopper, går vi så stadig op i dens DC’er?
Det er ikke Salesforce-spørgsmål. Det er forretningsspørgsmål, og svarene kan ændre modellen fuldstændigt.
Læs stregerne
Sektion kaldt “Læs stregerne ”Før vi går dybere, vil jeg give dig det sprog, vi bruger på hvert eneste diagram herfra. Det er et lille sprog. En streg mellem to kasser siger, at de to ting hænger sammen, og markeringerne i enderne siger hvor mange.
Start med en ren streg uden markeringer. Det er der, jeg starter på tavlen: jeg ved, at de to navneord hænger sammen, jeg har bare ikke spurgt hvordan endnu. Så får enderne markeringer. En enkelt tværstreg over stregen betyder én. Kragefoden, enden der deler sig i tre som en fuglefod, betyder mange. Senere i dette modul ser du en anden markering dukke op ved siden af den første, en tværstreg eller en cirkel, og den besvarer et andet spørgsmål: kan der være ingen?
Den ene regel, du skal huske: du læser hver markering ved den kasse, den rører. Markeringen nærmest kassen er det højeste antal, der kan være; den næste markering længere ude er det laveste.
Sit, bliv, modellér
Sektion kaldt “Sit, bliv, modellér ”Før Steve Trucking går vi tilbage til hundene fra modul 1. Vi havde fem kasser: Ejer, Opdrætter, Hund, Race og Trick. Nu spørger jeg til stregerne mellem dem.
Én eller mange? En ejer kan have mere end én hund; Ana har to. En hund har én ejer, i hvert fald i vores model. Det er én-til-mange: en tværstreg ved Ejer, en kragefod ved Hund. Opdrætteren har samme form: én opdrætter opdrætter mange hunde.
Kan der være ingen? Max kom fra internatet, så han har slet ingen opdrætter. Opdrætter-enden får en cirkel: en hund har nul eller én opdrætter. Til gengæld har hver hund en ejer, så den ende får en ekstra tværstreg: præcis én.
Mange til mange? En hund kan mange tricks, og et trick, for eksempel Sit, kan mange hunde. Det er mange-til-mange, og det er præcis der, jeg går på jagt efter et skjult begreb. Er der noget ved, at denne hund kan dette trick? Hvor godt hun gør det, og hvornår hun lærte det. Relationen har sine egne fakta, så den bliver en ting for sig: Hundetrick, med hunden først i navnet, fordi det er hunden, der driver den.
Hvad betyder hver streg? En ejer ejer en hund. En opdrætter opdrætter den. En hund kan sine tricks. Giv stregerne navne, og så kan alle læse modellen tilbage for dig.
Nu eller over tid? Går nogen op i, hvor god Bella er til Sit i dag, eller hvordan hun nåede dertil? Hvis en træner tjekker hende med et par måneders mellemrum, er hvert tjek en post for sig: en Trickvurdering med datoen, færdighedsniveauet og hvem der tjekkede, under det Hundetrick, den hører til. Selv en relation, der er blevet til en ting, kan have sin egen historik.
Race lader jeg stå uden forbindelse indtil videre. Det er stadig spørgsmålet fra modul 1, en kasse for sig eller et ord på hunden, og modul 4 afgør det.
Hvert af de spørgsmål virker på samme måde i en rigtig virksomhed. Lad os nu stille dem til Steve Trucking.
Spørg »én eller mange?«
Sektion kaldt “Spørg »én eller mange?« ”Noget af det første, jeg vil forstå ved en relation, er dens kardinalitet. Det er databaseordet; spørgsmålet er meget enklere: hvor mange af dem her kan hænge sammen med hvor mange af dem der? På det konceptuelle niveau er der tre grundmønstre.
Det er et vigtigt skridt i processen: tag to forskellige navneord, og forstå deres relation. I de fleste tilfælde er det én-til-mange eller mange-til-én. Kun i sjældne tilfælde møder du en én-til-én.
Én-til-mange er overalt. Én detailpartner har mange distributionscentre. Ét manifest oplister mange leveringer. Én rute har cirka ti stop. Når jeg hører den slags sprog, begynder jeg at tegne stregen.
Og nu får stregen sine markeringer. Hver ende fortæller dig, hvor mange der er af den kasse, den rører: tværstregen for én, kragefoden for mange. Læs den fra hver kasse: én detailpartner har mange distributionscentre.
Én-til-én-relationer findes, men de er sjældne, og når jeg finder en, stiller jeg nogle spørgsmål. Er det virkelig to forskellige navneord, eller det samme? Hvis de er forskellige, hvad er så én-til-én-relationen mellem dem? Og vil den altid være én-til-én, eller kun én-til-én lige nu? Det er nøglespørgsmål, når man designer datamodellen. Et team og en lastbil ligner én-til-én på en given morgen: to personer, én lastbil, én rute. Over en måned er de det ikke, og det er der, den mest interessante relation i denne model gemmer sig.
Mange-til-mange-relationer er særligt interessante, fordi de ofte fortæller os, at der findes et andet begreb i forretningen. Kan et team køre mere end én lastbil over tid? Ja. Kan en lastbil blive kørt af mere end ét team? I løbet af dens levetid, helt sikkert. Så teams og lastbiler har en mange-til-mange-relation. Men nu vil jeg vide mere. Går forretningen op i, hvornår et team havde en lastbil? Til hvilken rute, på hvilken dag? Hvem lavede tildelingen? Hvis selve relationen bærer information, vi går op i, har vi opdaget endnu et forretningsbegreb: teamtildelingen (Crew Assignment).
Det er en vigtig vane, når man modellerer. Nogle gange er det mest interessante ikke et af de navneord, vi hørte først. Det gemmer sig i relationen mellem to navneord.
Relationer kan blive til ting
Sektion kaldt “Relationer kan blive til ting ”Det er et af de steder, hvor jeg gerne vil have admins til at begynde at tænke anderledes. I Salesforce er vi vant til at tale om objekter og felter, så det er nemt at behandle kasserne som den vigtige del og stregerne som rørføring. Men selve relationen kan have forretningsmæssig betydning.
Tag en levering og produkterne på den. En levering kan indeholde flere produkter, for eksempel en vaskemaskine og en tørretumbler. Et produkt, den samme køleskabsmodel, optræder på tusindvis af leveringer. Nemt nok. Men hvad nu, hvis jeg skal vide, hvor mange af det produkt der er på denne levering, om det skal installeres, eller om det gamle skal køres bort? Så er jeg ikke længere kun interesseret i en relation mellem levering og produkt. Jeg er interesseret i en leveringslinje (Delivery Item), og det begreb fortjener sin egen entitet.
Hvis du kommer fra Salesforce, tænker du måske allerede: »Det er et forbindelsesobjekt.« Du tager ikke fejl. Men jeg vil ikke starte der. En leveringslinje er et forretningsbegreb, før den er et forbindelsesobjekt i Salesforce (Salesforce Junction Object). Forretningen først, implementeringen bagefter.
Et par af mine vaner for den slags relationsentiteter, uanset hvor de ender med at blive bygget.
Giv den et navn. Hvis forretningen allerede har et ord for den, så brug deres. Hvis ikke, så tag navnene på de to forældre og sæt dem sammen. Tænk på en ordre og et produkt. Tingen mellem dem er ordrelinjen (Order Item): ordren og linjen på ordren. Den er barn af begge forældre, og i Salesforce ender den måske som et forbindelsesobjekt i Salesforce. Men hvilket navn kommer først: linjeordre eller ordrelinje? Se på, hvilken slags data hver forælder er. Produktet er referencedata; ordren er transaktionsdata, og det er ordren, der driver den. Så det er ordrelinje, eller ordreprodukt (Order Product), på samme måde som Salesforce har Opportunity Product. Hos Steve Trucking er det leveringslinjen. Det drivende navn kommer først, og posten havner ved siden af sin ejer i hver eneste liste, du nogensinde kommer til at kigge på.
Giv den sin egen nøgle. Det er fristende at sige, at en leveringslinje identificeres ved levering plus produkt, og stoppe der. Det er en sammensat nøgle, og sammensatte nøgler er meget sværere at håndtere: hvert system, der peger på posten, skal have begge halvdele med. Giv relationsentiteten sit eget id, og behold levering plus produkt som en regel om entydighed, ikke som post-id’et.
Læg mærke til, hvad der ikke står på den: et serienummer. Et antal og et serienummer hører ikke hjemme på den samme post. Et antal tæller flere af en ting; et serienummer identificerer én bestemt ting. Hvis forretningen har brug for serienumre, bliver hver enhed sin egen post, og fem køleskabe er fem poster. Jeg kan ikke se en situation, hvor en leveringslinje skal have en leveringslinjedetalje under sig. Det er det ene eller det andet: en samlet post med et antal, eller én post pr. enhed. Her er det antallet.
Hold øje med de attributter, der vil have historik. Nogle relationsentiteter ligger fast, når de først er oprettet: vaskemaskinen på denne levering forbliver vaskemaskinen på denne levering. Andre ændrer sig hele tiden. Et team har lastbil 117 i denne uge, og i næste uge går lastbilen til et andet team. Når relationen ændrer sig, og forretningen går op i, hvad den plejede at være, har relationsentiteten brug for datoer, og teamtildelingen er den, du skal holde øje med. Spørg tidligt, om forretningen går op i nu eller over tid; vi vender tilbage til det om lidt.
Relationer har betydning ud over kardinaliteten
Sektion kaldt “Relationer har betydning ud over kardinaliteten ”»Én-til-mange« er ikke nok til at forstå en relation. Jeg vil også vide, hvad relationen betyder.
En levering har en lokation. Hvilken? Distributionscentret, den kører fra? Modtagerens hjem, den skal til? De kan ikke bruges i flæng. To modeller kan have præcis de samme kasser og den samme kardinalitet, og stregerne kan betyde helt forskellige ting. Derfor er en god model ikke bare kasser forbundet med streger. Stregerne skal have navne. Hvis jeg giver en anden arkitekt mit diagram, skal vedkommende ikke gætte på, hvad en relation betyder, og hvis jeg viser det til forretningen, skal det bruge et sprog, de kan genkende.
Optionalitet betyder også noget
Sektion kaldt “Optionalitet betyder også noget ”Der gemmer sig endnu et spørgsmål inde i »hvor mange?«: er relationen påkrævet? Kan en levering eksistere, før den er sat på en rute? Det er den nødt til: manifestet kommer en dag eller to før leveringen, og ruterne bliver lagt fast aftenen før. Kan en levering eksistere uden en detailpartner? Nej; hver levering kommer fra en partners manifest. Det er optionalitet.
Igen: spring ikke direkte til et Required-flueben i Salesforce. Der er forskel på at sige »hver levering skal have en detailpartner« og at sige »Salesforce skal kræve feltet for detailpartner, når posten oprettes«. De ender måske som den samme implementering, men de er ikke det samme udsagn. Det første er en forretningsregel; det andet er én måde at håndhæve den på. Som arkitekter vil vi forstå det første, før vi beslutter det andet.
På diagrammet er optionaliteten den anden markering i hver ende. Markeringen nærmest kassen er det højeste antal, der kan være: tværstregen for én, kragefoden for mange. Den næste markering længere ude er det laveste: endnu en tværstreg betyder mindst én, en cirkel betyder, at det kan være nul. Så hver levering står på præcis ét manifest, og et manifest oplister én eller mange leveringer. En levering hører til nul eller ét stop, intet før den er lagt på en rute, og ved et stop afleveres nul eller mange leveringer.
Tiden ændrer relationer
Sektion kaldt “Tiden ændrer relationer ”Her er et spørgsmål, jeg stiller tit: mener du nu, eller mener du over tid?
Et team kører en lastbil. Lige nu? Til dagens rute? Så længe de to personer arbejder sammen? Det giver forskellige modeller. Hvis forretningen kun går op i, hvilken lastbil et team har i dag, kan modellen forblive enkel. Hvis den har brug for hver lastbil, et team har kørt, hvornår og på hvilken rute, har vi brug for historik, og den teamtildeling, vi opdagede, bliver pludselig meget vigtig.
Det er en almindelig kilde til fejl i modellering. Vi modellerer den nuværende tilstand, fordi det er den, vi kan se på skærmen. Så, uger senere, indgiver en detailpartner et skadeskrav, og nogen spørger: »Hvilket team havde lastbil 117 den 17. marts?« Og vi opdager, at vi har overskrevet svaret, hver gang tildelingen ændrede sig.
En måde at bevare den historik på er at gøre tildelingen til en post for sig. Når et team bliver tildelt, opretter vi en teamtildeling med en startdato. Når tildelingen ændrer sig, sætter vi en slutdato på den gamle post og opretter en ny med sin egen startdato. Nu er »hvem havde den tildeling for seks måneder siden?« et enkelt spørgsmål at besvare, i stedet for en udgravning i felthistorikken eller en log over dataændringer. Og når et team først har haft mange tildelinger, vil nogen spørge, hvilken der er den aktuelle, så jeg ville også tilføje et Active-flag (aktiv).
Så når nogen fortæller mig om en relation, spørger jeg ikke bare, hvordan tingene hænger sammen. Jeg spørger: ændrer den relation sig, og går vi op i dens historik?
Tegn, før du konfigurerer
Sektion kaldt “Tegn, før du konfigurerer ”Vores model for Steve Trucking begynder at blive nyttig. Vi ved, hvilke relationer der er én-til-mange, hvor en mange-til-mange gemmer på et andet begreb, hvilke relationer der er valgfrie, og hvilke der ændrer sig over tid. Og vi har stadig ikke oprettet et eneste Salesforce-objekt. Det er med vilje.
Det her diagram skal være noget, jeg kan lægge foran forretningen, og de skal ikke kende Salesforce for at fortælle mig, om det er rigtigt. Hvis de ikke kan validere det, fordi det er fyldt med Salesforce-terminologi, er jeg gået for hurtigt over i det fysiske design.
Hvad en arkitekt beslutter her
Sektion kaldt “Hvad en arkitekt beslutter her ”Når jeg arbejder mig igennem relationerne i en konceptuel model, beslutter jeg:
- Hvordan de vigtigste forretningsentiteter hænger sammen med hinanden.
- Om hver relation er én-til-én, én-til-mange eller mange-til-mange, nu og over tid.
- Om hver relation er påkrævet eller valgfri.
- Om en mange-til-mange-relation gemmer på et meningsfuldt forretningsbegreb.
- Om relationen ændrer sig over tid, og om vi har brug for dens historik.
Lookup eller master-detail, opsætning af forbindelsesobjekter, kaskadeadfærd og deling er fysiske beslutninger; dem kommer vi til. Lige nu besvarer vi stadig det vigtigere spørgsmål: hvordan fungerer den her forretning egentlig? Når vi forstår entiteterne og relationerne mellem dem, kan vi begynde at tilføje de detaljer, der beskriver dem. Det er der, vores konceptuelle model begynder at blive til en logisk datamodel.