このドキュメントでは、Spanner Graph スキーマについて説明し、主なコンセプトを示す例を紹介します。Spanner Graph の詳細については、Spanner Graph の概要をご覧ください。
プロパティ グラフのデータモデル
プロパティグラフを使用すると、接続されたデータをモデル化できます。ノードとエッジのネットワークとして情報を表します。ノードは、データ ランドスケープ内のエンティティ(「顧客」、「商品」、「場所」など)を表します。エッジは、それらのノード間の接続を示し、「購入した」、「フォローしている」、「所在地」などの関係をキャプチャします。
ノードとエッジの両方に、次の情報を配置することができます。
- ラベル。ノードとエッジをセット(都市など)に分類します。
- プロパティ(Key-Value ペア)。例: 人口。
図 1 の例は、財務活動をモデル化するためにグラフを設計する方法を示しています。このグラフには、ノードとしてモデル化された次のタイプのエンティティが含まれています。
- 個人: 金融取引に関与する個人を表します。
- アカウント: 取引に使用される銀行口座を表します。
これらのエンティティは、次の有向エッジで表されるさまざまなタイプの関係で接続されています。
- 所有: 1 人の人が 1 つ以上のアカウントを所有しています。
- 振込: ある口座から別の口座に資金が移動します。
各有向エッジは、ソースノードから宛先ノードに流れる単方向のリレーションシップを示します。たとえば、Transfers
エッジは、ソース Account
を宛先 Account
に接続し、資金の流れを示します。
図 1. 複数のノードと有向エッジを含むグラフの例。
ノードとエッジには、プロパティの形式で追加情報を配置することができます。各プロパティには名前と値が表示されます。
- Person ノードには次のプロパティが設定されています。
name
(STRING
)id
(INT64
)
- 転送エッジには次のプロパティが設定されています。
amount
(FLOAT64)
有向エッジと無向エッジ
このサンプル グラフでは、有向エッジを使用しています。これは、エンティティ間の関係の特定の方向を示します。ただし、ソーシャル ネットワークの「友だち」関係など、一部の関係は無向であり、明確な起点やエンドポイントのない相互接続を表します。この場合、無向エッジを 2 つの有向エッジ(各方向に 1 つのエッジ)としてモデル化できます。
Spanner Graph スキーマの設計
Spanner Graph では、CREATE PROPERTY GRAPH ステートメントを使用してテーブルからグラフを作成できます。グラフの作成に使用されるテーブルは、入力テーブルと呼ばれます。このアプローチは、SQL:2023 標準の一部である SQL/PGQ(プロパティグラフ クエリ)に基づいています。
プロパティ グラフ内のノードの定義
ノードを定義するには、NODE TABLES 句にノードの定義を追加します。最もシンプルなノード定義の形式には、入力テーブル名のみが含まれます。入力テーブルの行はグラフノードにマッピングされます。
次の例では、NODE TABLES 句を使用して、FinGraph
プロパティグラフに Account
ノードを定義します。ノード定義には入力テーブル Account
が含まれています。
-- First, create an Account table.
CREATE TABLE Account (
id INT64 NOT NULL,
create_time TIMESTAMP,
) PRIMARY KEY (id);
-- Next, use the Account table as input table of Account node definition.
CREATE PROPERTY GRAPH FinGraph
NODE TABLES (
Account
);
デフォルトのラベルとプロパティ
デフォルトでは、すべてのノードが入力テーブル名をラベルとして使用し、入力テーブルのすべての列がノード プロパティとして公開されます。
上記の例では、次のようになっています。
- 各アカウントノードには
Account
ラベルが付いています。 - 各アカウントノードには、
Account
テーブル列から作成されたプロパティ[id, create_time]
があります。
要素キー
ノード定義では、グラフノードを一意に識別する要素キーも定義します。
- デフォルトでは、要素キーは入力テーブルの主キーです。
- 要素キーは
KEY
句で明示的に定義できます。 - 一意性制約
UNIQUE INDEX
を持つ列は、要素キーとして使用できます。
次の例では、Account
ノードと Person
ノードを定義しています。
Account
ノードは、デフォルトでAccount
テーブルの主キーを要素キーとして使用します。- 一方、
Person
ノードは、KEY
句を使用して要素キーとしてid
を明示的に指定します。
CREATE TABLE Person (
id INT64 NOT NULL,
name STRING(MAX),
) PRIMARY KEY (id);
CREATE TABLE Account (
id INT64 NOT NULL,
create_time TIMESTAMP,
) PRIMARY KEY (id);
CREATE PROPERTY GRAPH FinGraph
NODE TABLES (
Person KEY (id),
Account
);
入力テーブルの行をグラフ内のノードにマッピングする
- 要素キーが null 以外の各行は、要素キーで識別されるグラフ内の一意のノードにマッピングされます。
- 要素キーが null の行は無視されます。
プロパティ グラフでエッジを定義する
エッジを定義するには、EDGE TABLES 句にエッジ定義を追加します。最もシンプルなエッジ定義には、入力テーブル名のみが含まれます。入力テーブルの行はグラフのエッジにマッピングされます。
エッジのデフォルトのラベルとプロパティは、ノードと同じ方法で定義されます。
各エッジの要素キーは、ノードと同じ方法で定義されます。
送信元ノードと宛先ノードの参照
次の例では、次のようにプロパティグラフ FinGraph
を作成します。
Person
ノードとAccount
ノードPersonOwnAccount
エッジ
CREATE TABLE Person (
id INT64 NOT NULL,
name STRING(MAX),
) PRIMARY KEY (id);
CREATE TABLE Account (
id INT64 NOT NULL,
create_time TIMESTAMP,
) PRIMARY KEY (id);
CREATE TABLE PersonOwnAccount (
id INT64 NOT NULL,
account_id INT64 NOT NULL,
create_time TIMESTAMP,
FOREIGN KEY (account_id) REFERENCES Account (id)
) PRIMARY KEY (id, account_id),
INTERLEAVE IN PARENT Person;
CREATE PROPERTY GRAPH FinGraph
NODE TABLES (
Person,
Account
)
EDGE TABLES (
PersonOwnAccount
SOURCE KEY (id) REFERENCES Person (id)
DESTINATION KEY (account_id) REFERENCES Account (id)
);
エッジ定義では、SOURCE KEY
、DESTINATION KEY
、REFERENCES
句を使用して、送信元ノードと宛先ノードの参照を定義する必要があります。次の例では、PersonOwnAccount
のエッジ定義を使用して、このコンセプトを示します。
EDGE TABLES (
PersonOwnAccount
SOURCE KEY (id) REFERENCES Person (id)
DESTINATION KEY (account_id) REFERENCES Account (id)
)
各 PersonOwnAccount
エッジは、Person
(ソース)ノードを Account
(宛先)ノードに接続します。
- エッジの
SOURCE
ノードは、id
がエッジid
と同じであるPerson
ノードです。 - エッジの
DESTINATION
ノードは、id
がエッジaccount_id
と同じであるAccount
ノードです。
また、PersonOwnAccount
エッジには次のことが当てはまります。
- 要素キーは、
PersonOwnAccount
テーブルの主キー((id, account_id)
)です。 - 各エッジには、
PersonOwnAccount
テーブルの列と同じプロパティ セットがあります。 - 各エッジにはデフォルトの
PersonOwnAccount
ラベルが付いています。
エッジ入力テーブルの行をグラフのエッジにマッピングする
- エッジ入力テーブルの各行(要素キーが null でない行)は、通常、グラフ内の一意のエッジにマッピングされます。
- 1 行がグラフ内の 0 個以上のエッジに対応する場合があります。たとえば、ソースノード参照がソースノード テーブル内の 0 個以上のノードと一致する場合です。
- 同じ入力テーブルを異なるノード定義またはエッジ定義で使用して、異なるノードまたはエッジのセットを作成できます。詳細については、ノード入力テーブルとエッジ入力テーブルを統合するをご覧ください。
ラベルとプロパティをカスタマイズする
LABEL 句と PROPERTIES 句を使用して、ラベルとプロパティをカスタマイズできます。
次の例では、Person
と Account
の 2 つのノードが定義されています。
Person
ノードは、ラベルCustomer
を介してaddress
プロパティをexpose
します。address
プロパティは、入力テーブルPerson
のcity
列とcountry
列を参照する式CONCAT(city, ", ", country),
によって定義されます。Account
の場合、Account
ノードはラベルAccount
を介してid
プロパティとcreate_time
プロパティを公開します。Person
とAccount
には、プロパティ [id, name
] を持つEntity
ラベルがあります。Person
の場合、id
プロパティとname
プロパティは入力テーブルの列から取得されます。Account
の場合、name
プロパティは入力テーブルのnick_name
列を参照します。
CREATE TABLE Person (
id INT64 NOT NULL,
name STRING(MAX),
birthday TIMESTAMP,
country STRING(MAX),
city STRING(MAX),
) PRIMARY KEY (id);
CREATE TABLE Account (
id INT64 NOT NULL,
create_time TIMESTAMP,
is_blocked BOOL,
nick_name STRING(MAX),
) PRIMARY KEY (id);
CREATE PROPERTY GRAPH FinGraph
NODE TABLES (
Person KEY (id)
LABEL Customer
PROPERTIES (CONCAT(city, ", ", country) AS address)
LABEL Entity PROPERTIES (id, name),
Account KEY (id)
LABEL Account PROPERTIES (id, create_time)
LABEL Entity PROPERTIES (id, nick_name AS name)
);
ラベルとプロパティの整合性
グラフでは、ラベルとプロパティは名前で一意に識別されます。同じ名前のラベルとプロパティは、複数のノード定義またはエッジ定義に含めることができます。ただし、同じ名前のラベルとプロパティは、次のルールに従う必要があります。
- 同じ名前のプロパティは、同じ値の型を持つ必要があります。
- 同じ名前のラベルは、同じプロパティのリストを公開する必要があります。
上記の例では、Entity
ラベルは Person
ノードと Account
ノードの両方で定義されています。どちらの定義でも、同じ値の型を持つ同じプロパティ名 [id
、name
] が設定されています。
グラフと他のスキーマ オブジェクト間の依存関係
CREATE PROPERTY GRAPH
によって作成されたグラフは、ノードとエッジの定義の入力テーブルや、プロパティによって参照されるテーブル列など、他のスキーマ オブジェクトに依存しています。スキーマの変更によってこれらの依存関係のいずれかが破壊される場合、変更は許可されません。
次のステートメントは、FinGraph
から Account
テーブルと id
、create_time
列への依存関係を作成します。
CREATE OR REPLACE PROPERTY GRAPH FinGraph
NODE TABLES (
Account PROPERTIES (id, create_time)
);
許可されないスキーマ変更の例を次に示します。
Account
ノードの定義を先に削除しない限り、Account
テーブルを削除します。詳細については、既存のノードまたはエッジ定義を削除するをご覧ください。Account
ノード定義からcreate_time
プロパティを先に削除しない限り、Account
テーブルからcreate_time
列を削除します。詳細については、既存のノードまたはエッジの定義を更新するをご覧ください。
ただし、次のスキーマ変更は可能です。
- 他のスキーマ要件で許可されている限り、
Account
テーブルとid
列とcreate_time
列のスキーマを変更します。詳細については、スキーマを更新するをご覧ください。