Fundamentos del Modelado de Datos
El modelado de datos es la disciplina de decidir qué debe representar una base de datos antes de decidir cómo PostgreSQL debe almacenarla.
Cada tabla, clave externa y restricción en un esquema de producción es una respuesta física a una pregunta que se formuló por primera vez en términos de negocio, como "¿qué es un pedido?" o "¿puede existir un cliente sin cuenta?".
Esta página presenta el modelo mental sobre el que se construye el resto de esta sección: las tres capas del modelado, cómo se transfieren entre sí y dónde entran en juego las mecánicas específicas de PostgreSQL.
Resumen
- El modelado de datos mueve un dominio a través de tres capas de compromiso creciente: conceptual (qué existe), lógico (cómo se relaciona) y físico (cómo lo almacena PostgreSQL).
- Por qué Importa: Los esquemas diseñados con un enfoque físico tienden a codificar detalles accidentales de implementación como si fueran reglas de negocio, haciendo que los cambios posteriores sean costosos.
- Conceptos Clave: modelo conceptual, modelo lógico, modelo físico, entidad, atributo, evolución del esquema.
- Cuándo Usar: Cualquier diseño de esquema nuevo (greenfield), cualquier revisión de la intención de un esquema existente y cualquier discusión sobre si la forma de una tabla refleja el dominio o solo los atajos de una migración pasada.
- Limitaciones / Compensaciones: Un proceso estricto de tres capas añade tiempo de diseño inicial que un prototipo pequeño puede no necesitar.
- Temas Relacionados: modelado entidad-relación, normalización, evolución del esquema, límites de esquema impulsados por el dominio.
Fundamentos
Un modelo conceptual nombra las cosas que importan a un negocio, independientemente de cualquier tecnología de base de datos.
Identifica entidades como Cliente, Pedido y Producto, y las relaciones entre ellas, utilizando el vocabulario que el propio negocio utiliza.
Un modelo lógico toma ese esquema conceptual y añade estructura: se asignan atributos a las entidades, las relaciones obtienen cardinalidad (uno a muchos, muchos a muchos) y se define la identidad.
El modelo lógico sigue siendo tecnológicamente agnóstico en principio, aunque en la práctica la mayoría de los equipos piensan en términos relacionales una vez que llegan a esta etapa.
Un modelo físico es donde entra PostgreSQL: las entidades se convierten en sentencias CREATE TABLE, los atributos en columnas tipadas y las relaciones en claves externas, índices y restricciones.
Aquí es también donde residen las decisiones específicas de PostgreSQL, como la elección de bigint GENERATED ALWAYS AS IDENTITY para claves sustitutas o timestamptz en lugar de timestamp without time zone.
Las tres capas no son tres documentos separados que la mayoría de los equipos mantienen para siempre; son tres preguntas separadas que se hacen, aproximadamente en orden, cada vez que un esquema cambia.
Saltarse directamente a la capa física es el modo de fallo más común, porque se siente productivo escribir DDL inmediatamente.
El coste aparece más tarde, cuando una columna añadida bajo presión de plazos resulta codificar una suposición con la que nadie estuvo realmente de acuerdo.
Mecánicas e Interacciones
La transferencia entre capas es donde se introducen la mayoría de los defectos de modelado, no dentro de una sola capa.
Una entidad conceptual como "Pedido" podría mapearse a una tabla, o podría mapearse a varias tablas si el modelo lógico decide que un pedido tiene un ciclo de vida distinto al de sus artículos de línea.
Esa decisión, una tabla frente a varias, es una elección de la capa lógica, y debe tomarse preguntando qué cambia de forma independiente, no preguntando qué es conveniente para hacer JOIN.
El espacio de nombres de esquemas de PostgreSQL (CREATE SCHEMA) proporciona a la capa física una herramienta para expresar límites conceptuales sin pagar por bases de datos separadas.
-- Límite conceptual expresado físicamente como un esquema, no como una nueva base de datos
CREATE SCHEMA billing;
CREATE SCHEMA catalog;
CREATE TABLE billing.invoices (
invoice_id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
amount numeric(12, 2) NOT NULL
);Esto permite que una única base de datos física siga comunicando "estas tablas pertenecen a diferentes partes del dominio" a través de nombres y permisos, en lugar de solo a través de la memoria del desarrollador.
Las restricciones son el otro lugar donde las capas interactúan directamente entre sí.
Una restricción CHECK o una columna NOT NULL es un mecanismo físico que aplica una regla que se declaró en la capa conceptual, como "un pedido no puede marcarse como enviado sin una fecha de envío".
Cuando una restricción en el esquema no se mapea de nuevo a una regla de negocio declarada, eso suele ser una señal de que la capa física se ha alejado del modelo que se suponía que representaba.
Por el contrario, una regla de negocio que existe solo en el código de la aplicación y no en ninguna restricción es una regla que la base de datos no puede proteger, y una migración futura o una consulta ad hoc pueden violarla silenciosamente.
Consideraciones Avanzadas y Aplicaciones
Las decisiones de modelado rara vez se toman una vez y se dejan en paz, porque el dominio en sí cambia a medida que un producto crece.
La evolución del esquema es la práctica de mover un modelo físico hacia adelante sin romper el contrato lógico del que dependen otros servicios y código.
El patrón al que la mayoría de los equipos recurren es expandir-contraer: añadir nuevas columnas o tablas junto a las antiguas, migrar lectores y escritores gradualmente, y luego eliminar la forma antigua una vez que nada dependa de ella.
A mayor escala, los equipos también tienen que decidir dónde un límite de dominio se convierte en un límite de base de datos, no solo en un límite de esquema.
Los límites de esquema impulsados por el dominio aplican el mismo pensamiento de entidad-conceptual a una pregunta más difícil: ¿debería este contexto delimitado tener su propio esquema o su propia base de datos por completo?
Esa decisión intercambia consistencia y conveniencia de JOIN (base de datos única) contra aislamiento de radio de explosión y desplegabilidad independiente (bases de datos separadas), y merece su propio registro explícito en lugar de una acumulación implícita de tablas.
| Enfoque | Fortaleza | Debilidad | Mejor Ajuste |
|---|---|---|---|
| Modelado conceptual primero | El esquema refleja reglas de negocio reales, no historial de migración | Más lento para empezar; requiere conversaciones de dominio por adelantado | Dominios nuevos, o dominios con propiedad poco clara |
| Físico primero (DDL inmediatamente) | Rápido para prototipar | El esquema codifica decisiones accidentales como si fueran reglas | Solo prototipos desechables reales |
| Base de datos única, múltiples esquemas | Una transacción, uniones fáciles entre entidades | Despliegues acoplados y radio de explosión entre contextos delimitados | Dominios relacionados con consultas frecuentes entre entidades |
| Base de datos por contexto delimitado | Fuerte aislamiento, escalado y despliegues independientes | Las consultas entre contextos requieren APIs o replicación, no uniones | Dominios con diferente propiedad, cumplimiento o necesidades de escalado |
Las convenciones de nomenclatura merecen la misma deliberación que la forma de las tablas, porque son la interfaz que lee cada ingeniero futuro antes de leer cualquier código.
Una regla consistente para claves primarias, claves externas y tablas de unión convierte las rutas de JOIN en algo que un lector puede predecir en lugar de algo que tiene que buscar cada vez.
Conceptos Erróneos Comunes
- "El ERD es documentación, el esquema es el diseño real." El ERD (o su equivalente conceptual) es el diseño; el esquema es una posible representación física del mismo, y tratar el diagrama como una ocurrencia tardía es cómo los esquemas se desvían del dominio que pretenden representar.
- "La normalización y el modelado físico son el mismo paso." La normalización es una disciplina de la capa lógica sobre la eliminación de redundancia y anomalías de actualización; el modelado físico trata sobre cómo PostgreSQL almacena el resultado normalizado, y las dos preguntas pueden tener respuestas diferentes.
- "Un buen esquema nunca cambia." Cada esquema de un producto vivo cambia, y el objetivo de la disciplina de modelado es hacer que ese cambio sea barato y seguro, no evitar que ocurra.
- "Las claves sustitutas son siempre la opción correcta." Las claves sustitutas son la opción predeterminada sensata para tablas OLTP, pero un negocio ya tiene una clave natural globalmente única (un código de moneda ISO, por ejemplo) y esa clave natural puede ser la clave primaria sin daño.
- "El modelado es una fase única y preliminar." El modelado es una actividad recurrente que ocurre cada vez que aparece una nueva entidad, relación o regla de negocio, no una fase que termina cuando se envía la primera migración.
Preguntas Frecuentes
¿Cuál es la diferencia entre un modelo de datos conceptual, lógico y físico?
- Un modelo conceptual nombra entidades y relaciones en lenguaje de negocio, sin involucrar tecnología de base de datos.
- Un modelo lógico añade atributos, cardinalidad e identidad, mientras se mantiene neutral en cuanto a tecnología en principio.
- Un modelo físico es la representación en PostgreSQL: tablas, columnas tipadas, claves externas, índices y restricciones.
¿Necesito producir tres documentos separados para cada cambio de esquema?
No, las tres capas son tres preguntas a considerar, no tres entregables para mantener para siempre.
Para un cambio pequeño y bien entendido, las preguntas conceptuales y lógicas se pueden responder en una breve conversación antes de escribir el DDL.
¿Por qué empezar con DDL causa problemas más tarde?
Escribir CREATE TABLE primero tiende a codificar lo que era conveniente en ese momento como si fuera una regla de negocio.
Los lectores posteriores no pueden distinguir qué columnas representan decisiones deliberadas y cuáles son accidentes de una migración apresurada.
¿Cómo se relacionan los esquemas de PostgreSQL con el modelado conceptual?
Un espacio de nombres CREATE SCHEMA de PostgreSQL es una herramienta de capa física para expresar un límite conceptual, como facturación frente a catálogo, sin el coste de bases de datos separadas.
Es una forma ligera de hacer visibles los contextos delimitados en el modelo físico.
¿Es la normalización parte del modelado de datos o un tema separado?
La normalización es una técnica de capa lógica que este mismo proceso de modelado utiliza para evitar la colocación de atributos redundantes y propensos a contradicciones.
Se cubre en su propia página porque tiene suficiente profundidad como para merecerla, pero no es una disciplina separada del modelado de datos.
¿Cómo sé cuándo una regla de negocio debe convertirse en una restricción de base de datos?
Si violar la regla produciría datos que son objetivamente incorrectos, no solo inusuales, pertenece a una restricción.
Si la regla es una preferencia suave que legítimamente cambia según el contexto, generalmente pertenece a la lógica de la aplicación en su lugar.
¿Qué significa la evolución del esquema y cómo se relaciona con el modelado?
La evolución del esquema es la práctica de cambiar un modelo físico con el tiempo sin romper el contrato lógico del que depende otro código.
Es el lado continuo e iterativo del mismo proceso de modelado descrito en esta página.
¿Cuándo debe un contexto delimitado tener su propia base de datos en lugar de su propio esquema?
Cuando el contexto tiene diferente propiedad, diferentes requisitos de cumplimiento o necesidades de escalado que entran en conflicto con sus vecinos, una base de datos separada proporciona un aislamiento más fuerte que un esquema.
Un esquema es suficiente cuando los contextos están relacionados y se consultan frecuentemente juntos.
¿Son las claves sustitutas siempre mejores que las claves naturales?
Las claves sustitutas son la opción predeterminada más segura porque son estables y estrechas, pero una clave natural genuinamente global e inmutable puede servir como clave primaria sin las anomalías que las claves sustitutas existen para evitar.
La decisión debe seguir de si la clave natural puede cambiar o colisionar alguna vez, no por hábito.
¿Qué significa que un esquema "se desvíe" de su modelo?
La desviación ocurre cuando los cambios físicos (una columna añadida bajo presión de plazos, una restricción eliminada silenciosamente) se acumulan sin que nadie actualice la comprensión conceptual o lógica del dominio.
El síntoma es un esquema que nadie puede explicar completamente ya.
¿Por qué las convenciones de nomenclatura importan tanto para el modelado?
La nomenclatura consistente convierte cada futura ruta JOIN en algo predecible en lugar de algo que requiere buscar primero el esquema.
Es una forma barata y duradera de mantener legible el modelo físico a medida que un equipo crece.
¿Cómo se relaciona esta página con las otras páginas de esta sección?
Esta página proporciona el vocabulario y el proceso que el modelado entidad-relación, la evolución del esquema y los límites de esquema impulsados por el dominio profundizan.
Lee esto primero si la relación entre esas páginas no está clara.
Relacionado
- Conceptos Básicos de Modelado de Datos - ejemplos prácticos del flujo conceptual a físico
- Modelado Entidad-Relación - cardinalidad, opcionalidad y nomenclatura
- Estrategia de Evolución del Esquema - migraciones de expandir-contraer a lo largo del tiempo
- Límites de Esquema Impulsados por el Dominio - agrupar entidades por contexto delimitado
- ADR: Base de Datos Única vs. Base de Datos por Servicio - la decisión del límite de la base de datos
- Conceptos Básicos de Normalización - la disciplina de la capa lógica detrás de la colocación de atributos
Versiones de Stack: Esta página fue escrita para PostgreSQL 18.4 (estable 18, mantenimiento 17).