Tegn relasjonene
Finnes også på 28 språk
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 · Dansk · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Modul 2 av 6 i kapitlet Modeller data for mening, kapittel 2 i kurset Data Architect. Hver modul står på egne ben. Forrige: Lytt etter substantivene · Neste: Bygg den logiske modellen
Spørsmålet denne modulen besvarer: Hvordan gjør jeg kandidatentiteter om til en konseptuell datamodell?
Vi har substantiver på tavlen. Nå vil jeg vite om linjene mellom boksene, for en samling entiteter er egentlig ikke en datamodell ennå. Det er i relasjonene mye av meningen bor. En detaljhandelspartner (Retail Partner) driver distribusjonssentre. Et manifest lister opp leveringer. En levering går til en mottaker (Recipient). Et team kjører en lastebil. Hver eneste av de setningene forteller meg noe om virksomheten, og hver eneste gir meg enda et spørsmål å stille.
Start med forretningsspråket
Section titled “Start med forretningsspråket ”Jeg vil fortsatt ikke snakke om Salesforce. Jeg spør ikke om dette skal være en lookup- eller en master-detail-relasjon, jeg tenker ikke på koblingsobjekter i Salesforce (Salesforce Junction Objects), og jeg bestemmer ikke hva som skjer når en overordnet post slettes. Jeg prøver å forstå forretningsrelasjonen.
Ta «en detaljhandelspartner driver distribusjonssentre». Det høres enkelt ut. Men kan en detaljhandelspartner ha ett DC eller mange? Hos Steve Trucking driver hver detaljhandelspartner et regionalt distribusjonssenter i hver region Steve Trucking betjener, så mange. Kan et DC høre til mer enn én detaljhandelspartner? Betyr et DC noe i seg selv, med egne ansatte og egen historikk, eller er det bare en adresse? Hvis en detaljhandelspartner slutter, bryr vi oss fortsatt om DC-ene dens?
Det er ikke Salesforce-spørsmål. Det er forretningsspørsmål, og svarene kan endre modellen fullstendig.
Les linjene
Section titled “Les linjene ”Før vi går dypere, vil jeg gi deg språket vi kommer til å bruke på hvert diagram herfra. Det er et lite språk. En linje mellom to bokser sier at de to tingene henger sammen, og merkene i endene sier hvor mange.
Start med en enkel linje, helt uten merker. Det er der jeg starter på tavlen: Jeg vet at de to substantivene henger sammen, jeg har bare ikke spurt hvordan ennå. Så får endene merker. En enkelt strek på tvers av linjen betyr én. Kråkefoten, enden som deler seg i tre som en fuglefot, betyr mange. Senere i denne modulen ser du et merke nummer to dukke opp ved siden av det første, en strek eller en sirkel, og det svarer på et annet spørsmål: kan det være ingen?
Den ene regelen du må huske: du leser hvert merke ved boksen det berører. Merket nærmest boksen er det meste det kan være; det neste merket utover er det minste.
Sitt, bli, modellér
Section titled “Sitt, bli, modellér ”Før Steve Trucking går vi tilbake til hundene fra modul 1. Vi hadde fem bokser: Eier, Oppdretter, Hund, Rase og Triks. Nå spør jeg om linjene mellom dem.
Én eller mange? En eier kan ha mer enn én hund; Ana har to. En hund har én eier, i hvert fall i modellen vår. Det er én-til-mange: en strek ved Eier, en kråkefot ved Hund. Oppdretteren har samme form: én oppdretter avler mange hunder.
Kan det være ingen? Max kom fra et dyrehjem, så han har ingen oppdretter i det hele tatt. Oppdretter-enden får en sirkel: en hund har null eller én oppdretter. Alle hunder har derimot en eier, så den enden får en strek til: nøyaktig én.
Mange til mange? En hund kan mange triks, og et triks, for eksempel Sitt, kan mange hunder. Det er mange-til-mange, og det er nettopp der jeg leter etter et skjult begrep. Er det noe ved at denne hunden kan dette trikset? Hvor godt hun gjør det, og når hun lærte det. Relasjonen har egne fakta, så den blir en egen ting: Hundetriks, med hunden først i navnet, fordi det er hunden som driver det.
Hva betyr hver linje? En eier eier en hund. En oppdretter avler den. En hund kan triksene sine. Gi linjene navn, så kan hvem som helst lese modellen tilbake til deg.
Nå, eller over tid? Bryr noen seg om hvor god Bella er til Sitt i dag, eller om hvordan hun kom dit? Hvis en trener sjekker henne med noen måneders mellomrom, er hver sjekk en egen post: en Triksvurdering, med dato, ferdighetsnivå og hvem som sjekket, under Hundetrikset den hører til. Selv en relasjon som ble en ting, kan ha sin egen historikk.
Rase lar jeg stå uten kobling foreløpig. Det er fortsatt spørsmålet fra modul 1, en egen boks eller et ord på hunden, og modul 4 avgjør det.
Hvert eneste av de spørsmålene virker på samme måte i en ekte virksomhet. La oss nå stille dem til Steve Trucking.
Spør «én eller mange?»
Section titled “Spør «én eller mange?» ”Noe av det første jeg vil forstå om en relasjon, er kardinaliteten. Det er databaseordet; spørsmålet er mye enklere: hvor mange av disse kan henge sammen med hvor mange av de andre? På det konseptuelle nivået finnes det tre grunnmønstre.
Dette er et viktig steg i prosessen: ta to forskjellige substantiver og forstå relasjonen mellom dem. I de fleste tilfeller er det én-til-mange, eller mange-til-én. Bare i sjeldne tilfeller møter du en én-til-én.
Én-til-mange finnes overalt. Én detaljhandelspartner har mange distribusjonssentre. Ett manifest lister opp mange leveringer. Én rute har rundt ti stopp. Når jeg hører sånt språk, begynner jeg å tegne linjen.
Og nå får linjen merkene sine. Hver ende forteller deg hvor mange det er av boksen den berører: streken for én, kråkefoten for mange. Les det fra hver boks: én detaljhandelspartner har mange distribusjonssentre.
Én-til-én-relasjoner finnes, men de er sjeldne, og når jeg finner en, stiller jeg noen spørsmål. Er dette virkelig to forskjellige substantiver, eller det samme? Hvis de er forskjellige, hva er én-til-én-relasjonen mellom dem? Og vil den alltid være én-til-én, eller bare én-til-én akkurat nå? Dette er nøkkelspørsmål når du designer datamodellen. Et team og en lastebil ser ut som én-til-én på en hvilken som helst morgen: to personer, én lastebil, én rute. Over en måned er de det ikke, og det er der den mest interessante relasjonen i denne modellen gjemmer seg.
Mange-til-mange-relasjoner er spesielt interessante, fordi de ofte forteller oss at det finnes et annet begrep i virksomheten. Kan et team kjøre mer enn én lastebil over tid? Ja. Kan en lastebil kjøres av mer enn ett team? I løpet av levetiden, helt sikkert. Så team og lastebiler har en mange-til-mange-relasjon. Men nå vil jeg vite mer. Bryr virksomheten seg om når et team hadde en lastebil? For hvilken rute, på hvilken dag? Hvem gjorde tildelingen? Hvis selve relasjonen bærer informasjon vi bryr oss om, har vi oppdaget et nytt forretningsbegrep: teamtildelingen (Crew Assignment).
Det er en viktig modelleringsvane. Noen ganger er det mest interessante ikke et av substantivene vi hørte først. Det gjemmer seg i relasjonen mellom to substantiver.
Relasjoner kan bli ting
Section titled “Relasjoner kan bli ting ”Dette er et av stedene der jeg vil at admins skal begynne å tenke annerledes. I Salesforce er vi vant til å snakke om objekter og felt, så det er lett å behandle boksene som det viktige og linjene som rørleggerarbeid. Men selve relasjonen kan ha forretningsmessig betydning.
Tenk på en levering og produktene på den. En levering kan inneholde flere produkter, for eksempel en vaskemaskin og en tørketrommel. Et produkt, den samme kjøleskapsmodellen, dukker opp på tusenvis av leveringer. Greit nok. Men hva om jeg trenger å vite hvor mange av det produktet som er på denne leveringen, om det skal installeres, eller om det gamle skal kjøres bort? Da er jeg ikke lenger bare interessert i en relasjon mellom levering og produkt. Jeg er interessert i en leveringslinje (Delivery Item), og det begrepet fortjener en egen entitet.
Hvis du kommer fra Salesforce, tenker du kanskje allerede: «Det er et koblingsobjekt (junction object).» Du tar ikke feil. Men jeg vil ikke starte der. En leveringslinje er et forretningsbegrep før den er et koblingsobjekt i Salesforce (Salesforce Junction Object). Forretningen først, implementeringen etterpå.
Her er noen av vanene mine for slike relasjonsentiteter, uansett hvor de til slutt blir bygget.
Gi den et navn. Hvis virksomheten allerede har et ord for det, bruk deres. Hvis ikke, ta navnene på de to overordnede og sett dem sammen. Tenk på en ordre og et produkt. Tingen mellom dem er ordrelinjen (Order Item): ordren, og linjen på ordren. Den er et underordnet element til begge de overordnede, og i Salesforce kan den ende opp som et koblingsobjekt i Salesforce. Men hvilket navn skal stå først: linjeordre eller ordrelinje? Se på hva slags data hver av de overordnede er. Produktet er referansedata; ordren er en transaksjon, og det er ordren som driver det. Så det blir ordrelinje, eller ordreprodukt (Order Product), på samme måte som Salesforce har salgsmulighetsprodukt (Opportunity Product). Hos Steve Trucking er det leveringslinjen. Det drivende navnet står først, og posten sorteres ved siden av eieren sin i hver eneste liste du noen gang kommer til å se på.
Gi den sin egen nøkkel. Det er fristende å si at en leveringslinje identifiseres av levering pluss produkt og stoppe der. Det er en sammensatt nøkkel, og sammensatte nøkler er mye vanskeligere å håndtere: hvert system som peker på posten, må bære med seg begge halvdelene. Gi relasjonsentiteten sin egen ID, og behold levering pluss produkt som en regel om unikhet, ikke som post-ID-en.
Legg merke til hva som ikke er på den: et serienummer. Et antall og et serienummer hører ikke hjemme på samme post. Et antall teller flere av en ting; et serienummer identifiserer én bestemt ting. Hvis virksomheten trenger serienumre, blir hver enhet en egen post, og fem kjøleskap er fem poster. Jeg ser ikke noe tilfelle for en leveringslinje med en leveringslinjedetalj under seg. Det er det ene eller det andre: et aggregat med et antall, eller én post per enhet. Her er det antallet.
Følg med på attributtene som vil ha historikk. Noen relasjonsentiteter ligger fast når de først er opprettet: vaskemaskinen på denne leveringen forblir vaskemaskinen på denne leveringen. Andre endrer seg hele tiden. Et team har lastebil 117 denne uken, og neste uke går lastebilen til et annet team. Når relasjonen endrer seg og virksomheten bryr seg om hvordan den pleide å være, trenger relasjonsentiteten datoer, og det er teamtildelingen du må følge med på. Spør tidlig om virksomheten bryr seg om nå eller over tid; vi kommer tilbake til det om litt.
Relasjoner betyr mer enn kardinaliteten
Section titled “Relasjoner betyr mer enn kardinaliteten ”«Én-til-mange» er ikke nok til å forstå en relasjon. Jeg vil også vite hva relasjonen betyr.
En levering har et sted. Hvilket? Distribusjonssenteret den drar fra? Hjemmet til mottakeren den skal til? De er ikke utskiftbare. To modeller kan ha nøyaktig de samme boksene og den samme kardinaliteten, og linjene kan likevel bety helt forskjellige ting. Derfor er en god modell ikke bare bokser koblet sammen med linjer. Linjene trenger navn. Hvis jeg gir diagrammet mitt til en annen arkitekt, skal vedkommende ikke måtte gjette hva en relasjon betyr, og hvis jeg viser det til virksomheten, bør det bruke et språk de kjenner igjen.
Valgfrihet betyr også noe
Section titled “Valgfrihet betyr også noe ”Det gjemmer seg enda et spørsmål inni «hvor mange?»: er relasjonen påkrevd? Kan en levering finnes før den er lagt på en rute? Det må den: manifestet kommer en dag eller to før leveringen, og rutene fastsettes kvelden før. Kan en levering finnes uten en detaljhandelspartner? Nei; hver levering kommer fra en partners manifest. Det er valgfrihet (optionality).
Igjen: ikke hopp rett til en avkrysningsboks for Required (obligatorisk) i Salesforce. Det er forskjell på å si «hver levering må ha en detaljhandelspartner» og å si «Salesforce bør kreve feltet for detaljhandelspartner når posten opprettes». De kan ende opp som samme implementering, men de er ikke det samme utsagnet. Det første er en forretningsregel; det andre er én måte å håndheve den på. Som arkitekter vil vi forstå det første før vi bestemmer det andre.
På diagrammet er valgfriheten det andre merket i hver ende. Merket nærmest boksen er det meste det kan være: streken for én, kråkefoten for mange. Det neste merket utover er det minste: en strek til betyr minst én, en sirkel betyr at det kan være null. Så hver levering står på nøyaktig ett manifest, og et manifest lister opp én eller mange leveringer. En levering hører til null eller ett stopp, ingen før den er rutelagt, og et stopp leverer null eller mange leveringer.
Tiden endrer relasjoner
Section titled “Tiden endrer relasjoner ”Her er et spørsmål jeg stiller ofte: mener du nå, eller mener du over tid?
Et team kjører en lastebil. Akkurat nå? For dagens rute? Så lenge de to personene jobber sammen? Det gir forskjellige modeller. Hvis virksomheten bare bryr seg om hvilken lastebil et team har i dag, kan modellen forbli enkel. Hvis den trenger hver lastebil et team har kjørt, når, og på hvilken rute, trenger vi historikk, og den teamtildelingen vi oppdaget, blir plutselig veldig viktig.
Dette er en vanlig kilde til modelleringsfeil. Vi modellerer nåtilstanden fordi det er det vi ser på skjermen. Så, uker senere, sender en detaljhandelspartner inn et skadekrav, og noen spør: «Hvilket team hadde lastebil 117 den 17. mars?» Og vi oppdager at vi har skrevet over svaret hver gang tildelingen endret seg.
Én måte å ta vare på den historikken på er å gjøre tildelingen til en egen post. Når et team blir tildelt, oppretter vi en teamtildeling med en startdato. Når tildelingen endres, setter vi en sluttdato på den gamle posten og oppretter en ny med sin egen startdato. Nå er «hvem hadde den tildelingen for seks måneder siden?» et enkelt spørsmål å svare på, i stedet for graving i felthistorikk eller en logg over dataendringer. Og når et team har hatt mange tildelinger, kommer noen til å spørre hvilken som er den gjeldende, så jeg ville lagt til et Active-flagg (aktiv) også.
Så når noen forteller meg om en relasjon, spør jeg ikke bare hvordan tingene henger sammen. Jeg spør: endrer den relasjonen seg, og bryr vi oss om historikken?
Tegn før du konfigurerer
Section titled “Tegn før du konfigurerer ”Modellen vår for Steve Trucking begynner å bli nyttig. Vi vet hvilke relasjoner som er én-til-mange, hvor en mange-til-mange skjuler et annet begrep, hvilke relasjoner som er valgfrie, og hvilke som endrer seg over tid. Og vi har fortsatt ikke opprettet et eneste Salesforce-objekt. Det er med vilje.
Dette diagrammet bør være noe jeg kan legge fram for virksomheten, og de skal ikke trenge å kunne Salesforce for å fortelle meg om det stemmer. Hvis de ikke kan validere det fordi det er fullt av Salesforce-terminologi, har jeg gått for raskt over i det fysiske designet.
Hva en arkitekt bestemmer her
Section titled “Hva en arkitekt bestemmer her ”Når jeg jobber meg gjennom relasjonene i en konseptuell modell, bestemmer jeg:
- Hvordan de viktigste forretningsentitetene henger sammen med hverandre.
- Om hver relasjon er én-til-én, én-til-mange eller mange-til-mange, nå og over tid.
- Om hver relasjon er påkrevd eller valgfri.
- Om en mange-til-mange-relasjon skjuler et meningsfullt forretningsbegrep.
- Om relasjonen endrer seg over tid, og om vi trenger historikken.
Lookup eller master-detail, oppsett av koblingsobjekter, kaskadeoppførsel og deling er fysiske beslutninger; vi kommer dit. Akkurat nå svarer vi fortsatt på det viktigere spørsmålet: hvordan fungerer denne virksomheten egentlig? Når vi forstår entitetene og relasjonene mellom dem, kan vi begynne å legge til detaljene som beskriver dem. Det er da den konseptuelle modellen vår begynner å bli en logisk datamodell.