Wzorzec relacji partyjnej. Jak modelować relacje

Relacje są wszędzie:między ludźmi, między organizacjami, między organizacjami i ludźmi. Pomyśl o byciu pracownikiem firmy, byciu członkiem zespołu projektowego lub byciu filią innej firmy. Czy istnieje prosty sposób na dokładne modelowanie i zarządzanie wszystkimi tymi relacjami? Czy możemy łatwo odpowiedzieć na pytanie „Kto wie kto?”

Szybki przegląd relacji

Dokładnie sposób, w jaki powstał ten podstawowy model, został opisany w moim poprzednim artykule, Elastyczne i łatwe w zarządzaniu projekty zestawień materiałowych (BOM).

W tym modelu i w konwencjonalnym projekcie BOM, 1st interactor wydaje się być lepszą Party w Relationship – pracodawca zamiast pracownika, lider zespołu zamiast członka zespołu itp.

Oto, jak mogą wyglądać dane (z rolą każdej ze stron w nawiasach):

Bardziej wyrafinowany model

Wyobraź sobie, że chcesz zamodelować zespół projektowy w następujący sposób:

Źródło:https://www.edrawsoft.com/template-matrix -org-chart.php

Większość ról w tej hierarchii zespołu jest realna – m.in. analityk wymagań podlega analitykowi systemu. Innym sposobem patrzenia na to jest to, że analityk systemowy zarządza analitykiem wymagań.

Relacje między rolami można czytać od lewej do prawej (LTR) lub od prawej do lewej (RTL). Zwykle najlepiej jest trzymać się jednej lub drugiej konwencji – LTR lub RTL – ale w praktyce może się okazać, że są od tego wyjątki.

Zauważ też, że ten diagram pokazuje różne sposoby grupowania ról. Niektóre role są prawdziwe, jak mówiliśmy; inne są logiczne – np. grupa techniczna, grupa szkoleniowa, główny zespół i zespół wsparcia.

Można powiedzieć, że ten diagram definiuje strukturę zespołu z wykorzystaniem ról wymaganych do skompletowania zespołu deweloperskiego projektu. Różni się to od rzeczywistej instancji zespołu, która składałaby się z nazwisk prawdziwych osób w odniesieniu do każdej z ról.

Potrzebujemy więc modelu danych, który jest elastyczny i konfigurowalny , taki jak ten:

Żółte tabele zawierają metadane , a niebieskie tabele zawierają biznesowe bazy danych .

Ustawianie metadanych podstawy

Zaczniemy od wypełnienia party_type stół. Ta tabela rozróżnia, czy impreza jest osobą, czy organizacją.

Zanim zrobimy wiele więcej, musimy również zdefiniować role w role_type tabela metadanych:

Bez wątpienia zauważyłeś, że każda rola należy do osoby lub organizacji. Aby dać wyobrażenie o tym, co jest możliwe, dodałem kilka zewnętrznych organizacji, z którymi współpracuje nasza fikcyjna spółka z ograniczoną odpowiedzialnością, ABC Software Inc.

Dodawanie metadanych zatrudnienia

Następnym zadaniem jest zdefiniowanie prawidłowych par ról między pierwszym a drugim interaktorem. To z kolei określa rodzaje relacji, jakie mogą mieć strony. Zacznijmy wypełniać role_type_relationship tabela metadanych z rolami pracowników firmy. W końcu nie możemy tworzyć zespołów bez uprzednich pracowników:

Załóżmy, że ABC Software Inc. zatrudni dwóch pracowników, Jane Smith i Alex Jones, na następujące stanowiska:

Cofając się w czasie, zobaczysz, że ten związek zaczął się przed zatrudnieniem Jane Smith i Alexa Jonesa; musieli ubiegać się o pracę w ABC Software Inc. Relacja wyglądałaby tak:

Czy zaczynasz dostrzegać możliwości, jakie wzorzec relacji między stronami? obsługuje?

Nie mamy tabeli o nazwie applicant i kolejna tabela o nazwie employee , jakie można znaleźć w innych modelach. Jeśli się nad tym zastanowić, będą miały wiele takich samych atrybutów – imię i nazwisko, adres, data urodzenia itp.; musiałbyś skopiować wartości od applicant do employee po pomyślnym zatrudnieniu. Ale czy zaangażowani ludzie zostali przemienieni z jednej rzeczy w drugą? Oczywiście nie! To wciąż ci sami ludzie!

W rzeczywistości tylko relacja uległa zmianie pomiędzy ABC Software Inc. a Jane Smith lub Alexem Jonesem. I to jest dokładnie to, co modeluje wzorce relacji partyjnych.

Kontynuacja:Metadane zespołu projektowego

Zanim będziemy mogli utworzyć party_relationship tabeli, aby określić, że Jane Smith zarządza Alexem Jonesem, musimy zdefiniować strukturę zespołu deweloperskiego projektu. To tylko kwestia parowania ról rodzica i dziecka w celu utworzenia prawidłowej hierarchii:

Dla wszystkich powyższych ról relacja jest odczytywana od lewej do prawej – np. kierownik projektu zarządza inżynierem bazy danych. Alternatywnie możesz przyjąć format od prawej do lewej (inżynier bazy danych zgłasza się do kierownika projektu), jeśli jest to preferowana konwencja.

Na koniec musimy zdefiniować relacje między naszymi dwoma nowymi pracownikami:

Oczywiście możesz mieć dowolną liczbę zespołów w kształcie tej hierarchii. W pewnym sensie zatem party_relationship jest instancją role_type_relationship . Jest to podobne do sposobu, w jaki obiekt jest instancją klasy w programowaniu obiektowym.

W tym metadane logiczne

W odniesieniu do diagramu zespołu deweloperskiego projektu możemy również zdefiniować następujące logiczne relacje między rolami :

Pamiętaj, że party_relationship nigdy nie jest instancją logicznej role_type_relationship . Jaki jest więc sens definiowania relacji logicznych?

Cóż, najlepiej to wyjaśnić na przykładzie. Wyobraź sobie, że chcesz wysłać list do wszystkich pracowników, którzy logicznie są członkami zespołu wsparcia. Aby utworzyć listę mailingową, napisz zapytanie, które zwróci wszystkie role interaktora LOGICAL Support Team 2 połączone z tymi samymi rolami interaktora REAL 2, połączone z party_relationship , dołączył do 2 interakcji party . Umożliwiłoby to uzyskanie nazwisk i adresów wszystkich zainteresowanych.

Specjalny przypadek

Być może zauważyłeś kilka nietypowych wpisów w role_type tabela metadanych, a mianowicie:

Oto dwa przypadki szczególnego przypadku, który ma miejsce, gdy strona ma ze sobą refleksyjną relację:

Na przykład dla samozatrudnionego analityka systemu, interaktory 1 i 2 w party_relationship wróć do tej samej party wiersz – tzn. obie kolumny kluczy obcych zawierają dokładnie ten sam party.ID wartość.

Znaczenie posiadania kontekstu

Wyobraź sobie, że mamy mały zespół analityków, który zasadniczo składa się z gałęzi między kierownikiem projektu a pracownikiem technicznym:

Każda z relacji istnieje tutaj również w strukturze zespołu ds. rozwoju projektu. Jak więc odróżnić jednego kierownika projektu → analityka systemu od innego?

Używamy kontekstu opcjonalnego klucz obcy między role_type_relationship i role_type . Dla małego zespołu analitycznego ustawiamy kontekst wszystkich relacji na „mały zespół analityczny”, element najwyższego poziomu. I robimy to samo w przypadku struktury zespołu projektowego. Kiedy przemierzamy strukturę, robimy to tylko dla typu zespołu, który nas interesuje.

Wzorzec BOM relacji ze stronami Plusy i minusy

Jeśli czytałeś moje inne artykuły na ten temat, prawdopodobnie zgadłeś, że jestem fanem wzorca projektowego Bill of Materials. Jest prosty, ale bardzo potężny. Zastrzeżeniem jest to, że musi być odpowiednio używany i musi być dostosowany, aby Twoja implementacja była możliwa do zarządzania.

W tej implementacji wzorca BOM relacji między stronami zapewniamy, że nasze relacje pozostają dokładne, najpierw określając dopuszczalne relacje między interaktorami istniejącymi w naszej domenie. Uniemożliwiłoby to na przykład „zatrudnieniu” Internal Revenue Service jako projektanta stron internetowych w ABC Software Inc.

Jakie możliwości wynikają z definiowania relacji w ten sposób? Cóż, Twoja organizacja może potrzebować wiedzieć, dla jakich innych organizacji pracowali Twoi obecni pracownicy i kontrahenci. Pomaga to uniknąć możliwych konfliktów interesów, a nawet oszustw. Przykładem tego jest organizacja nagradzająca. Musi wiedzieć, w jakich szkołach wcześniej uczyli jej asesorzy, aby upewnić się, że nie oceniają prac egzaminacyjnych z tych szkół. W modelu relacji ze stronami łatwo jest wyszukiwać i uzyskiwać te informacje.

Z drugiej strony Twoja organizacja może chcieć przechowywać te same informacje, ponieważ może to przedstawiać możliwości biznesowe. Zależy to tylko od Twojej domeny.

Krótko mówiąc, spostrzeżenia, które można uzyskać z dobrze ustrukturyzowanych danych o relacjach między stronami, mogą być bezcenne.