Partsforholdsmønster. Sådan modelleres relationer

Relationer er overalt:mellem mennesker, mellem organisationer, mellem organisationer og mennesker. Tænk på at være ansat i en virksomhed, være medlem af et projektteam eller være et datterselskab af en anden virksomhed. Er der en ligetil måde at præcist modellere og administrere alle disse relationer? Kan vi nemt svare på spørgsmålet ’Hvem ved hvem?’

En hurtig gennemgang af forhold

Præcis hvordan denne grundlæggende model blev udledt, blev beskrevet i min tidligere artikel, Fleksible and Manageable Bill of Materials (BOM) Designs.

I denne model og i konventionelt styklistedesign er 1st interactor plejer at være den overlegne Party i Relationship – arbejdsgiver frem for medarbejder, teamleder frem for teammedlem osv.

Sådan kan dataene se ud (med den rolle, hver part spiller i parentes):

En mere sofistikeret model

Forestil dig, at du vil modellere et projektudviklingsteam som følgende:

Kilde:https://www.edrawsoft.com/template-matrix -org-chart.php

De fleste af rollerne i dette teamhierarki er reelle – f.eks. kravanalytikeren rapporterer til systemanalytikeren. En anden måde at se det på er, at systemanalytikeren styrer kravanalytikeren.

Relationer mellem roller kan læses fra venstre mod højre (LTR) eller fra højre mod venstre (RTL). Det er normalt bedst at holde sig til den ene eller den anden konvention – LTR eller RTL – men i praksis kan du opleve, at der er undtagelser fra dette.

Bemærk også, at dette diagram viser forskellige måder at gruppere roller på. Nogle roller er ægte, som vi har diskuteret; andre er logiske – f.eks. den tekniske gruppe, træningsgruppen, kerneteamet og supportteamet.

Vi kan sige, at dette diagram definerer teamstruktur bruge de roller, der kræves for at fuldføre projektudviklingsteamet. Dette er forskelligt fra en faktisk forekomst af holdet, som ville bestå af rigtige personers navne mod hver af rollerne.

Så vi har brug for en datamodel, der er fleksibel og konfigurerbar , såsom denne:

De gule tabeller indeholder metadata , og de blå tabeller indeholder virksomhedsdata .

Indstilling af grundmetadata

Vi starter med at udfylde party_type bord. Denne tabel skelner mellem, om en part er en person eller en organisation.

Før vi gør meget andet, skal vi også definere roller i role_type metadatatabel:

Du har uden tvivl bemærket, at hver rolle tilhører enten en person eller en organisation. For at give en idé om, hvad der er muligt, har jeg tilføjet nogle eksterne organisationer, som vores fiktive aktieselskab, ABC Software Inc, har relationer til.

Tilføjelse af ansættelsesmetadata

Den næste opgave er at definere de gyldige rollepar mellem første og anden interaktør. Til gengæld definerer dette, hvilke typer relationer parterne kan have. Lad os begynde at udfylde role_type_relationship metadatatabel med virksomhedens medarbejderroller. Vi kan trods alt ikke oprette teams uden først at have medarbejdere:

Antag, at ABC Software Inc. vil ansætte to medarbejdere, Jane Smith og Alex Jones, til følgende roller:

Tager du et skridt tilbage i tiden, vil du se, at dette forhold startede før Jane Smith og Alex Jones blev ansat; de skulle søge job hos ABC Software Inc. Forholdet ville have set sådan ud:

Er du begyndt at se de muligheder, som festforholdsmønsteret understøtter?

Vi har ikke en tabel, der hedder applicant og en anden tabel kaldet employee , som kan findes i andre modeller. Hvis du tænker over det, ville de dele mange af de samme egenskaber – navn, adresse, fødselsdato osv.; du skal kopiere værdierne fra applicant til employee ved succesfuld ansættelse. Men er de involverede mennesker blevet forvandlet fra det ene til det andet? Selvfølgelig ikke! De er stadig de samme mennesker!

Faktisk er det kun forholdet, der er ændret mellem ABC Software Inc. og Jane Smith eller Alex Jones. Og det er netop, hvad partiforholdsmønsteret modellerer.

Fortsætter på:Projektteammetadata

Før vi kan oprette et party_relationship tabel for at definere det faktum, at Jane Smith administrerer Alex Jones, skal vi definere projektudviklingsteamets struktur. Dette er kun et spørgsmål om at parre forældre- og underordnede roller for at danne et gyldigt hierarki:

For alle ovenstående roller læses forholdet fra venstre mod højre – f.eks. projektlederen leder databaseingeniøren. Alternativt kan du bruge højre-til-venstre-formatet (databaseingeniøren rapporterer til projektlederen), hvis det er din foretrukne konvention.

Endelig skal vi definere forholdet mellem vores to nye medarbejdere:

Selvfølgelig kan du have et hvilket som helst antal hold i form af dette hierarki. På en måde, derfor party_relationship er en forekomst af role_type_relationship . Dette svarer til den måde, et objekt er en instans af en klasse i OO-programmering.

Inklusive logiske metadata

Med reference til projektudviklingsteamdiagrammet kan vi også definere følgende logiske relationer mellem roller :

Bemærk, at party_relationship er aldrig en instans af et logisk role_type_relationship . Så hvad er meningen med at definere logiske relationer?

Nå, dette er nok bedst forklaret ved hjælp af et eksempel. Forestil dig, at du ville sende et brev til alle medarbejdere, som logisk set er medlemmer af supportteamet. For at oprette en mailingliste skal du skrive en forespørgsel, der returnerer alle LOGICAL Support Team 2-interaktørroller, der er knyttet til de samme ÆGTE 2 interaktørroller, forbundet med party_relationship , sluttede sig til 2-interaktør-party . Dette vil give dig mulighed for at få navne og adresser på alle involverede.

Et særligt tilfælde

Du har muligvis bemærket et par usædvanlige poster i role_type metadatatabel, nemlig:

Dette er to tilfælde af et særligt tilfælde, som opstår, når en part har et refleksivt forhold til sig selv:

For eksempel, for en selvstændig systemanalytiker, 1- og 2-interaktørerne i party_relationship henvise tilbage til det samme party række – dvs. begge fremmednøglekolonner indeholder nøjagtig det samme party.ID værdi.

Vigtigheden af ​​at have kontekst

Forestil dig, at vi har et lille analyseteam, der grundlæggende er dannet af grenen mellem projektlederen og den tekniske kontorist:

Hver af relationerne her findes også i projektudviklingsteamstrukturen. Så hvordan adskiller vi en projektleder → systemanalytikerforhold fra en anden?

Vi bruger den valgfri kontekst fremmednøgle mellem role_type_relationship og role_type . For det lille analyseteam sætter vi konteksten for alle relationer til "lille analyseteam", elementet på øverste niveau. Og vi gør det samme for projektudviklingsteamstrukturen. Når vi krydser strukturen, gør vi det kun for den type team, vi er interesserede i.

Fordele og ulemper med partiforhold styklistemønster

Hvis du har læst mine andre artikler om emnet, har du sikkert gættet, at jeg er fan af Bill of Materials designmønsteret. Det er enkelt, men meget kraftfuldt. Forbeholdet er, at det skal bruges korrekt, og det skal skræddersyes, så din implementering forbliver overskuelig.

I denne partsrelationsimplementering af styklistemønsteret sikrer vi, at vores relationer forbliver nøjagtige ved først at definere de tilladte relationer mellem de interaktører, der findes i vores domæne. Dette ville for eksempel forhindre Internal Revenue Service i at blive "ansat" som webdesigner hos ABC Software Inc.

Hvilke muligheder opstår ved at definere relationer på denne måde? Nå, din organisation skal muligvis vide, hvilke andre organisationer dine nuværende medarbejdere og entreprenører har arbejdet for. Dette hjælper med at undgå mulige interessekonflikter eller endda svindel. Et eksempel på dette er en prisgivende organisation. Den skal vide, på hvilke skoler dens bedømmere tidligere har undervist for at sikre, at de ikke vurderer eksamensopgaver fra disse skoler. I en partsforholdsmodel er det nemt at forespørge og få disse oplysninger.

På den anden side vil din organisation måske gemme de samme oplysninger, fordi det kan give forretningsmuligheder. Det afhænger kun af dit domæne.

Kort sagt kan den indsigt, du kan få fra velstrukturerede partsforholdsdata, være uvurderlig.