このページの一部またはすべての情報は、S3NS の Cloud de Confiance に適用されない場合があります。詳細については、Google Cloud との違いをご確認ください。

スキーマの概要

このドキュメントでは、プロパティグラフスキーマのコンポーネントについて説明し、グラフスキーマを作成して管理する方法を示します。

グラフを使用すると、情報をノードとエッジのネットワークで表す接続されたデータをモデル化できます。グラフスキーマは、ノードとエッジ、それらのタイプを分類するラベル、それらを記述するプロパティで構成されます。プロパティグラフのスキーマを定義するには、入力テーブルの行をグラフのノードとエッジにマッピングし、カスタムラベルとプロパティを定義します。BigQuery Graph の詳細については、BigQuery Graph の概要をご覧ください。

プロパティグラフのデータモデルを理解する

プロパティグラフを使用すると、接続されたデータをノードとエッジのネットワークとしてモデル化できます。ノードは、データ内のエンティティ（顧客、商品、場所など）を表します。エッジはノード間の接続を表し、購入、フォロー、位置などの関係をキャプチャします。

ノードとエッジには、次の情報を配置できます。

ラベル: ノードとエッジタイプを分類します。たとえば、クラスの生徒に Student ラベルと Person ラベルが付いている場合があります。ノードまたはエッジのラベルを明示的に定義しない場合、BigQuery Graph は入力テーブル名をデフォルトのラベルとして使用します。
プロパティ: ノードとエッジを記述するために使用されます。たとえば、人物を表すノードに、値 Alex の name プロパティと値 1 の id プロパティがある場合があります。

図 1 の例は、財務活動をモデル化するグラフを設計する方法を示しています。このグラフには、ノードとしてモデル化された次のタイプのエンティティが含まれています。

Person: 金融取引に関与する個人を表します。
Account: 取引に使用される銀行口座を表します。

これらのエンティティは、次の有向エッジで表されるさまざまなタイプの関係で接続されています。

Owns: 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 ノードです。
エッジの宛先ノードは、id プロパティがエッジの account_id プロパティと同じである Account ノードです。
要素キーは、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)
      LABEL Account PROPERTIES (id, create_time)
      LABEL Entity PROPERTIES (id, nick_name AS 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 列を参照します。

ラベルとプロパティの整合性

グラフでは、ラベルとプロパティはそれぞれの名前によって一意に識別されます。同じ名前のラベルとプロパティは、複数のノード定義またはエッジ定義で使用できます。ただし、同じ名前のラベルとプロパティについては、次のルールがあります。

同じ名前のプロパティは、同じ値の型を使用する必要があります。
同じ名前のラベルは、同じプロパティのリストを公開する必要がある。

上の例では、Entity ラベルは Person ノードと Account ノードの両方で定義されています。どちらの定義にも、同じ値の型を持つ同じプロパティ名のセット（id と name）が含まれています。

スキーマの依存関係を管理する

グラフは、ノード定義とエッジ定義の入力テーブルのスキーマと、プロパティによって参照されるテーブル列に依存します。BigQuery Graph は、テーブルまたは列の削除や変更によって既存のグラフスキーマが無効になるかどうかを確認しません。

スキーマの互換性を損なう変更を回避する責任はユーザーにあります。次のベストプラクティスに従ってください。

グラフノード定義で使用されているテーブルを削除する前に、まずそのノード定義をグラフから削除します。
グラフのプロパティとして公開されているテーブルから列を削除する前に、対応するノード定義またはエッジ定義からプロパティを削除します。

グラフスキーマを表示する

ノートブックでグラフスキーマを視覚化できます。

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

既存のグラフのスキーマを変更するには、CREATE PROPERTY GRAPH ステートメントを使用してグラフスキーマを再定義する必要があります。

グラフスキーマを削除する

プロパティグラフを削除するには、DROP PROPERTY GRAPH ステートメントを使用します。

次のステップ

BigQuery Graph の詳細を確認する。
プロパティグラフを作成してクエリする方法を学習する。
グラフスキーマのベストプラクティスについて確認する。