System Design
Explica cómo representar entidades, atributos, claves, relaciones, cardinalidades y restricciones mediante diagramas entidad-relación alineados con el dominio.
Un ERD útil no se limita a mostrar cajas y líneas: debe permitir razonar sobre identidad, cardinalidad, integridad y consecuencias de cambio.
Un Entity–Relationship Diagram representa entidades persistentes, atributos, claves y relaciones. Puede describir un modelo conceptual, lógico o físico; por eso debe declarar su nivel y audiencia.
Sin una representación común, es fácil crear relaciones ambiguas, duplicar información o permitir estados imposibles. El ERD hace visibles preguntas como:
Representa un conjunto de registros con significado. En un modelo físico suele corresponder a una tabla, pero no debe asumirse en niveles conceptuales.
Describen propiedades. Deben distinguir datos requeridos, opcionales, derivados e históricos.
(tenant_id, sku).1, 0..1, 1..* y 0..* expresan cuántos registros pueden relacionarse. La cardinalidad debe derivarse de reglas, no de comodidad de implementación.
erDiagram
TENANT {
uuid id PK
string name
}
BRANCH {
uuid id PK
uuid tenant_id FK
string name
}
PRODUCT {
uuid id PK
uuid tenant_id FK
string sku
string name
}
INVENTORY_ITEM {
uuid branch_id PK,FK
uuid product_id PK,FK
decimal on_hand
decimal reserved
int version
}
STOCK_MOVEMENT {
uuid id PK
uuid branch_id FK
uuid product_id FK
string type
decimal quantity
datetime occurred_at
}
TENANT ||--o{ BRANCH : owns
TENANT ||--o{ PRODUCT : owns
BRANCH ||--o{ INVENTORY_ITEM : stores
PRODUCT ||--o{ INVENTORY_ITEM : tracked_as
INVENTORY_ITEM ||--o{ STOCK_MOVEMENT : changes_throughINVENTORY_ITEM materializa la relación entre sucursal y producto.STOCK_MOVEMENT conserva historial y causa del cambio.version puede apoyar control optimista, pero no sustituye una estrategia transaccional completa.Una relación muchos a muchos suele requerir entidad intermedia cuando contiene información propia.
Sucursal ↔ Productose convierte en:
InventoryItem(branchId, productId, onHand, reserved, reorderPoint)No es solo una tabla puente: representa una relación con estado y reglas.
Cada registro posee identidad válida y no duplicada.
Una foreign key evita referencias a registros inexistentes.
CHECK (quantity > 0) o un tipo adecuado restringen valores.
Un historial puede requerir vigencias que no se solapen.
Las referencias deben impedir conectar datos de tenants distintos. Una FK simple por ID puede no ser suficiente si los IDs no incorporan alcance.
CASCADE, RESTRICT, SET NULL y soft delete tienen consecuencias diferentes.
CASCADE es útil para partes cuyo ciclo de vida depende totalmente del padre.RESTRICT evita perder información relacionada accidentalmente.SET NULL solo tiene sentido cuando la relación realmente puede quedar vacía.Referenciar siempre el registro actual puede alterar el pasado. Una línea de pedido suele conservar descripción, precio e impuestos aplicados aunque el producto cambie después.
Esto no es duplicación accidental; es un snapshot deliberado con significado histórico.
El ERD no debe diseñarse aislado de consultas:
- buscar producto por tenant + SKU
- listar stock bajo por sucursal
- reconstruir movimientos de un producto
- obtener pedido con líneasLos patrones ayudan a decidir claves e índices físicos. El diagrama puede anotar accesos críticos sin convertirse en plan de ejecución.
Un ERD muestra estructura, pero debe conectar con operaciones concurrentes. Dos ventas pueden leer el mismo saldo y descontarlo. La solución puede incluir lock, actualización condicional, versión o serialización según la garantía requerida.
| ERD | Class Diagram |
|---|---|
| Modela persistencia e integridad | Modela objetos, comportamiento y colaboración |
| Centrado en claves y cardinalidades | Centrado en operaciones y responsabilidades |
| Puede incluir tablas técnicas | Puede incluir clases no persistentes |
No deben coincidir uno a uno.
customer_id NULL puede representar venta anónima o dato pendiente; son significados diferentes y deben documentarse.
Un índice unique simple puede impedir reutilizar un email eliminado. Se necesita decidir si eso es deseado o usar unicidad parcial.
No uses un ID de proveedor como identidad interna única sin considerar cambio de proveedor y múltiples integraciones.
Una relación genérica entity_type + entity_id pierde foreign keys. Úsala solo con una justificación clara.
InventoryItem no es una simple tabla puente?product_id en un SaaS multi-tenant?OrderLine?Diccionario de datos documenta el significado, origen, reglas, sensibilidad y ciclo de vida de cada dato.