Cómo: los predicados (P y M)

En el mostrador acaba de cerrarse una venta, venta_001, y junto a ella una pantalla donde un agente de inteligencia artificial acaba de cerrar una consulta, sesion_ia_5521. Tienes delante todos los datos: sabes que la operación la atendió el vendedor vendedor_17, que el comprador fue cliente_1042, que lo vendido fue una camiseta camiseta_88 y que el monto fue 49,90 dólares; sabes que la sesión de IA corrió sobre el modelo modelo_lumen_2026, que consumió 4180 tokens de entrada y que invocó dos herramientas. Cada dato, por separado, ya tiene su casillero en alguno de los seis ejes que construimos en los capítulos anteriores. Y, sin embargo, si te detienes a mirarlos, 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 pertenezcan a esa venta y no a la 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), pero los valores, por sí solos, no se conocen entre ellos. Faltan los enlaces: los «cables» lógicos que le dicen a la máquina qué tiene que ver cada cosa con cada cosa. En lógica y en programación esos enlaces se llaman predicados, y en nuestro modelo viven en el séptimo eje, el que responde a la pregunta ¿cómo?: cómo se conecta cada cosa con cada otra.

Pero antes de declararlo cerrado, el capítulo nos obliga a una pregunta técnica que parece ingenua y resulta profunda: en el fondo de una base de datos, ¿qué diferencia real hay entre una propiedad y una relación? La respuesta (que ambas son el mismo tipo de cable y que lo único que las separa es su cardinalidad) se volverá nuestra decisión de diseño D2, y nos ahorrará miles de horas de programación innecesaria.

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 que empieza que divida estos cinco enlaces en dos montones: propiedades (atributos propios de la cosa) y relaciones (vínculos con otra cosa externa). Lo hará sin titubear. El monto y los tokens de entrada son, dirá, claramente propiedades: cifras que describen el objeto por dentro. En cambio la atendió y usó la herramienta son relaciones, porque atan el sujeto a otra entidad separada (un vendedor, una herramienta de software). La intuición es limpia: propiedad = atributo interno; relación = puente hacia afuera.

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.

Si miramos estos cinco enlaces con frialdad informática, aflora una verdad incómoda: la diferencia entre propiedad y relación no existe en la realidad material. Es una diferencia gramatical, sobre cómo los humanos redactamos las oraciones. A veces usamos verbos posesivos («tiene un monto de 49,90») y a veces verbos relacionales («la atendió el vendedor 17»). Para el disco que guarda el dato, la estructura técnica es idéntica: hay un sujeto de partida, un cable conector y un objeto de 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 (y la diferencia de seguridad frente a un grafo libre) está en que el predicado no es un texto ciego. Viene de fábrica con una signatura tipada: una etiqueta, como la de un enchufe, que le dice a la máquina de qué eje tiene que venir obligatoriamente el sujeto y a qué eje debe ir a parar el objeto. La forma de esa etiqueta es:

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 la magia que convierte un montón de datos desordenados en una estructura predecible y validable. Si un programador comete un error y trata de guardar (venta_001, monto, "color rojo"), el sistema lo bloquea solo: la signatura de monto exige que el destino esté en el eje N (los números), y «color rojo» es un texto. Esa capacidad de rechazar el absurdo desde el instante en que entra el dato es lo que separa la arquitectura sólida de 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 se comportan como lo que en matemáticas llamamos funciones: dado un sujeto concreto, el cable solo puede conducir a un único destino en ese instante. 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 de entrada.

El quinto cable (uso_herramienta) rompe la regla. Un mismo agente de IA pudo invocar la búsqueda web y la consulta al grafo y una calculadora, todo en la misma sesión. Un solo sujeto dispara varios cables hacia múltiples objetos a la vez, y todos son correctos.

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

Pero ambos son el mismo tipo de cable y viven en el mismo eje. La cardinalidad no es un eje aparte: es un atributo de cada cable, escrito en su signatura. Y lo único que ese atributo le dice a la base de datos es cómo comportarse cuando el dato se actualice. Aquí está la razón de fondo por la que conviene conservar las dos marcas (P y M) aunque algebraicamente sean la misma familia de funciones tipadas: cada una gobierna una lógica de actualización distinta.

Y aquí viene el alivio para quien programa: el motor de consulta no hace la diferencia. Da igual que preguntes «¿qué monto tiene venta_001?» o «¿con qué herramientas trabajó sesion_ia_5521?»: la máquina ejecuta exactamente el mismo código de búsqueda. Solo que en el primer caso te devuelve una respuesta y en el segundo, una lista.

Un cable conecta dos cosas, sí; pero el mismo cable, repetido sobre miles de sujetos, es una relación recorrible 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 precisar la relación entre D2 y la doble marca P / M, porque a primera vista parecen tirar en sentidos opuestos. Algebraicamente, todo es un mismo objeto: un predicado tipado con la forma predicado : eje_sujeto → eje_objeto. No hay dos familias de cables ni dos lenguajes. Operativamente, conviene seguir distinguiendo dos modos (P para los funcionales, M para los múltiples) porque la cardinalidad no es un adorno: gobierna la lógica de 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, pues, dos ejes: son la misma coordenada vista bajo su único atributo que de verdad cambia el comportamiento del motor.

Entender D2 significa comprender que el abismo técnico que se enseña en la universidad (donde nos obligan a tratar los atributos internos como «columnas en una tabla» y los vínculos externos como «tablas conectadas o joins») es, en realidad, una ilusión pedagógica. Una complicación heredada de la programación tradicional. A nivel matemático, todo es un sujeto, un cable tipado y un destino. Y esa simplicidad es la gasolina que hace volar al modelo.

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 registra al goleador, el evento y el asistente usando la misma estructura uniforme. Al no distinguir entre propiedades y relaciones, lee frases humanas casi como si leyera código de máquina.

Tres dominios bajo el microscopio

Para asentar el concepto, veamos cómo se reparten los cables funcionales y los múltiples al diseñar tres mundos sin relación entre sí. Fíjate en el patrón: lo que el sentido común considera «atributos estáticos» tiende a ser funcional; lo que son «piezas que se suman» tiende a ser múltiple.

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 escalar: 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 asumido, sin decirlo, una cardinalidad (un solo valor) que el mundo no respeta.

El eje M evita el problema de raíz: pone la cardinalidad en la signatura del predicado, no en la forma de la tabla. telefono se declara de antemano como funcional (un valor) o múltiple (varios), y el modelo lo respeta sin rediseños. Pasar de «un teléfono» a «muchos» deja de ser una migración de tabla y se vuelve cambiar una marca en M (de P a M). 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 con su cardinalidad escrita en la firma.

Un cable especial: parte_de y la puerta a las situaciones

Antes de cerrar la Parte II hace falta presentar un predicado que merece trato aparte, porque será una 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 pelicula_marea—. 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 habilita. Cuando muchos hechos pequeños cuelgan, por este predicado, 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 interconectados. El partido entero, el rodaje completo, la jornada de caja. Es la entidad compuesta que vimos asomar al hablar del eje qué, y que ahora tiene el cable que la ensambla.

Por eso parte_de es un subobjeto contingente: la pieza existe en función del todo. Y por eso este predicado es el puente entre lo que hemos hecho hasta ahora (hechos atómicos, 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:

Seis cajas gigantes para guardar «cosas», entrelazadas por una red de cables estructurales (el eje cómo). Cualquier fenómeno, suceso, registro bancario o reporte médico que ocurra en el mundo cabe, sin distorsiones, dentro de esta matriz de siete ejes. Cumplimos la promesa con la que abrió el libro: el universo de los datos puede mapearse usando únicamente las preguntas fundamentales del cerebro humano.

Conviene dejar nombrada una abreviatura que hará falta más adelante. Al conjunto de esas seis cajas de valor (Q, O, L, T, N, K tomadas juntas) lo llamamos V, el universo de valores. Lo nombramos desde ya porque cuando un predicado no se ate a un eje concreto, sino que admita cualquiera de los seis, diremos que su dominio o su rango es V. Lo veremos al definir las signaturas con todo rigor, en el Capítulo 13.

Pero tener el plano del motor en la mano no es lo mismo que encenderlo. Hasta aquí vimos los ejes por separado, como piezas sueltas de un reloj. Antes de armarlo y verlo girar, 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) y enseguida entramos en la etapa operativa: el modelo en movimiento, observando cómo interactúan todos los ejes juntos para estructurar escenarios reales de altísima complejidad.