Strana Vztah Vzor. Jak modelovat vztahy

Vztahy jsou všude:mezi lidmi, mezi organizacemi, mezi organizacemi a lidmi. Přemýšlejte o tom, že jste zaměstnancem společnosti, členem projektového týmu nebo dceřinou společností jiné společnosti. Existuje přímočarý způsob, jak přesně modelovat a řídit všechny tyto vztahy? Můžeme snadno odpovědět na otázku ‚Kdo ví kdo?‘

Rychlý přehled vztahů

Jak přesně byl tento základní model odvozen, bylo popsáno v mém předchozím článku Flexibilní a spravovatelné návrhy kusovníků (BOM).

V tomto modelu a v konvenčním návrhu kusovníku je 1st interactor bývá nadřazenou Party ve Relationship – zaměstnavatel spíše než zaměstnanec, vedoucí týmu spíše než člen týmu atd.

Takto mohou data vypadat (s rolí jednotlivých stran v závorkách):

Sofistikovanější model

Představte si, že chcete modelovat vývojový tým projektu, jako je tento:

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

Většina rolí v této týmové hierarchii je reálná – např. analytik požadavků se hlásí systémovému analytikovi. Jiný způsob, jak se na to dívat, je, že analytik požadavků spravuje analytika požadavků.

Vztahy mezi rolemi lze číst zleva doprava (LTR) nebo zprava doleva (RTL). Obvykle je nejlepší držet se jedné nebo druhé konvence – LTR nebo RTL – ale v praxi možná zjistíte, že existují výjimky.

Všimněte si také, že tento diagram ukazuje různé způsoby seskupování rolí. Některé role jsou skutečné, jak jsme diskutovali; jiné jsou logické – např. technická skupina, tréninková skupina, základní tým a podpůrný tým.

Můžeme říci, že tento diagram definuje strukturu týmu pomocí rolí potřebných k dokončení vývojového týmu projektu. To se liší od skutečné instance týmu, která by se skládala ze skutečných jmen lidí proti každé z rolí.

Potřebujeme tedy datový model, který je flexibilní a konfigurovatelný , jako je tento:

Žluté tabulky obsahují metadata a modré tabulky obsahují firemní údaje .

Nastavení základních metadat

Začneme vyplněním party_type stůl. Tato tabulka rozlišuje, zda je stranou osoba nebo organizace.

Než uděláme mnoho jiného, ​​musíme také definovat role v role_type tabulka metadat:

Nepochybně jste si všimli, že každá role patří buď osobě, nebo organizaci. Pro představu toho, co je možné, jsem přidal několik externích organizací, se kterými má vztahy naše fiktivní společnost s ručením omezeným, ABC Software Inc.

Přidání metadat zaměstnání

Dalším úkolem je definovat platné dvojice rolí mezi prvním a druhým interaktorem. To zase definuje typy vztahů, které strany mohou mít. Začněme vyplňovat role_type_relationship tabulka metadat s rolemi zaměstnanců společnosti. Koneckonců nemůžeme vytvářet týmy, aniž bychom nejprve měli pracovníky:

Předpokládejme, že společnost ABC Software Inc. najme dva zaměstnance, Jane Smith a Alex Jones, pro následující role:

Když uděláte krok zpět v čase, uvidíte, že tento vztah začal dříve, než byli najati Jane Smith a Alex Jones; museli se ucházet o práci ve společnosti ABC Software Inc. Vztah by vypadal takto:

Začínáte vidět možnosti, které party vztah vzor podporuje?

Nemáme tabulku s názvem applicant a další tabulka s názvem employee , jak lze nalézt u jiných modelů. Pokud se nad tím zamyslíte, měli by mnoho stejných atributů – jméno, adresa, datum narození atd.; museli byste zkopírovat hodnoty z applicant na employee po úspěšném pronájmu. Ale byli zúčastnění lidé přeměněni z jedné věci na druhou? Samozřejmě že ne! Jsou to stále stejní lidé!

Ve skutečnosti změnil se pouze vztah mezi ABC Software Inc. a Jane Smith nebo Alex Jones. A to je přesně to, co modeluje vzor vztahu stran.

Pokračování:Metadata projektového týmu

Než budeme moci vytvořit party_relationship Abychom mohli definovat skutečnost, že Jane Smithová řídí Alexe Jonese, musíme definovat strukturu vývojového týmu projektu. Toto je jen otázka párování rodičovských a podřízených rolí, aby se vytvořila platná hierarchie:

U všech výše uvedených rolí se vztah čte zleva doprava – např. projektový manažer řídí databázového inženýra. Případně můžete použít formát zprava doleva (databázový inženýr je podřízen projektovému manažerovi), pokud je to vaše preferovaná konvence.

Nakonec musíme definovat vztah mezi našimi dvěma novými zaměstnanci:

Samozřejmě můžete mít libovolný počet týmů ve tvaru této hierarchie. V jistém smyslu tedy party_relationship je instancí role_type_relationship . To je podobné způsobu, jakým je objekt instancí třídy v OO programování.

Včetně logických metadat

S odkazem na diagram vývojového týmu projektu můžeme také definovat následující logické vztahy mezi rolemi :

Všimněte si, že party_relationship nikdy není instance logického role_type_relationship . Jaký má tedy smysl definovat logické vztahy?

No, to se asi nejlépe vysvětluje na příkladu. Představte si, že byste chtěli poslat dopis všem zaměstnancům, kteří jsou logicky členy podpůrného týmu. Chcete-li vytvořit seznam adresátů, napsali byste dotaz, který vrátí všechny role interakce LOGICAL Support Team 2 spojené se stejnými rolemi REAL 2, připojené k party_relationship , připojil se ke 2 party . To vám umožní získat jména a adresy všech zúčastněných.

Zvláštní případ

Možná jste si všimli několika neobvyklých položek v role_type tabulka metadat, konkrétně:

Toto jsou dva případy zvláštního případu, ke kterému dochází, když má strana k sobě reflexivní vztah:

Například pro samostatně výdělečně činného systémového analytika jsou interaktory 1 a 2 v party_relationship odkažte se zpět na stejnou party řádek – tj. oba sloupce cizího klíče obsahují přesně stejné party.ID hodnotu.

Jak je důležité mít kontext

Představte si, že máme malý analytický tým, který se v podstatě skládá z větve mezi projektovým manažerem a technickým úředníkem:

Každý ze vztahů zde existuje i ve struktuře projektového vývojového týmu. Jak tedy odlišíme vztah jednoho projektového manažera → systémového analytika od druhého?

Používáme volitelný kontext cizí klíč mezi role_type_relationship a role_type . Pro malý analytický tým jsme nastavili kontext všech vztahů na „malý analytický tým“, prvek nejvyšší úrovně. A totéž děláme pro strukturu týmu pro vývoj projektu. Když procházíme strukturou, děláme to pouze pro typ týmu, který nás zajímá.

Výhody a nevýhody vzoru kusovníku vztahu strany

Pokud jste četli mé další články na toto téma, pravděpodobně jste uhodli, že jsem fanouškem návrhového vzoru Bill of Materials. Je to jednoduché, ale velmi silné. Upozornění je, že musí být používán správně a musí být přizpůsoben tak, aby vaše implementace zůstala zvládnutelná.

V této implementaci vzoru kusovníku vztahů mezi stranami zajišťujeme, aby naše vztahy zůstaly přesné tím, že nejprve definujeme přípustné vztahy mezi interaktory, které existují v naší doméně. To by například zabránilo tomu, aby Internal Revenue Service byla „zaměstnána“ jako webdesignér ve společnosti ABC Software Inc.

Jaké možnosti vyplývají z definování vztahů tímto způsobem? Vaše organizace možná potřebuje vědět, pro jaké jiné organizace vaši současní zaměstnanci a dodavatelé pracovali. To pomáhá předcházet možným střetům zájmů nebo dokonce podvodům. Příkladem toho je udělující organizace. Potřebuje vědět, na kterých školách jeho hodnotitelé dříve učili, aby zajistili, že nebudou hodnotit písemné zkoušky z těchto škol. V modelu vztahu mezi stranami je snadné dotazovat se a získat tyto informace.

Na druhou stranu může vaše organizace chtít uchovávat stejné informace, protože by mohly představovat obchodní příležitosti. Záleží jen na vaší doméně.

Stručně řečeno, poznatky, které můžete získat z dobře strukturovaných dat o vztazích mezi stranami, mohou být neocenitelné.