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 von Knoten und Kanten darstellen. Ein Graph-Schema besteht aus Knoten und Kanten sowie Labels, die ihren Typ klassifizieren, und Attributen, die sie beschreiben. Sie definieren ein Property-Graph-Schema, indem Sie Zeilen aus Eingabetabellen Knoten und Kanten des Graphen zuordnen und benutzerdefinierte Labels und Attribute definieren. Weitere Informationen zu BigQuery Graph finden Sie in der Übersicht zu BigQuery Graph.

Datenmodell für Property-Graphen

Mit einem Property-Graph können Sie verbundene Daten als Netzwerk von 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. Beispielsweise können Schüler in einer Klasse das Label Student und das Label Person haben. Wenn Sie kein Label für einen Knoten oder eine Kante explizit definieren, verwendet BigQuery Graph den Namen der Eingabetabelle als Standardlabel.

  • Attribute: werden verwendet, um Knoten und Kanten zu beschreiben. Ein Knoten, der eine Person darstellt, kann beispielsweise ein Attribut name mit dem Wert Alex und ein Attribut 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. Beispielsweise verbindet eine Transfers-Kante ein Quellkonto (Account) mit einem Zielkonto (Account) und gibt so den Geldfluss an.

Knoten, Kanten, Labels und Attribute eines Finanzgraphen.

Abbildung 1. Beispiel für einen Graphen mit mehreren Knoten und gerichteten Kanten.

Knoten und Kanten enthalten zusätzliche Informationen in Attributen.

  • Person-Knoten enthalten die folgenden Attribute:

    • name (STRING)
    • id (INT64)

  • Transfers-Kanten enthalten das folgende Attribut:

    • amount (FLOAT64)

Gerichtete und ungerichtete Kanten

Gerichtete Kanten geben eine bestimmte Richtung in der Beziehung zwischen Entitäten an. Beispielsweise besitzt eine Person 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 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 eine Knotendefinition in die NODE TABLES Klausel ein, 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 Attribute zur Verfügung.

  • Jeder Kontoknoten verwendet das Label Account.
  • Jeder Kontoknoten enthält die Attribute 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 Graphenknoten 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 Elementschlüssel, der nicht null ist, wird einem eindeutigen Knoten im Graphen zugeordnet, der durch den Elementschlüssel identifiziert wird.
  • Zeilen mit einem Elementschlüssel, der null ist, 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 eine Kantendefinition in die EDGE TABLES Klausel ein, 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 Attribute 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 das Attribut id mit dem Attribut id der Kante übereinstimmt.
  • Der Zielknoten einer Kante ist ein Account Knoten, bei dem das id Attribut mit dem account_id Attritt der Kante übereinstimmt.
  • Der Elementschlüssel ist der Primärschlüssel der Tabelle PersonOwnAccount, nämlich (id, account_id).
  • Jede Kante hat dieselben Attribute 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 Elementschlüssel, der nicht null ist, 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 Attribute anpassen

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

Im folgenden Beispiel werden ein Person-Knoten mit einem benutzerdefinierten Attribut 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 das Attribut address verfügbar zu machen. Das Attribut 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 Attribute id und create_time verfügbar zu machen.

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

  • Im Knoten Person stammen die Attribute id und name aus den Spalten der Eingabetabelle.
  • Im Knoten Account verweist das Attribut name auf die Spalte nick_name der Eingabetabelle.
  • Im Knoten Account verwendet das Attribut name die Klausel OPTIONS, um eine Beschreibung des Attributs 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 Graph-Abfragen auf diese Felder zugreifen und sie ändern die Abfrageergebnisse in keiner Weise.

Label- und Attributkonsistenz

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

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

Im vorherigen Beispiel wird das Label Entity sowohl im Knoten Person als auch im Knoten Account definiert. Beide Definitionen enthalten dieselbe Gruppe von Attributnamen, 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 Attributen verwiesen wird. BigQuery Graph prüft nicht, ob durch das Löschen oder Ändern von Tabellen oder Spalten ein vorhandenes Graph-Schema ungültig wird.

Sie sind dafür verantwortlich, dass keine Schemaänderungen vorgenommen werden, die zu Problemen führen. Wir empfehlen folgende Best Practices:

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

Graph-Schemas ansehen

Wenn Sie die Anweisung CREATE PROPERTY GRAPH sehen möchten, die zum Erstellen eines vorhandenen Graphen verwendet 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 Graph-Abfragen zu verbessern.

Umfang Ihrer Attributdefinitionen festlegen

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

Verwenden Sie das PROPERTIES Keyword, wenn Sie Elementattribute definieren in Ihrer CREATE PROPERTY GRAPH Anweisung, um die Attribute einzuschränken, die Sie in eine Knoten- oder Kantendefinition aufnehmen.

Die folgende Knotentabellendefinition beschränkt die Attribute 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 Graph-Knoten 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 sowie 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 .
  • Graph-Abfragen schreiben
  • Graphen mit Messwerten erstellen