Microsoft Fabricでリレーショナル データをグラフ モデルに変換する

Microsoft Fabricでリレーショナル データをグラフ モデルに変換すると、繰り返し結合を記述する代わりに、接続に直接クエリを実行できます。 この記事では、リレーショナル テーブルをノードタイプとエッジタイプにマッピングし、スケーリングする前にモデルを検証するための実用的な変換ワークフローを提供します。

グラフがワークロードに適しているかどうかをまだ判断している場合は、まず グラフとリレーショナル データベースの比較を確認してください。

変換チェックリストとしてこの記事を使用します。 モデリング ルールの詳細については、「 グラフ スキーマの設計」を参照してください。

前提条件

変換ワークフロー

リレーショナル データを変換するときは、次のシーケンスを使用します。

  1. ソース テーブルを確認し、データ内のエンティティ (顧客、製品、注文)、各行が一意に識別される方法、およびテーブルが相互に接続する方法を特定します。
  2. グラフ内のノード タイプになるエンティティと、各エンティティを一意に識別する列を決定します。
  3. どのテーブル接続がエッジの種類になり、どの方向に向かうかを決定します (たとえば、 CustomerpurchasesOrder)。
  4. テーブル構造 (一対多、多対多、埋め込み値、または関連テーブルのチェーン) に基づいて適切なマッピング パターンを適用します。
  5. グラフ モデル エディターでモデルを構築し、ノードの種類とエッジの種類が期待どおりに表示されることを確認します。

手順 1: ソース リレーショナル テーブルをプロファイルする

ソース テーブル内の次の項目を確認します。

  • 顧客、製品、注文など、個別のものを表す主要エンティティ。
  • CustomerID、OrderID、ProductSKUなど、各エンティティ行を一意に識別するキー列。
  • CustomerID テーブルを参照するOrders テーブル内のCustomersなど、テーブル間のリレーションシップを定義する外部キー列。
  • CountryやDepartmentなど、埋め込みエンティティである可能性がある列。

エンティティ、キー、プロパティ、マッピングの制約に関する詳細な決定基準については、「 グラフ スキーマの設計」を参照してください。

手順 2: エンティティをノード の種類にマップする

各エンティティをノードの種類にマップします。

リレーショナル要素 グラフ マッピング 例
エンティティ テーブル ノード タイプ Customers table ->Customer ノードの種類
プライマリキー ノード キー (ID) CustomerID_K
説明列 ノードのプロパティ FirstName、LastName、EmailAddress

安定した一意の値を持つキー列を使用します。 1 つの列が一意でない場合は、複合キーを構成します。

設計ガイダンスについては、「 グラフ スキーマの設計」を参照してください。

手順 3: リレーションシップをエッジの種類にマップする

各リレーションシップ パスを有向エッジ タイプにマップします。

リレーショナル要素 グラフ マッピング 例
外部キーリレーションシップ エッジの種類 purchases
テーブルの参照 エッジ ソース テーブル adventureworks_orders
親/子結合列 配信元とターゲットのマッピング CustomerID_FK ->CustomerID_K

エッジ ラベルは、 purchases、 contains、 belongsToなど、クエリで明確に読み取る動詞句として選択します。

エッジ マッピングの要件については、「 エッジの種類の選択」を参照してください。 UI の手順については、「 チュートリアル: エッジの種類をグラフに追加する」を参照してください。

手順 4: リレーショナルからグラフへの一般的なパターンを適用する

変換中にこれらのパターンを使用し、リンクされたガイドに従って詳細な実装を行います。 完全なパターンの説明については、 表形式からグラフへの一般的なパターンに関するページを参照してください。

手順 5: グラフ モデルを構築して検証する

マッピングが完了したら、エディターでグラフ モデルをビルドして検証します。

  1. ノードの種類を追加し、キー列から ID を構成します。

  2. エッジの種類を追加し、原点列とターゲット列をマップします。

  3. [ 保存] を 選択してモデルを確認し、データを読み込みます。

  4. 予想されるノードの種類とエッジの種類のラベルがキャンバスに表示されることを確認します。

  5. 検証クエリを実行して、リレーションシップとカーディナリティを確認します。 例えば次が挙げられます。

    MATCH (c:Customer)-[:purchases]->(o:Order)
RETURN c.CustomerID_K, COUNT(o) AS orderCount
ORDER BY orderCount DESC

    スキーマに一致するようにラベルを更新します。 各エッジの種類が結果を返し、カウントが正しく表示されることを確認します。

予想されるエッジがない場合は、ソース テーブルの結合列の値とデータ型を確認します。

変換に関する一般的な問題のトラブルシューティング

  • エッジが作成されていない: 原点とターゲットのマッピング列がノード キーの値とデータ型と一致するように確認します。
  • 重複するノード: ノード キー列が一意であることを確認するか、複合キーに切り替えます。
  • 過剰にモデル化されたグラフ: 説明フィールドは、エンティティとして走査する必要がない限り、プロパティとして保持します。
  • モデル化されていないグラフ: リレーションシップ ベースの分析が必要な場合は、ノードの種類に共有列を抽出します。

関連するコンテンツ

  • Last updated on