注
現在、この機能はパブリック プレビュー段階にあります。 このプレビュー版はサービス レベル アグリーメントなしで提供されています。運用環境のワークロードに使用することはお勧めできません。 特定の機能はサポート対象ではなく、機能が制限されることがあります。 詳細については、「 Microsoft Azure プレビューの追加使用条件」を参照してください。
グラフの種類は、存在できるノードとエッジを定義することによって、グラフの構造を表します。 これはブループリントやスキーマと考えてください。ラベルとプロパティの観点から、グラフ内のノードとエッジの形状を指定します。 エッジ (ノード間の接続) の場合、どの種類のエッジがどのノードを接続できるかも指定します。 リレーショナル データベースに慣れている場合、グラフの種類は、ER ダイアグラムがテーブルと外部キーリレーションシップを記述する方法と同様に機能します。
Important
この記事では、 ソーシャル ネットワークのグラフ データセットの例のみを使用します。
グラフの種類には、いくつかの主な利点があります。
- データ検証: グラフに有効なノードとエッジの組み合わせのみが含まれていることを確認します。
- クエリの最適化: パフォーマンスを向上させるために、クエリ エンジンがデータ構造を理解するのに役立ちます。
- ドキュメント: 開発者やアナリスト向けのグラフ構造の明確な仕様として機能します。
注
この記事では、グラフの種類を概念的に紹介し、GQL 標準で定義されている構文を使用して、その定義を示します。 ただし、現在、この構文は Microsoft Fabric のグラフでは直接サポートされていません。
構造上、グラフの種類は、許可されるノードの種類とグラフの種類のエッジの種類、およびそれらのグラフをさらに制限する追加の制約を定義します。
注
グラフの種類は、ノード の種類、エッジの種類、および制約の定義のセットを指定することによって定義されます。 これらの定義の順序を変更しても、定義されているグラフの種類は変更されません。
ノードの種類を定義する
ノードの種類は、ノードで使用できるラベルとプロパティの種類を指定します。 基本的なノードの種類を指定する方法を次に示します。
(:Organization => {
id :: UINT64 NOT NULL,
name :: STRING,
url :: STRING
})
この例では、次を使用してノードを定義するノードの種類を作成します。
- ラベル
Organization。 - 符号なし整数値を保持し、null にすることはできません
idプロパティ。 - 文字列値を保持する
nameプロパティ (null を指定できます)。 - 文字列値を保持する
urlプロパティ (null を指定できます)。
::演算子は各プロパティのデータ型を指定しますが、NOT NULLは、プロパティが常に値を持つ必要があることを示します。
注
NOT NULL は、SQL とは異なる GQL の型の一部と見なされます。
ノードの種類は、より多くのプロパティとデータ型を使用して、より複雑になる場合もあります。
(:Person => {
id :: UINT64 NOT NULL,
creationDate :: ZONED DATETIME,
firstName :: STRING,
lastName :: STRING,
gender :: STRING,
birthday :: UINT64,
browserUsed :: STRING,
locationIP :: STRING
})
複数のラベルを持つノードの種類
ノードは、継承と分類をサポートするために複数のラベルを持つことができます。 ノード タイプには複数のラベルを指定できますが、1 つのラベル ("キー ラベル") はノード タイプを一意に識別 する必要があります (ラベルが 1 つだけ指定されている場合、これはノード タイプのキー ラベルになります)。
例として、次の点を考慮してください。
(:University => :Organization),
(:Company => :Organization)
ここでは、 University と Company は定義されている 2 つのノード タイプのキー ラベルですが、 Organization は両方の種類で共有されるセカンダリ ラベルです。 キー ラベルとセカンダリ ラベルが各ノード タイプの => で区切られていることがわかります。 このアプローチにより、大学と企業の両方が組織の種類である型階層が作成されます。
キー ラベルはノードの種類を識別するため、この構文を使用すると、セカンダリ ラベルによって識別されるノードの種類のプロパティが自動的に継承されます。 したがって、前の構文を理解して、次のノードの種類を効果的に定義できます。
(:University => :Organization {
id :: UINT64 NOT NULL,
name :: STRING,
url :: STRING
}),
(:Company => :Organization {
id :: UINT64 NOT NULL,
name :: STRING,
url :: STRING
})
注
キー ラベルは、ノード タイプ階層を定義するときに不可欠です。 これらは、複数の種類が同じラベルを共有する場合に参照しているノードの種類をシステムが理解するのに役立ちます。
継承ショートカットを使用して時間を節約する
親ノードの種類からラベルとプロパティを繰り返し実行すると、面倒でエラーが発生しやすくなります。 Microsoft Fabric の Graph には += 演算子が用意されているため、追加の (非herited) ラベルとプロパティ型のみを指定できます。
(:Post => :Message += {
language :: STRING,
imageFile :: STRING
})
追加のプロパティが指定されていない場合、グラフは親型からすべての必須プロパティを継承します。
(:Comment => :Message) -- Same as: (:Comment => :Message += {})
抽象ノードの種類を使用する
グラフにその種類の具象ノードが含まれていない場合でも、階層を構築するためのノード型を純粋に定義できます。 抽象ノードの種類は、概念的なグループ化と共有プロパティ セットを作成するのに役立ちます。 この目的のために、Microsoft Fabric のグラフでノードの種類を ABSTRACT として定義できます。
ABSTRACT (:Message => {
id :: UINT64 NOT NULL,
creationDate :: ZONED DATETIME,
browserUsed :: STRING,
locationIP :: STRING,
content :: STRING,
length :: UINT64
})
抽象ノードの種類は、直接グラフの読み込みには使用できません。これらは、階層を構成し、共有プロパティを定義するためだけに存在します。 抽象型を継承する具象ノード型は、データと共に読み込むことができます。
エッジの種類とファミリを定義する
エッジタイプは、エッジのキー ラベル、プロパティタイプ、およびエンドポイントノードタイプを定義します。 グラフ データベースでは、エッジはノード間の接続を表します。 エッジ定義は、グラフで許可されているリレーションシップをシステムに通知します。
(:Person)-[:knows { creationDate :: ZONED DATETIME }]->(:Person)
このエッジ タイプでは、次を使用してすべてのエッジを定義します。
- (キー) ラベル
knows。 -
creationDate値 (タイムスタンプとタイムゾーン オフセット) を保持するZONED DATETIMEプロパティ。 - 両方ともノード
Personする必要があるソース エンドポイントと宛先エンドポイント。
矢印 -> は、ソースから宛先までのエッジの方向を示します。 この方向情報は、グラフのセマンティクスを理解するために非常に重要です。
エッジの種類の例を次に示します。
(:Person)-[:studyAt { classYear :: UINT64 }]->(:University)
(:Person)-[:workAt { workFrom :: UINT64 }]->(:Company)
エンドポイント ノード タイプのキー ラベル (Person、 University、または Company) のみを指定する必要があります。完全なノード タイプ定義を繰り返す必要はありません。 システムは、これらの参照を完全なノード・タイプ定義に解決します。
グラフ エッジ タイプ ファミリ
グラフ エッジ キー ラベルは、ノード キー ラベルとは動作が異なります。 同じラベルとプロパティの種類を持つ限り、グラフの種類に同じキー ラベルを持つ複数のエッジの種類を持つことができます。 ただし、同じキー ラベルを持つ 2 つのエッジ タイプは、少なくとも 1 つのエンドポイント ノード タイプで異なる必要があります。 同じキー ラベルを持つ一連のエッジ タイプを エッジ タイプ ファミリと呼びます。
この概念により、異なる種類のエンティティ間で同じ種類のリレーションシップをモデル化できます。
Example:
(:City)-[:isPartOf]->(:Country),
(:Country)-[:isPartOf]->(:Continent)
どちらのエッジタイプも isPartOf ラベルを使用しますが、異なる種類のノードを接続し、階層的な包含関係を表すエッジ タイプ ファミリを形成します。
エッジ型定義でノードサブタイピングを活用してください
各エッジタイプを一つ一つ説明するのは少し面倒です。 簡単にするために、端点によって示唆されるノード型の階層に整合したエッジ型ファミリーを定義することも可能です。
例:
-- Node types
ABSTRACT (:Message { ... }),
(:Post => :Message { ... }),
(:Comment => :Message { ... }),
-- All edge types (x)-[:hasTag]->(:Tag) where x is at least a (:Message)
(<:Message)-[:hasTag]->(:Tag)
これにより、暗黙のうちに以下の辺の種類が定義されます。
(:Post)-[:hasTag]->(:Tag)
(:Comment)-[:hasTag]->(:Tag)
サポートされているプロパティの種類
プロパティ型を定義する場合、プロパティ値の型は Microsoft Fabric でサポートされるグラフである必要があります。 適切なデータ型を選択することは、ストレージの効率とクエリのパフォーマンスにとって重要です。
プロパティ値に使用できるデータ型を次に示します。
-
INT(また:INT64) -
UINT(また:UINT64) STRING-
BOOL(また:BOOLEAN) -
DOUBLE(また、FLOAT64、FLOAT) -
T NOT NULL(Tは、上記のデータ型のいずれかです。 -
LIST<T>LIST<T> NOT NULL。ここで、Tは前述のデータ型のいずれかです。
値型の詳細については、「 GQL 値と値型」を参照してください。
Important
特定のグラフ型のノード型またはエッジ型で同じ名前を持つすべてのプロパティ型で、同じプロパティ値の型を指定する必要があります。
唯一の例外は、null 値を含めるかどうかによって異なる場合があります。
たとえば、この規則によると、 (:A { id :: STRING }), (:B { id :: STRING NOT NULL}) を持つグラフの種類は有効ですが、 (:A { id :: STRING }), (:B { id :: INT}) を持つグラフの種類は無効になります。
ノード キー制約を設定する
ノード キー制約は、グラフ内の各ノードが 1 つ以上のプロパティ値によって一意に識別される方法を定義します。 キー制約は、リレーショナル データベースの主キー制約と同様に機能し、データの整合性を確保します。 ノード キー制約では、複数のノード タイプのノードを対象とすることができ、概念階層全体のノード キーを定義できます。
主な制約を理解することは、次の理由から非常に重要です。
- 一意性を確保する: ビジネス ロジックに基づいてノードが重複しないようにします。
- 効率的な検索を有効にする: システムが特定のノードを検索するクエリを最適化できるようにします。
- データ統合のサポート: さまざまなデータ ソース間でノードを参照する安定した方法を提供します。
Important
Microsoft Fabric のグラフの場合、すべてのノードを 1 つのキー制約で制約する必要があります。
ノード キー制約のしくみ
グラフの種類でノード キー制約を指定できます。 各ノード キー制約には、効果的に機能する特定の特性があります。
ノード キー制約のコンポーネント:
- 簡単に参照できるように、グラフの種類内に一意の名前を付けます。
- 制約が適用されるノードを指定する単純な 制約パターン を使用して、対象となるノードを定義します。
- 一意のキー値を形成するプロパティを定義します。
Example:
CONSTRAINT person_pk
FOR (n:Person) REQUIRE n.id IS KEY
この構文では、person_pk ラベルを持つすべてのノードに対して Person というノード キー制約が作成されます。 この制約により、グラフ内の各ノードがその id プロパティによって一意に識別されるようになります。
Person ラベルを持つ 2 つのノードは、同じid値を持つ必要はありません。
また、複数のプロパティを一緒に使用する複合キーを定義して、 CONSTRAINT ... FOR ... REQUIRE (n.prop1, n.prop2) IS KEY 構文を使用して一意性を確保することもできます。
Important
キー制約で使用されるプロパティ:
- null にすることはできません
- キー制約の対象となるノードタイプとエッジタイプで
NOT NULLとして宣言する必要があります