Diagramm aus einer SQL-Ansicht erstellen

Hinweis: Diese Funktion ist in der Spanner Enterprise-Version und Enterprise Plus-Version verfügbar. Weitere Informationen finden Sie in der Übersicht über Spanner-Versionen.

Grafik mit SQL-Ansichten erstellen Dieses Dokument enthält eine detaillierte Anleitung und Codebeispiele zum Definieren von Ansichten und zum Verwenden dieser Ansichten zum Definieren von Knoten- und Kantentabellen. Beispiele mit Beispielcode, die Anwendungsfälle für das Erstellen von Diagrammen mit Ansichten veranschaulichen. Weitere Informationen zum Erstellen eines Eigenschaftsgraphen mithilfe von Ansichten, einschließlich Vorteilen und Überlegungen, finden Sie unter Übersicht über aus SQL-Ansichten erstellte Graphen.

Hinweis

So erstellen Sie ein Diagramm:

1. Ihre Spanner Graph-Umgebung muss eingerichtet sein.

2. Machen Sie sich mit der Funktionsweise von Spanner Graph-Schemas vertraut.

Graph mit Ansichten erstellen

So erstellen Sie ein Diagramm mit Ansichten:

1. Definieren Sie Ansichten für Ihr Diagramm. Standardmäßig müssen Ihre Ansichten einem der unterstützten Ansichtsmuster entsprechen, damit die Eindeutigkeit der Elemente gewährleistet ist. Wenn Ihre Ansichten Abfragen verwenden, die diesen Mustern nicht entsprechen, können Sie die Validierung der Schlüssel-Eindeutigkeit in Schritt 4 deaktivieren. Weitere Informationen finden Sie unter Ansicht erstellen.

2. Verwenden Sie Ihre Ansichten in den Klauseln NODE TABLES und EDGE TABLES der Anweisung CREATE PROPERTY GRAPH, um ein Diagramm zu erstellen.

3. Fügen Sie die KEY-Klausel in die CREATE PROPERTY GRAPH-Anweisung ein. Die KEY-Klausel gibt die Spalten aus der Quellansicht an, die jedes Grafikelement eindeutig identifizieren.

4. Optional: Wenn Ihre Ansichten beliebige SQL-Abfragen verwenden, die nicht den unterstützten Eindeutigkeitsmustern entsprechen, fügen Sie die OPTIONS (validate_element_key_uniqueness = false)-Klausel zur CREATE PROPERTY GRAPH-Anweisung hinzu. Die Spalten der KEY-Klausel müssen für jede Knoten- oder Kantenzeile eindeutige Werte erzeugen:

   CREATE PROPERTY GRAPH MyGraph
     NODE TABLES (
       CustomerViewTrusted KEY(id)
     ) OPTIONS (validate_element_key_uniqueness = false);
   

   Weitere Informationen finden Sie unter Deaktivierte Schlüsselvalidierung (beliebige SQL-Abfrage).

5. Optional: Wenn Ihre Ansichten eine Remote-Funktion aufrufen oder andere flüchtige Spalten enthalten, fügen Sie der CREATE PROPERTY GRAPH-Anweisung die OPTIONS (allow_view_with_volatile_column = true)-Klausel hinzu:

   CREATE PROPERTY GRAPH MyGraph
     NODE TABLES (
       AccountRemoteUdfView KEY(account_id)
     ) OPTIONS (allow_view_with_volatile_column = true);
   

   Weitere Informationen finden Sie unter Flüchtige Spalten aktivieren, wenn Ansichten Remote-Funktionen verwenden.

Beispiel: Graph mit Ansichten erstellen

In diesem Beispiel werden die folgenden Ansichten für die Tabellen Customer und Account erstellt: AsiaCustomer, AsiaBankAccount und AsiaAccountsOwnership. Anschließend werden diese Ansichten im Beispiel verwendet, um Folgendes in einem Diagramm zu erstellen:

• Erstellen Sie die Knotentabelle Customer mit der Ansicht AsiaCustomer.

• Erstellen Sie die Knotentabelle Account mit der Ansicht AsiaBankAccount.

• Erstellen Sie die Edge-Tabelle Owns mit der Ansicht AsiaAccountsOwnership. Diese Kante verbindet Customer-Knoten mit Account-Knoten.

Schritt 1: Tabellen erstellen

Erstellen Sie zuerst die Datentabellen. Mit dem folgenden Code werden die Tabellen Customer und Account erstellt.

CREATE TABLE Customer (
  customer_id INT64 NOT NULL,
  name STRING(MAX),
  address_continent STRING(MAX),
  address_country STRING(MAX),
) PRIMARY KEY(customer_id);

CREATE TABLE Account (
  account_id INT64 NOT NULL,
  customer_id INT64 NOT NULL,
  account_type STRING(MAX),
  balance INT64,
  create_time TIMESTAMP,
  address_continent STRING(MAX),
  address_country STRING(MAX),
  CONSTRAINT FK_CustomerId FOREIGN KEY (customer_id)
    REFERENCES Customer (customer_id)
) PRIMARY KEY(account_id);

Schritt 2: Ansichten erstellen

Erstellen Sie als Nächstes Ansichten, um Daten aus den Tabellen zu transformieren oder zu filtern. Diese Ansichten filtern die Tabellen so, dass nur Kunden und Konten in Asien enthalten sind. Sofern validate_element_key_uniqueness nicht auf false festgelegt ist, müssen Ansichten, die zum Erstellen von Diagrammelementen verwendet werden, unterstützten Mustern folgen, damit die Zeilen in der Ansicht eindeutig sind.

-- View for 'Customer' nodes, filtered for Asia
CREATE VIEW AsiaCustomer
  SQL SECURITY INVOKER AS
    SELECT customer.customer_id, customer.name
    FROM Customer customer
    WHERE LOWER(customer.address_continent) = "asia";

-- View for 'Account' nodes, filtered for Asia.
CREATE VIEW AsiaBankAccount
  SQL SECURITY INVOKER AS
    SELECT account.account_id, account.balance, account.account_type, account.create_time
    FROM Account account
    WHERE LOWER(account.address_continent) = "asia";

-- View for 'Owns' edges, connecting customers to accounts in Asia.
CREATE VIEW AsiaAccountsOwnership
  SQL SECURITY INVOKER AS
    SELECT account.customer_id, account.account_id
    FROM Account account
    WHERE LOWER(account.address_continent) = "asia";

Schritt 3: Property-Grafik erstellen

Erstellen Sie jetzt die AsiaFinGraph mit den von Ihnen erstellten Ansichten. Die CREATE PROPERTY GRAPH-Anweisung enthält die KEY-Klausel für jede Definition von Grafikelementen, um Spalten anzugeben, die die Grafikelemente eindeutig identifizieren.

CREATE PROPERTY GRAPH AsiaFinGraph
  NODE TABLES (
    AsiaCustomer AS Customer KEY(customer_id),
    AsiaBankAccount AS Account KEY(account_id)
  )
  EDGE TABLES (
    AsiaAccountsOwnership AS Owns
      KEY(customer_id, account_id)
      SOURCE KEY (customer_id) REFERENCES Customer (customer_id)
      DESTINATION KEY (account_id) REFERENCES Account (account_id)
  );

Anwendungsbeispiele

SQL-Ansichten bieten Vorteile gegenüber der Verwendung von Tabellen für Property Graph-Elemente. In den folgenden Beispielen werden einige Anwendungsfälle für die Definition von Diagrammelementen mit Ansichten anstelle von Tabellen veranschaulicht.

Beispiel: Detaillierte Zugriffssteuerung für Diagrammdaten erzwingen

Wenn Sie die Sicherheit auf Zeilenebene für Ihre Grafikdaten erzwingen möchten, definieren Sie Ihre Knoten- oder Kantentabellen mit Ansichten mit den Rechten des Erstellers. Die Ansicht stellt dem Diagramm eine zulässige Teilmenge der zugrunde liegenden Daten zur Verfügung.

Wenn Sie beispielsweise den Zugriff auf Diagramme auf Mitarbeiter in einer Kostenstelle für die Entwicklung beschränken möchten, können Sie eine EngineerEmployeeView-Ansicht erstellen und einer engineering_data_reader-Rolle mit der GRANT-Klausel SELECT-Berechtigungen für die Ansicht gewähren.

Wenn Sie eine Graphknotentabelle mit dieser Ansicht definieren, können Nutzer, die Graphabfragen mit der Rolle engineering_data_reader ausführen, nur die von der Ansicht gefilterten Zeilen sehen, die Mitarbeiter aus der Entwicklung enthalten.

-- The table containing all employee data.
CREATE TABLE Employee (
  id INT64 NOT NULL,
  cost_center STRING(MAX),
  job_title STRING(MAX),
  office STRING(MAX)
) PRIMARY KEY (id);

-- The definer's rights view that filters for engineering employees.
CREATE VIEW EngineerEmployeeView SQL SECURITY DEFINER AS
  SELECT e.id, e.cost_center, e.job_title, e.office
  FROM Employee e
  WHERE LOWER(e.cost_center) = "engineering";

-- The role that is granted to read the view.
CREATE ROLE engineering_data_reader;
GRANT SELECT ON VIEW EngineerEmployeeView TO ROLE engineering_data_reader;

-- The graph that uses definer's rights view.
CREATE PROPERTY GRAPH EngineeringGraph
  NODE TABLES (
    EngineerEmployeeView KEY(id)
  );

Beispiel: Vom Modell abgeleitete Diagrammelemente

Mit Ansichten können Sie Diagrammelemente definieren, für die Datentransformationen erforderlich sind. Ein wichtiger Vorteil ist, dass die Ansicht die Transformation definiert, sodass Sie keine separate Tabelle für die abgeleiteten Daten verwalten müssen.

Arrays zum Modellieren von Kanten auflösen

Sie können beispielsweise Daten aus einer ARRAY-Spalte (oder einem Arrayfeld in einer JSON-Spalte) UNNEST, um mehrere Edge-Beziehungen aus einer einzelnen Zeile zu modellieren.

Im folgenden Beispiel für ein Lieferkettenschema speichert eine Parts-Tabelle eine Liste von Unterkomponenten in einem dependent_parts-Array. In einer Ansicht kann der Operator UNNEST verwendet werden, um jedes Element dieses Arrays in separate Zeilen umzuwandeln. Diese Ansicht kann dann als Edge-Tabelle dienen, mit der Sie eine PartDependsOnPart-Edge modellieren können, um Abhängigkeitsbeziehungen zwischen Teilen darzustellen.

-- Parts table with an ARRAY of dependent parts.
CREATE TABLE Parts (
  part_id INT64 NOT NULL,
  dependent_parts ARRAY<INT64>
) PRIMARY KEY (part_id);

-- A view that unnests the dependent_parts array.
-- GROUP BY ensures uniqueness for the graph element KEY.
CREATE VIEW PartDependsOnPart SQL SECURITY INVOKER AS
  SELECT p.part_id, dependent_part_id
  FROM Parts AS p,
    UNNEST(p.dependent_parts) AS dependent_part_id
  GROUP BY p.part_id, dependent_part_id;

-- Graph modeling the part dependency relationship.
CREATE PROPERTY GRAPH SupplyChainGraph
  NODE TABLES (
    Parts
  )
  EDGE TABLES (
    PartDependsOnPart KEY (part_id, dependent_part_id)
      SOURCE KEY (part_id) REFERENCES Parts(part_id)
      DESTINATION KEY (dependent_part_id) REFERENCES Parts(part_id)
  );

Attribute mit Remote-Funktionen berechnen

Sie können auch eine Remote-Funktion in einer Ansicht verwenden, um abgeleitete Properties für Diagrammelemente zu berechnen. Legen Sie dazu allow_view_with_volatile_column = true in der OPTIONS-Klausel der CREATE PROPERTY GRAPH-Anweisung fest. Weitere Informationen finden Sie unter Flüchtige Spalten aktivieren, wenn Ansichten Remote-Funktionen verwenden.

-- Define a remote function.
CREATE FUNCTION rudf_identity_func(x INT64)
  RETURNS INT64 NOT DETERMINISTIC LANGUAGE REMOTE
  OPTIONS (
    endpoint = 'https://us-central1-project-id.cloudfunctions.net/my-func'
  );

-- Base table for accounts.
CREATE TABLE Account (
  account_id INT64 NOT NULL,
  balance INT64
) PRIMARY KEY (account_id);

-- View that computes a property using the remote function.
CREATE VIEW AccountRemoteUdfView SQL SECURITY INVOKER AS
  SELECT
    t.account_id,
    t.balance,
    rudf_identity_func(t.account_id) AS view_computed_prop
  FROM Account AS t;

-- Graph using the view requires allow_view_with_volatile_column = true.
CREATE PROPERTY GRAPH AccountViewRemoteUdfGraph
  NODE TABLES (
    AccountRemoteUdfView KEY (account_id)
      PROPERTIES (account_id, balance, view_computed_prop)
  )
  OPTIONS (allow_view_with_volatile_column = true);

Beispiel: Schemalose Datenumstellung

Mit der schemalosen Datenverwaltung können Sie eine flexible Graphdefinition ohne vordefinierte Knoten- und Kantentypen erstellen. Die schemalose Datenverwaltung bietet zwar Flexibilität, aber Sie müssen möglicherweise zu einer formelleren Struktur übergehen, wenn Ihre Daten definierter werden. Eine formellere Struktur macht die Knoten- und Kantenbeziehungen, Labels und Attribute des Graphen im Schema sichtbar. Dadurch ist weniger manuelle Datenexploration erforderlich, um das Graphschema zu verstehen.

Mit Ansichten können Sie die Knoten- und Kantentypen formalisieren, ohne die zugrunde liegenden Daten migrieren zu müssen. Sie können beispielsweise von einem typischen schemalosen Modell mit kanonischen GraphNode- und GraphEdge-Tabellen wechseln. Dazu erstellen Sie Ansichten, die die Daten aus Ihren schemalosen Tabellen extrahieren:

1. Definieren Sie eine Ansicht für jeden Knoten- und Kantentyp, den Sie formalisieren möchten (z. B. Person oder WorksFor). Filtern Sie die Daten in der Ansicht nach ihrem Label (z. B. WHERE n_label = "person") und wandeln Sie die Attribute aus der JSON-Spalte in bestimmte Datentypen um (z. B. STRING(prop.name) AS name).

2. Definieren Sie einen neuen Attributgraphen, in dem NODE TABLES und EDGE TABLES auf die gerade erstellten typisierten Ansichten verweisen.

Ein schemaloser Graph bietet bei einigen Abfragen eine bessere Leistung als ein formalisierter Graph (z. B. ein quantifiziertes Pfadmuster mit mehreren Kantentypen). Wenn formalisierte Metadaten für Ihren Anwendungsfall wichtig sind, können Sie Ansichten verwenden, um von einem schemalosen Graphen zu einem typisierten Schema zu wechseln. Sie können auch für einige Anwendungsfälle einen schemalosen Graphen und für andere Anwendungsfälle einen typisierten Schemagraphen verwenden. Weitere Informationen finden Sie unter Schemadesign basierend auf Graphabfragen auswählen.

Das folgende Beispiel zeigt den Workflow für den Übergang von einem schemalosen zu einem formalisierten Graphen in vier Schritten:

1. Definieren Sie die kanonischen Tabellen GraphNode und GraphEdge für das schemalose Modell.

2. Erstellen Sie einen ersten, flexiblen Graphen für diese schemalosen Tabellen.

3. Definieren Sie typisierte Ansichten (Person, Company, WorksFor), die die Daten aus den schemalosen Tabellen extrahieren und formalisieren.

4. Erstellen Sie den endgültigen, stark typisierten Graphen, der diese Ansichten als Knoten- und Kantentabellen verwendet.

-- 1. Create the canonical tables for a schemaless model.
CREATE TABLE GraphNode (
  id INT64 NOT NULL,
  label STRING(MAX) NOT NULL,
  properties JSON
) PRIMARY KEY (id);

CREATE TABLE GraphEdge (
  id INT64 NOT NULL,
  dest_id INT64 NOT NULL,
  edge_id INT64 NOT NULL,
  label STRING(MAX) NOT NULL,
  properties JSON
) PRIMARY KEY (id, dest_id, edge_id),
  INTERLEAVE IN PARENT GraphNode;

-- 2. Define a schemaless graph.
CREATE PROPERTY GRAPH FinGraph
  NODE TABLES (
    GraphNode
      DYNAMIC LABEL (label)
      DYNAMIC PROPERTIES (properties)
  )
  EDGE TABLES (
    GraphEdge
      SOURCE KEY (id) REFERENCES GraphNode(id)
      DESTINATION KEY (dest_id) REFERENCES GraphNode(id)
      DYNAMIC LABEL (label)
      DYNAMIC PROPERTIES (properties)
  );

-- 3. Define typed views that extract and formalize the data.
--    Convert JSON fields to primitive types (for example, INT64, STRING) to
--    ensure type safety.
CREATE VIEW Person SQL SECURITY INVOKER AS
  SELECT n.id, STRING(n.properties.name) AS name, INT64(n.properties.age) AS age
  FROM GraphNode n WHERE n.label = "person";

CREATE VIEW Company SQL SECURITY INVOKER AS
  SELECT n.id, STRING(n.properties.name) AS company_name, BOOL(n.properties.is_public) AS is_public
  FROM GraphNode n WHERE n.label = "company";

CREATE VIEW WorksFor SQL SECURITY INVOKER AS
  SELECT e.id AS person_id, e.dest_id AS company_id, e.edge_id AS edge_id, STRING(e.properties.since) AS since
  FROM GraphEdge e
  WHERE e.label = "worksfor";

-- 4. Create the final, formalized graph from the typed views.
CREATE PROPERTY GRAPH typed_formalized_graph
  NODE TABLES (
    Person KEY(id)
      PROPERTIES (name, age),
    Company KEY(id)
      PROPERTIES (company_name, is_public)
  )
  EDGE TABLES(
    WorksFor KEY(person_id, company_id, edge_id)
      SOURCE KEY (person_id) REFERENCES Person(id)
      DESTINATION KEY (company_id) REFERENCES Company(id)
      PROPERTIES (since)
  );

Nächste Schritte

• Weitere Informationen zu den Anforderungen an die Eindeutigkeit von Elementschlüsseln

• Spanner Graph-Schema

• Best Practices für das Entwerfen eines Spanner Graph-Schemas