Schemaübersicht

In diesem Dokument werden die Komponenten eines Property-Graph-Schemas erläutert und Sie erfahren, wie Sie ein Graph-Schema erstellen und verwalten.

Mit Graphen können Sie verbundene Daten modellieren, die Informationen als Netzwerk aus Knoten und Kanten darstellen. Ein Graph-Schema besteht aus Knoten und Kanten sowie Labels, die ihren Typ klassifizieren, und Eigenschaften, die sie beschreiben. Sie definieren ein Property-Graph-Schema, indem Sie Zeilen aus Eingabetabellen Knoten und Kanten des Graphen zuordnen und benutzerdefinierte Labels und Eigenschaften definieren. Weitere Informationen zu BigQuery Graph finden Sie in der Übersicht zu BigQuery Graph.

Property-Graph-Datenmodell

Mit einem Property-Graph können Sie verbundene Daten als Netzwerk aus Knoten und Kanten modellieren. Knoten stellen Entitäten in Ihren Daten dar, z. B. Kunden, Produkte oder Standorte. Kanten stellen Verbindungen zwischen diesen Knoten dar und erfassen Beziehungen wie Käufe, Follows oder Standorte.

Knoten und Kanten können die folgenden Informationen enthalten:

  • Labels: klassifizieren Knoten- und Kantentypen. Schüler in einer Klasse können beispielsweise das Label Student und das Label Person haben. Wenn Sie kein Label für einen Knoten oder eine Kante definieren, verwendet BigQuery Graph den Namen der Eingabetabelle als Standardlabel.

  • Eigenschaften: werden verwendet, um Knoten und Kanten zu beschreiben. Ein Knoten, der eine Person darstellt, kann beispielsweise die Eigenschaft name mit dem Wert Alex und die Eigenschaft id mit dem Wert 1 haben.

Das Beispiel in Abbildung 1 zeigt, wie Sie einen Graphen entwerfen können, um Finanzaktivitäten zu modellieren. Dieser Graph enthält die folgenden Arten von Entitäten, die als Knoten modelliert werden:

  • Person: stellt eine Person dar, die an Finanztransaktionen beteiligt ist.
  • Account: stellt ein Bankkonto dar, das für Transaktionen verwendet wird.

Diese Entitäten sind durch verschiedene Arten von Beziehungen verbunden, die durch die folgenden gerichteten Kanten dargestellt werden:

  • Owns: Eine Person besitzt ein oder mehrere Konten.
  • Transfers: Geld wird von einem Konto auf ein anderes übertragen.

Jede gerichtete Kante gibt eine unidirektionale Beziehung an, die von einem Quellknoten zu einem Zielknoten verläuft. Eine Transfers-Kante verbindet beispielsweise ein Quellkonto (Account) mit einem Zielkonto (Account) und gibt den Geldfluss an.

Knoten, Kanten, Labels und Attribute eines Finanzgraphen.

Abbildung 1. Beispielgraph mit mehreren Knoten und gerichteten Kanten.

Knoten und Kanten enthalten zusätzliche Informationen in Eigenschaften.

  • Person-Knoten enthalten die folgenden Eigenschaften:

    • name (STRING)
    • id (INT64)

  • Transfers-Kanten enthalten die folgende Eigenschaft:

    • amount (FLOAT64)

Gerichtete und ungerichtete Kanten

Gerichtete Kanten geben eine bestimmte Richtung in der Beziehung zwischen Entitäten an. Eine Person besitzt beispielsweise ein Konto, aber ein Konto besitzt keine Person. Einige Beziehungen wie die Freundschaftsbeziehung in einem sozialen Netzwerk sind jedoch ungerichtet und stellen eine wechselseitige Verbindung dar. In diesem Fall können Sie ungerichtete Kanten als zwei gerichtete Kanten modellieren, eine Kante in jeder Richtung.

Schema entwerfen

Mit BigQuery Graph können Sie mit der CREATE PROPERTY GRAPH Anweisung einen Graphen aus Tabellen erstellen. Die Tabellen, aus denen Graphen erstellt werden, werden als Eingabetabellen bezeichnet.

Knoten definieren

Knoten werden durch Zeilen in den folgenden Arten von Tabellen oder Ansichten definiert:

  • Standardtabellen
  • Externe Tabellen
  • Verwaltete Apache Iceberg-Tabellen
  • Lakehouse Iceberg REST-Katalogtabellen
  • Ansichten, einschließlich autorisierter Ansichten
  • Nicht inkrementelle materialisierte Ansichten

Fügen Sie in der NODE TABLES Klausel eine Knotendefinition hinzu, um einen Knoten zu definieren. Die einfachste Form einer Knotendefinition enthält den Namen einer Eingabe tabelle mit einem Primärschlüssel. BigQuery Graph ordnet Zeilen aus der Eingabetabelle Knoten des Graphen zu.

Im folgenden Beispiel wird die Klausel NODE TABLES verwendet, um den Knoten Account im Property-Graph FinGraph zu definieren. Die Knotendefinition enthält die Eingabetabelle 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
  );

Standardmäßig verwendet BigQuery den Tabellennamen als Label und stellt alle Spalten aus der Eingabetabelle als Eigenschaften zur Verfügung.

  • Jeder Kontoknoten verwendet das Label Account.
  • Jeder Kontoknoten enthält die Eigenschaften id und create_time aus den Spalten der Tabelle Account.

Elementschlüssel

Eine Knotendefinition definiert auch den Elementschlüssel, eine Sammlung von Spalten die einen Graphknoten eindeutig identifizieren. Standardmäßig ist der Elementschlüssel der Primärschlüssel der Eingabetabelle. Alternativ können Sie mit der Klausel KEY explizit Elementschlüssel definieren.

Im folgenden Beispiel werden ein Account-Knoten und ein Person-Knoten definiert. Der Account-Knoten verwendet den Primärschlüssel der Tabelle Account als Elementschlüssel. Der Person-Knoten gibt die Spalte id mit der Klausel KEY explizit als Elementschlüssel an.

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
  );
  • Jede Zeile mit einem nicht leeren Elementschlüssel wird einem eindeutigen Knoten im Graphen zugeordnet, der durch den Elementschlüssel identifiziert wird.
  • Zeilen mit einem leeren Elementschlüssel werden ignoriert.

Dieselbe Eingabetabelle kann in mehreren Knotendefinitionen verwendet werden. In diesem Fall wird eine bestimmte Zeile in der Eingabetabelle für jede Knotendefinition einem Knoten zugeordnet.

Kante definieren

Kanten werden durch Zeilen in den folgenden Arten von Tabellen oder Ansichten definiert:

  • Standardtabellen
  • Externe Tabellen
  • Verwaltete Apache Iceberg-Tabellen
  • Lakehouse Iceberg REST-Katalogtabellen
  • Ansichten, einschließlich autorisierter Ansichten
  • Nicht inkrementelle materialisierte Ansichten

Fügen Sie der EDGE TABLES Klausel eine Kantendefinition hinzu, um eine Kante zu definieren. Die einfachste Form der Kantendefinition enthält den Namen einer Eingabetabelle und definiert Quell- und Zielknotenreferenzen. BigQuery Graph verwendet diese Definition, um Zeilen aus der Eingabetabelle Kanten des Graphen zuzuordnen.

Standardmäßig verwendet BigQuery den Tabellennamen als Label und stellt alle Spalten aus der Eingabetabelle als Eigenschaften zur Verfügung.

  • Der Elementschlüssel jeder Kante wird auf dieselbe Weise wie bei Knoten definiert.

Quell- und Zielknotenreferenzen

Eine Kantendefinition definiert die Quell- und Zielknotenreferenz mit den Klauseln SOURCE KEY, DESTINATION KEY und REFERENCES. Sie müssen die Quell- und Zielknoten definieren, bevor Sie sie in der Kantendefinition verwenden.

Im folgenden Beispiel erstellen Sie einen Property-Graph FinGraph mit den folgenden Elementen:

  • Person- und Account-Knoten
  • PersonOwnAccount-Kante
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)
  );

Jede PersonOwnAccount-Kante verbindet einen Person-Knoten (Quelle) mit einem Account (Ziel)-Knoten.

  • Der Quellknoten einer Kante ist ein Person-Knoten, bei dem die Eigenschaft id mit der Eigenschaft id der Kante übereinstimmt.
  • Der Zielknoten einer Kante ist ein Account Knoten, bei dem die id Eigenschaft mit der Eigenschaft account_id der Kante übereinstimmt.
  • Der Elementschlüssel ist der Primärschlüssel der Tabelle PersonOwnAccount, nämlich (id, account_id).
  • Jede Kante hat dieselben Eigenschaften wie die Spalten aus der Tabelle PersonOwnAccount.
  • Jede Kante hat das Standardlabel PersonOwnAccount.

Zeilen Kanten zuordnen

Jede Zeile in der Eingabetabelle für Kanten mit einem nicht leeren Elementschlüssel wird in der Regel einer einzelnen Kante in Ihrem Graphen zugeordnet. Wenn die Quell- oder Ziel knotenreferenz jedoch mit null oder mehreren Knoten in der Quell- oder Zielknoten tabelle übereinstimmt, kann die Zeile in der Eingabetabelle für Kanten zu null oder mehreren Kanten in Ihrem Graphen führen.

Knoten und Kanten in einer einzelnen Tabelle definieren

Sie können einen Knoten und seine eingehenden oder ausgehenden Kanten in einer einzelnen Tabelle definieren, wenn die Spalten der Tabelle eine Beziehung zu einer anderen Tabelle definieren. Dieser Ansatz reduziert die Anzahl der Tabellen, vereinfacht die Datenverwaltung und kann die Abfrageleistung verbessern, da keine Verknüpfung mit einer separaten Kantentabelle erforderlich ist.

Wenn die folgende Tabelle Account beispielsweise einen zusammengesetzten Primärschlüssel (owner_id, account_id) hat, kann die Spalte owner_id ein Fremdschlüssel sein, der auf eine Tabelle Person verweist. Mit dieser Struktur kann die Tabelle Account sowohl den Knoten Account als auch die eingehende Kante vom Knoten Person darstellen.

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
);

Sie können die Tabelle Account verwenden, um sowohl den Knoten Account als auch die eingehende Kante Owns zu definieren. Dies wird in der folgenden Anweisung CREATE PROPERTY GRAPH gezeigt. In der Klausel EDGE TABLES geben Sie der Tabelle Account den Alias Owns. Das liegt daran, dass jedes Element im Graph-Schema einen eindeutigen Namen haben muss.

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
  );

Labels und Eigenschaften anpassen

Mit den LABEL und PROPERTIES Klauseln können Sie Labels und Eigenschaften anpassen.

Im folgenden Beispiel werden ein Person-Knoten mit einer benutzerdefinierten Eigenschaft und ein Account-Knoten mit mehreren Labels definiert:

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'])
      )
  );

  • Die Person-Knoten verwenden das Label Customer, um die Eigenschaft address verfügbar zu machen. Die Eigenschaft address wird durch den Ausdruck CONCAT(city, ", ", country), definiert, der auf die Spalten city und country aus der Eingabetabelle Person verweist.

  • Der Account-Knoten verwendet das Label Account, um die Eigenschaften id und create_time verfügbar zu machen.

Die Knoten Person und Account haben beide das Label Entity mit den Eigenschaften id und name.

  • Im Knoten Person stammen die Eigenschaften id und name aus den Spalten der Eingabetabelle.
  • Im Knoten Account verweist die Eigenschaft name auf die Spalte nick_name der Eingabetabelle.
  • Im Knoten Account verwendet die Eigenschaft name die Klausel OPTIONS, um eine Beschreibung der Eigenschaft und eine Liste von Synonymen bereitzustellen. Diese Felder bieten Kontext und verbessern die Auffindbarkeit für Schnittstellen zur Abfrage in natürlicher Sprache. Sie können nicht direkt in Ihren Graphabfragen auf diese Felder zugreifen und sie ändern die Abfrageergebnisse in keiner Weise.

Label- und Eigenschaftskonsistenz

In einem Graphen werden Labels und Eigenschaften eindeutig durch ihre Namen identifiziert. Sie können Labels und Eigenschaften mit demselben Namen in mehreren Knoten- oder Kantendefinitionen verwenden. Labels und Eigenschaften mit demselben Namen müssen jedoch die folgenden Regeln einhalten:

  • Eigenschaften mit demselben Namen müssen denselben Werttyp verwenden.
  • Labels mit demselben Namen müssen dieselbe Liste von Eigenschaften verfügbar machen.

Im vorherigen Beispiel wird das Label Entity sowohl im Knoten Person als auch im Knoten Account definiert. Beide Definitionen enthalten dieselben Eigenschaftsnamen, id und name, mit identischen Werttypen.

Schemaabhängigkeiten verwalten

Graphen sind vom Schema der Eingabetabellen für die Knoten- und Kantendefinitionen und den Tabellenspalten abhängig, auf die von den Eigenschaften verwiesen wird. BigQuery Graph prüft nicht, ob das Löschen oder Ändern von Tabellen oder Spalten ein vorhandenes Graph-Schema ungültig macht.

Sie sind dafür verantwortlich, dass keine Schemaänderungen vorgenommen werden, die zu Fehlern führen. Beachten Sie diese Best Practices:

  • Bevor Sie eine Tabelle löschen, die in einer Graphknotendefinition verwendet wird, entfernen Sie zuerst diese Knotendefinition aus dem Graphen.
  • Bevor Sie eine Spalte aus einer Tabelle entfernen, die als Eigenschaft in einem Graphen verfügbar gemacht wird, entfernen Sie die Eigenschaft aus der entsprechenden Knoten- oder Kantendefinition.

Graph-Schemas ansehen

Wenn Sie die Anweisung CREATE PROPERTY GRAPH sehen möchten, mit der ein vorhandener Graph erstellt wurde, fragen Sie die INFORMATION_SCHEMA.PROPERTY_GRAPHS Ansicht ab:

SELECT
  property_graph_name,
  ddl
FROM
  `region-REGION`.INFORMATION_SCHEMA.PROPERTY_GRAPHS;

Ersetzen Sie REGION durch die Region des Datasets, das den Graphen enthält.

Alternativ können Sie Ihr Graph-Schema in einem Notebook visualisieren.

Graph-Schema aktualisieren

Wenn Sie Änderungen am Schema eines vorhandenen Graphen vornehmen möchten, müssen Sie das Graph-Schema mit der Anweisung CREATE PROPERTY GRAPH neu definieren.

Graph-Schema löschen

Verwenden Sie die DROP PROPERTY GRAPH Anweisung, um einen Property-Graph zu löschen.

Best Practices

In den folgenden Abschnitten werden Best Practices für die Definition Ihres Graph-Schemas beschrieben, um die Leistung Ihrer Graphabfragen zu verbessern.

Umfang Ihrer Eigenschaftsdefinitionen festlegen

Eigenschaften sind Schlüssel/Wert-Paare, die zusätzliche Informationen zu Knoten oder Kanten enthalten. Wir empfehlen, nur die erforderlichen Eigenschaften in Knoten oder Kanten aufzunehmen und die Syntax PROPERTIES ALL COLUMNS oder die Standardsyntax zu vermeiden, mit der alle Spalten aus den Knoten- oder Kantentabellen an die Eigenschaftsliste angehängt werden. Viele Eigenschaften in Knoten oder Kanten können zu unnötigen Spaltenscans in Graphabfragen führen, was die Leistung beeinträchtigt.

Wenn Sie die Eigenschaften einschränken möchten, die Sie in eine Knoten- oder Kantendefinition aufnehmen, verwenden Sie das PROPERTIES Schlüsselwort, wenn Sie Elementattribute definieren in Ihrer CREATE PROPERTY GRAPH Anweisung.

Die folgende Knotentabellendefinition beschränkt die Eigenschaften für die Knotentabelle Person auf id und name:

NODE TABLES (
  graph_db.Person PROPERTIES (id, name)
)

Beschränkungen für Primär- und Fremdschlüssel für Graphknoten und -kanten definieren

BigQuery kann Beschränkungen für Primär- und Fremdschlüssel für Ihre Knoten- und Kantentabellen verwenden, um Ihre Graph abfragen zu optimieren, indem unnötige Tabellenscans reduziert werden. BigQuery erzwingt jedoch keine Beschränkungen für Primär- oder Fremdschlüssel für Tabellen. Wenn Ihre Anwendung keine referenzielle Integrität oder Eindeutigkeit für Primärschlüssel garantieren kann, kann die Verwendung von Primär- oder Fremdschlüsseln zur Abfrageoptimierung zu falschen Abfrageergebnissen führen.

Im folgenden Beispiel werden Beschränkungen für Primär- und Fremdschlüssel für die Knoten tabellen Person und Account, und die Kantentabelle PersonOwnAccount definiert:

CREATE OR REPLACE TABLE graph_db.Person (
  id               INT64,
  name             STRING,
  birthday         TIMESTAMP,
  country          STRING,
  city             STRING,
  PRIMARY KEY (id) NOT ENFORCED
);

CREATE OR REPLACE TABLE graph_db.Account (
  id               INT64,
  create_time      TIMESTAMP,
  is_blocked       BOOL,
  nick_name        STRING,
  PRIMARY KEY (id) NOT ENFORCED
);

CREATE OR REPLACE TABLE graph_db.PersonOwnAccount (
  id               INT64 NOT NULL,
  account_id       INT64 NOT NULL,
  create_time      TIMESTAMP,
  PRIMARY KEY (id, account_id) NOT ENFORCED,
  FOREIGN KEY (id) references graph_db.Person(id) NOT ENFORCED,
  FOREIGN KEY (account_id) references graph_db.Account(id) NOT ENFORCED
);

Nächste Schritte

  • Weitere Informationen zu BigQuery Graph.
  • Property-Graph erstellen und abfragen .
  • Graphabfragen schreiben
  • Graphen mit Messwerten erstellen