Partiförhållandemönster. Hur man modellerar relationer

Relationer finns överallt:mellan människor, mellan organisationer, mellan organisationer och människor. Tänk på att vara anställd i ett företag, vara medlem i ett projektteam eller vara ett dotterbolag till ett annat företag. Finns det ett enkelt sätt att noggrant modellera och hantera alla dessa relationer? Kan vi enkelt svara på frågan 'Vem vet vem?'

En snabb genomgång av relationer

Exakt hur denna grundmodell härleddes beskrevs i min tidigare artikel, Flexibla och hanterbara stycklistor (BOM) Designs.

I den här modellen och i konventionell stycklista är 1st interactor tenderar att vara den överlägsna Party i Relationship – arbetsgivare snarare än anställd, teamledare snarare än teammedlem, etc.

Så här kan uppgifterna se ut (med den roll varje part spelar inom parentes):

En mer sofistikerad modell

Föreställ dig att du vill modellera ett projektutvecklingsteam enligt följande:

Källa:https://www.edrawsoft.com/template-matrix -org-chart.php

De flesta av rollerna i denna laghierarki är verkliga – t.ex. kravanalytikern rapporterar till systemanalytikern. Ett annat sätt att se på det är att systemanalytikern sköter kravanalytikern.

Relationer mellan roller kan läsas från vänster till höger (LTR) eller från höger till vänster (RTL). Det är normalt bäst att hålla sig till den ena eller den andra konventionen – LTR eller RTL – men i praktiken kan du upptäcka att det finns undantag från detta.

Lägg också märke till att det här diagrammet visar olika sätt att gruppera roller. Vissa roller är verkliga, som vi har diskuterat; andra är logiska – t.ex. den tekniska gruppen, träningsgruppen, kärnteamet och supportteamet.

Vi kan säga att detta diagram definierar teamstruktur använda de roller som krävs för att slutföra projektutvecklingsteamet. Detta skiljer sig från en faktisk instans av teamet, som skulle bestå av riktiga personers namn mot var och en av rollerna.

Så vi behöver en datamodell som är flexibel och konfigurerbar , som den här:

De gula tabellerna innehåller metadata , och de blå tabellerna innehåller företagsdata .

Ställa in grundmetadata

Vi börjar med att fylla i party_type tabell. Denna tabell skiljer på om ett parti är en person eller en organisation.

Innan vi gör mycket annat måste vi också definiera roller i role_type metadatatabell:

Du har utan tvekan noterat att varje roll tillhör antingen en person eller en organisation. För att ge en uppfattning om vad som är möjligt har jag lagt till några externa organisationer som vårt fiktiva aktiebolag, ABC Software Inc, har relationer med.

Lägga till anställningsmetadata

Nästa uppgift är att definiera de giltiga rollparen mellan den första och andra interaktören. Detta definierar i sin tur vilka typer av relationer parterna kan ha. Låt oss börja fylla i role_type_relationship metadatatabell med företagets anställdas roller. När allt kommer omkring kan vi inte skapa team utan att först ha arbetare:

Anta att ABC Software Inc. kommer att anställa två anställda, Jane Smith och Alex Jones, för följande roller:

Om du tar ett steg tillbaka i tiden skulle du se att detta förhållande började innan Jane Smith och Alex Jones anställdes; de var tvungna att söka jobb på ABC Software Inc. Relationen skulle ha sett ut så här:

Börjar du se de möjligheter som partsrelationsmönstret stöder?

Vi har ingen tabell som heter applicant och en annan tabell som heter employee , som kan finnas i andra modeller. Om du tänker på det, skulle de dela många av samma attribut – namn, adress, födelsedatum, etc; du måste kopiera värdena från applicant till employee vid framgångsrik anställning. Men har de inblandade förvandlats från en sak till en annan? Självklart inte! De är fortfarande samma människor!

Faktum är att det är bara förhållandet som har förändrats mellan ABC Software Inc. och Jane Smith eller Alex Jones. Och det är precis vad partirelationsmönstret modellerar.

Fortsätter på:Project Team Metadata

Innan vi kan skapa en party_relationship tabell för att definiera det faktum att Jane Smith leder Alex Jones, måste vi definiera projektutvecklingsteamets struktur. Det här är bara en fråga om att para ihop överordnade och underordnade roller för att bilda en giltig hierarki:

För alla ovanstående roller läses relationen från vänster till höger – t.ex. projektledaren leder databasingenjören. Alternativt kan du använda formatet från höger till vänster (databasingenjören rapporterar till projektledaren) om det är din föredragna konvention.

Slutligen måste vi definiera relationen mellan våra två nya medarbetare:

Naturligtvis kan du ha valfritt antal lag i form av denna hierarki. På sätt och vis, därför party_relationship är en instans av role_type_relationship . Detta liknar det sätt som ett objekt är en instans av en klass i OO-programmering.

Inklusive logisk metadata

Med hänvisning till diagrammet för projektutvecklingsteamet kan vi också definiera följande logiska relationer mellan roller :

Observera att party_relationship är aldrig en instans av ett logiskt role_type_relationship . Så vad är poängen med att definiera logiska relationer?

Tja, detta förklaras nog bäst som ett exempel. Föreställ dig att du ville skicka ett brev till alla anställda som logiskt sett är medlemmar i supportteamet. För att skapa en e-postlista skulle du skriva en fråga som returnerar alla LOGICAL Support Team 2-interaktörsroller kopplade till samma REAL 2 interaktörsroller, kopplade till party_relationship , gick med i 2 interaktörs party . Detta skulle tillåta dig att få namn och adresser till alla berörda.

Ett specialfall

Du kanske har märkt ett par ovanliga poster i role_type metadatatabell, nämligen:

Det här är två fall av ett specialfall, som inträffar när en part har ett reflexivt förhållande till sig själv:

Till exempel, för en egenföretagare systemanalytiker, interaktörerna 1 och 2 i party_relationship hänvisa tillbaka till samma party rad – dvs båda kolumnerna för främmande nyckel innehåller exakt samma party.ID värde.

Vikten av att ha sammanhang

Föreställ dig att vi har ett litet analysteam som i grunden består av grenen mellan projektledaren och den tekniska tjänstemannen:

Var och en av relationerna här finns också i strukturen för projektutvecklingsteamet. Så, hur skiljer vi en projektledare → systemanalytikerrelation från en annan?

Vi använder det valfria sammanhanget främmande nyckel mellan role_type_relationship och role_type . För det lilla analysteamet sätter vi sammanhanget för alla relationer till "litet analysteam", elementet på toppnivå. Och vi gör samma sak för strukturen för projektutvecklingsteamet. När vi korsar strukturen gör vi det bara för den typ av lag vi är intresserade av.

För- och nackdelar för partirelationer BOM-mönster

Om du har läst mina andra artiklar om ämnet, har du förmodligen gissat att jag är ett fan av Bill of Materials designmönster. Det är enkelt, men väldigt kraftfullt. Förbehållet är att det måste användas på rätt sätt och det måste skräddarsys så att din implementering förblir hanterbar.

I den här partrelationsimplementeringen av BOM-mönstret säkerställer vi att våra relationer förblir korrekta genom att först definiera de tillåtna relationerna mellan de interaktörer som finns i vår domän. Detta skulle till exempel hindra Internal Revenue Service från att "anställas" som webbdesigner på ABC Software Inc.

Vilka möjligheter uppstår genom att definiera relationer på detta sätt? Jo, din organisation kan behöva veta vilka andra organisationer dina nuvarande anställda och entreprenörer har arbetat för. Detta hjälper till att undvika eventuella intressekonflikter eller till och med bedrägerier. Ett exempel på detta är en utdelande organisation. Den måste veta vid vilka skolor dess bedömare tidigare har undervisat för att säkerställa att de inte bedömer tentamensuppgifter från dessa skolor. I en partsrelationsmodell är det lätt att fråga och få den informationen.

Å andra sidan kanske din organisation vill lagra samma information eftersom det kan ge affärsmöjligheter. Det beror bara på din domän.

Kort sagt, de insikter du kan få från välstrukturerade partrelationsdata kan vara ovärderliga.