Diagramm aus einer SQL-Ansicht erstellen

Informationen zum Erstellen eines Graphen mit SQL-Ansichten In diesem Dokument finden Sie eine Schritt-für-Schritt-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 Graphen mit Ansichten veranschaulichen Weitere Informationen zum Erstellen eines Attributgraphen mit Ansichten, einschließlich Vorteilen und Überlegungen, finden Sie unter Übersicht über Graphen, die aus SQL-Ansichten erstellt wurden.

Hinweis

So erstellen Sie einen Graphen:

1. Prüfen Sie, ob Ihre Spanner Graph-Umgebung eingerichtet ist.

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

Graphen mit Ansichten erstellen

So erstellen Sie einen Graphen mit Ansichten:

1. Definieren Sie Ansichten für Ihren Graphen. Standardmäßig müssen Ihre Ansichten einem der unterstützten Ansichtsmuster folgen, um die Eindeutigkeit der Elemente zu gewährleisten. Wenn Ihre Ansichten Abfragen verwenden, die diesen Mustern nicht folgen, können Sie die Validierung der Schlüsseleindeutigkeit in Schritt 4 deaktivieren. Weitere Informationen finden Sie unter Ansicht erstellen.

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

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

4. Optional: Wenn Ihre Ansichten beliebige SQL-Abfragen verwenden, die nicht den unterstützten Mustern für die Eindeutigkeit entsprechen, fügen Sie der Anweisung CREATE PROPERTY GRAPH die Klausel OPTIONS (validate_element_key_uniqueness = false) hinzu. Achten Sie darauf, dass die Spalten der Klausel KEY eindeutige Werte für jede Knoten- oder Kantenzeile 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).

Beispiel: Graphen 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 verwendet, um im Graphen Folgendes zu erstellen:

• Erstellen Sie die Customer Knotentabelle mit der AsiaCustomer Ansicht.

• Erstellen Sie die Account Knotentabelle mit der AsiaBankAccount Ansicht.

• Erstellen Sie die Kantentabelle 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. In diesen Ansichten werden die Tabellen so gefiltert, dass nur Kunden und Konten in Asien berücksichtigt werden. Sofern validate_element_key_uniqueness nicht auf false gesetzt ist, müssen Ansichten, die zum Erstellen von Graphen elementen 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: Attributgraphen erstellen

Erstellen Sie jetzt den Graphen AsiaFinGraph mit den erstellten Ansichten. Die Anweisung CREATE PROPERTY GRAPH enthält die Klausel KEY für jede Graphenelementdefinition, um Spalten anzugeben, die die Graphenelemente 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 Attributgraphenelemente. Die folgenden Beispiele veranschaulichen einige Anwendungsfälle für das Definieren von Graphenelementen mit Ansichten anstelle von Tabellen.

Beispiel: Detaillierte Zugriffskontrolle für Graphendaten erzwingen

Wenn Sie die Sicherheit auf Zeilenebene für Ihre Graphendaten erzwingen möchten, definieren Sie Ihre Knoten- oder Kanten tabellen mit Ansichten mit den Rechten des Definierers. Die Ansicht macht eine zulässige Teilmenge der zugrunde liegenden Daten für den Graphen verfügbar.

Wenn Sie beispielsweise den Zugriff auf den Graphen auf Mitarbeiter in einem Kostenstellenbereich für die Entwicklung beschränken möchten, können Sie die Ansicht EngineerEmployeeView erstellen und der Rolle engineering_data_reader mit der Klausel GRANT die Berechtigung SELECT für die Ansicht gewähren.

Wenn Sie eine Knotentabelle für den Graphen mit dieser Ansicht definieren, sehen Nutzer, die Graphabfragen mit der Rolle engineering_data_reader ausführen, nur die Zeilen, die von der Ansicht gefiltert wurden, einschließlich der Mitarbeiter in der Entwicklung.

-- 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: Abgeleitete Graphenelemente modellieren

Sie können Ansichten verwenden, um Graphenelemente zu definieren, für die Datentransformationen erforderlich sind. Ein wichtiger Vorteil ist, dass die Transformation in der Ansicht definiert wird. Sie müssen also keine separate Tabelle für die abgeleiteten Daten verwalten.

Sie können beispielsweise Daten aus einer ARRAY-Spalte (oder einem Arrayfeld in einer JSON-Spalte) mit UNNEST aufschlüsseln, um mehrere Kantenbeziehungen aus einer einzelnen Zeile zu modellieren.

Im folgenden Beispiel für ein Lieferkettenschema speichert eine Tabelle Parts eine Liste von Unterkomponenten in einem Array dependent_parts. In einer Ansicht kann der Operator UNNEST verwendet werden, um jedes Element dieses Arrays in separate Zeilen zu transformieren. Diese Ansicht kann dann als Kantentabelle dienen, mit der Sie eine Kante PartDependsOnPart 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)
  );

Beispiel: Schemaloser Datenübergang

Die schemalose Datenverwaltung ermöglicht Ihnen die Erstellung einer flexiblen Graphdefinition ohne vordefinierte Knoten- und Kantentypen. Die schemalose Datenverwaltung bietet zwar Flexibilität, aber möglicherweise müssen Sie zu einer formaleren Struktur wechseln, wenn Ihre Daten besser definiert werden. Eine formalere 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.

Sie können Ansichten verwenden, um die Knoten- und Kantentypen zu formalisieren, ohne die zugrunde liegenden Daten zu migrieren. Sie können beispielsweise von einem typischen schemalosen Modell mit kanonischen Tabellen GraphNode und GraphEdge 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 dem 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 veranschaulicht 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 Elementen

• Informationen zum Spanner Graph-Schema.

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