Cómo: los predicados (P y M)

En el mostrador acaba de cerrarse una venta, venta_001. Junto a ella, en una pantalla, un agente de inteligencia artificial acaba de cerrar una consulta, sesion_ia_5521.

Tienes delante todos los datos. De la venta sabes quién la atendió, quién compró, qué se vendió y por cuánto. De la sesión de IA sabes sobre qué modelo corrió, cuántos tokens consumió y cuántas herramientas invocó.

Cada dato, por separado, ya tiene su casillero en alguno de los seis ejes que construimos en los capítulos anteriores.

Y aun así, míralos: son un montón de fichas sueltas sobre el mostrador.

Nada dice todavía que la venta sea del vendedor 17, ni que los 49,90 dólares sean de esa venta y no de la caja de al lado.

Ese es el agujero que cierra este capítulo.

Hemos llenado el universo de valores (personas, objetos, lugares, instantes, números, clases), y los valores por sí solos no se conocen entre ellos.

Faltan los cables: los enlaces que le dicen a la máquina qué tiene que ver cada cosa con cada cosa.

En lógica y en programación se llaman predicados. En nuestro modelo viven en el séptimo eje, el que responde a ¿cómo?

Pero antes de darlo por cerrado, hay una pregunta que parece ingenua y resulta honda: en el fondo de una base de datos, ¿qué diferencia real hay entre una propiedad y una relación?

La respuesta es que son el mismo cable, y que lo único que las separa es cuántos valores admiten.

Esa será nuestra decisión D2, y ahorra miles de horas de programación inútil.

Una distinción que parece de sentido común

Calentemos motores con cinco datos sueltos, repartidos entre la venta del mostrador y la sesión del agente de IA:

1.  venta_001  tiene de monto         49.90 (USD)
2.  venta_001  se cerró a las         16:32
3.  venta_001  la atendió            vendedor_17
4.  sesion_ia_5521  consumió de entrada  4180 (tokens)
5.  sesion_ia_5521  usó la herramienta   busqueda_web, consulta_grafo

Pídele a un programador novato que reparta estos cinco enlaces en dos montones: propiedades (lo que la cosa tiene) y relaciones (con qué otra cosa se ata).

Lo hará sin titubear. El monto y los tokens son propiedades, dirá: cifras que describen el objeto por dentro.

La atendió y usó la herramienta son relaciones, porque enganchan el sujeto con otra entidad.

La intuición es limpia: propiedad hacia dentro, relación hacia fuera.

Suena impecable. Pero basta someterla a un poco de presión arquitectónica para verla desmoronarse:

• Decimos que «la atendió vendedor_17» es una relación externa. ¿Y si diseñamos la tabla con un campo interno vendedor_responsable cuyo valor es el vendedor 17? Bajo esa óptica, se vuelve una propiedad.
• Decimos que «el monto es 49,90 dólares» es una propiedad interna. Pero, matemáticamente, podemos leerlo como que la venta «está conectada» con el número 49.90, que vive con derechos propios en el eje N. Bajo esa óptica, se vuelve una relación externa.
• Decimos que «se cerró a las 16:32» es casi un sello de tiempo, una propiedad. Pero 16:32 es un instante que habita el eje T: la venta, en realidad, se relaciona con un punto del tiempo.

Mira esos cinco enlaces con frialdad y aflora una verdad incómoda: la diferencia entre propiedad y relación no existe en el mundo material.

Es una diferencia gramatical, sobre cómo redactamos las frases los humanos. A veces usamos verbos de tener («tiene un monto de 49,90») y a veces verbos de relación («la atendió el vendedor 17»).

Para el disco que guarda el dato, la estructura es idéntica: un sujeto, un cable y un destino.

La frontera entre tener un atributo y estar relacionado con algo no la dibuja la realidad: la dibuja la gramática. La base de datos nunca la vio. El punto de partida de D2

Esa observación es el germen de la regla D2. Pero antes de formalizarla, miremos la «estructura técnica idéntica» que comparten todos los cables.

La anatomía del cable: la signatura tipada

Todo enlace de nuestro modelo (lo llames propiedad o relación) obedece a una misma forma de tres partes:

Hasta aquí, nada que no tenga cualquier grafo.

El truco está en que el predicado no es un texto ciego. Viene de fábrica con una etiqueta, como la de un enchufe, que le dice a la máquina de qué eje tiene que venir el sujeto y a qué eje tiene que ir el objeto.

Esa etiqueta se llama signatura, y tiene esta forma:

Vista así, cada cable es una pequeña función tipada. Los enlaces de nuestras cuatro escenas (venta, agente de IA, fútbol y cine) quedan con estas etiquetas de seguridad:

La signatura es lo que convierte un montón de datos sueltos en una estructura predecible y comprobable.

Si alguien se equivoca e intenta guardar (venta_001, monto, "color rojo"), el sistema lo bloquea solo. La signatura de monto exige que el destino esté en el eje N, el de los números, y «color rojo» es un texto.

Esa capacidad de rechazar el absurdo en el momento en que entra el dato separa a WQuestions del caos de los grafos libres, donde cualquiera puede conectar una venta con un color usando el verbo «monto» sin que nada chille.

La diferencia verdadera: ¿funcional o múltiple?

Si la forma del cable es siempre la misma (sujeto, cable, objeto), ¿queda alguna razón técnica para distinguir entre «propiedades» y «relaciones»? Sí, una sola, y es estrictamente matemática: la cardinalidad.

Vuelve a mirar las signaturas de la figura. Cuatro de ellas admiten un solo destino por sujeto.

Una venta tiene un monto. Se cerró en un instante. La atendió un vendedor. Una sesión de IA consumió un número exacto de tokens.

El quinto cable, uso_herramienta, rompe la regla.

Un mismo agente pudo invocar la búsqueda web y la consulta al grafo y una calculadora, todo en la misma sesión. Un sujeto, varios destinos, y todos correctos.

Esa es la única diferencia estructural, en la base de datos, entre lo que solemos llamar «propiedades» y «relaciones»:

Pero los dos son el mismo tipo de cable y viven en el mismo eje.

Cuántos valores admite un cable no es un eje aparte. Es un dato del propio cable, escrito en su signatura.

Y lo único que ese dato le dice a la base es qué hacer cuando llegue un valor nuevo: pisar el anterior, o sumarse a él.

Por eso conviene conservar las dos marcas, P y M, aunque en el fondo sean la misma familia. Cada una gobierna una forma distinta de actualizar.

Y aquí viene el alivio para quien programa: al motor de consulta le da igual.

Preguntes «¿qué monto tiene venta_001?» o «¿con qué herramientas trabajó sesion_ia_5521?», la máquina ejecuta el mismo código. Solo que en un caso devuelve un valor y en el otro, una lista.

Un cable conecta dos cosas. Pero ese mismo cable, repetido sobre miles de sujetos, se recorre de punta a punta.

«¿Qué sesiones usaron la búsqueda web?» no se responde mirando a sesion_ia_5521. Se responde recorriendo el cable uso_herramienta hacia atrás, desde todas las sesiones que lo tienen.

La regla de diseño D2: la unificación algebraica

Esta revelación nos permite enunciar de manera formal una de las decisiones de diseño más elegantes del modelo. Reúne todo lo anterior en una sola frase:

Conviene aclarar cómo se llevan D2 y la doble marca P / M, porque a primera vista parecen tirar en sentidos opuestos.

En el fondo, todo es lo mismo: un predicado con la forma predicado : eje_sujeto → eje_objeto. No hay dos familias de cables ni dos lenguajes.

En la práctica, conviene seguir distinguiendo dos modos, P para los de un solo valor y M para los de varios.

Porque la cardinalidad no es un adorno: manda sobre la actualización, y un sistema que la ignore no sabría si un dato nuevo pisa al viejo o se le suma.

P y M no son dos ejes. Son la misma coordenada vista por su único rasgo que de verdad cambia el comportamiento del motor.

Entender D2 es entender que el abismo que se enseña en la universidad, donde los atributos son «columnas de una tabla» y los vínculos son «tablas conectadas», es una ilusión de pizarra.

Una complicación heredada de la programación tradicional.

Por debajo, todo es un sujeto, un cable con su tipo y un destino. Y esa simplicidad es la gasolina que hace volar al modelo.

La forma: qué voltaje es aceptable

La signatura tiene un límite que conviene ver ahora, mientras la imagen del enchufe está fresca.

Comprueba que el cable enchufe donde debe: que el sujeto venga del eje correcto y el valor vaya al eje correcto. No dice nada sobre el valor mismo.

Una disponibilidad del 140 % encaja en M(O→N) igual de bien que una del 94 %, porque las dos son números, y el número es lo único que la signatura mira.

La signatura dice qué enchufe encaja. La forma dice qué voltaje es aceptable.Las dos comprobaciones

La forma es una entidad más del grafo, como todo lo demás. Declara a qué rol apunta, qué comprueba y con qué cotas, y el evaluador la lee de ahí. Cuatro tipos cubren casi todo lo que un dominio quiere exigir.

(forma_disponibilidad, tipo_forma,   rango)
(forma_disponibilidad, rol_objetivo, "disponibilidad")
(forma_disponibilidad, minimo,       0 K:Porcentaje)
(forma_disponibilidad, maximo,       100 K:Porcentaje)

Lo que el evaluador no hace, y por qué

Aquí está la decisión que más cuesta aceptar y más se agradece después: el evaluador no rechaza nada. Encuentra la violación, la anota y deja que el hecho entre. Suena a permisividad y es lo contrario.

Un almacén que rechaza la escritura te obliga a decidir de antemano qué es imposible, y esa decisión envejece mal.

La excepción que nadie previó llega igual. Y el sistema que la rechaza la empuja a un correo, a una hoja aparte, a la memoria de alguien.

Peor todavía en un sector regulado: una operación sospechosa que se rechaza al escribir es una operación que después nadie puede auditar.

Así que la violación se registra como un hecho más. Tiene sujeto, tiene la forma que la delata, tiene su momento y tiene un estado con fecha.

Se cuenta con una consulta corriente, se ordena por antigüedad, y se cierra sola cuando el hecho que la causaba se corrige. Sin que nadie borre nada.

(violacion_0001, instancia_de,     violacion_de_forma)
(violacion_0001, sobre,            transferencia_002)
(violacion_0001, justificado_por,  forma_limite_operacion)
(violacion_0001, detalle,          "25000 USD por encima del máximo 10000 USD")
(violacion_0001, estado,           abierta)     [12-jun .. ∞)
(violacion_0001, estado,           resuelta)    [14-jun .. ∞)   # se corrigió

La cardinalidad que acabas de ver hace aquí un trabajo silencioso.

Cuando el cable admite un solo valor, el motor juzga el vigente, así que corregir un dato apaga la violación en vez de acumular una segunda. Cuando admite varios, los mira todos.

La misma distinción que servía para saber si un cable borra y reemplaza decide también qué se comprueba.

Cuatro cosas que gana una empresa al unificar

Adoptar D2 no es una elegancia teórica: tiene cuatro consecuencias prácticas, directas y medibles en producción.

Esa última consecuencia merece subrayarse, porque es el puente hacia toda la Parte IV.

Cuando le decimos al sistema «Messi anotó el gol tras la asistencia de Di María», la máquina guarda al goleador, el evento y el asistente con la misma estructura.

Al no distinguir entre propiedades y relaciones, lee una frase humana casi como si leyera código.

Tres dominios bajo el microscopio

Para asentarlo, mira cómo se reparten los cables de un valor y los de varios en tres mundos sin relación entre sí.

Fíjate en el patrón: lo que el sentido común llama «atributos» tiende a admitir un valor; lo que son «piezas que se suman» tiende a admitir varios.

La venta del mostrador

# funcionales (P) — respuesta única, borra y reemplaza
monto          : O → N    P   # 49.90
atendida_por   : O → Q    P   # vendedor_17
comprada_por   : O → Q    P   # cliente_1042
categoria      : O → K    P   # venta

# múltiples (M) — acumulan
articulo       : O → O    M   # varios objetos en una venta
etiqueta       : O → K    M   # camiseta, promocion…

La sesión del agente de IA

# funcionales (P)
tokens_entrada : O → N    P   # 4180
tokens_salida  : O → N    P   # 920
latencia_ms    : O → N    P   # 2100
costo_usd      : O → N    P   # 0.015
modelo_usado   : O → K    P   # modelo_lumen_2026

# múltiples (M)
uso_herramienta : O → K   M   # busqueda_web, consulta_grafo…
consultó_fuente : O → O   M   # la IA pudo leer 5 documentos

El consumo exacto en dinero es uno solo (funcional); las herramientas invocadas y los documentos leídos durante la consulta pueden ser docenas (múltiples).

El partido de fútbol

# funcionales (P)
resultado    : O → K    P   # victoria_local
asistencia   : O → N    P   # 52000 espectadores

# múltiples (M)
juega        : O → Q    M   # SON SIEMPRE 2 equipos — y aun así, múltiple
gol_anotado  : O → O    M   # varios goles
tarjeta      : O → O    M   # decenas de tarjetas

Trampa de programación: la relación disfrazada de columna

Hay un error que parece inocente y se paga carísimo al crecer: modelar una relación como una columna de la tabla.

La directora serra tiene un teléfono, así que el sistema crea una columna telefono. Funciona hasta el día en que alguien tiene dos números.

Entonces empieza el parche: telefono2, telefono_alt, un campo de texto con comas, una tablita improvisada a las apuradas.

La columna había dado por hecho, sin decirlo, que el valor era único. Y el mundo no lo respeta.

El eje M evita el problema de raíz: pone la cardinalidad en la signatura del cable, no en la forma de la tabla.

telefono se declara de antemano como de un valor o de varios, y el modelo lo respeta sin rediseños. Pasar de «un teléfono» a «muchos» deja de ser una migración y se vuelve cambiar una marca.

Distinguir «tener un atributo» de «estar relacionado con algo» deja de ser una decisión rígida de esquema y pasa a ser un dato más.

Un cable especial: parte_de y la puerta a las situaciones

Antes de cerrar la Parte II hay que presentar un cable que merece trato aparte, porque será bisagra del resto del libro.

Hasta aquí hemos tratado cada hecho como un punto suelto. Pero el mundo no viene en puntos sueltos. Viene en escenas.

El gol de Messi no flota en el vacío: ocurre dentro de un partido. La escena 42 no es una isla: es una pieza de la película. El acto de cobrar la venta pertenece a la jornada de caja de toda la mañana.

Ese vínculo de pertenencia tiene su propio cable. Es un predicado múltiple, de objeto a objeto, y lo llamamos parte_de:

Lo notable de parte_de no es su forma (es un cable múltiple corriente), sino lo que permite.

Cuando muchos hechos pequeños cuelgan de un mismo hecho contenedor, ese contenedor deja de ser un objeto cualquiera y se convierte en una situación: un marco amplio dentro del cual ocurren eventos conectados.

El partido entero. El rodaje completo. La jornada de caja.

Es la entidad compuesta que asomó al hablar del eje qué, y que ahora tiene el cable que la ensambla.

Por eso parte_de crea piezas que existen en función del todo. Y por eso es el puente entre lo que hemos hecho (hechos sueltos) y lo que viene en la Parte III: las situaciones, los contextos y la agencia.

Dejamos puesto el cable. En la sala de máquinas lo veremos sostener escenas enteras.

Cierre de la Parte II: el tablero está listo

Con la formalización del eje cómo, terminamos de armar el andamiaje del modelo. El inventario de las siete coordenadas queda oficialmente cerrado:

Q quién: las personas y agentes que actúan.
O qué: los objetos físicos, los eventos y las situaciones.
L dónde: las locaciones.
T cuándo: el flujo del tiempo.

N cuánto: los números y las magnitudes.
K cuál: los conceptos y las categorías: tipos, unidades, estados, vocabularios.
M cómo: los cables o predicados que conectan los ejes de valor, funcionales (P) o múltiples (M).

Seis cajas gigantes para guardar cosas, entrelazadas por una red de cables.

Cualquier suceso, registro bancario o informe médico del mundo cabe, sin deformarse, dentro de esta rejilla de siete ejes.

Es la promesa con la que abrió el libro: el universo de los datos se puede mapear usando solo las preguntas de siempre.

Conviene dejar puesto un nombre que hará falta más adelante.

Al conjunto de esas seis cajas (Q, O, L, T, N, K juntas) lo llamamos V, el universo de valores.

Lo nombramos desde ya porque, cuando un cable no se ate a un eje concreto y admita cualquiera de los seis, diremos que su origen o su destino es V. Lo veremos con rigor en el capítulo 13.

Pero tener el plano del motor no es lo mismo que encenderlo.

Hasta aquí vimos los ejes por separado, como piezas sueltas de un reloj. Antes de armarlo, conviene cerrar una pregunta que dejamos abierta en el primer capítulo: ¿por qué estas preguntas y no otras?

Es una pausa breve, el próximo capítulo. Después entramos en la parte operativa: el modelo en movimiento, con todos los ejes trabajando juntos sobre casos reales.