Ü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. Es enthält Informationen zu den Vorteilen des Erstellens von Diagrammen mit Ansichten, zu den Anforderungen und zu Ü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 Attributgrafik aus SQL-Ansichten erstellen.

Vorteile des Erstellens von Diagrammen mit Ansichten anstelle von Tabellen

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 sie die Ergebnisse der Abfrage, die die Ansicht definiert, nicht als tatsächliche Tabelle im Datenspeicher speichern. Weitere Informationen finden Sie in der Übersicht über Ansichten . Sie können Diagrammelemente aus SQL-Ansichten erstellen, aber keine Ansicht, die ein Diagramm abfragt.

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

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

Sie müssen die folgenden Anforderungen erfüllen, wenn Sie Ansichten zum Erstellen von Diagrammelementen verwenden:

Verwenden Sie die Klausel KEY, wenn Sie ein Diagrammelement angeben

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

Achten Sie auf die Eindeutigkeit von Knoten- und Kantenschlüsseln

Jeder Knoten und jede Kante in einer Attributgrafik muss einen eindeutigen Schlüssel haben. Wenn Sie Diagrammelemente mit Ansichten definieren, können Sie auswählen, wie die Eindeutigkeit des Elementschlüssels überprüft werden soll:

Strenge Schlüsselvalidierung (Standard)

Standardmäßig prüft Spanner, ob Ansichten, die Knoten- oder Kantentabellen definieren, einem der folgenden Muster entsprechen, um sicherzustellen, dass jeder Knoten oder jede Kante eindeutig ist:

  • Muster 1: Die Ansicht verwendet den Primärschlüssel einer einzelnen Tabelle.

  • Muster 2: Die Ansicht verwendet eine GROUP BY oder eine SELECT DISTINCT Klausel.

Sie können andere SQL-Operatoren wie WHERE, HAVING, ORDER BY,LIMIT und TABLESAMPLE in Kombination mit diesen Mustern verwenden. Diese Operatoren filtern oder sortieren die Ergebnisse, ändern aber nicht die zugrunde liegende Garantie für die Eindeutigkeit, die die Muster bieten.

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

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

Im folgenden Beispiel wird eine Teilmenge der Zeilen aus der Tabelle Account ausgewählt. Der Diagrammschlüssel KEY(account_id) entspricht dem Primärschlüssel der Tabelle Account. So wird sichergestellt, dass jede von der Ansicht erstellte Zeile 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: Klausel GROUP BY oder SELECT DISTINCT verwenden

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

  • Für GROUP BY: Die Spalten der Klausel KEY müssen mit allen Spalten in der Klausel GROUP BY übereinstimmen.

  • Für SELECT DISTINCT: Die Spalten der Klausel KEY müssen mit den Spalten in der Liste SELECT DISTINCT ü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)
  );

Deaktivierte Schlüsselvalidierung (beliebige SQL-Abfrage)

Wenn Ihre Ansicht eine Abfrage verwendet, die nicht Muster 1 oder Muster 2 entspricht, z. B. eine Abfrage, die Tabellen ohne eine Klausel GROUP BY oder SELECT DISTINCT verknüpft, können Sie die Validierung des Elementschlüssels deaktivieren, indem Sie die Diagrammoption validate_element_key_uniqueness = false festlegen.

Standardmäßig ist validate_element_key_uniqueness auf true gesetzt. Wenn die Option auf false gesetzt ist, validiert Spanner die Abfragedefinition der Ansicht nicht zum Zeitpunkt der Schemaerstellung. Sie können eine beliebige SQL-Abfrage in der Ansicht verwenden, müssen aber dafür sorgen, dass die in der Klausel KEY angegebenen Spalten für jede Knoten- oder Kantenzeile eindeutige Werte enthalten.

Im folgenden Beispiel wird eine Ansicht namens CustomerOrderTrusted definiert, die die Customer und SaleOrder Tabellen ohne eine GROUP BY Klausel verknüpft. Da jede Verkaufsbestellung eindeutig ist, bleibt die Eindeutigkeit von order_id in den Ansichtsergebnissen erhalten, wenn SaleOrder mit Customer verknüpft wird. Da die Abfrage jedoch eine JOIN verwendet und nicht Muster 1 oder Muster 2 entspricht, kann Spanner die Eindeutigkeit nicht syntaktisch überprüfen.

Wenn Sie KEY(order_id) angeben und validate_element_key_uniqueness = false in der Klausel OPTIONS festlegen, können Sie die Attributgrafik definieren, ohne die Ansichtsabfrage zu ändern:

-- View uses a JOIN without GROUP BY or DISTINCT.
CREATE VIEW CustomerOrderTrusted
  SQL SECURITY INVOKER AS
    SELECT
      s.order_id,
      c.customer_id,
      c.name AS customer_name
    FROM Customer c JOIN SaleOrder s ON c.customer_id = s.customer_id;

-- Property graph disables element key uniqueness validation.
CREATE PROPERTY GRAPH OrderGraphTrusted
  NODE TABLES (
    CustomerOrderTrusted
      KEY(order_id)
      LABEL CustomerOrder PROPERTIES(
        order_id,
        customer_id,
        customer_name)
  ) OPTIONS (validate_element_key_uniqueness = false);

Überlegungen bei der Verwendung von Ansichten

Wenn Sie Ansichten zum Definieren von Diagrammelementen verwenden, können Ihnen die folgenden Informationen helfen, ein effektives Diagramm zu entwerfen und zu implementieren:

Abfrageleistung von Attributgrafiken

Wenn Sie Diagrammelemente in Ansichten definieren, die Datentransformationen ausführen (z. B. GROUP BY, UNNEST oder JOIN-Vorgänge), sollten Sie die Abfrageleistung für Ihren Anwendungsfall sorgfältig bewerten. Spanner führt die Abfragedefinition einer Ansicht jedes Mal aus, wenn eine Abfrage eine Mustererkennung für Elementedurchführt.

Optimierung des Diagrammschemas

Wenn Sie Ansichten zum Definieren von Diagrammelementen verwenden, sind einige Optimierungen des Diagrammschemas 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 dieser zugrunde liegenden Tabelle für Diagrammabfragen wirksam. Wenn Sie beispielsweise die folgenden Techniken auf Basistabellen anwenden, ergeben sich ähnliche Leistungsverbesserungen für Diagrammelemente, die in solchen Ansichten definiert sind:

Mit GROUP BY oder DISTINCT definierte Ansichten

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

Datenänderung mit ansichtsbasierter Grafik

Ansichten sind nicht materialisiert. Das bedeutet, dass sie die Ergebnisse der Abfrage, die die Ansicht definiert, nicht als Tabelle im Datenspeicher speichern und schreibgeschützt sind. Wenn Sie Knoten oder Kanten in einem aus Ansichten erstellten Diagramm einfügen, aktualisieren oder löschen möchten, müssen Sie die Daten in den Tabellen ändern, die zum Erstellen der Ansichten verwendet wurden.

Graph-Fehlerbehandlung zur Durchsetzung der Datenintegrität

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

Wenn Sie beispielsweise von einem schemalosen zu einem formalisierten Diagramm wechseln, verwenden Sie CHECK Einschränkungen, um die Daten in Ihren Basistabellen (GraphNode und GraphEdge) zu validieren. Der folgende Code wendet diese Einschränkungen innerhalb der JSON-Attribute an, 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));

Nächste Schritte