O Spanner Graph permite modelar dados conectados como um gráfico de propriedades que representa informações como uma rede de nós e arestas. Os nós simbolizam entidades, e as arestas mostram conexões entre elas. Os nós e as arestas incluem rótulos que classificam os tipos de nós e arestas. Os nós e as arestas também incluem propriedades que os descrevem.
Este documento descreve como definir um esquema do Spanner Graph mapeando linhas de tabelas para nós e arestas de gráficos. Você também aprende a personalizar rótulos e propriedades de nós e arestas e a trabalhar com dependências de objetos de gráficos e esquemas.
Se você quiser definições de gráficos mais flexíveis, consulte Gerenciar dados sem esquema. Se você quiser aprender a usar visualizações SQL em vez de tabelas para definir nós e arestas, consulte Visão geral dos gráficos criados com visualizações SQL. Para saber mais sobre o Spanner Graph, consulte a visão geral do Spanner Graph.
Entender o modelo de dados do gráfico de propriedades
Um gráfico de propriedades permite modelar dados conectados. Ele representa informações como uma rede de nós e arestas. Os nós simbolizam entidades no cenário de dados, como clientes, produtos ou locais. As arestas mostram as conexões entre esses nós, capturando relações como "adquirido", "segue" ou "localizado em".
Tanto os nós quanto as arestas podem incluir as seguintes informações:
Rótulos: classificam nós e tipos de arestas. Se você não definir explicitamente um rótulo para um nó ou uma aresta, o Spanner Graph usará o nome da tabela de entrada como o rótulo padrão. Por exemplo,
Accountpode ser um rótulo.Propriedades: usadas para descrever nós e arestas. Por exemplo, um nó
Personpode ter uma propriedadenamecom o valorAlexe uma propriedadeidcom o valor1.
O exemplo na Figura 1 mostra como você pode criar um gráfico para modelar atividades financeiras. Esse gráfico inclui os seguintes tipos de entidades modeladas como nós:
- Person:representa um indivíduo envolvido em transações financeiras.
- Account:representa uma conta bancária usada para transações.
Essas entidades estão conectadas por diferentes tipos de relações, que são representadas pelas seguintes arestas direcionadas:
- Owns:uma pessoa tem uma ou mais contas.
- Transfers:o dinheiro se move de uma conta para outra.
Cada aresta direcionada indica uma relação unidirecional que flui de um nó de origem para um nó de destino. Por exemplo, uma aresta Transfers conecta uma Account de origem a uma Account de destino, indicando o fluxo de dinheiro.
Figura 1. Exemplo de gráfico com vários nós e arestas direcionadas.
Os nós e as arestas incluem informações adicionais nas propriedades.
- Os nós Person incluem estas propriedades:
name(STRING)id(INT64)
- As arestas Transfers incluem esta propriedade:
amount(FLOAT64)
Arestas direcionadas e não direcionadas
O gráfico de exemplo usa arestas direcionadas que indicam uma direção específica na relação entre entidades. No entanto, algumas relações, como a relação amigo em uma rede social, não são direcionadas e representam uma conexão recíproca sem uma origem ou endpoint distintos. Nesse caso, é possível modelar arestas não direcionadas como duas arestas direcionadas, uma em cada direção.
Design de esquema do Spanner Graph
No Spanner Graph, você usa a instrução CREATE PROPERTY GRAPH para criar um gráfico de tabelas ou visualizações SQL. As tabelas usadas para criar gráficos são chamadas de tabelas de entrada. Este documento mostra como usar tabelas para criar um gráfico. Para informações sobre como usar visualizações SQL, consulte Criar um Spanner Graph de uma visualização SQL.
Definir um nó de uma tabela
Para definir um nó, adicione uma definição de nó na cláusula NODE TABLES. A forma mais simples de uma definição de nó contém o nome de uma tabela de entrada que tem referências de nó de origem e destino definidas. O Spanner Graph mapeia linhas da tabela de entrada para nós de gráficos.
No exemplo a seguir, você usa a
cláusula NODE TABLES
para definir o nó Account no gráfico de propriedades FinGraph. A definição do nó contém a tabela de entrada Account.
-- First, create an Account table.
CREATE TABLE Account (
id INT64 NOT NULL,
create_time TIMESTAMP,
) PRIMARY KEY (id);
-- Next, use the Account table as input table of Account node definition.
CREATE PROPERTY GRAPH FinGraph
NODE TABLES (
Account
);
Rótulos e propriedades padrão
Além de usar o nome da tabela de entrada como o rótulo padrão, o Spanner Graph expõe todas as colunas da tabela de entrada como propriedades de nó.
No exemplo anterior,
- Cada nó de conta usa o rótulo
Account. - Cada nó de conta inclui propriedades
[id, create_time]das colunas da tabelaAccount.
Chave do elemento
Uma definição de nó também define a chave do elemento que identifica exclusivamente um nó de gráfico.
- Por padrão, a chave do elemento é a chave primária da tabela de entrada.
- É possível usar a cláusula
KEYpara definir explicitamente as chaves de elementos. - É possível usar colunas com uma restrição de índice exclusivo como chaves de elementos.
O exemplo a seguir define o nó Account e o nó Person.
- O nó
Accountusa a chave primária da tabelaAccountcomo chave de elemento por padrão. - O nó
Person, por outro lado, especifica explicitamente oidcomo a chave do elemento com a cláusulaKEY.
CREATE TABLE Person (
id INT64 NOT NULL,
name STRING(MAX),
) PRIMARY KEY (id);
CREATE TABLE Account (
id INT64 NOT NULL,
create_time TIMESTAMP,
) PRIMARY KEY (id);
CREATE PROPERTY GRAPH FinGraph
NODE TABLES (
Person KEY (id),
Account
);
Mapear uma linha na tabela de entrada para um nó no gráfico
- Cada linha com uma chave de elemento não nula é mapeada para um nó exclusivo no gráfico, identificado pela chave do elemento.
- As linhas com uma chave de elemento nula são ignoradas.
Definir uma aresta de uma tabela
Para definir uma aresta, adicione uma definição de aresta na cláusula EDGE TABLES. A forma mais simples de definição de aresta contém apenas um nome de tabela de entrada. O Spanner Graph mapeia linhas da tabela de entrada para arestas de gráficos.
O rótulo e as propriedades padrão das arestas são definidos da mesma forma que os nós.
A chave do elemento de cada aresta é definida da mesma forma que os nós.
Referências de nó de origem e destino
No exemplo a seguir, você cria um gráfico de propriedades FinGraph com o seguinte:
- Nós
PersoneAccount - Aresta
PersonOwnAccount
CREATE TABLE Person (
id INT64 NOT NULL,
name STRING(MAX),
) PRIMARY KEY (id);
CREATE TABLE Account (
id INT64 NOT NULL,
create_time TIMESTAMP,
) PRIMARY KEY (id);
CREATE TABLE PersonOwnAccount (
id INT64 NOT NULL,
account_id INT64 NOT NULL,
create_time TIMESTAMP,
FOREIGN KEY (account_id) REFERENCES Account (id)
) PRIMARY KEY (id, account_id),
INTERLEAVE IN PARENT Person;
CREATE PROPERTY GRAPH FinGraph
NODE TABLES (
Person,
Account
)
EDGE TABLES (
PersonOwnAccount
SOURCE KEY (id) REFERENCES Person (id)
DESTINATION KEY (account_id) REFERENCES Account (id)
);
Uma definição de aresta define a referência do nó de origem e destino usando as cláusulas SOURCE KEY, DESTINATION KEY e REFERENCES. O exemplo a seguir usa a definição de aresta de PersonOwnAccount para ilustrar esse conceito:
EDGE TABLES (
PersonOwnAccount
SOURCE KEY (id) REFERENCES Person (id)
DESTINATION KEY (account_id) REFERENCES Account (id)
)
Cada aresta PersonOwnAccount conecta um Person (origem) a um nó Account
(destino).
- O nó de origem de uma aresta é um nó
Personem que oidé o mesmo que a arestaid. - O nó de destino de uma aresta é um nó
Accountem que oidé o mesmo que a arestaaccount_id.
Além disso, o seguinte é verdadeiro para a aresta PersonOwnAccount:
- A chave do elemento é a chave primária da tabela
PersonOwnAccount, ou seja,(id, account_id). - Cada aresta tem o mesmo conjunto de propriedades que as colunas da tabela
PersonOwnAccount. - Cada aresta tem o rótulo
PersonOwnAccountpadrão.
Mapear uma linha em uma tabela de entrada de aresta para arestas no gráfico
- Cada linha na tabela de entrada de aresta, em que a chave do elemento não é nula, geralmente é mapeada para uma aresta exclusiva no gráfico.
- Uma linha pode corresponder a zero ou mais de uma aresta no gráfico. Por exemplo, isso ocorre quando a referência do nó de origem corresponde a zero ou mais nós na tabela de nós de origem.
Definir nós e arestas em uma única tabela
É possível definir um nó e as arestas de entrada ou saída em uma única tabela se as colunas da tabela definirem uma relação com outra tabela. Essa abordagem reduz o número de tabelas, simplifica o gerenciamento de dados e pode melhorar o desempenho da consulta, eliminando a necessidade de uma junção a uma tabela de arestas separada.
Por exemplo, se a tabela Account a seguir tiver uma chave primária composta
(owner_id, account_id), a parte owner_id poderá ser uma chave externa que
faz referência a uma tabela Person. Essa estrutura permite que a tabela Account represente o nó Account e a aresta de entrada do nó Person.
CREATE TABLE Person (
id INT64 NOT NULL,
) PRIMARY KEY (id);
-- Assume each account has exactly one owner.
CREATE TABLE Account (
owner_id INT64 NOT NULL,
account_id INT64 NOT NULL,
FOREIGN KEY (owner_id) REFERENCES Person(id)
) PRIMARY KEY (owner_id, account_id);
É possível usar a tabela Account para definir o nó Account e a aresta Owns de entrada. Isso é mostrado na instrução CREATE PROPERTY GRAPH a seguir. Na cláusula EDGE TABLES, você atribui o alias Owns à tabela Account. Isso ocorre porque cada elemento no esquema de gráfico precisa ter um nome exclusivo.
CREATE PROPERTY GRAPH FinGraph
NODE TABLES (
Person,
Account
)
EDGE TABLES (
Account AS Owns
SOURCE KEY (owner_id) REFERENCES Person
DESTINATION KEY (owner_id, account_id) REFERENCES Account
);
Personalizar rótulos e propriedades
É possível usar as LABEL e PROPERTIES para personalizar rótulos e propriedades.
O exemplo a seguir define dois nós: Person e Account.
- Os nós
Personusam o rótuloCustomerpara expor a propriedadeaddress. A propriedadeaddressé definida pela expressãoCONCAT(city, ", ", country),que se refere à colunacityecountryda tabela de entradaPerson. - Para
Account, o nóAccountusa o rótuloAccountpara expor as propriedadesidecreate_time. PersoneAccounttêm o rótuloEntitycom propriedades [id, name].- Para
Person, as propriedadesidenamevêm das colunas da tabela de entrada. - Para
Account, a propriedadenamese refere à colunanick_nameda tabela de entrada.
- Para
CREATE TABLE Person (
id INT64 NOT NULL,
name STRING(MAX),
birthday TIMESTAMP,
country STRING(MAX),
city STRING(MAX),
) PRIMARY KEY (id);
CREATE TABLE Account (
id INT64 NOT NULL,
create_time TIMESTAMP,
is_blocked BOOL,
nick_name STRING(MAX),
) PRIMARY KEY (id);
CREATE PROPERTY GRAPH FinGraph
NODE TABLES (
Person KEY (id)
LABEL Customer
PROPERTIES (CONCAT(city, ", ", country) AS address)
LABEL Entity PROPERTIES (id, name),
Account KEY (id)
LABEL Account PROPERTIES (id, create_time)
LABEL Entity PROPERTIES (id, nick_name AS name)
);
Consistência de rótulos e propriedades
Em um gráfico, os rótulos e as propriedades são identificados exclusivamente pelos nomes. É possível usar rótulos e propriedades com o mesmo nome em várias definições de nós ou arestas. No entanto, rótulos e propriedades com o mesmo nome precisam seguir estas regras:
- Propriedades com o mesmo nome usam o mesmo tipo de valor.
- Rótulos com o mesmo nome expõem a mesma lista de propriedades.
No exemplo anterior, o rótulo Entity é definido nos nós Person e Account. Ambas as definições incluem o mesmo conjunto de nomes de propriedades [id, name] com tipos de valores idênticos.
Dependências entre gráficos e outros objetos de esquema
O gráfico criado por CREATE PROPERTY GRAPH depende de outros objetos de esquema, como as tabelas de entrada das definições de nós e arestas e as colunas de tabela referenciadas pelas propriedades. O Spanner Graph não permite uma mudança de esquema que quebre uma dessas dependências.
A instrução a seguir torna FinGraph dependente da tabela Account e das colunas id e create_time.
CREATE OR REPLACE PROPERTY GRAPH FinGraph
NODE TABLES (
Account PROPERTIES (id, create_time)
);
Neste exemplo, o Spanner Graph não permite as seguintes mudanças de esquema:
- Não é possível descartar a tabela
Account. Para fazer isso, é necessário remover a definição do nóAccount. Para mais informações, consulte Remover nós ou definições de arestas atuais. - Não é possível descartar colunas
create_timeda tabelaAccount. Para fazer isso, é necessário remover a propriedadecreate_timeda definição do nóAccount. Para mais informações, consulte Atualizar nós ou definições de arestas atuais.
No entanto, é possível fazer as seguintes mudanças de esquema:
- Modifique o esquema da tabela
Accounte das colunasidecreate_timese outros requisitos de esquema permitirem. Para mais informações, consulte Fazer atualizações de esquema.
Conferir uma visualização de esquema
É possível conferir uma visualização de esquema no Spanner Studio depois de executar uma consulta do Spanner Graph. Para mais informações, consulte Usar visualizações do Spanner Graph.
Gerenciar dados sem esquema
O Spanner Graph também oferece suporte ao gerenciamento de dados sem esquema, o que é útil quando você precisa de uma definição de gráfico mais flexível. Para mais informações, consulte Gerenciar dados sem esquema no Spanner Graph.
A seguir
- Criar um esquema do Spanner Graph.
- Atualizar ou excluir um esquema do Spanner Graph.
- Gerenciar dados sem esquema com o Spanner Graph.
- Saiba mais sobre as práticas recomendadas para o design de esquema do Spanner Graph.
- Saiba mais sobre as práticas recomendadas para ajustar consultas do Spanner Graph.