仮想メタデータの例

この機能を使うケースとして考えられるのは、プロファイル データや購入履歴など、大量の顧客情報に一度にアクセスしたい場合などです。このような情報を Data Hub モデルに「物理的に」保存し、複製するのは、処理のボトルネックになる可能性があります。
  • データの量が多すぎるか、広く分散しすぎていると、中心のハブに適切に格納できません。
  • データが頻繁に変更されると、ハブ内での複製があまりに多く必要となり、実用性が失われます。
  • 社会保障番号、給与明細、価格データなどの機密情報の取り扱いについて、ビジネスまたはプライバシーの点で懸念もあります。

データを外部に保存し、それらに仮想的にアクセスすれば、顧客の全体像を把握しつつ、Data Hub 内でのデータ複製に関する懸念を緩和できます。

Data Hub モデル

既存のモデルには、Customer および CustomerMaster の 2 つのエンティティと HasMasterRecord という関連性が含まれています。

Customer エンティティには、次の情報が含まれます。
  • 顧客 ID (顧客ごとに固有の ID)
  • 名前
  • 出生日
  • Gold Club ステータス (顧客が Gold Club のメンバーであるかどうかを示す情報)
CustomerMaster エンティティには、次の情報が含まれます。
  • マスター ID (世帯ごとに固有の ID)
  • 顧客 ID
  • 名前
  • 出生日

以下の図は、このメタデータを使って構築したモデルを示しています。ご覧のとおり、George Washington と Martha Washington は個別に Customer エンティティを持ちますが、CustomerMaster エンティティは共通です。これは、マスター ID が個人ではなく世帯を表すからです。

外部テーブル

顧客と購入履歴をリンクする必要があります。そうするには、3 つの外部テーブルを作成します。顧客用、購入履歴用、そして製品用のテーブルです。

Customers テーブルには、Customer エンティティに設定したものと同じ情報を使用します。

Purchases テーブルは、注文番号、製品 ID、購入日を格納し、オンラインでの購入かどうかを記録します。このデータは、Customer テーブルでも使用される顧客 ID に結び付けられます。

Products テーブルは、製品名、モデル番号、および説明を格納します。このデータは、Customer テーブルでも使用される製品 ID に結び付けられます。

Purchases テーブルは、Customers テーブルと Products テーブルのレコード間に接続を確立する結合テーブルの役目を担います。次の画像は、3 つの外部テーブルにある各フィールドの関係を示したものです。

すべての情報が統合されて、次のレコードが Martha Washington のために生成されます。

物理データと仮想データのリンク

Data Hub モデルのエンティティと外部テーブルのレコードの間に関係を作成するには、外部データを参照するプロパティを Data Hub エンティティに与える必要があります。Data Hub モデルから Customers テーブル内のレコードにリンクするには、そのエンティティの CustomerID フィールドに格納されているものと同じ値を持つプロパティが外部テーブルにある必要があります。以下の図では、Martha Washington エンティティに CustRef というプロパティがあり、その値は Customers テーブルの CustomerID フィールドと同じです。

Customer エンティティと外部テーブルを結ぶリンクを確立するには、Customers テーブルに対応する仮想エンティティを最初に作成します。これを行うには、前のトピック「モデルでの仮想メタデータの使用」のステップ 5 以降を実行します。以下の画像は、新しいエンティティ タイプの完成後の画面を示しています。"CustomerID" がプライマリ キーとして選択されていることに注目してください。これが仮想エンティティと物理エンティティをリンクするために使われるプロパティです。

仮想エンティティを追加した後で、このエンティティをモデル側の既存の物理エンティティにリンクする関係を追加します。これを行うには、前のトピックのステップ 14 から実行します。以下の画像は、新しい関係タイプの完成後の画面を示しています。[ソース エンティティ ID] が CustRef プロパティを指し、[ターゲット エンティティ ID] が CustomerID プロパティを指していることに注目してください。これは、仮想エンティティを物理エンティティに関連付けるリンクです。両方のプロパティに顧客 ID が含まれるため、このリンクが成立します。

また、この例では、顧客間の関係は 1 対 1 です。つまり、物理エンティティには多くとも 1 つの対応する仮想エンティティが必ずあり、仮想エンティティにも多くとも 1 つの対応する物理エンティティがあります。1 対 1 の関係では、1 対多の関係と同様に、本当の結合テーブルを作成する必要はないので、ここでは Customers テーブルを使用します。このテーブルは、仮想エンティティの定義に使うテーブルでもあります。

これでモデルのメタデータに仮想データへのリンクが追加されました。ERP_Customer エンティティの横に青い星印があることに注目してください。これは仮想エンティティであることを示しています。

多対多の関係

顧客の仮想エンティティを物理エンティティにリンクしたので、購入のエンティティと製品のエンティティも同様にリンクする必要があります。これを行うには、製品の仮想エンティティを作成し、Purchases テーブルを結合テーブルとして使って物理 Customers と仮想 Products の間に多対多の仮想関係を作成するのが最適です。最初に、ProductID をプライマリ キーとして使う Products テーブルに仮想エンティティを作成する必要があります。

その後で、Purchases テーブルを結合テーブルとして使って多対多関係を確立する新しい関係を追加します。つまり、Purchases テーブルの情報に基づいて、Customer エンティティを Product エンティティにリンクします。CustomerID プロパティが Customer エンティティのリンク ID として使用され、ProductID プロパティが Product エンティティのリンク ID として使用されることに注目してください。Purchases テーブルには、両方のプロパティが含まれています。このようにすると、情報を Customer から Product へ対応付けることができます。

ソース エンティティ ID (CustRef) は、Customer エンティティのプロパティで、Purchases テーブルのソース リンク ID 列 (CustomerID) と一致します。ターゲット リンク ID (ProductID) は、Purchases テーブルの列で、Products エンティティのターゲット エンティティ ID (これも ProductID) プロパティに一致します。以下の図は、Customer を Product にリンクするために使用される各フィールドを示しています。

クエリが Customer から Product へトラバースする場合、ソース エンティティ ID として選択されたプロパティが最初に処理されます。ここで使っている例では、CustRef プロパティがこれに当たります。Martha Washington の場合、このプロパティの値は C23 です。この値が Purchases テーブルからデータ行を見つけるために使用されます。ソース リンク ID (この例では CustomerID) の値が C23 であれば、それが目的の行です。
ターゲット リンク ID (この例では ProductID) は、Products テーブルから対応するデータ行を見つけるために使用されます。Purchases テーブルから見つかる行では、ProductID フィールドの値が Products テーブルのターゲット エンティティ ID (この例では ProductID) に一致します。以下の図は、このフローで各フィールドがどのように使われるかを示しています。

高度な設定

別の方法でも同様の多対多関係を確立できます。Purchases テーブルを使って、顧客の仮想エンティティと製品の仮想エンティティの間に多対多関係を作成します。これを行うには、物理的な顧客から仮想の顧客への不要な仮想ホップを追加する必要があります。グラフ データベースを基盤とするため、Data Hub を使うと、SQL データ ソースと比べてはるかに効率よく関係をトラバースできます。したがって、可能であれば余分なホップの作成は避けるのが賢明です。

2 番目の方法は、Products テーブルの仮想エンティティに加えて、Purchases テーブルにも仮想エンティティを作成することです。この方法では、購入の仮想エンティティと製品の仮想エンティティとの間に1 対多の関係を作成するだけでなく、顧客の物理エンティティと購入の仮想エンティティとの間にも 1 対多の関係が必要となります。この方法では、顧客の仮想エンティティから製品の仮想エンティティに到達するために不要な仮想ホップを作成するので、非効率です。関係ですべての Purchases フィールドをプロパティとして抱えることができるため、購入をエンティティとして表すことに利点はありません。Purchases にエンティティを作成する必要がある唯一のケースは、2 つ以上のエンティティ タイプを接続する場合です。購入を店舗にリンクする第 3 の外部キーが存在するような使い方が、これに該当します。