Tu primer grafo en BigQuery: el error está en modelar las aristas

Para crear un property graph en BigQuery necesitas tablas existentes, claves que identifiquen cada nodo y una tabla de relaciones cuyos campos apunten al origen y al destino. Después declaras el grafo con CREATE PROPERTY GRAPH y lo consultas mediante GRAPH, MATCH y RETURN.

La parte delicada es la arista. Si su clave no distingue relaciones repetibles o si sus extremos contradicen el hecho representado, el esquema ya no expresa correctamente los datos y el patrón consultado puede perder relaciones o recorrerlas en el sentido equivocado.

1. Decide qué es nodo y qué es arista

Este ejemplo hipotético de comercio parte de dos entidades: clientes y productos. Cada compra conecta ambas entidades, pero también tiene fecha y cantidad; por eso se almacena en una tabla de aristas separada y conserva un identificador propio.

La descripción oficial del esquema explica que BigQuery Graph convierte las filas de las tablas de entrada en nodos o aristas. La función permanece en vista previa, las claves de elemento deben ser únicas y BigQuery no comprueba por sí mismo esa unicidad.

Crea el conjunto de datos y las tres tablas:

SQL 1. CREATE SCHEMA IF NOT EXISTS demo_grafo;

SQL 2. CREATE OR REPLACE TABLE demo_grafo.clientes (cliente_id INT64 NOT NULL, nombre STRING, PRIMARY KEY (cliente_id) NOT ENFORCED);

SQL 3. CREATE OR REPLACE TABLE demo_grafo.productos (producto_id INT64 NOT NULL, nombre STRING, PRIMARY KEY (producto_id) NOT ENFORCED);

SQL 4. CREATE OR REPLACE TABLE demo_grafo.compras (compra_id INT64 NOT NULL, cliente_id INT64 NOT NULL, producto_id INT64 NOT NULL, cantidad INT64, fecha DATE, PRIMARY KEY (compra_id) NOT ENFORCED);

cliente_id y producto_id identifican entidades. compra_id identifica una ocurrencia de la relación: así es posible representar dos compras del mismo producto por el mismo cliente como aristas diferentes.

2. Carga datos que revelen la cardinalidad

Un conjunto pequeño permite separar los problemas de modelado de los de volumen. Inserta dos clientes, dos productos y tres compras hipotéticas; dos registros conectarán al mismo cliente con el mismo producto en fechas distintas.

SQL 5. INSERT INTO demo_grafo.clientes VALUES (1, 'Ana'), (2, 'Luis');

SQL 6. INSERT INTO demo_grafo.productos VALUES (101, 'Teclado'), (102, 'Monitor');

SQL 7. INSERT INTO demo_grafo.compras VALUES (1001, 1, 101, 1, DATE '2025-01-10'), (1002, 1, 101, 2, DATE '2025-01-24'), (1003, 2, 102, 1, DATE '2025-02-03');

Antes de declarar el grafo, comprueba dos invariantes relacionales: compra_id no debe repetirse y todos los identificadores presentes en compras deben existir en sus tablas de entidades. El DDL describe la correspondencia del grafo, pero no convierte una clave duplicada o una referencia huérfana en una relación válida.

3. Declara la identidad y los extremos de la arista

La referencia de CREATE PROPERTY GRAPH divide la definición entre NODE TABLES y EDGE TABLES, y establece que una arista es dirigida: SOURCE KEY identifica su nodo de origen y DESTINATION KEY, el de destino.

SQL 8. CREATE OR REPLACE PROPERTY GRAPH demo_grafo.comercio NODE TABLES (demo_grafo.clientes KEY (cliente_id) LABEL Cliente PROPERTIES (cliente_id, nombre), demo_grafo.productos KEY (producto_id) LABEL Producto PROPERTIES (producto_id, nombre)) EDGE TABLES (demo_grafo.compras KEY (compra_id) SOURCE KEY (cliente_id) REFERENCES clientes (cliente_id) DESTINATION KEY (producto_id) REFERENCES productos (producto_id) LABEL COMPRO PROPERTIES (cantidad, fecha));

La declaración toma tres decisiones distintas. KEY (compra_id) separa una compra de otra; la referencia de origen enlaza cada registro con Cliente; y la referencia de destino lo enlaza con Producto. La etiqueta COMPRO expresa el sentido Cliente → Producto, mientras que fecha y cantidad permanecen como propiedades de la relación.

No confundas la identidad de la arista con sus extremos. Usar únicamente cliente_id como clave trataría todas las compras de ese cliente como una misma relación. La pareja cliente-producto tampoco basta cuando esa combinación puede repetirse; en este modelo, compra_id es la clave adecuada.

4. Recorre la relación con MATCH

Empieza consultando un tipo de nodo. Así puedes detectar problemas de etiqueta o de propiedades antes de probar la relación:

GQL 1. GRAPH demo_grafo.comercio MATCH (c:Cliente) RETURN c.cliente_id AS id, c.nombre AS nombre;

Después recorre la arista en la dirección declarada:

GQL 2. GRAPH demo_grafo.comercio MATCH (c:Cliente)-[r:COMPRO]->(p:Producto) RETURN c.nombre AS cliente, p.nombre AS producto, r.cantidad AS cantidad, r.fecha AS fecha ORDER BY fecha;

El laboratorio Customer 360 de Google amplía este mecanismo con clientes, productos, tiendas y pedidos como nodos, además de relaciones dirigidas como Visited, Placed y Has. Para ejecutar las consultas GQL del laboratorio se requiere una reserva de las ediciones Enterprise o Enterprise Plus.

Si quieres empezar el recorrido en Producto y llegar a Cliente mediante la misma relación, invierte el patrón: MATCH (p:Producto)<-[r:COMPRO]-(c:Cliente). No intercambies los extremos del esquema solo para acomodar una consulta: eso cambiaría el significado de COMPRO en todo el modelo.

5. Comprueba claves, dirección y resultado

• Clave de nodo repetida: dos filas comparten un identificador que debería corresponder a una sola entidad.
• Clave de arista insuficiente: una relación repetible se identifica con uno de sus extremos o con una combinación que admite duplicados.
• Extremos invertidos: Producto queda como origen y Cliente como destino, aunque la etiqueta se interpreta como Cliente COMPRO Producto.
• Referencia huérfana: una compra apunta a un cliente o producto inexistente y no encuentra el extremo esperado.
• Evento convertido en nodo sin necesidad: aquí la compra funciona como arista porque el recorrido principal conecta al cliente con el producto. Convertirla en nodo tendría sentido si otras entidades debieran relacionarse directamente con ella o si poseyera un ciclo de vida independiente.
• Propiedades sin alcance: exponer todas las columnas dificulta controlar el contrato del grafo; declara únicamente las propiedades que deban estar disponibles para sus consultas.

Con los datos hipotéticos del ejemplo, la consulta dirigida devuelve tres filas: dos compras de Ana para Teclado y una de Luis para Monitor. Si falta alguna, revisa primero la unicidad de compra_id y las referencias; si no aparece ninguna, comprueba las etiquetas y el sentido de la flecha en MATCH.

La regla central es concreta: un nodo necesita una identidad estable; una arista repetible necesita además una identidad propia, referencias válidas y una dirección compatible con el hecho que representa.

Lee también:

• YouTube contará una vista desde el primer fotograma, pero no pagará por ella
• El vacío no está vacío: un magnetar respalda una predicción de hace 90 años
• PUNCH calculó una tormenta solar con solo 30 minutos de error