Parteibeziehungsmuster. Wie man Beziehungen modelliert

Beziehungen sind überall:zwischen Menschen, zwischen Organisationen, zwischen Organisationen und Menschen. Stellen Sie sich vor, Mitarbeiter eines Unternehmens, Mitglied eines Projektteams oder Tochtergesellschaft eines anderen Unternehmens zu sein. Gibt es eine einfache Möglichkeit, all diese Beziehungen genau zu modellieren und zu verwalten? Können wir die Frage „Wer kennt wen?“ leicht beantworten.

Ein kurzer Überblick über Beziehungen

Wie genau dieses Grundmodell abgeleitet wurde, wurde in meinem vorherigen Artikel Flexible und verwaltbare Stücklisten (BOM)-Designs beschrieben.

In diesem Modell und im konventionellen BOM-Design der 1st interactor tendenziell die überlegene Party in der Relationship – Arbeitgeber statt Arbeitnehmer, Teamleiter statt Teammitglied usw.

So könnten die Daten aussehen (mit der Rolle, die jede Partei in Klammern spielt):

Ein ausgefeilteres Modell

Stellen Sie sich vor, Sie möchten ein Projektentwicklungsteam wie folgt modellieren:

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

Die meisten Rollen in dieser Teamhierarchie sind real – z. der Anforderungsanalytiker berichtet an den Systemanalytiker. Eine andere Sichtweise ist, dass der Systemanalytiker den Anforderungsanalytiker verwaltet.

Beziehungen zwischen Rollen können von links nach rechts (LTR) oder von rechts nach links (RTL) gelesen werden. Normalerweise ist es am besten, sich an die eine oder andere Konvention zu halten – LTR oder RTL – aber in der Praxis werden Sie vielleicht feststellen, dass es Ausnahmen davon gibt.

Beachten Sie auch, dass dieses Diagramm verschiedene Arten der Gruppierung von Rollen zeigt. Einige Rollen sind real, wie wir besprochen haben; andere sind logisch – z.B. die technische Gruppe, die Schulungsgruppe, das Kernteam und das Support-Team.

Wir können sagen, dass dieses Diagramm die Teamstruktur definiert Verwenden der Rollen, die zum Vervollständigen des Projektentwicklungsteams erforderlich sind. Dies unterscheidet sich von einer tatsächlichen Instanz des Teams, das aus den Namen echter Personen für jede der Rollen bestehen würde.

Wir brauchen also ein Datenmodell, das flexibel und konfigurierbar ist , wie diese hier:

Die gelben Tabellen enthalten Metadaten , und die blauen Tabellen enthalten Geschäftsdaten .

Foundation-Metadaten festlegen

Wir beginnen mit dem Ausfüllen des party_type Tisch. Diese Tabelle unterscheidet, ob eine Partei eine Person oder eine Organisation ist.

Bevor wir viel anderes tun, müssen wir auch Rollen im role_type Metadatentabelle:

Sie haben zweifellos festgestellt, dass jede Rolle entweder einer Person oder einer Organisation gehört. Um eine Vorstellung davon zu geben, was möglich ist, habe ich einige externe Organisationen hinzugefügt, mit denen unsere fiktive Gesellschaft mit beschränkter Haftung, ABC Software Inc, Beziehungen unterhält.

Hinzufügen von Beschäftigungsmetadaten

Die nächste Aufgabe besteht darin, die gültigen Rollenpaare zu definieren zwischen dem ersten und dem zweiten Interaktor. Dies wiederum definiert die Arten von Beziehungen, die Parteien haben können. Beginnen wir mit dem Füllen der role_type_relationship Metadatentabelle mit den Mitarbeiterrollen des Unternehmens. Schließlich können wir keine Teams bilden, ohne zuerst Mitarbeiter zu haben:

Angenommen, ABC Software Inc. stellt zwei Mitarbeiter, Jane Smith und Alex Jones, für die folgenden Rollen ein:

Wenn Sie einen Schritt zurück in die Vergangenheit gehen, würden Sie sehen, dass diese Beziehung begann, bevor Jane Smith und Alex Jones eingestellt wurden; sie mussten sich bei ABC Software Inc. bewerben. Die Beziehung hätte so ausgesehen:

Fangen Sie an, die Möglichkeiten zu erkennen, die das Parteibeziehungsmuster bietet unterstützt?

Wir haben keine Tabelle namens applicant und eine weitere Tabelle namens employee , wie es auch bei anderen Modellen zu finden ist. Wenn Sie darüber nachdenken, würden sie viele der gleichen Attribute teilen – Name, Adresse, Geburtsdatum usw.; Sie müssten die Werte von applicant an employee bei erfolgreicher Anstellung. Aber haben sich die beteiligten Personen von einer Sache in die andere verwandelt? Natürlich nicht! Es sind immer noch dieselben Leute!

Eigentlich hat sich nur die Beziehung verändert zwischen ABC Software Inc. und Jane Smith oder Alex Jones. Und genau das modelliert das Parteibeziehungsmuster.

Fortsetzung:Projektteam-Metadaten

Bevor wir eine party_relationship Um zu definieren, dass Jane Smith Alex Jones verwaltet, müssen wir die Struktur des Projektentwicklungsteams definieren. Dies ist nur eine Frage der Paarung von übergeordneten und untergeordneten Rollen, um eine gültige Hierarchie zu bilden:

Für alle oben genannten Rollen wird die Beziehung von links nach rechts gelesen – z. Der Projektmanager verwaltet den Datenbankingenieur. Alternativ können Sie das Format von rechts nach links übernehmen (der Datenbankingenieur berichtet an den Projektmanager), wenn dies Ihre bevorzugte Konvention ist.

Schließlich müssen wir die Beziehung zwischen unseren beiden neuen Mitarbeitern definieren:

Natürlich können Sie beliebig viele Teams in Form dieser Hierarchie haben. In gewisser Weise also party_relationship ist eine Instanz von role_type_relationship . Dies ähnelt der Art und Weise, wie ein Objekt eine Instanz einer Klasse in der OO-Programmierung ist.

Einschließlich logischer Metadaten

Mit Bezug auf das Diagramm des Projektentwicklungsteams können wir auch die folgenden logischen Beziehungen zwischen Rollen definieren :

Beachten Sie, dass party_relationship ist nie eine Instanz einer logischen role_type_relationship . Wozu also logische Beziehungen definieren?

Nun, das lässt sich wahrscheinlich am besten anhand eines Beispiels erklären. Stellen Sie sich vor, Sie wollten einen Brief an alle Mitarbeiter schicken, die logischerweise Mitglieder des Support-Teams sind. Um eine Mailingliste zu erstellen, würden Sie eine Abfrage schreiben, die alle Interaktionsrollen des LOGISCHEN Support-Teams 2 zurückgibt, die mit denselben REAL 2-Interaktionsrollen verbunden sind, die mit party_relationship , ist der party . Dies würde es Ihnen ermöglichen, die Namen und Adressen aller Beteiligten zu erhalten.

Ein Sonderfall

Möglicherweise sind Ihnen einige ungewöhnliche Einträge im role_type Metadatentabelle, nämlich:

Dies sind zwei Fälle eines Sonderfalls, der auftritt, wenn eine Partei eine reflexive Beziehung zu sich selbst hat:

Zum Beispiel für einen selbstständigen Systemanalytiker die Interaktionspartner 1 und 2 in party_relationship beziehen sich auf dieselbe party Zeile – d.h. beide Fremdschlüsselspalten enthalten genau die gleiche party.ID Wert.

Die Bedeutung des Kontexts

Stellen Sie sich vor, wir haben ein kleines Analytics-Team, das sich im Grunde aus der Branche zwischen dem Projektleiter und dem technischen Sachbearbeiter bildet:

Jede der Beziehungen hier existiert auch in der Struktur des Projektentwicklungsteams. Wie unterscheiden wir also die Beziehung zwischen Projektmanager → Systemanalytiker?

Wir verwenden den optionalen Kontext Fremdschlüssel zwischen role_type_relationship und role_type . Für das kleine Analyseteam setzen wir den Kontext aller Beziehungen zum „kleinen Analyseteam“, dem Element der obersten Ebene. Und wir tun dasselbe für die Struktur des Projektentwicklungsteams. Wenn wir die Struktur durchqueren, tun wir dies nur für den Teamtyp, an dem wir interessiert sind.

Vor- und Nachteile von Stücklistenmustern für Parteienbeziehungen

Wenn Sie meine anderen Artikel zu diesem Thema gelesen haben, haben Sie wahrscheinlich erraten, dass ich ein Fan des Bill of Materials-Designmusters bin. Es ist einfach, aber sehr mächtig. Der Vorbehalt ist, dass es angemessen verwendet und so angepasst werden muss, dass Ihre Implementierung überschaubar bleibt.

Bei dieser Parteibeziehungsimplementierung des BOM-Musters stellen wir sicher, dass unsere Beziehungen korrekt bleiben, indem wir zunächst die zulässigen Beziehungen zwischen den in unserer Domäne vorhandenen Interaktoren definieren. Dies würde beispielsweise verhindern, dass der Internal Revenue Service als Webdesigner bei ABC Software Inc. „angestellt“ wird.

Welche Möglichkeiten ergeben sich aus dieser Art der Beziehungsdefinition? Nun, Ihre Organisation muss möglicherweise wissen, für welche anderen Organisationen Ihre derzeitigen Mitarbeiter und Auftragnehmer gearbeitet haben. Dies trägt dazu bei, mögliche Interessenkonflikte oder sogar Betrug zu vermeiden. Ein Beispiel hierfür ist eine Vergabeorganisation. Es muss wissen, an welchen Schulen seine Prüfer zuvor unterrichtet haben, um sicherzustellen, dass sie keine Prüfungsunterlagen dieser Schulen bewerten. In einem Parteienbeziehungsmodell ist es einfach, diese Informationen abzufragen und zu erhalten.

Andererseits möchte Ihre Organisation möglicherweise dieselben Informationen speichern, weil sie Geschäftsmöglichkeiten bieten könnten. Es hängt nur von Ihrer Domain ab.

Kurz gesagt, die Erkenntnisse, die Sie aus gut strukturierten Beziehungsdaten gewinnen können, können von unschätzbarem Wert sein.