Créer un graphique à partir d'une vue SQL

Découvrez comment créer un graphique à l'aide de vues SQL. Ce document fournit des instructions détaillées et des exemples de code pour définir des vues et les utiliser pour définir des tables de nœuds et d'arêtes. Explorez des exemples avec des exemples de code qui illustrent des cas d'utilisation pour créer des graphiques avec des vues. Pour en savoir plus sur l'utilisation des vues pour créer un graphique de propriétés, y compris sur les avantages et les points à prendre en compte, consultez Présentation des graphiques créés à partir de vues SQL.

Avant de commencer

Pour créer un graphique, vous devez :

Assurez-vous que votre environnement Spanner Graph est configuré.
Familiarisez-vous avec le fonctionnement des schémas Spanner Graph.

Créer un graphique à l'aide de vues

Pour créer un graphique à l'aide de vues :

Définissez les vues de votre graphique. Assurez-vous que vos vues suivent l'un des schémas de vues requis. Pour en savoir plus, consultez Créer une vue.
Utilisez vos vues dans les clauses NODE TABLES et EDGE TABLES de l'instruction CREATE PROPERTY GRAPH pour créer un graphique.
Incluez la clause KEY dans l'instruction CREATE PROPERTY GRAPH. La clause KEY spécifie les colonnes de la vue source qui identifient de manière unique chaque élément du graphique.

Exemple : Créer un graphique à l'aide de vues

Cet exemple crée les vues suivantes sur les tables Customer et Account : AsiaCustomer, AsiaBankAccount et AsiaAccountsOwnership. L'exemple utilise ensuite ces vues pour créer les éléments suivants dans un graphique :

Créez la table de nœuds Customer à l'aide de la vue AsiaCustomer.
Créez la table de nœuds Account à l'aide de la vue AsiaBankAccount.
Créez la table d'arêtes Owns à l'aide de la vue AsiaAccountsOwnership. Cette arête connecte les nœuds Customer aux nœuds Account.

Étape 1 : Créez les tableaux

Commencez par créer les tables de données. Le code suivant crée les tables Customer et Account.

CREATE TABLE Customer (
  customer_id INT64 NOT NULL,
  name STRING(MAX),
  address_continent STRING(MAX),
  address_country STRING(MAX),
) PRIMARY KEY(customer_id);

CREATE TABLE Account (
  account_id INT64 NOT NULL,
  customer_id INT64 NOT NULL,
  account_type STRING(MAX),
  balance INT64,
  create_time TIMESTAMP,
  address_continent STRING(MAX),
  address_country STRING(MAX),
  CONSTRAINT FK_CustomerId FOREIGN KEY (customer_id)
    REFERENCES Customer (customer_id)
) PRIMARY KEY(account_id);

Étape 2 : Créez les vues

Créez ensuite des vues pour transformer ou filtrer les données des tables. Ces vues filtrent les tableaux pour n'inclure que les clients et les comptes en Asie. Les vues utilisées pour créer des éléments de graphique doivent s'assurer que les lignes de la vue sont uniques.

-- View for 'Customer' nodes, filtered for Asia
CREATE VIEW AsiaCustomer
  SQL SECURITY INVOKER AS
    SELECT customer.customer_id, customer.name
    FROM Customer customer
    WHERE LOWER(customer.address_continent) = "asia";

-- View for 'Account' nodes, filtered for Asia.
CREATE VIEW AsiaBankAccount
  SQL SECURITY INVOKER AS
    SELECT account.account_id, account.balance, account.account_type, account.create_time
    FROM Account account
    WHERE LOWER(account.address_continent) = "asia";

-- View for 'Owns' edges, connecting customers to accounts in Asia.
CREATE VIEW AsiaAccountsOwnership
  SQL SECURITY INVOKER AS
    SELECT account.customer_id, account.account_id
    FROM Account account
    WHERE LOWER(account.address_continent) = "asia";

Étape 3 : Créez le graphique de propriétés

Créez maintenant le AsiaFinGraph à l'aide des vues que vous avez créées. L'instruction CREATE PROPERTY GRAPH inclut la clause KEY pour chaque définition d'élément de graphique afin de spécifier les colonnes qui identifient de manière unique les éléments de graphique.

CREATE PROPERTY GRAPH AsiaFinGraph
  NODE TABLES (
    AsiaCustomer AS Customer KEY(customer_id),
    AsiaBankAccount AS Account KEY(account_id)
  )
  EDGE TABLES (
    AsiaAccountsOwnership AS Owns
      KEY(customer_id, account_id)
      SOURCE KEY (customer_id) REFERENCES Customer (customer_id)
      DESTINATION KEY (account_id) REFERENCES Account (account_id)
  );

Exemples de cas d'utilisation

Les vues SQL offrent des avantages par rapport à l'utilisation de tables pour les éléments de graphiques de propriétés. Les exemples suivants illustrent certains cas d'utilisation pour définir des éléments de graphique avec des vues au lieu de tables.

Exemple : Appliquer un contrôle précis des accès aux données graphiques

Pour appliquer la sécurité au niveau des lignes à vos données graphiques, définissez vos tables de nœuds ou d'arêtes à l'aide de vues avec droits du définisseur. La vue expose un sous-ensemble autorisé des données sous-jacentes au graphique.

Par exemple, pour limiter l'accès à un graphique aux employés d'un centre de coûts d'ingénierie, vous pouvez créer une vue EngineerEmployeeView et accorder des autorisations SELECT sur la vue à un rôle engineering_data_reader à l'aide de la clause GRANT.

Lorsque vous définissez une table de nœuds de graphique à l'aide de cette vue, les utilisateurs qui exécutent des requêtes de graphique avec le rôle engineering_data_reader ne peuvent voir que les lignes filtrées par la vue, qui incluent les employés du service d'ingénierie.

-- The table containing all employee data.
CREATE TABLE Employee (
  id INT64 NOT NULL,
  cost_center STRING(MAX),
  job_title STRING(MAX),
  office STRING(MAX)
) PRIMARY KEY (id);

-- The definer's rights view that filters for engineering employees.
CREATE VIEW EngineerEmployeeView SQL SECURITY DEFINER AS
  SELECT e.id, e.cost_center, e.job_title, e.office
  FROM Employee e
  WHERE LOWER(e.cost_center) = "engineering";

-- The role that is granted to read the view.
CREATE ROLE engineering_data_reader;
GRANT SELECT ON VIEW EngineerEmployeeView TO ROLE engineering_data_reader;

-- The graph that uses definer's rights view.
CREATE PROPERTY GRAPH EngineeringGraph
  NODE TABLES (
    EngineerEmployeeView KEY(id)
  );

Exemple : Éléments de graphique dérivés du modèle

Vous pouvez utiliser des vues pour définir des éléments de graphique qui nécessitent des transformations de données. L'un des principaux avantages est que la vue définit la transformation. Vous n'avez donc pas besoin de gérer une table distincte pour les données dérivées.

Par exemple, vous pouvez UNNEST des données à partir d'une colonne ARRAY (ou d'un champ de tableau dans une colonne JSON) pour modéliser plusieurs relations d'arête à partir d'une seule ligne.

Dans l'exemple de schéma de chaîne d'approvisionnement suivant, une table Parts stocke une liste de sous-composants dans un tableau dependent_parts. Une vue peut utiliser l'opérateur UNNEST pour transformer chaque élément de ce tableau en lignes distinctes. Cette vue peut ensuite servir de table d'arêtes, ce qui vous permet de modéliser une arête PartDependsOnPart pour représenter les relations de dépendance entre les pièces.

-- Parts table with an ARRAY of dependent parts.
CREATE TABLE Parts (
  part_id INT64 NOT NULL,
  dependent_parts ARRAY<INT64>
) PRIMARY KEY (part_id);

-- A view that unnests the dependent_parts array.
-- GROUP BY ensures uniqueness for the graph element KEY.
CREATE VIEW PartDependsOnPart SQL SECURITY INVOKER AS
  SELECT p.part_id, dependent_part_id
  FROM Parts AS p,
    UNNEST(p.dependent_parts) AS dependent_part_id
  GROUP BY p.part_id, dependent_part_id;

-- Graph modeling the part dependency relationship.
CREATE PROPERTY GRAPH SupplyChainGraph
  NODE TABLES (
    Parts
  )
  EDGE TABLES (
    PartDependsOnPart KEY (part_id, dependent_part_id)
      SOURCE KEY (part_id) REFERENCES Parts(part_id)
      DESTINATION KEY (dependent_part_id) REFERENCES Parts(part_id)
  );

Exemple : Transition de données sans schéma

La gestion des données sans schéma vous permet de créer une définition de graphique flexible sans types de nœuds ni d'arêtes prédéfinis. Bien que la gestion des données sans schéma offre de la flexibilité, vous devrez peut-être passer à une structure plus formelle à mesure que vos données se définissent. Une structure plus formelle expose les relations, les libellés et les propriétés des nœuds et des arêtes du graphique dans le schéma, ce qui réduit la nécessité d'explorer manuellement les données pour comprendre le schéma du graphique.

Vous pouvez utiliser des vues pour formaliser les types de nœuds et d'arêtes sans migrer vos données sous-jacentes. Par exemple, vous pouvez passer d'un modèle sans schéma typique qui utilise des tables canoniques GraphNode et GraphEdge. Pour ce faire, vous devez créer des vues qui extraient les données de vos tables sans schéma :

Définissez une vue pour chaque type de nœud et d'arête que vous souhaitez formaliser (par exemple, Person ou WorksFor). Dans la vue, filtrez les données par leur libellé (par exemple, WHERE n_label = "person") et convertissez les propriétés de la colonne JSON en types de données spécifiques (par exemple, STRING(prop.name) AS name).
Définissez un graphique de propriété dans lequel NODE TABLES et EDGE TABLES font référence aux vues typées que vous venez de créer.

Un graphique sans schéma offre de meilleures performances qu'un graphique formalisé pour certaines requêtes (par exemple, un modèle de chemin quantifié avec plusieurs types d'arêtes). Si les métadonnées formalisées sont importantes pour votre cas d'utilisation, vous pouvez utiliser des vues pour passer d'un graphique sans schéma à un schéma typé. Vous pouvez également choisir d'utiliser un graphique sans schéma pour certains cas d'utilisation et un graphique de schéma typé pour d'autres. Pour en savoir plus, consultez Choisir une conception de schéma en fonction des requêtes de graphiques.

L'exemple suivant illustre le workflow permettant de passer d'un graphique sans schéma à un graphique formalisé en quatre étapes :

Définissez les tables canoniques GraphNode et GraphEdge pour le modèle sans schéma.
Créez un graphique initial et flexible sur ces tables sans schéma.
Définissez des vues typées (Person, Company, WorksFor) qui extraient et formalisent les données des tables sans schéma.
Créez le graphique final fortement typé qui utilise ces vues comme tables de nœuds et d'arêtes.

-- 1. Create the canonical tables for a schemaless model.
CREATE TABLE GraphNode (
  id INT64 NOT NULL,
  label STRING(MAX) NOT NULL,
  properties JSON
) PRIMARY KEY (id);

CREATE TABLE GraphEdge (
  id INT64 NOT NULL,
  dest_id INT64 NOT NULL,
  edge_id INT64 NOT NULL,
  label STRING(MAX) NOT NULL,
  properties JSON
) PRIMARY KEY (id, dest_id, edge_id),
  INTERLEAVE IN PARENT GraphNode;

-- 2. Define a schemaless graph.
CREATE PROPERTY GRAPH FinGraph
  NODE TABLES (
    GraphNode
      DYNAMIC LABEL (label)
      DYNAMIC PROPERTIES (properties)
  )
  EDGE TABLES (
    GraphEdge
      SOURCE KEY (id) REFERENCES GraphNode(id)
      DESTINATION KEY (dest_id) REFERENCES GraphNode(id)
      DYNAMIC LABEL (label)
      DYNAMIC PROPERTIES (properties)
  );

-- 3. Define typed views that extract and formalize the data.
--    Convert JSON fields to primitive types (for example, INT64, STRING) to
--    ensure type safety.
CREATE VIEW Person SQL SECURITY INVOKER AS
  SELECT n.id, STRING(n.properties.name) AS name, INT64(n.properties.age) AS age
  FROM GraphNode n WHERE n.label = "person";

CREATE VIEW Company SQL SECURITY INVOKER AS
  SELECT n.id, STRING(n.properties.name) AS company_name, BOOL(n.properties.is_public) AS is_public
  FROM GraphNode n WHERE n.label = "company";

CREATE VIEW WorksFor SQL SECURITY INVOKER AS
  SELECT e.id AS person_id, e.dest_id AS company_id, e.edge_id AS edge_id, STRING(e.properties.since) AS since
  FROM GraphEdge e
  WHERE e.label = "worksfor";

-- 4. Create the final, formalized graph from the typed views.
CREATE PROPERTY GRAPH typed_formalized_graph
  NODE TABLES (
    Person KEY(id)
      PROPERTIES (name, age),
    Company KEY(id)
      PROPERTIES (company_name, is_public)
  )
  EDGE TABLES(
    WorksFor KEY(person_id, company_id, edge_id)
      SOURCE KEY (person_id) REFERENCES Person(id)
      DESTINATION KEY (company_id) REFERENCES Company(id)
      PROPERTIES (since)
  );

Étapes suivantes

En savoir plus sur le schéma Spanner Graph
Découvrez les bonnes pratiques de conception d'un schéma Spanner Graph.