Vista geral dos gráficos criados a partir de vistas SQL

Use este documento para saber mais sobre as vantagens de usar vistas SQL para criar um gráfico. Este documento inclui vantagens da criação de gráficos com vistas, requisitos e considerações para ajudar a decidir se deve usar tabelas ou vistas para criar um gráfico.

Para ver detalhes sobre como criar um gráfico a partir de visualizações de propriedade, consulte o artigo Crie um gráfico de propriedades a partir de visualizações de SQL.

Vantagens de criar gráficos com vistas em vez de tabelas

Uma vista SQL é uma tabela virtual definida por uma consulta SQL. No Spanner, a consulta que define uma vista é executada sempre que uma consulta que se refere à vista é executada. As vistas do Spanner não são vistas materializadas porque não armazenam os resultados da consulta que define a vista como uma tabela real no armazenamento de dados. Para mais informações, consulte o artigo Vista geral das visualizações. Pode criar elementos de grafos a partir de vistas SQL, mas não pode criar uma vista que consulte um grafo.

As vistas oferecem várias vantagens como uma camada de abstração entre tabelas e um esquema de gráfico que não estão disponíveis quando usa tabelas para criar um gráfico.

Requisitos para usar visualizações para criar gráficos

Tem de cumprir estes requisitos quando usa vistas para criar elementos de gráficos:

Use a cláusula KEY quando especificar um elemento do gráfico

Tem de definir explicitamente as colunas que identificam de forma exclusiva o elemento do gráfico quando usa vistas para criar um nó ou um elemento de aresta. Para o fazer, use a cláusula KEY na definição do elemento de nó ou aresta. Para saber como usar a cláusula KEY ao criar um elemento de gráfico, consulte os exemplos de código neste documento e em Crie um gráfico do Spanner a partir de uma vista SQL.

Use vistas que garantam que os nós e as arestas são únicos

As vistas que definem tabelas de nós ou arestas têm de seguir um dos seguintes padrões para garantir que os nós e as arestas são únicos:

  • Padrão 1: a vista usa a chave principal de uma única tabela.

  • Padrão 2: a vista usa uma cláusula GROUP BY ou SELECT DISTINCT.

Pode usar outros operadores SQL, como WHERE, HAVING,ORDER BY,LIMIT e TABLESAMPLE em combinação com estes padrões. Estes operadores filtram ou ordenam os resultados, mas não alteram a garantia de exclusividade subjacente que os padrões oferecem.

Padrão 1: usar a chave principal de uma única tabela

Neste padrão, a vista seleciona a partir de uma única tabela e a cláusula KEY na definição do gráfico corresponde às colunas da chave primária da tabela de base. Por este motivo, cada linha de nós ou arestas produzida pela vista é única.

Por exemplo, o seguinte seleciona um subconjunto de linhas da tabela Account. O gráfico KEY(account_id) corresponde à chave principal da tabela Account, o que garante que cada linha produzida pela vista é ú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)
  );

Padrão 2: use a cláusula GROUP BY ou SELECT DISTINCT

Neste padrão, a consulta da vista usa uma cláusula GROUP BY ou SELECT DISTINCT. As colunas na cláusula KEY têm de corresponder às colunas que estas cláusulas usam para definir a singularidade:

  • Para GROUP BY: as colunas da cláusula KEY têm de corresponder a todas as colunas da cláusula GROUP BY.

  • Para SELECT DISTINCT: as colunas da cláusula KEY têm de corresponder às colunas na lista SELECT DISTINCT.

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

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

Considerações sobre a utilização de visualizações

Quando usa vistas para definir elementos do gráfico, o seguinte pode ajudar a criar e implementar um gráfico eficaz:

Desempenho das consultas de gráficos de propriedades

Quando define elementos do gráfico em vistas que realizam transformações de dados (por exemplo, operações GROUP BY, UNNEST ou JOIN), avalie cuidadosamente o desempenho das consultas para o seu exemplo de utilização. Lembre-se de que o Spanner executa a definição de consulta de uma vista sempre que uma consulta realiza a correspondência de padrões de elementos.

Otimização do esquema de grafos

Quando usa visualizações para definir elementos do gráfico, algumas otimizações do esquema do gráfico podem ser menos eficazes do que quando usa tabelas para definir elementos do gráfico.

Vistas que projetam a chave principal de uma única tabela

Se uma vista for uma projeção de uma única tabela base, todas as otimizações nessa tabela subjacente permanecem eficazes para consultas de gráficos. Por exemplo, a aplicação das seguintes técnicas às tabelas base oferece vantagens de desempenho semelhantes para os elementos de grafos definidos nessas visualizações:

Vistas definidas com a cláusula GROUP BY ou DISTINCT

As vistas que realizam agregações, como GROUP BY, SELECT DISTINCT ou outras transformações complexas, perdem a relação direta com a estrutura da tabela subjacente. Por este motivo, as otimizações de esquemas nas tabelas base podem não oferecer as mesmas vantagens de desempenho para consultas de gráficos que operam nas vistas. Avalie cuidadosamente o desempenho das consultas para o seu exemplo de utilização quando as suas visualizações realizam agregações complexas.

Modificação de dados com gráficos baseados na vista

As vistas não são materializadas, o que significa que não armazenam os resultados da consulta que define a vista como uma tabela no armazenamento de dados e são apenas de leitura. Por este motivo, para inserir, atualizar ou eliminar nós ou arestas num gráfico criado a partir de vistas, tem de modificar os dados nas tabelas usadas para criar as vistas.

Tratamento de erros de gráficos para aplicar a integridade dos dados

Quando usa vistas para definir elementos de gráficos, aplique a integridade dos dados (por exemplo, aplique tipos de dados) nas tabelas de base subjacentes. Caso contrário, os dados nas tabelas base podem ser inválidos e fazer com que as consultas no seu gráfico baseado em visualizações falhem no tempo de execução.

Por exemplo, quando transita de um esquema sem esquema para um gráfico formalizado, use restrições CHECK para validar os dados nas tabelas base (GraphNode e GraphEdge). O código seguinte aplica estas restrições nas propriedades JSON para garantir a integridade dos dados na origem e evitar erros de consulta de tempo de execução.

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

O que se segue?