Übersicht über Diagramme, die aus SQL-Ansichten erstellt wurden

In diesem Dokument erfahren Sie mehr über die Vorteile der Verwendung von SQL-Ansichten zum Erstellen eines Diagramms. Dieses Dokument enthält Vorteile des Erstellens von Diagrammen mit Ansichten, Anforderungen und Überlegungen, die Ihnen bei der Entscheidung helfen sollen, ob Sie Tabellen oder Ansichten zum Erstellen eines Diagramms verwenden sollten.

Weitere Informationen zum Erstellen eines Diagramms aus Ansichten finden Sie unter Eigenschaftsgraphen aus SQL-Ansichten erstellen.

Vorteile von Diagrammen, die mit Ansichten statt mit Tabellen erstellt werden

Eine SQL-Ansicht ist eine virtuelle Tabelle, die durch eine SQL-Abfrage definiert wird. In Spanner wird die Abfrage, die eine Ansicht definiert, jedes Mal ausgeführt, wenn eine Abfrage ausgeführt wird, die auf die Ansicht verweist. Spanner-Ansichten sind keine materialisierten Ansichten, da die Ergebnisse der Abfrage, mit der die Ansicht definiert wird, nicht als tatsächliche Tabelle im Datenspeicher gespeichert werden. Weitere Informationen finden Sie unter Ansichten – Übersicht. Sie können Grafikelemente aus SQL-Ansichten erstellen, aber keine Ansicht, mit der ein Graph abgefragt wird.

Ansichten bieten als Abstraktionsebene zwischen Tabellen und einem Diagrammschema mehrere Vorteile, die nicht verfügbar sind, wenn Sie Tabellen zum Erstellen eines Diagramms verwenden.

Zugriffssteuerung auf Zeilenebene: Detaillierte Zugriffssteuerung auf Zeilenebene für Grafiken mit den Sicherheitsberechtigungen von Ansichten mit Definer-Rechten anwenden. So wird sichergestellt, dass Nutzer nur Knoten und Kanten abfragen können, die sie sehen dürfen.
Flexible Datenmodellierung: Mit einer Ansicht mit einer Abfrage können Sie relationale Daten bearbeiten und transformieren, bevor Sie ein Grafikelement erstellen. Mit der Abfrage der Ansicht können Sie Zeilen filtern, Spalten kombinieren oder verschachtelte Felder wie in einer ARRAY aufheben.
Übergang von schemalosen zu formalisierten Daten: Erstellen Sie Ansichten aus schemalosen Daten, um Knoten- und Kantentypen explizit zu definieren. So lassen sich die Beziehungen in den Daten formalisieren.

Voraussetzungen für die Verwendung von Ansichten zum Erstellen von Diagrammen

Wenn Sie Ansichten zum Erstellen von Grafikelementen verwenden, müssen Sie die folgenden Anforderungen einhalten:

Verwenden Sie die KEY-Klausel, wenn Sie ein Grafikelement angeben.
Ansichten verwenden, die dafür sorgen, dass Knoten und Kanten eindeutig sind:

`KEY`-Klausel verwenden, wenn Sie ein Grafikelement angeben

Sie müssen die Spalten, die das Grafikelement eindeutig identifizieren, explizit definieren, wenn Sie Ansichten zum Erstellen eines Knoten- oder Kantenelements verwenden. Verwenden Sie dazu die KEY-Klausel in der Knoten- oder Kantenelementdefinition. Informationen zur Verwendung der KEY-Klausel beim Erstellen eines Grafikelements finden Sie in den Codebeispielen in diesem Dokument und unter Spanner-Diagramm aus einer SQL-Ansicht erstellen.

Ansichten verwenden, die dafür sorgen, dass Knoten und Kanten eindeutig sind

Ansichten, in denen Knoten- oder Kantentabellen definiert werden, müssen einem der folgenden Muster entsprechen, damit die Knoten und Kanten eindeutig sind:

Muster 1: In der Ansicht wird der Primärschlüssel einer einzelnen Tabelle verwendet.
Muster 2: In der Ansicht wird eine GROUP BY- oder eine SELECT DISTINCT-Klausel verwendet.

Sie können auch andere SQL-Operatoren wie WHERE, HAVING, ORDER BY, LIMIT und TABLESAMPLE in Kombination mit diesen Mustern verwenden. Mit diesen Operatoren werden die Ergebnisse gefiltert oder sortiert. Die zugrunde liegende Garantie für die Eindeutigkeit, die die Muster bieten, wird dadurch jedoch nicht geändert.

Muster 1: Primärschlüssel einer einzelnen Tabelle verwenden

In diesem Muster wird in der Ansicht aus einer einzelnen Tabelle ausgewählt und die KEY-Klausel in der Diagrammdefinition entspricht den Primärschlüsselspalten der Basistabelle. Aus diesem Grund ist jede Knoten- oder Kantenzeile, die von der Ansicht generiert wird, eindeutig.

Im folgenden Beispiel wird eine Teilmenge von Zeilen aus der Tabelle Account ausgewählt. Der Primärschlüssel des Diagramms KEY(account_id) entspricht dem der Tabelle Account. So wird sichergestellt, dass jede Zeile, die von der Ansicht generiert wird, eindeutig ist.

-- Table has PRIMARY KEY(account_id).
CREATE TABLE Account (
  account_id INT64 NOT NULL,
  customer_id INT64 NOT NULL,
  account_type STRING(MAX),
  balance INT64
) PRIMARY KEY(account_id);

-- Pattern 1: View uses the primary key from a single table.
CREATE VIEW SavingAccount
  SQL SECURITY INVOKER AS
    SELECT accnt.account_id, accnt.customer_id, accnt.balance
    FROM Account accnt
    WHERE accnt.account_type = 'saving';

CREATE PROPERTY GRAPH SavingAccountGraph
  NODE TABLES (
    -- The element KEY(account_id) matches the table's primary key.
    SavingAccount KEY(account_id)
  );

Muster 2: `GROUP BY`- oder `SELECT DISTINCT`-Klausel verwenden

In diesem Muster wird in der Abfrage der Ansicht eine GROUP BY- oder eine SELECT DISTINCT-Klausel verwendet. Die Spalten in der KEY-Klausel müssen mit den Spalten übereinstimmen, die in diesen Klauseln zur Definition der Eindeutigkeit verwendet werden:

Für GROUP BY: Die Spalten der KEY-Anweisung müssen mit allen Spalten der GROUP BY-Anweisung übereinstimmen.
Für SELECT DISTINCT: Die Spalten der KEY-Klausel müssen mit den Spalten in der SELECT DISTINCT-Liste übereinstimmen.

Beispiel mit GROUP BY:

CREATE TABLE Customer (
  customer_id INT64,
  name STRING(MAX)
) PRIMARY KEY (customer_id);

CREATE TABLE SaleOrder (
  order_id INT64,
  customer_id INT64,
  amount INT64
) PRIMARY KEY (order_id);

CREATE VIEW CustomerOrder
  SQL SECURITY INVOKER AS
    SELECT
      s.order_id,
      ANY_VALUE(c.customer_id) AS customer_id,
      ANY_VALUE(c.name) AS customer_name
    FROM Customer c JOIN SaleOrder s ON c.customer_id = s.customer_id
    GROUP BY s.order_id;

CREATE PROPERTY GRAPH OrderGraph
  NODE TABLES (
    -- The KEY(order_id) matches the GROUP BY column in view definition.
    CustomerOrder KEY(order_id)
  );

Beispiel mit SELECT DISTINCT:

CREATE TABLE SaleOrder (
  order_id INT64,
  customer_id INT64,
  amount INT64
) PRIMARY KEY (order_id);

CREATE VIEW KeyCustomer SQL SECURITY INVOKER AS
  SELECT DISTINCT s.customer_id, s.amount
  FROM SaleOrder s
  WHERE s.amount > 1000;

CREATE PROPERTY GRAPH KeyCustomersGraph
  NODE TABLES (
    -- The KEY(customer_id, amount) matches the DISTINCT columns.
    KeyCustomer KEY(customer_id, amount)
  );

Überlegungen bei der Verwendung von Ansichten

Wenn Sie Ansichten verwenden, um Grafikelemente zu definieren, können Ihnen die folgenden Informationen helfen, einen effektiven Graphen zu entwerfen und zu implementieren:

Bewertung der Abfrageleistung:
Schemaoptimierung
Fehlerbehandlung zur Durchsetzung der Datenintegrität:

Leistung von Attributgrafikabfragen

Wenn Sie Grafikelemente für Ansichten definieren, in denen Datentransformationen ausgeführt werden (z. B. GROUP BY-, UNNEST- oder JOIN-Vorgänge), sollten Sie die Abfrageleistung für Ihren Anwendungsfall sorgfältig prüfen. Die Abfragedefinition einer Ansicht wird in Spanner bei jeder Abfrage ausgeführt, bei der Elementmuster abgeglichen werden.

Optimierung des Grafschemas

Wenn Sie Ansichten zum Definieren von Grafikelementen verwenden, sind einige Optimierungen des Grafschemas möglicherweise weniger effektiv als bei der Verwendung von Tabellen.

Ansichten, die den Primärschlüssel einer einzelnen Tabelle projizieren

Wenn eine Ansicht eine Projektion aus einer einzelnen Basistabelle ist, bleiben alle Optimierungen für diese zugrunde liegende Tabelle für Diagrammabfragen wirksam. Wenn Sie beispielsweise die folgenden Techniken auf Basistabellen anwenden, ergeben sich ähnliche Leistungsvorteile für Grafikelemente, die auf solchen Ansichten definiert sind:

Mit der `GROUP BY`- oder `DISTINCT`-Klausel definierte Ansichten

Bei Ansichten, in denen Aggregationen wie GROUP BY, SELECT DISTINCT oder andere komplexe Transformationen ausgeführt werden, geht die direkte Beziehung zur zugrunde liegenden Tabellenstruktur verloren. Daher bieten Schemaoptimierungen für die Basistabellen möglicherweise nicht dieselben Leistungsvorteile für Diagrammabfragen, die für die Ansichten ausgeführt werden. Bewerten Sie die Abfrageleistung für Ihren Anwendungsfall sorgfältig, wenn in Ihren Ansichten komplexe Aggregationen ausgeführt werden.

Datenänderung mit ansichtsbezogenen Grafiken

Ansichten werden nicht materialisiert. Das bedeutet, dass die Ergebnisse der Abfrage, mit der die Ansicht definiert wird, nicht als Tabelle im Datenspeicher gespeichert werden. Außerdem sind Ansichten schreibgeschützt. Wenn Sie Knoten oder Kanten in einem Diagramm einfügen, aktualisieren oder löschen möchten, das aus Ansichten erstellt wurde, müssen Sie daher die Daten in den Tabellen ändern, die zum Erstellen der Ansichten verwendet wurden.

Fehlerbehandlung im Diagramm zur Durchsetzung der Datenintegrität

Wenn Sie Ansichten zum Definieren von Grafikelementen verwenden, erzwingen Sie die Datenintegrität (z. B. Datentypen) für die zugrunde liegenden Basistabellen. Andernfalls sind die Daten in den Basistabellen möglicherweise ungültig und führen dazu, dass Abfragen für Ihren ansichtsbezogenen Graphen zur Laufzeit fehlschlagen.

Wenn Sie beispielsweise von einem schemalosen zu einem formalisierten Diagramm wechseln, verwenden Sie CHECK-Einschränkungen, um Daten in Ihren Basistabellen (GraphNode und GraphEdge) zu validieren. Mit dem folgenden Code werden diese Einschränkungen in den JSON-Eigenschaften angewendet, um die Datenintegrität an der Quelle zu gewährleisten und Laufzeitfehler bei Abfragen zu vermeiden.

-- Enforce that the 'name' property exists for nodes with the 'person' label.
ALTER TABLE GraphNode
ADD CONSTRAINT NameMustExistForPersonConstraint
CHECK (IF(label = 'person', properties.name IS NOT NULL, TRUE));

-- Enforce that the 'name' property is a string for nodes with the 'person' label.
ALTER TABLE GraphNode
ADD CONSTRAINT PersonNameMustBeStringTypeConstraint
CHECK (IF(label = 'person', JSON_TYPE(properties.name) = 'string', TRUE));