Rita relationerna
Finns även 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 · العربية · עברית · Українська · हिन्दी · Русский · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Modul 2 av 6 i kapitlet Modellera data för mening, kapitel 2 i kursen Data Architect. Varje modul står på egna ben. Föregående: Lyssna efter substantiven · Nästa: Bygg den logiska modellen
Frågan den här modulen besvarar: Hur gör jag kandidatentiteter till en konceptuell datamodell?
Vi har substantiv på tavlan. Nu vill jag veta mer om linjerna mellan rutorna, för en samling entiteter är egentligen inte en datamodell än. Det är i relationerna som mycket av meningen finns. En detaljhandelspartner driver distributionscentraler. Ett manifest listar leveranser. En leverans går till en mottagare. Ett team kör en lastbil. Vart och ett av de påståendena säger mig något om verksamheten, och vart och ett ger mig ännu en fråga att ställa.
Börja med verksamhetens språk
Section titled “Börja med verksamhetens språk ”Jag vill fortfarande inte prata om Salesforce. Jag frågar inte om det här ska vara en lookup-relation eller en master-detail-relation, jag funderar inte på kopplingsobjekt i Salesforce (Salesforce Junction Objects), och jag bestämmer inte vad som händer när en föräldrapost raderas. Jag försöker förstå affärsrelationen.
Ta ”en detaljhandelspartner driver distributionscentraler”. Det låter enkelt. Men kan en detaljhandelspartner ha en DC eller många? Hos Steve Trucking driver varje detaljhandelspartner en regional distributionscentral i varje region som Steve Trucking betjänar, alltså många. Kan en DC höra till mer än en detaljhandelspartner? Spelar en DC roll i sig själv, med egen personal och egen historik, eller är den bara en adress? Om en detaljhandelspartner slutar, bryr vi oss då fortfarande om dess DC:er?
Det är inga Salesforce-frågor. Det är affärsfrågor, och svaren kan ändra modellen helt.
Läs linjerna
Section titled “Läs linjerna ”Innan vi går djupare vill jag ge dig det språk vi kommer att använda i varje diagram från och med nu. Det är ett litet språk. En linje mellan två rutor säger att de två sakerna hör ihop, och markeringarna i ändarna säger hur många.
Börja med en vanlig linje, helt utan markeringar. Det är där jag börjar på whiteboarden: jag vet att de här två substantiven hör ihop, jag har bara inte frågat hur än. Sedan får ändarna markeringar. Ett enkelt streck tvärs över linjen betyder en. Kråkfoten, änden som delar sig i tre som en fågelfot, betyder många. Längre fram i den här modulen ser du en andra markering dyka upp bredvid den första, ett streck eller en cirkel, och den svarar på en annan fråga: kan det finnas ingen alls?
Den enda regeln att komma ihåg: du läser varje markering vid den ruta den rör. Markeringen närmast rutan är det högsta antalet; nästa markering utåt är det lägsta.
Sitt, stanna, modellera
Section titled “Sitt, stanna, modellera ”Innan vi går till Steve Trucking, tillbaka till hundarna från modul 1. Vi hade fem rutor: Ägare, Uppfödare, Hund, Ras och Trick. Nu frågar jag om linjerna mellan dem.
En eller många? En ägare kan ha mer än en hund; Ana har två. En hund har en ägare, åtminstone i vår modell. Det är en-till-många: ett streck vid Ägare, en kråkfot vid Hund. Uppfödaren har samma form: en uppfödare föder upp många hundar.
Kan det finnas ingen? Max kom från ett hundhem, så han har ingen uppfödare alls. Uppfödarens ände får en cirkel: en hund har noll eller en uppfödare. Varje hund har däremot en ägare, så den änden får ett andra streck: exakt en.
Många-till-många? En hund kan många trick, och ett trick, säg Sitt, kan många hundar. Det är många-till-många, och det är precis där jag letar efter ett dolt begrepp. Finns det något om att den här hunden kan det här tricket? Hur bra hon gör det, och när hon lärde sig det. Relationen har egna fakta, så den blir en egen sak: Hundtrick, med hundens namn först, eftersom det är hunden som driver den.
Vad betyder varje linje? En ägare äger en hund. En uppfödare föder upp den. En hund kan sina trick. Namnge linjerna, så kan vem som helst läsa modellen tillbaka för dig.
Nu, eller över tid? Bryr sig någon om hur bra Bella är på Sitt i dag, eller hur hon kom dit? Om en tränare kontrollerar henne med några månaders mellanrum blir varje kontroll en egen post: en Trickbedömning, med datum, färdighetsnivå och vem som gjorde kontrollen, under det hundtrick den hör till. Även en relation som blev en sak kan ha en egen historik.
Ras lämnar jag okopplad tills vidare. Det är fortfarande frågan från modul 1, en egen ruta eller ett ord på hunden, och modul 4 avgör den.
Var och en av de frågorna fungerar på samma sätt i en riktig verksamhet. Nu ställer vi dem till Steve Trucking.
Fråga ”en eller många?”
Section titled “Fråga ”en eller många?” ”En av de första sakerna jag vill förstå om en relation är dess kardinalitet. Det är databastermen; frågan är mycket enklare: hur många av de här kan höra ihop med hur många av de där? På konceptuell nivå finns det tre grundmönster.
Det här är ett viktigt steg i processen: ta två olika substantiv och förstå deras relation. I de flesta fall är det en-till-många, eller många-till-en. Bara i sällsynta fall stöter du på en-till-en.
En-till-många finns överallt. En detaljhandelspartner har många distributionscentraler. Ett manifest listar många leveranser. En rutt har ungefär tio stopp. När jag hör sådant språk börjar jag rita linjen.
Och nu får linjen sina markeringar. Varje ände säger hur många av den ruta den rör: strecket för en, kråkfoten för många. Läs den från varje ruta: en detaljhandelspartner har många distributionscentraler.
En-till-en-relationer finns, men de är sällsynta, och när jag hittar en ställer jag några frågor. Är det här verkligen två olika substantiv, eller samma? Om de är olika, vad är då en-till-en-relationen mellan dem? Och kommer den alltid att vara en-till-en, eller bara en-till-en just nu? Det här är nyckelfrågor när du designar datamodellen. Ett team och en lastbil ser ut att vara en-till-en en given morgon: två personer, en lastbil, en rutt. Över en månad är de inte det, och det är där den mest intressanta relationen i den här modellen gömmer sig.
Många-till-många-relationer är särskilt intressanta, eftersom de ofta säger oss att det finns ännu ett begrepp i verksamheten. Kan ett team köra mer än en lastbil över tid? Ja. Kan en lastbil köras av mer än ett team? Under sin livstid, absolut. Så team och lastbilar har en många-till-många-relation. Men nu vill jag veta mer. Bryr sig verksamheten om när ett team hade en lastbil? För vilken rutt, vilken dag? Vem gjorde tilldelningen? Om själva relationen bär information vi bryr oss om har vi upptäckt ännu ett affärsbegrepp: teamtilldelningen (Crew Assignment).
Det är en viktig modelleringsvana. Ibland är det mest intressanta inte ett av substantiven vi hörde först. Det gömmer sig i relationen mellan två substantiv.
Relationer kan bli saker
Section titled “Relationer kan bli saker ”Det här är ett av ställena där jag vill att admins börjar tänka annorlunda. I Salesforce är vi vana vid att prata om objekt och fält, så det är lätt att se rutorna som det viktiga och linjerna som rörledningar. Men själva relationen kan ha en affärsmässig betydelse.
Tänk på en leverans och produkterna på den. En leverans kan innehålla flera produkter, säg en tvättmaskin och en torktumlare. En produkt, samma kylskåpsmodell, dyker upp på tusentals leveranser. Enkelt nog. Men tänk om jag behöver veta hur många av den produkten som finns på den här leveransen, om den ska installeras, eller om den gamla ska forslas bort? Då är jag inte längre bara intresserad av en relation mellan leverans och produkt. Jag är intresserad av en leveransrad (Delivery Item), och det begreppet förtjänar en egen entitet.
Om du kommer från Salesforce kanske du redan tänker: ”Det där är ett kopplingsobjekt.” Du har inte fel. Men jag vill inte börja där. En leveransrad är ett affärsbegrepp innan den är ett kopplingsobjekt i Salesforce (Salesforce Junction Object). Verksamheten först, implementationen sedan.
Några av mina vanor för de här relationsentiteterna, var de än byggs till slut.
Namnge den. Om verksamheten redan har ett ord för den, använd deras. Om den inte har det, ta namnen på de två föräldrarna och sätt ihop dem. Tänk på en order och en produkt. Saken mellan dem är orderraden (Order Item): ordern, och raden på ordern. Den är barn till båda föräldrarna, och i Salesforce kan den sluta som ett kopplingsobjekt i Salesforce. Men vilket namn kommer först: Item Order eller Order Item? Titta på vilken sorts data varje förälder är. Produkten är referensdata; ordern är transaktionsdata, och det är ordern som driver den. Så det blir Order Item, eller Order Product, på samma sätt som Salesforce har Opportunity Product. Hos Steve Trucking är det leveransraden (Delivery Item). Det drivande namnet kommer först, och posten sorteras bredvid sin ägare i varje lista du någonsin kommer att titta på.
Ge den en egen nyckel. Det är frestande att säga att en leveransrad identifieras av leverans plus produkt och stanna där. Det är en sammansatt nyckel, och sammansatta nycklar är mycket svårare att hantera: varje system som pekar på posten måste bära med sig båda halvorna. Ge relationsentiteten ett eget ID, och behåll leverans plus produkt som en regel om unikhet, inte som postens ID.
Lägg märke till vad som inte finns där: ett serienummer. Ett antal och ett serienummer hör inte hemma på samma post. Ett antal räknar flera av en sak; ett serienummer identifierar en viss sak. Om verksamheten behöver serienummer blir varje enhet en egen post, och fem kylskåp är fem poster. Jag ser inget fall för en leveransrad med en Delivery Item Detail under sig. Det är det ena eller det andra: ett aggregat med ett antal, eller en post per enhet. Här blir det antalet.
Håll koll på attributen som vill ha historik. En del relationsentiteter är färdiga när de väl skapats: tvättmaskinen på den här leveransen förblir tvättmaskinen på den här leveransen. Andra ändras hela tiden. Ett team har lastbil 117 den här veckan, och nästa vecka går lastbilen till ett annat team. När relationen ändras och verksamheten bryr sig om hur den brukade vara behöver relationsentiteten datum, och det är teamtilldelningen du ska hålla koll på. Fråga tidigt om verksamheten bryr sig om nu eller över tid; vi återkommer till det om en stund.
Relationer betyder mer än kardinalitet
Section titled “Relationer betyder mer än kardinalitet ””En-till-många” räcker inte för att förstå en relation. Jag vill också veta vad relationen betyder.
En leverans har en plats. Vilken? Distributionscentralen den lämnar? Mottagarens hem dit den ska? De är inte utbytbara. Två modeller kan ha exakt samma rutor och samma kardinalitet, och linjerna kan betyda helt olika saker. Därför är en bra modell inte bara rutor sammankopplade med linjer. Linjerna behöver namn. Om jag ger mitt diagram till en annan arkitekt ska hen inte behöva gissa vad en relation betyder, och om jag visar det för verksamheten ska det använda ett språk de känner igen.
Valfrihet spelar också roll
Section titled “Valfrihet spelar också roll ”Det finns en annan fråga gömd i ”hur många?”: är relationen obligatorisk? Kan en leverans finnas innan den har lagts på en rutt? Det måste den: manifestet kommer en eller två dagar före leveransen, och rutterna fastställs kvällen innan. Kan en leverans finnas utan en detaljhandelspartner? Nej; varje leverans kommer från en partners manifest. Det är valfrihet (optionality).
Återigen, hoppa inte direkt till en Required-kryssruta i Salesforce. Det är skillnad på att säga ”varje leverans måste ha en detaljhandelspartner” och att säga ”Salesforce ska kräva fältet för detaljhandelspartner när posten skapas”. De kan sluta som samma implementation, men de är inte samma påstående. Det första är en affärsregel; det andra är ett sätt att upprätthålla den. Som arkitekter vill vi förstå det första innan vi bestämmer det andra.
I diagrammet är valfriheten den andra markeringen i varje ände. Markeringen närmast rutan är det högsta antalet: strecket för en, kråkfoten för många. Nästa markering utåt är det lägsta: ännu ett streck betyder minst en, en cirkel betyder att det kan vara noll. Så varje leverans finns på exakt ett manifest, och ett manifest listar en eller många leveranser. En leverans hör till noll eller ett stopp, inget förrän den har ruttplanerats, och ett stopp lämnar av noll eller många leveranser.
Tiden ändrar relationer
Section titled “Tiden ändrar relationer ”Här är en fråga jag ställer ofta: menar du nu, eller menar du över tid?
Ett team kör en lastbil. Just nu? För dagens rutt? Så länge de två personerna arbetar ihop? Det ger olika modeller. Om verksamheten bara bryr sig om vilken lastbil ett team har i dag kan modellen förbli enkel. Om den behöver varje lastbil ett team har kört, när och på vilken rutt, behöver vi historik, och den där teamtilldelningen vi upptäckte blir plötsligt väldigt viktig.
Det här är en vanlig källa till modelleringsmisstag. Vi modellerar det aktuella läget, för det är det vi ser på skärmen. Sedan, några veckor senare, anmäler en detaljhandelspartner en skada och någon frågar: ”Vilket team hade lastbil 117 den 17 mars?” Och vi upptäcker att vi har skrivit över svaret varje gång tilldelningen ändrades.
Ett sätt att behålla den historiken är att göra tilldelningen till en egen post. När ett team tilldelas skapar vi en teamtilldelning med ett startdatum. När tilldelningen ändras sätter vi ett slutdatum på den gamla posten och skapar en ny med ett eget startdatum. Nu är ”vem hade den tilldelningen för sex månader sedan?” en enkel fråga att besvara, i stället för att gräva i fälthistorik eller en logg över dataändringar. Och när ett team väl har haft många tilldelningar kommer någon att fråga vilken som är den aktuella, så jag skulle lägga till en Active-flagga (aktiv) också.
Så när någon berättar om en relation frågar jag inte bara hur sakerna hänger ihop. Jag frågar: ändras relationen, och bryr vi oss om dess historik?
Rita innan du konfigurerar
Section titled “Rita innan du konfigurerar ”Vår modell för Steve Trucking börjar bli användbar. Vi vet vilka relationer som är en-till-många, var en många-till-många döljer ett annat begrepp, vilka relationer som är valfria och vilka som ändras över tid. Och vi har fortfarande inte skapat ett enda Salesforce-objekt. Det är avsiktligt.
Det här diagrammet ska vara något jag kan lägga fram för verksamheten, och de ska inte behöva kunna Salesforce för att säga om det stämmer. Om de inte kan validera det för att det är fullt av Salesforce-terminologi har jag gått för snabbt till den fysiska designen.
Vad en arkitekt bestämmer här
Section titled “Vad en arkitekt bestämmer här ”När jag arbetar igenom relationerna i en konceptuell modell bestämmer jag:
- Hur verksamhetens viktigaste entiteter hänger ihop med varandra.
- Om varje relation är en-till-en, en-till-många eller många-till-många, nu och över tid.
- Om varje relation är obligatorisk eller valfri.
- Om en många-till-många-relation döljer ett meningsfullt affärsbegrepp.
- Om relationen ändras över tid, och om vi behöver dess historik.
Lookup eller master-detail, konfiguration av kopplingsobjekt, kaskadbeteende och delning är fysiska beslut; dit kommer vi. Just nu besvarar vi fortfarande den viktigare frågan: hur fungerar den här verksamheten egentligen? När vi förstår entiteterna och relationerna mellan dem kan vi börja lägga till detaljerna som beskriver dem. Det är då vår konceptuella modell börjar bli en logisk datamodell.