スキーマの概要
このドキュメントでは、プロパティ グラフのスキーマのコンポーネントについて説明し、グラフスキーマを作成して管理する方法を示します。
グラフを使用すると、情報をノードとエッジのネットワークとして表す接続されたデータをモデル化できます。グラフスキーマは、ノードとエッジ、タイプを分類するラベル、それらを記述するプロパティで構成されます。 プロパティ グラフのスキーマを定義するには、入力テーブルの行をグラフのノードとエッジにマッピングし、カスタムラベルとプロパティを定義します。 BigQuery Graph の詳細については、 BigQuery Graph の概要をご覧ください。
プロパティ グラフのデータモデルを理解する
プロパティ グラフを使用すると、接続されたデータをノードとエッジのネットワークとしてモデル化できます。ノードは、顧客、商品、場所など、データ内のエンティティを表します。エッジは、これらのノード間の接続を表し、購入、フォロー、場所などの関係をキャプチャします。
ノードとエッジには、次の情報を含めることができます。
ラベル: ノードとエッジのタイプを分類します。たとえば、クラスの生徒には
StudentラベルとPersonラベルが付いている場合があります。 ノードまたはエッジのラベルを明示的に定義しない場合、BigQuery Graph は入力テーブル名をデフォルトのラベルとして使用します。プロパティ: ノードとエッジを記述するために使用されます。たとえば、人物を表すノードには、値が
Alexのnameプロパティと、値が1のidプロパティが含まれる場合があります。
図 1 の例は、財務活動をモデル化するグラフを設計する方法を示しています。このグラフには、ノードとしてモデル化された次のタイプのエンティティが含まれています。
- Person: 金融取引に関与する個人を表します。
- Account: 取引に使用される銀行口座を表します。
これらのエンティティは、次の有向エッジで表されるさまざまなタイプの関係で接続されています。
- 所有: 1 人のユーザーが 1 つ以上のアカウントを所有しています。
- Transfers: あるアカウントから別のアカウントに資金が移動します。
各有向エッジは、ソースノードから宛先ノードへの一方向の関係を表します。たとえば、Transfers エッジは、ソース Account を宛先 Account に接続し、資金の流れを示します。
図 1.複数のノードと有向エッジを含むグラフの例。
ノードとエッジには、プロパティに追加情報が含まれています。
Personノードには次のプロパティが含まれます。name（STRING）id（INT64）
Transfersエッジには次のプロパティが含まれます。amount（FLOAT64）
有向エッジと無向エッジ
有向エッジは、エンティティ間の関係の特定の方向を示します。たとえば、ユーザーはアカウントを所有していますが、アカウントはユーザーを所有していません。ただし、ソーシャル ネットワークの友だち関係など、一部の関係は無向であり、相互接続を表します。 この場合、無向エッジを 2 つの有向エッジ（各方向に 1 つのエッジ）としてモデル化できます。
スキーマを設計する
BigQuery Graph では、
CREATE PROPERTY GRAPH
ステートメントを使用してテーブルからグラフを作成できます。グラフを作成するテーブルは、入力テーブルと呼ばれます。
ノードを定義する
ノードはテーブルの行で定義されます。
ノードを定義するには、
NODE TABLES句にノード定義を追加します。
最もシンプルなノード定義の形式には、入力
テーブルの名前と主キーが含まれます。BigQuery
Graph は、入力テーブルの行をグラフノードにマッピングします。
次の例では、NODE TABLES 句を使用して、FinGraph プロパティ グラフに Account
ノードを定義します。ノード定義には入力テーブル Account が含まれています。
-- Create an Account table.
CREATE TABLE graph_db.Account (
id INT64 NOT NULL,
create_time TIMESTAMP,
PRIMARY KEY (id) NOT ENFORCED
);
-- Use the Account table as the input table for the Account node definition.
CREATE PROPERTY GRAPH graph_db.FinGraph
NODE TABLES (
graph_db.Account
);
デフォルトでは、BigQuery はテーブル名をラベルとして使用し、入力テーブルのすべての列をプロパティとして公開します。
- 各アカウント ノードは、
Accountというラベルを持ちます。 - 各アカウント ノードには、
Accountテーブル列のidプロパティとcreate_timeプロパティが含まれます。
要素キー
ノード定義では、グラフノードを一意に識別する列のコレクションである要素キーも定義します。デフォルトでは、要素キーは入力テーブルの主キーです。
または、KEY
句を使用して、要素キーを明示的に定義することもできます。
次の例では、Account ノードと Person ノードを定義します。Account ノードの要素キーは Account
テーブルの主キーになります。Person ノードの要素キーは、KEY 句を使用して明示的に id
列に設定されています。
CREATE TABLE graph_db.Person (
id INT64 NOT NULL,
name STRING
);
CREATE TABLE graph_db.Account (
id INT64 NOT NULL,
create_time TIMESTAMP,
PRIMARY KEY (id) NOT ENFORCED
);
CREATE PROPERTY GRAPH graph_db.FinGraph
NODE TABLES (
graph_db.Person KEY (id),
graph_db.Account
);
- 要素キーが null 以外の各行は、要素キーで識別されるグラフ内の一意のノードにマッピングされます。
- 要素キーが null の行は無視されます。
同じ入力テーブルを複数のノード定義で使用できます。この場合、入力テーブルの特定の行は、ノード定義ごとに 1 つのノードにマッピングされます。
エッジを定義する
エッジはテーブルの行で定義されます。
エッジを定義するには、
EDGE TABLES句にエッジ定義を追加します。
最もシンプルなエッジ定義の形式には、入力テーブルの名前が含まれ、ソースノードと宛先ノードの参照を定義します。BigQuery
Graph は、この定義を使用して、入力テーブルの行をグラフエッジにマッピングします。
デフォルトでは、BigQuery はテーブル名をラベルとして使用し、入力テーブルのすべての列をプロパティとして公開します。
- 各エッジの要素キーは、ノードと同じ方法で定義されます。
ソースノードと宛先ノードの参照
エッジ定義では、SOURCE KEY、DESTINATION KEY、REFERENCES
句を使用して、ソースノードと宛先ノードの参照を定義します。
エッジ定義で使用する前に、ソースノードと宛先ノードを定義する必要があります。
次の例では、次の設定でプロパティ グラフ FinGraph を作成します。
PersonノードとAccountノードPersonOwnAccountエッジ
CREATE TABLE graph_db.Person (
id INT64 NOT NULL,
name STRING,
PRIMARY KEY (id) NOT ENFORCED
);
CREATE TABLE graph_db.Account (
id INT64 NOT NULL,
create_time TIMESTAMP,
PRIMARY KEY (id) NOT ENFORCED
);
CREATE TABLE graph_db.PersonOwnAccount (
id INT64 NOT NULL,
account_id INT64 NOT NULL,
create_time TIMESTAMP,
FOREIGN KEY (account_id) REFERENCES graph_db.Account (id) NOT ENFORCED,
PRIMARY KEY (id, account_id) NOT ENFORCED
);
CREATE PROPERTY GRAPH graph_db.FinGraph
NODE TABLES (
graph_db.Person,
graph_db.Account
)
EDGE TABLES (
PersonOwnAccount
SOURCE KEY (id) REFERENCES Person (id)
DESTINATION KEY (account_id) REFERENCES Account (id)
);
各 PersonOwnAccount エッジは、Person（ソース）ノードを Account
（宛先）ノードに接続します。
- エッジのソースノードは、
idプロパティがエッジのidプロパティと同じPersonノードです。 - エッジの宛先ノードは、
Accountノードで、idプロパティがエッジのaccount_idプロパティと同じです。 - 要素キーは、
PersonOwnAccountテーブルの主キー（(id, account_id)）です。 - 各エッジには、
PersonOwnAccountテーブルの列と同じプロパティのセットがあります。 - 各エッジにはデフォルトの
PersonOwnAccountラベルが付いています。
行をエッジにマッピングする
要素キーが null 以外のエッジ入力テーブルの各行は通常、グラフ内の単一のエッジにマッピングされます。ただし、ソースノードまたは宛先 ノード参照がソースノードまたは宛先ノード テーブル内の 0 個以上のノードと一致する場合、エッジ入力テーブルの行はグラフ内の 0 個以上の エッジになる可能性があります。
単一テーブル内でノードとエッジを定義する
テーブルの列が別のテーブルとの関係を定義している場合は、1 つのテーブルでノードとその入出力エッジを定義できます。このアプローチでは、テーブル数が減り、データの管理が簡素化されます。また、別のエッジテーブルへの結合が不要になるため、クエリのパフォーマンスが向上します。
たとえば、次の Account テーブルに複合主キー
(owner_id, account_id) がある場合、owner_id 列は Person テーブルを参照する外部キーにできます。この構造により、Account テーブルは Account ノードと Person
ノードからの入力エッジの両方を表すことができます。
CREATE TABLE graph_db.Person (
id INT64 NOT NULL,
PRIMARY KEY (id) NOT ENFORCED
);
-- Assume each account has exactly one owner.
CREATE TABLE graph_db.Account (
owner_id INT64 NOT NULL,
account_id INT64 NOT NULL,
FOREIGN KEY (owner_id) REFERENCES graph_db.Person(id) NOT ENFORCED,
PRIMARY KEY (owner_id, account_id) NOT ENFORCED
);
Account テーブルを使用して、Account ノードとその入力 Owns エッジの両方を定義できます。これは、次の CREATE PROPERTY GRAPH ステートメントに含まれています。EDGE TABLES 句では、Account テーブルにエイリアス Owns を指定します。これは、グラフスキーマ内の各要素に一意の名前を付ける必要があるためです。
CREATE PROPERTY GRAPH graph_db.FinGraph
NODE TABLES (
graph_db.Person,
graph_db.Account
)
EDGE TABLES (
graph_db.Account AS Owns
SOURCE KEY (owner_id) REFERENCES Person
DESTINATION KEY (owner_id, account_id) REFERENCES Account
);
ラベルとプロパティをカスタマイズする
LABEL
句と
PROPERTIES
句を使用して、ラベルとプロパティをカスタマイズできます。
次の例では、カスタム プロパティを持つ Person ノードと、複数のラベルを持つ Account ノードを定義します。
CREATE TABLE graph_db.Person (
id INT64 NOT NULL,
name STRING,
birthday TIMESTAMP,
country STRING,
city STRING,
PRIMARY KEY (id) NOT ENFORCED
);
CREATE TABLE graph_db.Account (
id INT64 NOT NULL,
create_time TIMESTAMP,
is_blocked BOOL,
nick_name STRING,
PRIMARY KEY (id) NOT ENFORCED
);
CREATE PROPERTY GRAPH graph_db.FinGraph
NODE TABLES (
graph_db.Person KEY (id)
LABEL Customer
PROPERTIES (CONCAT(city, ", ", country) AS address)
LABEL Entity PROPERTIES (id, name),
graph_db.Account KEY (id)
DEFAULT LABEL OPTIONS(description = 'A checking or savings account')
PROPERTIES (id, create_time)
LABEL Entity
PROPERTIES (
id,
nick_name AS name OPTIONS(description = 'A user-defined account name',
synonyms = ['friendly name', 'display name'])
)
);
Personノードは、Customerラベルを使用してaddressプロパティを公開します。addressプロパティは、入力テーブルPersonのcity列とcountry列を参照する式CONCAT(city, ", ", country),で定義されます。Accountノードは、Accountラベルを使用してidプロパティとcreate_timeプロパティを公開します。
Person ノードと Account ノードの両方に、プロパティ id と name を持つ Entity ラベルがあります。
Personノードでは、idプロパティとnameプロパティは入力テーブルの列から取得されます。Accountノードでは、nameプロパティは入力テーブルのnick_name列 を参照します。Accountノードでは、nameプロパティはOPTIONS句を使用して、プロパティの説明とシノニムのリストを提供します。これらのフィールドは、コンテキストを提供し、自然言語クエリ インターフェースの検出可能性を向上させます。グラフクエリでこれらのフィールドに直接アクセスすることはできません。また、クエリ結果は変更されません。
ラベルとプロパティの整合性
グラフでは、ラベルとプロパティはそれぞれの名前によって一意に識別されます。同じ名前のラベルとプロパティは、複数のノード定義またはエッジ定義で使用できます。ただし、同じ名前のラベルとプロパティについては、次のルールがあります。
- 同じ名前のプロパティは、同じ値の型を使用する必要があります。
- 同じ名前のラベルは、同じプロパティのリストを公開する必要がある。
前の例では、Entity ラベルは Person ノードと Account ノードの両方で定義されています。どちらの定義にも、同じ値の型を持つ同じプロパティ名（id と name）のセットが含まれています。
スキーマの依存関係を管理する
グラフは、ノード定義とエッジ定義の入力テーブルのスキーマと、プロパティによって参照されるテーブル列に依存します。 BigQuery Graph は、テーブルまたは列の削除や変更によって既存のグラフスキーマが無効になるかどうかを確認しません。
スキーマの変更による中断を回避する必要があります。次のベスト プラクティスに従ってください。
- グラフノード定義で使用されているテーブルを削除する前に、まずそのノード定義をグラフから削除します。
- グラフでプロパティとして公開されているテーブルから列を削除する前に、対応するノードまたはエッジ定義からプロパティを削除します。
グラフスキーマを表示する
既存の
グラフの構築に使用される CREATE PROPERTY GRAPH ステートメントを確認するには、
INFORMATION_SCHEMA.PROPERTY_GRAPHS ビューに対してクエリを実行します。
SELECT
property_graph_name,
ddl
FROM
`region-REGION`.INFORMATION_SCHEMA.PROPERTY_GRAPHS;
REGION は、グラフを含むデータセットのリージョンに置き換えます。
または、ノートブックでグラフスキーマを 可視化 することもできます。
グラフスキーマを更新する
既存のグラフのスキーマを変更するには、CREATE PROPERTY GRAPH ステートメントを使用してグラフスキーマを再定義する必要があります。
グラフスキーマを削除する
プロパティ グラフを削除するには、
DROP PROPERTY GRAPH ステートメントを使用します。
次のステップ
- BigQuery Graph の詳細を確認する。
- プロパティ グラフを作成してクエリする方法を学習する 。
- グラフスキーマのベスト プラクティスについて学習する。