Модел на партийни взаимоотношения. Как да моделирам взаимоотношения

Отношенията са навсякъде:между хора, между организации, между организации и хора. Помислете за това да сте служител на компания, да сте член на проектен екип или да сте дъщерно дружество на друга компания. Има ли лесен начин за точно моделиране и управление на всички тези взаимоотношения? Можем ли лесно да отговорим на въпроса „Кой знае кой?“

Бърз преглед на взаимоотношенията

Как точно е получен този основен модел е описано в предишната ми статия, Гъвкави и управляеми дизайни на материалите (BOM).

В този модел и в конвенционалния дизайн на спецификацията, 1st interactor има тенденция да бъде най-добрата Party в Relationship – работодател, а не служител, ръководител на екип, а не член на екипа и т.н.

Ето как могат да изглеждат данните (с ролята, която всяка страна играе в скоби):

По-усъвършенстван модел

Представете си, че искате да моделирате екип за разработка на проекти по следния начин:

Източник:https://www.edrawsoft.com/template-matrix -org-chart.php

Повечето от ролите в тази йерархия на екипа са реални – напр. анализаторът на изискванията докладва на системния анализатор. Друг начин на разглеждане е, че системният анализатор управлява анализатора на изискванията.

Отношенията между ролите могат да се четат от ляво на дясно (LTR) или от дясно на ляво (RTL). Обикновено е най-добре да се придържате към една или друга конвенция – LTR или RTL – но на практика може да откриете, че има изключения от това.

Също така имайте предвид, че тази диаграма показва различни начини за групиране на роли. Някои роли са реални, както обсъждахме; други са логични – напр. техническата група, групата за обучение, основният екип и екипът за поддръжка.

Можем да кажем, че тази диаграмадефинира екипната структура използвайки ролите, необходими за завършване на екипа за разработка на проекта. Това е различно от действителен екземпляр на екипа, който ще се състои от имена на истински хора срещу всяка от ролите.

Така че имаме нужда от модел на данни, който да е гъвкав и конфигурируем , като този:

Жълтите таблици съдържат метаданни , а сините таблици съдържат бизнес данни .

Задаване на основни метаданни

Ще започнем с попълване на party_type маса. Тази таблица прави разлика дали дадена страна е лице или организация.

Преди да направим много друго, трябва също да дефинираме роли в role_type таблица с метаданни:

Без съмнение сте забелязали, че всяка роля принадлежи или на човек, или на организация. За да дам представа какво е възможно, добавих някои външни организации, с които нашето фиктивно дружество с ограничена отговорност, ABC Software Inc, има взаимоотношения.

Добавяне на метаданни за заетостта

Следващата задача е да дефинирате валидните двойки роли между първия и втория интерактори. Това от своя страна определя видовете взаимоотношения, които страните могат да имат. Нека започнем да попълваме role_type_relationship таблица с метаданни с ролите на служителите на компанията. В крайна сметка не можем да създаваме екипи, без първо да имаме работници:

Да предположим, че ABC Software Inc. ще наеме двама служители, Джейн Смит и Алекс Джоунс, за следните роли:

Ако направите крачка назад във времето, ще видите, че тази връзка е започнала преди да бъдат наети Джейн Смит и Алекс Джоунс; те трябваше да кандидатстват за работа в ABC Software Inc. Връзката щеше да изглежда така:

Започвате ли да виждате възможностите, които има моделът на партийни взаимоотношения поддържа?

Нямаме таблица, наречена applicant и друга таблица, наречена employee , както може да се намери в други модели. Ако се замислите, те биха споделяли много от същите атрибути – име, адрес, дата на раждане и т.н.; ще трябва да копирате стойностите от applicant на employee при успешно наемане. Но дали участващите хора са се трансформирали от едно нещо в друго? Разбира се, че не! Те са все същите хора!

Всъщност, само връзката е променена между ABC Software Inc. и Джейн Смит или Алекс Джоунс. И точно това моделира моделът на партийните взаимоотношения.

Продължаване:Метаданни на екипа по проекта

Преди да можем да създадем party_relationship таблица, за да определим факта, че Джейн Смит управлява Алекс Джоунс, трябва да определим структурата на екипа за разработка на проекта. Това е просто въпрос на сдвояване на родителски и дъщерни роли, за да се формира валидна йерархия:

За всички горепосочени роли връзката се чете отляво надясно – напр. ръководителят на проекта управлява инженера на базата данни. Като алтернатива можете да приемете формата отдясно наляво (инженерът на базата данни докладва на ръководителя на проекта), ако това е предпочитаната от вас конвенция.

И накрая, трябва да дефинираме връзката между нашите двама нови служители:

Разбира се, можете да имате произволен брой екипи във формата на тази йерархия. Следователно в известен смисъл party_relationship е екземпляр на role_type_relationship . Това е подобно на начина, по който обектът е екземпляр на клас в OO програмирането.

Включително логически метаданни

По отношение на диаграмата на екипа за разработване на проекти можем също да дефинираме следните логически връзки между роли :

Имайте предвид, че party_relationship никога не е екземпляр на логическа role_type_relationship . И така, какъв е смисълът от дефинирането на логически връзки?

Е, това вероятно е най-добре обяснено като пример. Представете си, че искате да изпратите писмо до всички служители, които логично са членове на екипа за поддръжка. За да създадете пощенски списък, трябва да напишете заявка, която връща всички роли на LOGICAL Support Team 2 на интерактори, присъединени към същите REAL 2 роли на интерактори, присъединени към party_relationship , се присъедини към party . Това ще ви позволи да получите имената и адресите на всички засегнати.

Специален случай

Може да сте забелязали няколко необичайни записа в role_type таблица с метаданни, а именно:

Това са два случая на специален случай, който възниква, когато дадена страна има рефлексивна връзка със себе си:

Например, за самостоятелно зает системен анализатор, 1 и 2 интерактори в party_relationship се обърнете към същата party ред – т.е. и двете колони на външния ключ съдържат абсолютно същия party.ID стойност.

Важността на наличието на контекст

Представете си, че имаме малък аналитичен екип, който основно се формира от клона между ръководителя на проекта и техническия служител:

Всяка от връзките тук също съществува в структурата на екипа за разработка на проекти. И така, как да разграничим една връзка мениджър на проект → системен анализатор от друга?

Използваме незадължителния контекст външен ключ между role_type_relationship и role_type . За малкия аналитичен екип ние задаваме контекста на всички връзки към „малкия аналитичен екип“, елемента от най-високо ниво. И ние правим същото нещо за структурата на екипа за разработка на проекти. Когато преминаваме през структурата, правим това само за типа екип, който ни интересува.

Плюсове и минуси на модела на спецификацията на партийните взаимоотношения

Ако сте чели другите ми статии по темата, вероятно сте се досетили, че съм фен на модела за дизайн на Списък с материали. Това е просто, но много мощно. Предупреждението е, че трябва да се използва по подходящ начин и трябва да бъде пригодено така, че внедряването ви да остане управляемо.

В тази реализация на модела на спецификацията на взаимоотношенията със страни ние гарантираме, че нашите взаимоотношения остават точни, като първо дефинираме допустимите връзки между интеракторите, които съществуват в нашия домейн. Това например би попречило на Службата за вътрешни приходи да бъде „наета“ като уеб дизайнер в ABC Software Inc.

Какви възможности произтичат от дефинирането на взаимоотношенията по този начин? Е, вашата организация може да се наложи да знае за какви други организации са работили настоящите ви служители и изпълнители. Това помага да се избегнат възможни конфликти на интереси или дори измами. Пример за това е организация за награждаване. Той трябва да знае в кои училища са преподавали неговите оценители преди това, за да гарантира, че няма да оценяват изпитни работи от тези училища. В модела на взаимоотношения със страна е лесно да се направи запитване и да се получи тази информация.

От друга страна, вашата организация може да иска да съхранява същата информация, защото това би могло да предостави бизнес възможности. Просто зависи от вашия домейн.

Накратко, прозренията, които можете да получите от добре структурирани данни за взаимоотношенията между страните, могат да бъдат безценни.