Note
現在、この機能はパブリック プレビュー段階にあります。 このプレビュー版はサービス レベル アグリーメントなしで提供されています。運用環境のワークロードに使用することはお勧めできません。 特定の機能はサポート対象ではなく、機能が制限されることがあります。 詳細については、「 Microsoft Azure プレビューの追加使用条件」を参照してください。
Microsoft Fabricでリレーショナル データをグラフ モデルに変換すると、繰り返し結合を記述する代わりに、接続に直接クエリを実行できます。 この記事では、リレーショナル テーブルをノードタイプとエッジタイプにマッピングし、スケーリングする前にモデルを検証するための実用的な変換ワークフローを提供します。
グラフがワークロードに適しているかどうかをまだ判断している場合は、まず グラフとリレーショナル データベースの比較を確認してください。
変換チェックリストとしてこの記事を使用します。 モデリング ルールの詳細については、「 グラフ スキーマの設計」を参照してください。
前提条件
- アイテムを作成するアクセス許可を持つ Fabric ワークスペース。
- ソースのリレーショナルテーブルを含むレイクハウス。
テナントに対してグラフが有効化され、お使いの リージョン で利用可能です。- グラフ モデル エディターに関する知識。 グラフを初めて使用する場合は、「 チュートリアル: グラフの概要」から始めます。
変換ワークフロー
リレーショナル データを変換するときは、次のシーケンスを使用します。
- ソース テーブルを確認し、データ内のエンティティ (顧客、製品、注文)、各行が一意に識別される方法、およびテーブルが相互に接続する方法を特定します。
- グラフ内のノード タイプになるエンティティと、各エンティティを一意に識別する列を決定します。
- どのテーブル接続がエッジの種類になり、どの方向に向かうかを決定します (たとえば、
CustomerpurchasesOrder)。 - テーブル構造 (一対多、多対多、埋め込み値、または関連テーブルのチェーン) に基づいて適切なマッピング パターンを適用します。
- グラフ モデル エディターでモデルを構築し、ノードの種類とエッジの種類が期待どおりに表示されることを確認します。
手順 1: ソース リレーショナル テーブルをプロファイルする
ソース テーブル内の次の項目を確認します。
- 顧客、製品、注文など、個別のものを表す主要エンティティ。
-
CustomerID、OrderID、ProductSKUなど、各エンティティ行を一意に識別するキー列。 -
CustomerIDテーブルを参照するOrdersテーブル内のCustomersなど、テーブル間のリレーションシップを定義する外部キー列。 -
CountryやDepartmentなど、埋め込みエンティティである可能性がある列。
エンティティ、キー、プロパティ、マッピングの制約に関する詳細な決定基準については、「 グラフ スキーマの設計」を参照してください。
手順 2: エンティティをノード の種類にマップする
各エンティティをノードの種類にマップします。
| リレーショナル要素 | グラフ マッピング | 例 |
|---|---|---|
| エンティティ テーブル | ノード タイプ |
Customers table ->Customer ノードの種類 |
| プライマリキー | ノード キー (ID) | CustomerID_K |
| 説明列 | ノードのプロパティ |
FirstName、LastName、EmailAddress |
安定した一意の値を持つキー列を使用します。 1 つの列が一意でない場合は、複合キーを構成します。
設計ガイダンスについては、「 グラフ スキーマの設計」を参照してください。
手順 3: リレーションシップをエッジの種類にマップする
各リレーションシップ パスを有向エッジ タイプにマップします。
| Relational 要素 | グラフ マッピング | 例 |
|---|---|---|
| 外部キーリレーションシップ | エッジの種類 | purchases |
| テーブルの参照 | エッジ マッピング テーブル | adventureworks_orders |
| 親/子結合列 | ソースとターゲットのマッピング |
CustomerID_FK ->CustomerID_K |
エッジ ラベルは、 purchases、 contains、 belongsToなど、クエリで明確に読み取る動詞句として選択します。
エッジ マッピングの要件については、「 エッジの種類の選択」を参照してください。 UI の手順については、「 チュートリアル: エッジの種類をグラフに追加する」を参照してください。
手順 4: リレーショナルからグラフへの一般的なパターンを適用する
変換中にこれらのパターンを使用し、リンクされたガイドに従って詳細な実装を行います。 完全なパターンの説明については、 表形式からグラフへの一般的なパターンに関するページを参照してください。
- 一対多: 子テーブルは親キー (たとえば、顧客を参照する注文) を参照します。 「チュートリアル: グラフにエッジの種類を追加する」を参照してください。
- 多対多: ジャンクション テーブルは、2 つのエンティティ (たとえば、Products と Orders をリンクする SalesOrderDetail テーブル) をリンクします。 「チュートリアル: グラフにエッジの種類を追加する」を参照してください。
-
埋め込みエンティティ: 列の値は、走査可能なノード型にする必要があります (たとえば、
CountryをCountryノード 型に昇格させる)。 「チュートリアル: 1 つのマッピング テーブルから複数のノードとエッジの種類を追加する」を参照してください。 - 階層: 親子チェーンは複数のレベルにまたがっています (たとえば、従業員レポート構造)。 「チュートリアル: グラフにエッジの種類を追加する」を参照してください。
手順 5: グラフ モデルを構築して検証する
マッピングが完了したら、エディターでグラフ モデルをビルドして検証します。
ノードの種類を追加し、キー列から ID を構成します。
エッジの種類を追加し、ソース列とターゲット列をマップします。
[ 保存] を 選択してモデルを確認し、データを読み込みます。
予想されるノードの種類とエッジの種類のラベルがキャンバスに表示されることを確認します。
検証クエリを実行して、リレーションシップとカーディナリティを確認します。 例えば次が挙げられます。
MATCH (c:Customer)-[:purchases]->(o:Order) RETURN c.CustomerID_K, COUNT(o) AS orderCount ORDER BY orderCount DESCスキーマに一致するようにラベルを更新します。 各エッジの種類が結果を返し、カウントが正しく表示されることを確認します。
予想されるエッジがない場合は、マッピング テーブルの結合列の値とデータ型を確認します。
変換に関する一般的な問題のトラブルシューティング
- エッジが作成されていない: ソースとターゲットのマッピング列がノード のキー値とデータ型と一致するようにします。
- 重複するノード: ノード キー列が一意であることを確認するか、複合キーに切り替えます。
- 過剰にモデル化されたグラフ: 説明フィールドは、エンティティとして走査する必要がない限り、プロパティとして保持します。
- モデル化されていないグラフ: リレーションシップ ベースの分析が必要な場合は、ノードの種類に共有列を抽出します。