エンティティーのタイプ

データ・モデルに新しいエンティティー・タイプを定義する場合は、このエンティティーの目的を決定する必要があります。

• アイデンティティー 対象は、すべてが同じ実世界の個人、組織、またはオブジェクトを表すように見えるレコードをリンクします。 共通のアイデンティティーを共有します。 例えば、ビジネス・パートナー・エンティティーを使用して、同じ実世界の企業を表すデータ内の組織レコードを突き合わせることができます。

• アソシエーション 対象は、共有アドレス、雇用主、購買決定など、別の理由で関連付ける必要があるレコードをリンクします。 関連エンティティー・タイプの一般的な例として、世帯があります。 特定の世帯のメンバーを単一のエンティティーに一致させる「世帯」エンティティー・タイプを作成できます。 ハウスホールディング・エンティティーを使用することで、世帯ごとに行動とアクティビティーを追跡および分析できます。

ハウス・ホールディング・エンティティー

次のビデオを視聴して、 IBM Match 360 データ内の世帯を識別するためにアソシエーション・エンティティーを使用する方法を確認してください。

世帯を共有する個人レコードを追跡および識別するのに役立つ関連エンティティー・タイプを作成する場合、考慮すべき重要な要因がいくつかあります。 世帯の管理と形成において、世帯の基準を確立することは重要な第一歩です。 世帯は、明示的な基準、表現された基準、またはこれら 2 つの組み合わせによって定義することができます。

明示的基準 には、データ・モデル内の任意の属性を含めることができます。 以下に、ハウス・ホールディング戦略で考慮する可能性がある明示的な基準の例を示します。

• パーティーは、同じ自宅住所など、特定の住所タイプの同じ住所を共有します。
• パーティーは姓を共有します。
• パーティーは、定義された年齢範囲内にあります。
• パーティーは、自宅の電話番号などの連絡方法を共有します。
• パーティーには、ファミリー関係のように、特定のタイプの関係があります。
• 関係者には、契約のコンテキストで特定の役割があります。 例えば、親には、子が所有するアカウントに対する法定代理人役割がある場合があります。

マッチング・アルゴリズムを使用して世帯を作成するには、明示的な基準を使用します。 IBM Match 360 が世帯エンティティーをアルゴリズム的に作成できるようにするには、このエンティティー・タイプのマッチング属性として、選択した明示的基準を選択します。 マッチング・アルゴリズムの構成については、 マスター・データ・エンティティーを作成するためのデータのマッチングを参照してください。

「表現された基準」 には、データ・モデルの一部ではないその他の情報が含まれます。 表現された基準は、世帯メンバーまたは代理人によって口頭で伝達された可能性があります。 ハウス・ホールディング戦略で考慮できる表現基準の例を以下に示します。

• 当事者は、自分たちが同じ世帯内にいることを伝えました。
• エージェントが、顧客アカウントの初期セットアップ時に世帯情報を収集しました。

表現された基準に基づいて世帯エンティティーを作成するには、レコードを手動でリンクしてエンティティーを形成する必要があります。 マスター・データ・ワークスペースを使用してレコードのリンク・ルールを編集することにより、手動でレコード・リンクを作成できます。 詳しくは、 Exploring master data entities and records in IBM Match 360 with Watsonを参照してください。

エンティティーの属性値の決定

マスター・データ・エンティティーには、以下の 2 つのカテゴリーの属性を含めることができます。

• 値がエンティティーのメンバー・レコードから構成される属性。
• 値がエンティティーに直接保管される属性。 エンティティー属性と呼ばれます。

合成された属性

エンティティーは、そのメンバー・レコードに定義されている値から多くの属性値を派生させます。 エンティティーの属性値は、属性構成ルールのセットを使用して、そのメンバー・レコードから選択されます。 データ・モデル内のエンティティー・タイプごとに、属性構成ルールを定義およびカスタマイズできます。 属性構成について詳しくは、 IBM Match 360を参照してください。

エンティティー属性

エンティティー属性は、そのメンバー・レコードから構成されるのではなく、エンティティー内で直接定義されます。 エンティティー・タイプのデータ・モデルでエンティティー属性を定義します。 データ・モデルの変更については、 データ・モデルのカスタマイズを参照してください。

• エンティティー属性の値を変更するには、エンティティーを直接編集します。 メンバー・レコードを編集しても、エンティティー属性の値には影響しません。 エンティティーの編集について詳しくは、「 IBM Match 360」の「レコードおよびエンティティーの追加および編集」を参照してください。
• マッチング・アルゴリズムによって最初に作成されたエンティティーには、定義されたエンティティー属性値はありません。 マスター・データ・ワークスペースでエンティティを編集して、エンティティ属性に値を指定します。
• 手動の リンク または リンク解除 アクションによって、またはマッチング・アルゴリズムの変更によって、エンティティー属性値が取り込まれたエンティティーが、その構成の変更の結果として削除された場合、そのエンティティー属性値は存続しているエンティティーに転送されます。
• 両方ともエンティティー属性を持つ 2 つのエンティティーがマージされる (一致または手動でリンクされる) 場合、存続するエンティティー ID のエンティティー属性値が優先されます。 問題の属性が値のリストで構成されている場合、システムは両方のエンティティーからのリストをマージします。 マージにより、リストに重複する値が含まれないようになります。 2 つのリストの両方に同じ値が含まれている場合、その値はマージされたリストに 1 回だけ表示されます。

エンティティの永続性

データ・モデルを定義するときに、各エンティティ・タイプの複合ビューをデータベースに保存するか、メンバ・レコードからオンデマンドで構成するかを設定できます。 エンティティ・タイプが永続化するように構成されている場合、各エンティティの合成された属性は、レコードの属性が保存される方法と同様にデータベースに保存される。

エンティティを永続化するように構成すると、データ・スチュワードやビジネス・ユーザは、補足属性、監査属性、およびレコード数やエンティティIDなどのシステム・プロパティを含むエンティティ・データを直接検索できる。 ユーザーは、マスターデータエクスプローラーインターフェースのシンプルまたは高度な検索メカニズムを使用して、永続化されたエンティティを検索することができます。

マスターデータのエンティティの量によっては、エンティティ複合ビューをデータベースに格納すると、データベースのサイズが大幅に増大する可能性があります。

エンティティ・タイプの定義の詳細については、データ・モデルのカスタマイズを参照してください。

システム・プロパティー (監査属性)

データ・モデルのシステム・プロパティーにより、 IBM Match 360 のデータを監査する機能が強化され、データ・ガバナンス・ルールへの準拠が確保されます。 システム・プロパティーは、システムによって定義、収集、および保管され、カスタマイズや変更には使用できません。 データ・モデルの 4 つの異なるエレメント (レコード・タイプ、エンティティー・タイプ、属性タイプ、および関係タイプ) に関連付けられたシステム・プロパティーがあります。

• 「レコード・タイプ」 システム・プロパティーは、レコード・レベルでシステム情報を保管します。 次に例を示します。

  • record_last_updated は、各レコードが最後に更新された時刻を追跡します。
  • record_number は、レコードごとにシステム生成の識別番号を保管します。

• 「エンティティー・タイプ」 システム・プロパティーは、エンティティー・レベルでシステム情報を保管します。 次に例を示します。

  • created_date は、エンティティーが作成された日時を保管します。
  • link_last_updated_date は、エンティティーのメンバー・レコードが最後に変更された日時を追跡します。
  • last_updated_date は、エンティティーの補足属性が最後に変更された日時を保管します。
  • last_updated_user は、エンティティーの補足属性に対して最新の変更を行ったユーザーを追跡します。

• 「属性タイプ」 システム・プロパティーは、属性レベルでシステム情報を保管します。 例えば、 attribute_last_updated は、各属性が最後に更新された時刻を追跡します。

• 「関係タイプ」 システム・プロパティーは、関係レベルでシステム情報を保管します。 次に例を示します。

  • relationship_last_updated は、各関係が最後に更新された時刻を追跡します。
  • relationship_number は、関係ごとにシステム生成の識別番号を保管します。

以下のビデオを視聴して、レコード・データの追加または編集時に IBM Match 360 が作成するシステム生成監査属性を確認する方法を確認してください。

レコード・タイプ

データ・モデル内のレコード・タイプは、組織が必要とするドメインおよびユース・ケースに関連するさまざまなタイプのレコードを定義します。 各レコード・タイプは、以下のプロパティーまたはオブジェクトで構成されます。

• label はレコード・タイプのラベルです。
• description は、レコード・タイプの簡略説明です。
• entity_types には、このレコードタイプに含まれるすべての対象タイプのオブジェクトが含まれます。 各 entity_type オブジェクトには、ラベル、説明、およびオプションでエンティティーのタイプ (アイデンティティーまたは関連付け) が含まれます。
• attributes は、レコード・タイプに関連付けられたすべての属性を含むオブジェクトです。 定義された各属性には、以下のプロパティーが含まれます。
  • label -属性のラベルです。
  • description -属性の説明です。
  • attribute_type -この属性の属性タイプ。
  • cardinality -属性のカーディナリティー (リスト、または単一)。 カーディナリティーは、この属性が持つことができる値の数を定義します。
  • indexed -属性がその内容のフリー・テキスト検索をサポートするために索引付けされるかどうかを示すブール値フィールド。

属性タイプ

データ・モデル内の属性タイプは、レコード・タイプまたは関係タイプに関連付けることができる属性のタイプを定義します。 各属性タイプ項目は、以下のプロパティーまたはオブジェクトで構成されます。

• label は、属性タイプのラベルです。
• description は、属性タイプの簡略説明です。
• matching_types は、この属性タイプのすべての属性に適用するマッチング関数のタイプを示します。
• fields には、この属性タイプの一部であるすべてのフィールドの定義が含まれています。 各フィールドは、 label、 description、および indexed の各プロパティーで構成されます。

関係のタイプ

データ・モデル内の関係タイプは、このデータで割り当てることができる関係のタイプを定義します。 定義された各関係タイプには、以下のプロパティーとオブジェクトが含まれます。

• label は、関係タイプのラベルです。
• description は、関係タイプの簡略説明です。
• label_from_source は、ソースの観点から見た場合の、関係のラベルです。 例: "Manages"。
• label_from_target は、ターゲットの視点から見た場合の、関係のラベルです。 例: "Reports to"。
• cardinality は、関係のカーディナリティー (例えば、1 対多または 1 対 1) を定義します。
• directional は、このタイプの関係が方向性 (医師/患者関係など、関係のどちらの側で表示するかによって異なる) であるか、双方向 (対等関係など、関係の両側で同じ) であるかを示します。
• attributes は、この関係タイプの一部であるすべての属性の定義を含むオブジェクトです。 attributes オブジェクトは、レコード・タイプの属性の構造と同じ構造を持ちます。
• rules は、この関係タイプのソース・ルールとターゲット・ルールを定義するオブジェクトです。
  • ソース ・ルールのオブジェクトには、このタイプの関係を作成するときにソースとして使用できるレコード・タイプとエンティティー・タイプのリストが含まれています。
  • target ルールのオブジェクトには、このタイプの関係を作成するときにターゲットとして使用できるレコード・タイプとエンティティー・タイプのリストが含まれています。