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.

Diagramme mit SQL-Ansichten erstellen Dieses Dokument enthält 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 ansehen, in denen Anwendungsfälle für das Erstellen von Diagrammen mit Ansichten veranschaulicht werden. Weitere Informationen zum Erstellen eines Eigenschaftsgraphen mit Ansichten, einschließlich der Vorteile und Überlegungen, finden Sie unter Übersicht über aus SQL-Ansichten erstellte Diagramme.

Hinweise

So erstellen Sie ein Diagramm:

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

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

Diagramm mit Ansichten erstellen

So erstellen Sie ein Diagramm mit Ansichten:

1. Ansichten für das Diagramm definieren Ihre Ansichten müssen einem der erforderlichen Ansichtsmuster entsprechen. 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.

Beispiel: Diagramm mit Ansichten erstellen

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

• Erstellen Sie die Knotentabelle Customer mithilfe der Ansicht AsiaCustomer.

• Erstellen Sie die Knotentabelle Account mithilfe der Ansicht AsiaBankAccount.

• Erstellen Sie die Owns-Knotentabelle mit der AsiaAccountsOwnership-Ansicht. 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 enthalten sind. Für Ansichten, die zum Erstellen von Grafikelementen verwendet werden, muss dafür gesorgt werden, dass 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-Diagramm erstellen

Erstellen Sie nun die AsiaFinGraph mit den Ansichten, die Sie erstellt haben. 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)
  );

Beispiele für Anwendungsfälle

SQL-Ansichten bieten Vorteile gegenüber der Verwendung von Tabellen für Attributgrafikelemente. Die folgenden Beispiele veranschaulichen einige Anwendungsfälle für das Definieren von Grafikelementen mit Ansichten anstelle von Tabellen.

Beispiel: Detaillierte Zugriffssteuerung für Grafdaten erzwingen

Wenn Sie die Sicherheit auf Zeilenebene für Ihre Diagrammdaten erzwingen möchten, definieren Sie Ihre Knoten- oder Tabellen für Kanten mit Ansichten mit Definer-Rechten. Die Ansicht stellt eine zulässige Teilmenge der zugrunde liegenden Daten für das Diagramm bereit.

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

Wenn Sie eine Tabellengrafik mit dieser Ansicht definieren, sehen Nutzer mit der Rolle engineering_data_reader bei der Ausführung von Grafikanfragen nur die durch die Ansicht gefilterten Zeilen, die Mitarbeiter aus dem Engineering-Team 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: Abgeleitete Grafikelemente modellieren

Mit Ansichten können Sie Grafikelemente 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 UNNEST-Daten aus einer ARRAY-Spalte (oder einem Arrayfeld in einer JSON-Spalte) verwenden, um mehrere Edge-Beziehungen aus einer einzelnen Zeile zu modellieren.

Im folgenden Beispiel für ein Lieferkettenschema wird in einer Parts-Tabelle eine Liste von untergeordneten Komponenten in einem dependent_parts-Array gespeichert. 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 PartDependsOnPart-Kante 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

Mit schemaloser Datenverwaltung können Sie eine flexible Diagrammdefinition ohne vordefinierte Knoten- und Kantentypen erstellen. Die schemalose Datenverwaltung bietet zwar Flexibilität, aber möglicherweise müssen Sie zu einer formaleren Struktur wechseln, wenn Ihre Daten definierter werden. Eine formalere Struktur macht die Knoten- und Kantenbeziehungen, Labels und Eigenschaften des Graphen im Schema sichtbar, wodurch der manuelle Aufwand für die Datenexploration zum Verständnis des Graphenschemas reduziert wird.

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

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 Anfragen eine bessere Leistung als ein formalisierter Graph, z. B. bei einem quantifizierten Pfadmuster mit mehreren Kantentypen. Wenn formalisierte Metadaten für Ihren Anwendungsfall wichtig sind, können Sie Ansichten verwenden, um von einem schemalosen Diagramm zu einem typisierten Schema zu wechseln. Sie können auch für einige Anwendungsfälle ein schemaloses Diagramm und für andere ein Diagramm mit typisiertem Schema verwenden. Weitere Informationen finden Sie unter Schema auf Grundlage von Graphabfragen entwerfen.

Das folgende Beispiel veranschaulicht den Workflow für die Umstellung von einem schemalosen auf einen 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), mit denen die Daten aus den schemalosen Tabellen extrahiert und formalisiert werden.

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

• Informationen zum Spanner Graph-Schema

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