パーティー関係パターン。関係をモデル化する方法

関係はどこにでもあります：人の間、組織の間、組織と人の間。会社の従業員、プロジェクトチームのメンバー、または別の会社の子会社になることを考えてください。これらすべての関係を正確にモデル化して管理する簡単な方法はありますか？ 「誰が誰を知っているか」という質問に簡単に答えることができますか？

関係の簡単なレビュー

この基本モデルがどのように導き出されたかは、前回の記事「柔軟で管理しやすい部品表（BOM）の設計」で説明されています。

このモデルと従来のBOM設計では、1st interactor 優れたParty Relationship –従業員ではなく雇用主、チームメンバーではなくチームリーダーなど。

データは次のようになります（括弧内に各当事者が果たす役割を含む）：

より洗練されたモデル

次のようなプロジェクト開発チームをモデル化するとします。

出典：https：//www.edrawsoft.com/template-matrix -org-chart.php

このチーム階層のほとんどの役割は実際のものです。要件アナリストはシステムアナリストに報告します。別の見方をすれば、システムアナリストが要件アナリストを管理しているということです。

ロール間の関係は、左から右（LTR）または右から左（RTL）に読み取ることができます。通常は、LTRまたはRTLのいずれかの規則に従うのが最善ですが、実際には、これには例外がある場合があります。

また、この図は役割をグループ化するさまざまな方法を示していることに注意してください。すでに説明したように、いくつかの役割は現実のものです。他のものは論理的です-例えば。技術グループ、トレーニンググループ、コアチーム、サポートチーム。

この図はチーム構造を定義すると言えます プロジェクト開発チームを完了するために必要な役割を使用します。これは、各役割に対する実際の人の名前で構成されるチームの実際のインスタンスとは異なります。

そのため、柔軟で構成可能なデータモデルが必要です。 、このような：

黄色のテーブルにはメタデータが含まれています 、および青い表にはビジネスデータが含まれています 。

Foundationメタデータの設定

まず、party_type テーブル。この表は、当事者が個人であるか組織であるかを区別します。

他の多くのことを行う前に、role_type メタデータテーブル：

それぞれの役割が個人または組織のいずれかに属していることは間違いありません。何が可能かを理解するために、架空の有限会社であるABCSoftwareIncが関係している外部組織をいくつか追加しました。

雇用メタデータの追加

次のタスクは、有効な役割のペアを定義することです。 最初のインタラクターと2番目のインタラクターの間。次に、これは当事者が持つことができる関係のタイプを定義します。 role_type_relationship 会社の従業員の役割を持つメタデータテーブル。結局のところ、最初に労働者がいなければチームを作成することはできません。

ABC Software Inc.が、次の役割のために2人の従業員、JaneSmithとAlexJonesを雇用するとします。

時間をさかのぼると、この関係はジェーンスミスとアレックスジョーンズが雇われる前に始まったことがわかります。彼らはABCSoftwareIncでの仕事に応募しなければなりませんでした。関係は次のようになります。

パーティ関係パターンの可能性を見始めていますか サポートしますか？

applicant employee 、他のモデルに見られるように。あなたがそれについて考えるならば、彼らは同じ属性の多くを共有するでしょう–名前、住所、生年月日など。 applicant employee 採用が成功すると。しかし、関係者はあるものから別のものに変わったのでしょうか？もちろん違います！彼らはまだ同じ人です！

実際には、変更されたのは関係だけです ABCSoftwareInc.とJaneSmithまたはAlexJonesの間。そして、これはまさにパーティー関係パターンがモデル化するものです。

続行：プロジェクトチームのメタデータ

party_relationship JaneSmithがAlexJonesを管理しているという事実を定義するための表では、プロジェクト開発チームの構造を定義する必要があります。これは、親と子の役割を組み合わせて有効な階層を形成するための問題です。

上記のすべての役割について、関係は左から右に読み取られます。例：プロジェクトマネージャーはデータベースエンジニアを管理します。または、右から左への形式（データベースエンジニアがプロジェクトマネージャーに報告する）を採用することもできます。

最後に、2人の新入社員間の関係を定義する必要があります。

もちろん、この階層の形でチームをいくつでも持つことができます。したがって、ある意味で、party_relationship はのインスタンスです role_type_relationship 。これは、オブジェクトがオブジェクト指向プログラミングのクラスのインスタンスである方法に似ています。

論理メタデータを含む

プロジェクト開発チームの図を参照して、次の役割間の論理的関係を定義することもできます。 ：

party_relationship インスタンスになることはありません 論理的なrole_type_relationship 。では、論理的な関係を定義することのポイントは何ですか？

まあ、これはおそらく例として最もよく説明されています。論理的にサポートチームのメンバーであるすべての従業員に手紙を送りたいと想像してみてください。メーリングリストを作成するには、party_relationship 、2つのインタラクターparty 。これにより、関係者全員の名前と住所を取得できます。

特別な場合

role_type メタデータテーブル、つまり：

これらは、当事者がそれ自体と反射的な関係を持っているときに発生する特殊なケースの2つの例です。

たとえば、自営業のシステムアナリストの場合、party_relationshipの1人と2人のインタラクター 同じpartyを参照してください 行–つまり、両方の外部キー列にまったく同じparty.IDが含まれています 値。

コンテキストを持つことの重要性

基本的にプロジェクトマネージャーと技術担当者の間のブランチから形成された小さな分析チームがあると想像してください：

ここでの各関係は、プロジェクト開発チームの構造にも存在します。では、あるプロジェクトマネージャー→システムアナリストの関係を別のプロジェクトマネージャーとどのように区別するのでしょうか。

オプションのコンテキストを使用します role_type_relationship およびrole_type 。小規模な分析チームの場合、すべての関係のコンテキストを、最上位の要素である「小規模な分析チーム」に設定します。そして、プロジェクト開発チームの構造についても同じようなことをします。構造をトラバースするときは、関心のあるタイプのチームに対してのみトラバースします。

パーティ関係のBOMパターンの長所と短所

このテーマに関する他の記事を読んだことがあれば、おそらく私が部品表のデザインパターンのファンだと推測しているでしょう。シンプルですが、非常に強力です。注意点は、適切に使用する必要があり、実装を管理しやすいように調整する必要があるということです。

このBOMパターンのパーティ関係の実装では、ドメインに存在するインタラクター間の許容可能な関係を最初に定義することにより、関係が正確に保たれるようにします。これにより、たとえば、内国歳入庁がABCSoftwareInc.のWebデザイナーとして「雇用」されるのを防ぐことができます。

この方法で関係を定義することからどのような可能性が生じますか？さて、あなたの組織はあなたの現在の従業員と請負業者が働いている他の組織を知る必要があるかもしれません。これにより、利害の衝突や詐欺の可能性を回避できます。この例は、授与組織です。評価者が以前にどの学校で教えたのかを知って、それらの学校の試験問題を評価しないようにする必要があります。パーティー関係モデルでは、その情報を簡単に照会して取得できます。

一方、ビジネスチャンスをもたらす可能性があるため、組織は同じ情報を保存したい場合があります。ドメインによって異なります。

つまり、適切に構成されたパーティ関係データから得られる洞察は非常に貴重です。