Partijrelatiepatroon. Hoe relaties te modelleren

Relaties zijn overal:tussen mensen, tussen organisaties, tussen organisaties en mensen. Denk aan een werknemer zijn van een bedrijf, lid zijn van een projectteam of een dochteronderneming zijn van een ander bedrijf. Is er een eenvoudige manier om al deze relaties nauwkeurig te modelleren en te beheren? Kunnen we de vraag 'Wie weet wie?' gemakkelijk beantwoorden

Een snel overzicht van relaties

Hoe dit basismodel precies tot stand kwam, werd beschreven in mijn vorige artikel, Flexible and Manageable Bill of Materials (BOM) Designs.

In dit model en in conventioneel stuklijstontwerp, is de 1st interactor is meestal de superieure Party in de Relationship – werkgever in plaats van werknemer, teamleider in plaats van teamlid, enz.

Dit is hoe de gegevens eruit kunnen zien (met de rol die elke partij tussen haakjes speelt):

Een verfijnder model

Stel je voor dat je een projectontwikkelingsteam als volgt wilt modelleren:

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

De meeste rollen in deze teamhiërarchie zijn echt – b.v. de requirementsanalist rapporteert aan de systeemanalist. Een andere manier om ernaar te kijken is dat de systeemanalist de behoefteanalist aanstuurt.

Relaties tussen rollen kunnen van links naar rechts (LTR) of van rechts naar links (RTL) worden gelezen. Het is normaal gesproken het beste om je aan de ene of de andere conventie te houden - LTR of RTL - maar in de praktijk zul je merken dat er uitzonderingen zijn.

Merk ook op dat dit diagram verschillende manieren laat zien om rollen te groeperen. Sommige rollen zijn echt, zoals we hebben besproken; andere zijn logisch – b.v. de technische groep, de trainingsgroep, het kernteam en het ondersteuningsteam.

We kunnen zeggen dat dit diagram de teamstructuur definieert met behulp van de rollen die nodig zijn om het projectontwikkelingsteam te voltooien. Dit verschilt van een echt exemplaar van het team, dat zou bestaan ​​uit de namen van echte mensen bij elk van de rollen.

We hebben dus een datamodel nodig dat flexibel en configureerbaar is , zoals deze:

De gele tabellen bevatten metadata , en de blauwe tabellen bevatten bedrijfsgegevens .

Instellen van metadata van de stichting

We beginnen met het invullen van de party_type tafel. Deze tabel maakt onderscheid of een partij een persoon of een organisatie is.

Voordat we veel anders doen, moeten we ook rollen definiëren in de role_type metadatatabel:

U hebt ongetwijfeld opgemerkt dat elke rol toebehoort aan een persoon of een organisatie. Om een ​​idee te geven van wat er mogelijk is, heb ik enkele externe organisaties toegevoegd waarmee onze fictieve naamloze vennootschap, ABC Software Inc, een relatie heeft.

Werkgelegenheidsmetadata toevoegen

De volgende taak is het definiëren van de geldige rolparen tussen de eerste en de tweede interactie. Dit definieert op zijn beurt de soorten relaties die partijen kunnen hebben. Laten we beginnen met het invullen van de role_type_relationship metadatatabel met de werknemersrollen van het bedrijf. We kunnen tenslotte geen teams maken zonder eerst medewerkers te hebben:

Stel dat ABC Software Inc. twee medewerkers gaat aannemen, Jane Smith en Alex Jones, voor de volgende rollen:

Als je een stap terug in de tijd doet, zou je zien dat deze relatie begon voordat Jane Smith en Alex Jones werden aangenomen; ze moesten solliciteren bij ABC Software Inc. De relatie zou er als volgt hebben uitgezien:

Begin je de mogelijkheden te zien dat het relatiepatroon van de partij ondersteunt?

We hebben geen tabel met de naam applicant en een andere tabel genaamd employee , zoals te vinden in andere modellen. Als je erover nadenkt, zouden ze veel van dezelfde kenmerken delen - naam, adres, geboortedatum, enz.; je zou de waarden moeten kopiëren van applicant naar employee bij succesvolle verhuur. Maar zijn de betrokkenen van het een in het ander getransformeerd? Natuurlijk niet! Het zijn nog steeds dezelfde mensen!

In feite is alleen de relatie veranderd tussen ABC Software Inc. en Jane Smith of Alex Jones. En dit is precies wat het patroon van partijrelaties modelleert.

Vervolg op:metadata projectteam

Voordat we een party_relationship tabel om te definiëren dat Jane Smith Alex Jones aanstuurt, moeten we de structuur van het projectontwikkelingsteam definiëren. Dit is gewoon een kwestie van ouder- en kindrollen koppelen om een ​​geldige hiërarchie te vormen:

Voor alle bovenstaande rollen wordt de relatie van links naar rechts gelezen - b.v. de projectmanager stuurt de database engineer aan. Als alternatief kunt u de rechts-naar-links-indeling gebruiken (de database-engineer rapporteert aan de projectmanager) als dat uw voorkeursconventie is.

Ten slotte moeten we de relatie tussen onze twee nieuwe medewerkers definiëren:

Natuurlijk kunt u een willekeurig aantal teams hebben in de vorm van deze hiërarchie. In zekere zin is daarom party_relationship is een instantie van role_type_relationship . Dit is vergelijkbaar met de manier waarop een object een instantie is van een klasse in OO-programmering.

Inclusief logische metadata

Met verwijzing naar het projectontwikkelingsteamdiagram kunnen we ook de volgende logische relaties tussen rollen definiëren :

Merk op dat party_relationship is nooit een instantie van een logische role_type_relationship . Dus wat heeft het voor zin om logische relaties te definiëren?

Welnu, dit kan waarschijnlijk het beste worden uitgelegd aan de hand van een voorbeeld. Stel je voor dat je een brief wilt sturen naar alle medewerkers die logischerwijs lid zijn van het supportteam. Om een ​​mailinglijst te maken, zou u een query moeten schrijven die alle interactierollen van LOGICAL Support Team 2 retourneert die zijn samengevoegd met dezelfde REAL 2 interactorrollen, verbonden met party_relationship , lid geworden van de 2 interactor party . Dit zou u in staat stellen de namen en adressen van alle betrokkenen te verkrijgen.

Een speciaal geval

Je hebt misschien een aantal ongebruikelijke vermeldingen opgemerkt in de role_type metadatatabel, namelijk:

Dit zijn twee gevallen van een speciaal geval, dat optreedt wanneer een partij een reflexieve relatie met zichzelf heeft:

Bijvoorbeeld, voor een zelfstandige systeemanalist, de 1 en 2 interactors in party_relationship terugverwijzen naar dezelfde party rij – d.w.z. beide vreemde-sleutelkolommen bevatten exact dezelfde party.ID waarde.

Het belang van context

Stel je voor dat we een klein analyseteam hebben dat in feite wordt gevormd uit de tak tussen de projectmanager en de technisch bediende:

Elk van de relaties hier bestaat ook in de structuur van het projectontwikkelingsteam. Dus, hoe onderscheiden we de ene projectmanager → systeemanalistrelatie van de andere?

We gebruiken de optionele context externe sleutel tussen role_type_relationship en role_type . Voor het kleine analyseteam hebben we de context voor alle relaties ingesteld op 'klein analyseteam', het element op het hoogste niveau. En we doen hetzelfde voor de structuur van het projectontwikkelingsteam. Wanneer we de structuur doorkruisen, doen we dit alleen voor het type team waarin we geïnteresseerd zijn.

Partijrelatie stuklijstpatroon voor- en nadelen

Als je mijn andere artikelen over dit onderwerp hebt gelezen, heb je waarschijnlijk geraden dat ik een fan ben van het Bill of Materials-ontwerppatroon. Het is eenvoudig, maar zeer krachtig. Het voorbehoud is dat het op de juiste manier moet worden gebruikt en dat het moet worden aangepast zodat uw implementatie beheersbaar blijft.

In deze partijrelatie-implementatie van het stuklijstpatroon zorgen we ervoor dat onze relaties accuraat blijven door eerst de toelaatbare relaties te definiëren tussen de interactoren die in ons domein bestaan. Dit zou bijvoorbeeld voorkomen dat de Internal Revenue Service wordt "in dienst genomen" als webdesigner bij ABC Software Inc.

Welke mogelijkheden ontstaan ​​er door relaties op deze manier te definiëren? Welnu, uw organisatie moet mogelijk weten voor welke andere organisaties uw huidige werknemers en contractanten hebben gewerkt. Dit helpt mogelijke belangenverstrengeling of zelfs fraude te voorkomen. Een voorbeeld hiervan is een toekennende organisatie. Het moet weten op welke scholen zijn beoordelaars eerder les hebben gegeven om ervoor te zorgen dat ze geen examenwerken van die scholen beoordelen. In een partijrelatiemodel is het gemakkelijk om die informatie op te vragen en te verkrijgen.

Aan de andere kant wil uw organisatie misschien dezelfde informatie opslaan omdat dit zakelijke kansen kan bieden. Het hangt gewoon af van uw domein.

Kortom, de inzichten die u kunt krijgen uit goed gestructureerde gegevens over partijrelaties kunnen van onschatbare waarde zijn.