Microsoft Fabricでグラフ スキーマを設計する

グラフ スキーマは、ノードの種類、エッジの種類、およびグラフの構造を定義するプロパティのコレクションです。 適切に設計されたグラフ スキーマを使用すると、データのクエリ、保守、拡張が容易になります。 この記事では、レイクハウス内の表形式データを、Microsoft Fabricの有効なラベル付きプロパティ グラフに変換するためのベスト プラクティスについて説明します。

グラフ モデル エディターでモデリングを開始する前に、次のガイドラインを使用してください。 ノードとエッジを作成する手順については、 グラフのチュートリアルを参照してください。 この記事の例では、 Adventure Works サンプル データセットを使用します。

前提条件

• Fabric ワークスペース には、ソース テーブルを含むレイクハウスがあります。
• グラフ モデル エディターに関する知識。
• 省略可能です: この記事の例に従うためのAdventure Works サンプル データセットです。

ノードの種類とエッジの種類について

スキーマを設計する前に、次の主要な概念を理解してください。

ノードの種類は、顧客、製品、注文など、グラフ内のエンティティの種類を定義します。 構成は次のとおりです。

• ラベル。ノードのこのカテゴリを識別する名前です。 たとえば、「 Customer 」のように入力します。 クエリでラベルを使用して、この種類のノードを参照します。
• マッピング テーブル。ノード タイプのソース データを提供する lakehouse テーブルです。 たとえば、 adventureworks_customers テーブルです。
• 各ノードを一意に識別する キー列 (グラフ モデル エディターで ID というラベルが付いています)。 たとえば、「 CustomerID_K 」のように入力します。
• プロパティ。各ノードの属性となるテーブルの列です。 たとえば、 FirstName、 LastName、 EmailAddressなどです。

ノードは、ノード タイプの個々のインスタンスです。マッピング テーブル内の 1 行です。 たとえば、 adventureworks_customers の各行は Customer ノードになります。

エッジ タイプは、2 つのノード タイプ間のリレーションシップの種類を定義します。 構成は次のとおりです。

• ラベル。このリレーションシップ のカテゴリを識別する名前です。 たとえば、「 purchases 」のように入力します。
• ソース ノードとターゲット ノード間のリレーションシップ データを含む マッピング テーブル 。 たとえば、 adventureworks_orders テーブルです。
• エッジが接続する ソース ノード タイプ と ターゲット ノード タイプ 。 たとえば、ソースとして Customer し、ターゲットとして Order します。

エッジは、2 つの特定のノードを接続するマッピング テーブル内の 1 つの行である、エッジの種類の個々のインスタンスです。

エンティティとリレーションシップを識別する

まず、データ内の エンティティ (モノ) と リレーションシップ (接続) を識別します。 エンティティはノード 型になります。 エンティティ間の接続はエッジタイプとなります。

ソース テーブルについて次の質問をします。

• 主なエンティティは何ですか? 実際の状況を表す行は、ノードタイプの候補です。 たとえば、顧客、製品、注文、従業員などです。
• これらのエンティティは互いにどのように関連していますか? 別のテーブル (外部キー) の行を参照する列は、エッジの種類を提案します。 たとえば、CustomerID_FK テーブル内のordersは、customers テーブルを指しており、purchases エッジのモデリングを提案します。
• 埋め込みエンティティはありますか? テーブル内の列は、独自のノード型に抽出する価値のある個別のエンティティを表している可能性があります。 例については、「 ノードタイプの選択」を参照してください。 詳細なチュートリアルについては、「 1 つのマッピング テーブルから複数のノードとエッジの種類を追加する」を参照してください。

ノードの種類を選択する

個別にクエリまたは走査する必要があるエンティティごとにノードの種類を作成します。 次のガイドラインを使用します。

例： Adventure Works データセットで、 Country は employees テーブルの列として開始されます。 "どの従業員が同じ国に住んでいるか" または "従業員が最も多い国" をクエリする必要がある場合は、 Country を独自のノード タイプに抽出します。 従業員の国のみをラベルとして表示する必要がある場合は、プロパティのままにします。

キー列の選択

すべてのノード タイプには、各ノードを一意に識別するキー列 (または複合キー) が必要です。 キーは慎重に選択してください。

• ソース テーブルの既存の一意識別子を使用してください。 たとえば、CustomerID_K または ProductID_K です。
• 自然キーが存在しない限り、ビジネス上の意味がない代理キーは避けてください。 たとえば、自動インクリメント行番号よりも CustomerID を優先します。
• 1 つの列で一意性が保証されない場合は、複合キーを使用します。 たとえば、 ProductVersion ノードでは、キーとして ProductID と VersionNumber の両方が必要な場合があります。
• キー列とエッジ マッピングで使用される外部キー列の間でデータ型を一致させます。 型が一致しない場合、エッジの作成エラーが発生します。

エッジの種類を選択する

エッジタイプは、ノードタイプ間のリレーションシップを定義します。 各エッジ タイプは、マッピング テーブルを介してソース ノード タイプをターゲット ノード タイプに接続します。

次のガイドラインに従ってください。

• 動詞または動詞句として読み取る説明ラベルを使用します。 たとえば、 purchases、 sells、 livesIn、 belongsToなどです。 適切な名前のエッジを使用すると、クエリの読み取りが容易になります。
• 方向を慎重に検討してください。 グラフのエッジは有向です。 実際の関係を最もよく表す方向を選択します。 たとえば、 Customer --purchases--->Order は、 Order --purchasedBy-->Customer よりも自然に読み取ります。
• 異なるノード タイプ ペアを接続するエッジ タイプに個別の名前を付けます。 "従業員が注文を販売する" と "顧客の発注書" の両方が Orderに接続する場合は、同じラベルの両方を指定するのではなく、 sells と purchases に名前を付けます。 詳細については、 エッジ作成の制限事項を参照してください。

エッジの種類にプロパティを追加する

ノードタイプとは異なり、エッジタイプはプロパティなしで始まります。 必要に応じて、いずれかのエンドポイントではなく、データがリレーションシップ自体を記述するときにプロパティを追加できます。 エッジ プロパティは、リレーションシップ自体に関するデータをフィルター処理、集計、または返す必要がある GQL クエリを記述する場合に最も便利です。

プロパティを追加するには、グラフ モデル エディターでエッジの種類をダブルクリックして [ エッジ スキーマの編集] ダイアログを開き、[ プロパティの追加] を選択し、マッピング テーブルから列を選択します。

エッジ プロパティを追加する場合: 2 つのノード間の接続に関して列が "どのくらいの量?"、"いつ"、または "どのような方法で?" と答える場合は、どちらのノードにも属していませんが、エッジに属します。

例：Adventure Works データセットでは、contains エッジは、adventureworks_orders テーブルを介してOrderをProductに接続します。 OrderQty、UnitPrice、LineTotalなどの列は、特定の注文に含まれる製品の数 (価格) の関係を表します。 OrderDateやShipDateなどの列は、順序自体を記述し、エッジではなく、Order ノード タイプに属します。

不要なプロパティを削除する

マッピング テーブルからノード タイプを作成すると、テーブル内のすべての列が既定でプロパティになります。 過剰なプロパティを使用すると、ストレージが増加し、クエリが遅くなり、グラフの保守が困難になります。 このような理由から、クエリや分析に必要のないプロパティを削除します。

ノードの種類ごとに、次のプロパティのみを保持します。

• ノードの一意性 (キー列) に必要
• クエリの WHERE フィルターまたは RETURN プロジェクションで使用されます
• ダウンストリーム分析または視覚化に必要

プロパティ数がクエリのパフォーマンスに与える影響の詳細については、「 必要なプロパティのみを返す」を参照してください。

データ型の選択

各プロパティの最も具体的なデータ型を選択します。 適切な種類により、ストレージ効率とクエリパフォーマンスの両方が向上します。

• 数値識別子とカウントには、 INT または UINT64 を使用します。 数値比較は、文字列比較よりも高速です。
• 文字列形式の日付ではなく、タイムスタンプに ZONED DATETIME を使用します。
• BOOLEANや"yes"などの文字列値の代わりに、true/false フラグに"no"を使用します。

サポートされている型の完全な一覧については、「 現在の制限事項 - データ型」を参照してください。

表形式からグラフへの一般的なパターン

次の表は、一般的な表形式データ構造がグラフ要素にどのように変換されるかをまとめたものです。

埋め込みエンティティ パターンの詳細なチュートリアルについては、「 1 つのマッピング テーブルから複数のノードとエッジの種類を追加する」を参照してください。

グラフ スキーマを変更する

グラフはスキーマの進化をサポートしていません。 グラフ モデルを保存すると、ノードタイプ、エッジタイプ、およびそれらのプロパティの構造が固定されます。 ノード タイプへのプロパティの追加、エッジの種類の削除、キー列の変更など、構造上の変更を行うには、新しいグラフ モデルを作成してデータを再読み込みする必要があります。

グラフ スキーマを変更するには:

1. ワークスペースで、同じレイクハウスに接続する新しいグラフ項目を作成します。
2. グラフ モデル エディターで、新しいプロパティや変更されたプロパティを含め、必要なノードの種類とエッジの種類を追加します。
3. キー列とエッジ マッピングを構成します。 キー列と外部キー列の間でデータ型が一致していることを確認します。
4. [保存] を選択してデータを取り込み、新しいグラフを作成します。
5. 新しいグラフを指すクエリセットを更新します。
6. 新しいグラフが期待どおりに動作することを確認した後、不要な場合は元のグラフ項目を削除します。

関連するコンテンツ

• チュートリアル: グラフの概要
• GQL グラフの種類
• GQL クエリのパフォーマンスを最適化する
• ラベル付きプロパティ グラフ
• 現在の制限