Diseño de esquema de base de datos que todo tu equipo pueda leer

Un diagrama de esquema es uno de los documentos más útiles que puede tener un equipo de backend, y uno de los primeros en quedarse obsoleto. Alguien lo dibuja antes del lanzamiento, ocupa un lugar de honor en la wiki y, veinte migraciones después, describe una base de datos que ya no existe.

El otro modo de fallo es peor: el diagrama sigue técnicamente actualizado pero se convierte en un espagueti. Las líneas de clave foránea atraviesan tres tablas en línea recta para llegar a una cuarta, la cardinalidad se adivina en lugar de mostrarse, y nadie sabe a simple vista si un usuario tiene muchos pedidos o exactamente uno. LetDraw está hecho para que los diagramas de esquema sean legibles y correctos a la vez, de modo que valga la pena conservarlos.

Tablas que saben que son tablas

Una tabla ER en LetDraw no es una caja con texto escrito dentro. Es un elemento de tabla real con columnas tipadas y marcadores de clave, así que la estructura forma parte de la forma, no es un dibujo que tengas que mantener sincronizado a mano.

• Columnas tipadas. Cada fila lleva un nombre y un tipo, así que id bigint se lee como esquema, no como una etiqueta.
• Marcadores de clave. Las claves primarias y foráneas se marcan en la columna, así que el lector ve por dónde se unen las tablas sin tener que buscarlo.
• Editable en el sitio. Añade una columna, cambia un tipo o renombra un campo, y la maquetación se adapta. Estás editando un modelo, no moviendo rectángulos.

Como las columnas están estructuradas, las relaciones entre tablas se pueden dibujar correctamente en lugar de forma decorativa. Ahí es donde entra la cardinalidad.

Cardinalidad de pata de gallo, de forma nativa

Una relación entre dos tablas solo es útil si te dice la forma de los datos. Un usuario con muchos pedidos es un mundo distinto de un usuario con un solo pedido, y un diagrama que confunde ambos es peor que no tener diagrama. LetDraw dibuja la notación de pata de gallo de forma nativa sobre la línea de la relación, así que uno a muchos, uno a uno y muchos a muchos se leen directamente en el conector.

Una línea de relación debería decirte la forma de los datos, no solo que dos tablas se tocan.

Cuando modelas código en lugar de tablas, el mismo motor de conectores dibuja diagramas de clases UML como es debido, con puntas de flecha huecas para la herencia y las demás puntas estándar. No tienes que dibujar un triángulo a mano y esperar que caiga en el lugar correcto; la notación es nativa, así que una flecha de herencia parece herencia para cualquiera que lea UML.

Claves foráneas que rodean tus tablas en el diagrama entidad relación

Este es el detalle que decide si un diagrama de esquema sobrevive a partir de diez tablas. A medida que crece un esquema, el enfoque ingenuo traza una línea recta de una clave a otra, y esas líneas enseguida atraviesan todas las tablas que hay en medio. El dibujo se convierte en un nudo.

LetDraw usa enrutamiento inteligente en los conectores de clave foránea, así que una línea de relación trata tus tablas como obstáculos y las rodea. La unión entre orders.user_id y users.id sigue siendo visible aunque haya una docena de tablas entre ellas. El diagrama se vuelve más denso a medida que crece tu esquema, pero no se vuelve ilegible, que es justamente el sentido de dibujarlo.

Empieza por el SQL que ya escribiste

No tienes que colocar ni una sola tabla a mano. Abre el diálogo Generar desde código, pega tus sentencias CREATE TABLE y LetDraw construye el diagrama ER por ti: tablas con columnas tipadas, claves marcadas y relaciones trazadas a partir de las claves foráneas. Este es el DDL que hay detrás de la figura anterior.

CREATE TABLE users (
  id          bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  email       text NOT NULL UNIQUE,
  created_at  timestamptz NOT NULL DEFAULT now()
);

CREATE TABLE orders (
  id          bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  user_id     bigint NOT NULL REFERENCES users (id),
  total_cents integer NOT NULL,
  status      text NOT NULL DEFAULT 'pending'
);
-- user_id REFERENCES users(id) becomes the crow's-foot relationship

Esa cláusula REFERENCES es lo que lee LetDraw para colocar la línea de uno a muchos, con la pata de gallo en el lado de orders. A partir de ahí es un dibujo normal, así que lo pules y lo publicas:

• Reorganiza tablas, agrupa las que pertenecen a un mismo contexto delimitado y anota las uniones complicadas
• Añade tablas que el DDL aún no incluía y dibuja sus relaciones a mano con las mismas puntas de pata de gallo
• Exporta a PNG, SVG o PDF para un documento de diseño, o convierte el diagrama de nuevo en Mermaid o D2 cuando lo quieras otra vez como código

Por qué vale la pena un esquema legible

Un diagrama de esquema es un contrato sobre cómo encajan tus datos, y solo compensa si la gente confía en él. Las columnas tipadas y las claves marcadas lo hacen preciso; la cardinalidad de pata de gallo lo hace honesto sobre la forma de los datos; el enrutamiento inteligente lo mantiene legible a medida que crece. Genera el primer borrador a partir del SQL que ya mantienes y el coste de tenerlo al día cae casi a cero, que es la única forma de que un diagrama así siga vivo.

Pega tus sentencias CREATE TABLE y mira cómo el diagrama ER se ensambla solo, claves incluidas.