Grafos, ontologías,
agentes de IA y prompt engineering

El modelo, en un diagrama entidad-relación

Preguntas que caben en una tabla

• ¿Cuánto tiene Ana en total?
• ¿Cuánto transfirió Pedro?
• ¿Cuántos clientes tenemos? ¿Cuál es la transferencia promedio?
• ¿Quién recibió dinero de Carlos?

Tres caminos, todos ya en los datos

• Ana → cuenta → transferencia → cuenta → Pedro
• Ana → trabaja en → Acme ← trabaja en ← Pedro
• Ana → comparte teléfono → Pedro

No reemplazamos el lakehouse

Esto se corre, no se lee

• Cada consulta vive en un lab embebido, se ejecuta en vivo.
• Panel izquierdo: SQL. Panel derecho: el resultado que aparece.
• Terreno cómodo: todo lo que sigue, el tabular lo responde sin despeinarse.

¿Cuántos clientes? ¿Cuánto es la transferencia promedio?

SELECT COUNT(*) AS n_clientes
FROM   banco_customers;
-- → 4

SELECT ROUND(AVG(amount),2) AS promedio,
       COUNT(*)             AS n
FROM   banco_transfers;
-- → 600.00 · 4

Todo esto lo resolvió el tabular sin esfuerzo

En SQL: una consulta por cada tipo de vínculo

SELECT co.name AS empresa
FROM   banco_employment e1
JOIN   banco_employment e2
       ON e2.company_id = e1.company_id
JOIN   banco_companies co
       ON co.id = e1.company_id
WHERE  e1.customer_id = 1   -- Ana
  AND  e2.customer_id = 2;  -- Pedro
-- → Acme

SELECT p1.phone
FROM   banco_phones p1
JOIN   banco_phones p2
       ON p2.phone = p1.phone
WHERE  p1.customer_id = 1   -- Ana
  AND  p2.customer_id = 2;  -- Pedro
-- → +51-900

Ana no solo tiene cuentas. Tiene gente alrededor

¿Qué relación hay entre Ana y Pedro?

¿Qué amigos y familiares de Ana son clientes del banco?

SELECT p.name
FROM   banco_relations r
JOIN   banco_persons   p ON p.id = r.person_b
WHERE  r.person_a = 1            -- Ana
  AND  r.type IN ('RELATIVE_OF','KNOWS')
  AND  p.is_customer = 1;        -- "...en el banco"

MATCH (ana:Customer {name:'Ana'})
      -[:RELATIVE_OF|KNOWS]-(p:Customer)
RETURN p.name

¿Algún pariente de Ana le transfirió dinero, aunque sea indirectamente?

La cadena existe, pero nadie la guardó

Un salto más = más JOINs

-- Ana ↔ compañeros de empresa
JOIN banco_employment e1 ...
JOIN banco_employment e2
     ON e2.company_id = e1.company_id
-- → Pedro (comparten Acme)

JOIN banco_employment e1 ...  -- salto 1
JOIN banco_employment e2 ...
JOIN banco_employment e3 ...  -- salto 2
JOIN banco_employment e4 ...
-- → Carlos (Ana→Acme→Pedro→Beta→Carlos)

La vía correcta en SQL: WITH RECURSIVE

WITH RECURSIVE conexion AS (
  SELECT c.id, c.name,
         CAST(c.id AS CHAR(200)) AS camino,   -- path-tracking manual
         0                       AS saltos
  FROM   banco_customers c WHERE c.name = 'Ana'
  UNION ALL
  SELECT c2.id, c2.name,
         CONCAT(k.camino, '>', c2.id),
         k.saltos + 1
  FROM   conexion k
  JOIN   banco_employment e1 ON e1.customer_id = k.id
  JOIN   banco_employment e2 ON e2.company_id  = e1.company_id
  JOIN   banco_customers  c2 ON c2.id = e2.customer_id
  WHERE  LOCATE(c2.id, k.camino) = 0   -- cycle guard manual
    AND  k.saltos < 10                -- tope de saltos manual
)
SELECT name, camino, saltos FROM conexion WHERE name = 'Carlos';

Lo que tuve que escribir a mano

• Cycle guard: sin él, un ciclo (A1→A2→A3→A1) cuelga la recursión.
• Tope de saltos: un límite artificial, porque no sé la profundidad.
• Path-tracking: reconstruir el camino paso a paso.

¿Cuándo la pregunta es "de red"?

Es una pregunta de red si se cumple al menos uno:

• Profundidad variable: no sé cuántos saltos hay de antemano.
• Vínculos heterogéneos: empresa y cuenta y teléfono en la misma pregunta.
• El camino es la respuesta: quiero la cadena, no un total.

El dato no cambia. Cambia cómo lo escribimos

El diccionario de traducción

Anatomía de un grafo: las cuatro piezas

El monto vive en la arista, no en el círculo

Un cuidado: el supernodo

¿Nodo propio o propiedad?

Patrones de modelado de grafos

• Tabla puente M:N → arista. Con propiedades si el vínculo las carga. EMPLOYMENT a WORKS_AT.
• Reificar la relación. Si la relación tiene atributos propios, viven en la arista. amount en TRANSFER.
• Atributo compartido → nodo. Teléfono, domicilio, IP: promoverlos revela conexiones que ninguna tabla guardaba.
• Junction con > 2 FKs o vida propia → nodo intermedio. Cuando la relación deja de ser un enlace y pasa a ser una entidad.

Cuatro tipos de nodo. Cuatro tipos de arista.

CUSTOMERS → nodos Customer

FK → arista OWNS, y la columna que se vuelve propiedad de la arista

Tabla puente M:N → arista WORKS_AT

El grafo completo del banco básico

Coral = Customer · índigo = Account · charcoal = Company · ámbar = Phone. Ciclo A1→A2→A3→A1 visible. Ana y Pedro llegan al mismo teléfono.

PHONES: ¿propiedad de Customer, o nodo propio?

El "comparte teléfono" no es una tabla

Antes y después, lado a lado

El patrón se lee como el dibujo

(a)-[:TRANSFER]->(b)

Mismo caso, dos lenguajes: ¿cuánto transfirió Ana?

SELECT SUM(t.amount)
FROM   banco_transfers t
JOIN   banco_accounts a  ON t.from_account = a.id
JOIN   banco_customers c ON a.customer_id = c.id
WHERE  c.name = 'Ana';

MATCH (c:Customer {name:'Ana'})
      -[:OWNS]->(:Account)
      -[t:TRANSFER]->()
RETURN sum(t.amount)

Dos vínculos que no sabíamos que estaban

• Ana → Acme → Pedro, trabajan juntos (WORKS_AT)
• Ana → +51-900 → Pedro, comparten teléfono (HAS_PHONE)

La prueba de fuego: ¿qué conecta a Ana con Carlos?

WITH RECURSIVE conexion AS (
  SELECT c.id, c.name, 0 AS saltos
  FROM   banco_customers c WHERE c.name='Ana'
  UNION ALL
  SELECT c2.id, c2.name, k.saltos+1
  FROM   conexion k
  JOIN   banco_employment e1 ON e1.customer_id=k.id
  JOIN   banco_employment e2 ON e2.company_id=e1.company_id
  JOIN   banco_customers  c2 ON c2.id=e2.customer_id
  WHERE  k.saltos < 10        -- tope artificial
)  -- + cycle guard + path-tracking a mano
SELECT * FROM conexion WHERE name='Carlos';

MATCH p = (a:Customer {name:'Ana'})
          -[:WORKS_AT*1..]-
          (c:Customer {name:'Carlos'})
RETURN p
ORDER BY length(p)
LIMIT 1

El camino lo recibimos, no lo reconstruimos

Lo que acabamos de ver

Tres preguntas incómodas

1. ¿Ana y Pedro comparten algo que nadie registró?
2. ¿El dinero vuelve al punto de partida?
3. ¿Quién está cerca de Ana, sin saber a cuántos saltos?

Una estrella de teléfono

El self-join contra la estrella

SELECT c1.name AS cliente_a,
       c2.name AS cliente_b,
       p1.phone
FROM   banco_phones p1
JOIN   banco_phones p2
       ON p1.phone = p2.phone
      AND p1.customer_id < p2.customer_id
JOIN   banco_customers c1 ON c1.id = p1.customer_id
JOIN   banco_customers c2 ON c2.id = p2.customer_id;

MATCH (a:Customer)-[:HAS_PHONE]->(p:Phone)
        <-[:HAS_PHONE]-(b:Customer)
WHERE a.id < b.id
RETURN a.name, b.name, p.number;

Un anillo de transferencias

Recursión con guardas contra el patrón de ciclo

WITH RECURSIVE walk AS (
  SELECT from_account AS start,
         to_account   AS curr, 1 AS hops
  FROM   banco_transfers
  WHERE  from_account = 'A1'
  UNION ALL
  SELECT w.start, t.to_account, w.hops + 1
  FROM   walk w
  JOIN   banco_transfers t
         ON t.from_account = w.curr
  WHERE  w.hops < 10          -- tope artificial
    AND  w.curr <> w.start    -- corta el ciclo a mano
)
SELECT start AS cuenta, MIN(hops) AS saltos
FROM   walk WHERE curr = start GROUP BY start;

MATCH path =
  (a:Account {id:'A1'})-[:TRANSFER*1..3]->(a)
RETURN a.id AS cuenta,
       length(path) AS saltos;

Los JOINs se multiplican por salto

WITH edges AS (        -- aristas de todo tipo
  SELECT customer_id AS src, id AS dst FROM banco_accounts
  UNION SELECT id, customer_id          FROM banco_accounts
  UNION SELECT from_account, to_account FROM banco_transfers
  UNION SELECT to_account, from_account FROM banco_transfers
  UNION SELECT customer_id, company_id  FROM banco_employment
  UNION SELECT company_id, customer_id  FROM banco_employment
  UNION SELECT customer_id, phone       FROM banco_phones
  UNION SELECT phone, customer_id       FROM banco_phones
)
SELECT DISTINCT e2.dst          -- + el vecindario de 1 salto
FROM   edges e1
JOIN   edges e2 ON e2.src = e1.dst
WHERE  e1.src = '1';            -- Ana

MATCH (ana:Customer {name:'Ana'})
      -[*1..2]-(vecino)
RETURN DISTINCT vecino;

El vecindario de Ana

Donde la tabla suda, el grafo respira

Databricks no es una base de datos de grafos

Un grafo se puede escribir como dos tablas

-- nodes (id, type, properties)
id    type      properties
c1    Customer  {name: "Ana"}
a1    Account   {balance: 5000}
co10  Company   {name: "Acme"}

-- edges (source, relationship, target, properties)
source  relationship  target  properties
c1      OWNS          a1      {}
a1      TRANSFERS_TO  a2      {amount: 1000}
c1      WORKS_AT      co10    {}

Esas tablas se procesan como grafo

# GraphFrames: el mismo dataset, otra vista
g = GraphFrame(nodes, edges)
g.find("(a)-[t]->(b); (b)-[t2]->(a)")   # motif: transferencia recíproca

La arquitectura, en un dibujo

La progresión práctica del laboratorio

Cada paso se apoya en el anterior. Y todo esto puede vivir sobre las tablas Delta que ya tienen.

Y hay más de una vía

Databricks con nodes+edges es una forma. Existen otras, se ven en la próxima sesión:

• Motor dedicado: recorrido interactivo (Kùzu, embebido).
• Zero-ETL: consultar el Delta como grafo sin duplicarlo (PuppyGraph).

El arco del día, de un vistazo

Qué se conserva y qué cambia

No es "malo vs. bueno": es la forma de la pregunta

Puente a la Sesión 2