Información general sobre los gráficos creados a partir de vistas de SQL

En este documento se explican las ventajas de usar vistas de SQL para crear un gráfico. Este documento incluye ventajas de crear gráficos con vistas, requisitos y consideraciones para ayudarte a decidir si debes usar tablas o vistas para crear un gráfico.

Para obtener información sobre cómo crear un gráfico a partir de vistas, consulte Crear un gráfico de propiedades a partir de vistas de SQL.

Ventajas de crear gráficos con vistas en lugar de tablas

Una vista de SQL es una tabla virtual definida por una consulta de SQL. En Spanner, la consulta que define una vista se ejecuta cada vez que se ejecuta una consulta que hace referencia a la vista. Las vistas de Spanner no son vistas materializadas porque no almacenan los resultados de la consulta que define la vista como una tabla real en el almacenamiento de datos. Para obtener más información, consulta Introducción a las visualizaciones. Puedes crear elementos de gráfico a partir de vistas de SQL, pero no puedes crear una vista que consulte un gráfico.

Las vistas ofrecen varias ventajas como capa de abstracción entre las tablas y un esquema de gráfico que no están disponibles cuando se usan tablas para crear un gráfico.

Requisitos para usar vistas y crear gráficos

Debes cumplir estos requisitos cuando uses vistas para crear elementos de gráficos:

Usa la cláusula KEY cuando especifiques un elemento de gráfico

Debes definir explícitamente las columnas que identifican de forma única el elemento del gráfico cuando usas vistas para crear un nodo o un elemento de arista. Para ello, usa la cláusula KEY en la definición del elemento de nodo o de arista. Para saber cómo usar la cláusula KEY al crear un elemento de gráfico, consulta los ejemplos de código de este documento y de Crear un gráfico de Spanner a partir de una vista de SQL.

Usa vistas que aseguren que los nodos y los bordes sean únicos

Las vistas que definen tablas de nodos o aristas deben seguir uno de los siguientes patrones para asegurarse de que los nodos y las aristas sean únicos:

  • Patrón 1: la vista usa la clave principal de una sola tabla.

  • Patrón 2: la vista usa una cláusula GROUP BY o SELECT DISTINCT.

Puedes usar otros operadores de SQL, como WHERE, HAVING, ORDER BY,LIMIT y TABLESAMPLE, junto con estos patrones. Estos operadores filtran u ordenan los resultados, pero no cambian la garantía de unicidad subyacente que proporcionan los patrones.

Patrón 1: usar la clave principal de una sola tabla

En este patrón, la vista selecciona datos de una sola tabla y la cláusula KEY de la definición del gráfico coincide con las columnas de clave principal de la tabla base. Por este motivo, cada fila de nodos o aristas que genera la vista es única.

Por ejemplo, la siguiente consulta selecciona un subconjunto de filas de la tabla Account. El gráfico KEY(account_id) coincide con la clave principal de la tabla Account, lo que asegura que cada fila generada por la vista sea única.

-- 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)
  );

Patrón 2: Usar la cláusula GROUP BY o SELECT DISTINCT

En este patrón, la consulta de la vista usa una cláusula GROUP BY o SELECT DISTINCT. Las columnas de la cláusula KEY deben coincidir con las columnas que usan estas cláusulas para definir la unicidad:

  • En el caso de GROUP BY, las columnas de la cláusula KEY deben coincidir con todas las columnas de la cláusula GROUP BY.

  • En el caso de SELECT DISTINCT, las columnas de la cláusula KEY deben coincidir con las columnas de la lista SELECT DISTINCT.

Ejemplo con 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)
  );

Ejemplo con 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)
  );

Consideraciones al usar vistas

Cuando usas vistas para definir elementos de un gráfico, lo siguiente puede ayudarte a diseñar e implementar un gráfico eficaz:

Rendimiento de las consultas de gráficos de propiedades

Cuando defina elementos de gráfico en vistas que realicen transformaciones de datos (por ejemplo, operaciones GROUP BY, UNNEST o JOIN), evalúe detenidamente el rendimiento de las consultas en su caso práctico. Recuerda que Spanner ejecuta la definición de consulta de una vista cada vez que una consulta realiza una coincidencia de patrón de elemento.

Optimización del esquema de gráficos

Cuando usas vistas para definir elementos de un gráfico, algunas optimizaciones del esquema del gráfico pueden ser menos eficaces que cuando usas tablas para definir elementos de un gráfico.

Vistas que proyectan la clave principal de una sola tabla

Si una vista es una proyección de una sola tabla base, las optimizaciones de esa tabla subyacente seguirán siendo eficaces para las consultas de gráficos. Por ejemplo, aplicar las siguientes técnicas a las tablas base proporciona ventajas de rendimiento similares a los elementos de gráfico definidos en dichas vistas:

Vistas definidas con la cláusula GROUP BY o DISTINCT

Las vistas que realizan agregaciones, como GROUP BY, SELECT DISTINCT u otras transformaciones complejas, pierden la relación directa con la estructura de la tabla subyacente. Por este motivo, las optimizaciones de esquemas en las tablas base pueden no proporcionar las mismas ventajas de rendimiento para las consultas de gráficos que operan en las vistas. Evalúa detenidamente el rendimiento de las consultas de tu caso práctico cuando tus vistas realicen agregaciones complejas.

Modificación de datos con gráficos basados en vistas

Las vistas no se materializan, lo que significa que no almacenan los resultados de la consulta que define la vista como una tabla en el almacenamiento de datos y son de solo lectura. Por este motivo, para insertar, actualizar o eliminar nodos o aristas en un grafo creado a partir de vistas, debes modificar los datos de las tablas usadas para crear las vistas.

Gestión de errores de gráficos para garantizar la integridad de los datos

Cuando uses vistas para definir elementos de un gráfico, aplica la integridad de los datos (por ejemplo, aplica tipos de datos) en las tablas base subyacentes. De lo contrario, los datos de las tablas base podrían no ser válidos y provocar que las consultas en el gráfico basado en la vista fallen en tiempo de ejecución.

Por ejemplo, cuando pasas de un esquema a un gráfico formalizado, usa restricciones CHECK para validar los datos de tus tablas base (GraphNode y GraphEdge). El siguiente código aplica estas restricciones en las propiedades JSON para asegurar la integridad de los datos en la fuente y evitar errores de consulta en el tiempo de ejecución.

-- 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));

Siguientes pasos