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.
//
Busca en todas las páginas de la documentación
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Versiones de Stack: Esta página fue escrita para PostgreSQL 18.4 (estable 18, mantenimiento 17).
Revisado por Chris St. John·Última actualización: 15 jul 2026