Spanner Graph-Schema – Übersicht

In diesem Dokument wird das Spanner-Graph-Schema beschrieben und Beispiele für Schlüsselkonzepte veranschaulichen. Weitere Informationen zu Spanner Graph finden Sie unter Spanner Graph – Übersicht.

Attributgrafik-Datenmodell

Mit einem Property-Graph können Sie verbundene Daten modellieren. Dabei werden Informationen als Netzwerk von Knoten und Kanten dargestellt. Knoten stehen für Entitäten in Ihrer Datenlandschaft, z. B. „Kunden“, „Produkte“ oder „Standorte“. Kanten zeigen die Verbindungen zwischen diesen Knoten und erfassen Beziehungen wie „gekauft“, „folgt“ oder „befindet sich in“.

Sowohl Knoten als auch Kanten können die folgenden Informationen enthalten:

  • Labels, die Knoten und Kanten in Sätzen klassifizieren, z. B. „Stadt“.
  • Eigenschaften, d. h. Schlüssel/Wert-Paare, z. B. „Bevölkerung“

Das Beispiel in Abbildung 1 zeigt, wie Sie einen Graphen zur Modellierung von Finanzaktivitäten entwerfen können. Dieses Diagramm enthält die folgenden Elementtypen modelliert als Knoten:

  • Person:Eine natürliche Person, die an Finanztransaktionen beteiligt ist.
  • Konto:Bankkonto, das für Transaktionen verwendet wird

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

  • Inhaber: Eine Person ist Inhaber eines oder mehrerer Konten.
  • Überweisungen:Geld wird von einem Konto auf ein anderes übertragen.

Jede gerichtete Kante gibt eine Einwegbeziehung an, die von einem Quellknoten zu einem Zielknoten verläuft. Ein Transfers-Edge verbindet beispielsweise eine Quelle Account an ein Ziel Account, das den Geldfluss angibt.

Übersichtsdiagramm für Spanner-Graph-Schemas

Abbildung 1. Beispieldiagramm mit mehreren Knoten und gerichteten Kanten.

Knoten und Kanten können zusätzliche Informationen in Form von Attributen enthalten. Jedes Attribut hat einen Namen und einen Wert.

  • Person-Knoten haben die folgenden Eigenschaften:
    • name (STRING)
    • id (INT64)
  • Kanten vom Typ Übertragungen haben die folgende Eigenschaft:
    • amount (FLOAT64)

Richte und ungerichtete Kanten

In der Beispielgrafik werden gerichtete Kanten verwendet, die eine bestimmte Richtung im Beziehung zwischen Entitäten. Einige Beziehungen, wie der "Freund" Beziehung in einem sozialen Netzwerk sind, sind nicht auf bestimmte Zielgruppen ausgerichtet und stellen eine wechselseitige Verbindung ohne eindeutigen Ursprung oder Endpunkt. In diesem Fall können Sie ungerichtete Kanten als zwei gerichtete Kanten modellieren, eine in jede Richtung.

Schemadesign für Spanner Graph

Mit Spanner Graph können Sie mit der Anweisung CREATE PROPERTY GRAPH einen Graphen aus Tabellen erstellen. Die Tabellen, die zum Erstellen von Grafiken verwendet werden werden als Eingabetabellen bezeichnet. Dieser Ansatz basiert auf SQL/PGQ (Property Graph-Abfragen) das Teil von SQL:2023 Standards ist.

Knoten in einem Attributdiagramm definieren

Um einen Knoten zu definieren, fügen Sie eine Knotendefinition in die NODE TABLES-Klausel ein. Die einfachste Form von Knotendefinition enthält nur einen Eingabetabellennamen. Zeilen aus der Eingabetabelle werden Graphknoten zugeordnet.

Im folgenden Beispiel definieren Sie mit der Klausel NODE TABLES den Parameter Account-Knoten im Attributdiagramm FinGraph. Die Knotendefinition enthält die Eingabetabelle 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
  );

Standardlabel und ‐eigenschaften

Standardmäßig verwenden alle Knoten den Namen der Eingabetabelle als Label und alle Spalten aus der Eingabetabelle werden als Knotenattribute angezeigt.

Im vorherigen Beispiel

  • Jeder Kontoknoten hat das Label Account.
  • Jeder Kontoknoten hat Attribute, die [id, create_time] aus dem Account Tabellenspalten.

Elementschlüssel

Eine Knotendefinition definiert auch den Elementschlüssel, der ein Diagrammknoten.

  • Der Elementschlüssel ist standardmäßig der Primärschlüssel der Eingabetabelle.
  • Elementschlüssel können explizit durch die KEY-Klausel definiert werden.
  • Spalten mit Eindeutigkeitsbeschränkungen UNIQUE INDEX können als Elementschlüssel verwendet werden.

Im folgenden Beispiel werden der Account-Knoten und der Person-Knoten definiert.

  • Für den Account-Knoten wird standardmäßig der Primärschlüssel der Tabelle Account als Elementschlüssel verwendet.
  • Person-Knoten dagegen explizit die id als den Elementschlüssel mit der KEY-Klausel.
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
  );

Eine Zeile in der Eingabetabelle einem Knoten im Diagramm zuordnen

  • Jede Zeile mit einem Elementschlüssel ungleich null wird einem eindeutigen Knoten im das durch den Elementschlüssel identifiziert wird.
  • Zeilen mit einem Null-Elementschlüssel werden ignoriert.

Kanten in einer Property-Graph-Datei definieren

Fügen Sie eine Edge-Definition in die EDGE TABLES-Klausel ein, um eine Kante zu definieren. Die einfachste Form einer Kantendefinition enthält nur den Namen einer Eingabetabelle. Zeilen aus der Eingabetabelle Graphenkanten zugeordnet.

Quell- und Zielknotenreferenz

Im folgenden Beispiel erstellen Sie eine Attributgrafik FinGraph mit den folgenden Elementen:

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

Eine Edge-Definition muss die Referenz des Quell- und Zielknotens mithilfe von den SOURCE KEY-, DESTINATION KEY- und REFERENCES-Klauseln. Im folgenden Beispiel wird die Kantendefinition von PersonOwnAccount verwendet, um dieses Konzept zu veranschaulichen:

EDGE TABLES (
  PersonOwnAccount
    SOURCE KEY (id) REFERENCES Person (id)
    DESTINATION KEY (account_id) REFERENCES Account (id)
)

Jede PersonOwnAccount-Kante verbindet einen Person-Knoten (Quellknoten) mit einem Account-Knoten (Zielknoten).

  • Der SOURCE-Knoten einer Kante ist ein Person-Knoten, dessen id mit der Kante id identisch ist.
  • Der DESTINATION-Knoten einer Kante ist ein Account-Knoten, dessen id mit der Kante account_id übereinstimmt.

Außerdem gilt für die PersonOwnAccount-Kante Folgendes:

  • 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.

Zuordnung einer Zeile in einer Edge-Eingabetabelle zu Kanten im Diagramm

  • Jede Zeile in der Eingabetabelle für Kanten, deren Elementschlüssel nicht null ist, wird normalerweise einer eindeutigen Kante in Ihrem Graphen zugeordnet.
  • Eine Zeile kann null oder mehr als einer Kante im Graphen entsprechen, z. B. wenn die Referenz des Quellknotens mit null oder mehr Knoten in der Tabelle mit Quellknoten übereinstimmt.
  • Die gleiche Eingabetabelle kann in verschiedenen Knoten- oder Kantendefinitionen verwendet werden, um verschiedene Knoten- oder Kantengruppen zu erstellen. Weitere Informationen finden Sie unter Knoten- und Kanteneingabetabellen zusammenführen.

Labels und Eigenschaften anpassen

Sie können das Feld LABEL und EIGENSCHAFTEN um Labels und Eigenschaften anzupassen.

Im folgenden Beispiel sind zwei Knoten definiert: Person und Account.

  • Die Person-Knoten expose die address-Eigenschaft über das Label Customer. Die Das Attribut address wird durch den Ausdruck CONCAT(city, ", ", country), definiert, der auf die Spalten city und country aus der Eingabe verweist Tabelle Person.
  • Für Account stellt der Knoten Account die Eigenschaften id und create_time über das Label Account bereit.
  • Person und Account haben das Label Entity mit den Eigenschaften [id, name].
    • Für Person haben die Properties id und name aus den Eingabetabellenspalten.
    • Bei Account bezieht sich die Eigenschaft name auf die Spalte nick_name der Eingabetabelle.
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)
  );

Label- und Property-Konsistenz

In einem Diagramm werden Labels und Eigenschaften eindeutig anhand ihrer Namen identifiziert. Labels und Eigenschaften mit demselben Namen können in mehreren Knoten- oder Kantendefinitionen vorkommen. Labels und Properties mit demselben Namen müssen jedoch diesen Regeln entsprechen:

  • Eigenschaften mit demselben Namen müssen denselben Werttyp haben.
  • Labels mit demselben Namen müssen dieselbe Liste von Properties enthalten.

Im vorherigen Beispiel ist das Label Entity sowohl in Person als auch in Account Knoten. In beiden Definitionen haben sie dieselben Attributnamen [id, name] mit denselben Werttypen.

Abhängigkeiten zwischen Diagrammen und anderen Schemaobjekten

Die von CREATE PROPERTY GRAPH erstellte Grafik ist von einem anderen Schema abhängig wie die Eingabetabellen der Knoten- und Edge-Definitionen sowie Spalten, auf die in den Eigenschaften verwiesen wird. Wenn eine Schemaänderung eine dieser Abhängigkeiten bricht, ist die Änderung nicht zulässig.

Die folgende Anweisung erstellt eine Abhängigkeit von FinGraph zum Account. und den Spalten id und create_time.

CREATE OR REPLACE PROPERTY GRAPH FinGraph
  NODE TABLES (
    Account PROPERTIES (id, create_time)
  );

Im Folgenden finden Sie Beispiele für Schemaänderungen, die nicht zulässig sind:

Sie können jedoch die folgenden Schemaänderungen vornehmen:

  • Ändern Sie das Schema der Tabelle Account und der Spalten id und create_time, sofern dies durch andere Schemaanforderungen zulässig ist. Weitere Informationen finden Sie unter Schemaaktualisierungen vornehmen

Nächste Schritte