Modelado entidad-relación

🛠️ En la práctica

Receta para tomar requisitos y producir un diagrama ER:

Paso 1: identificá entidades

Releé la descripción del sistema. Todos los sustantivos importantes son candidatos:

"Una pupusería vende productos a clientes. Cada cliente puede hacer muchos pedidos. Cada pedido contiene varios productos con sus cantidades. Hay un inventario de los productos. Algunos clientes son fieles y tienen descuento."

Candidatos: cliente, pedido, producto, inventario, fidelidad.

Filtrar: algunos son atributos, no entidades. Inventario probablemente es un atributo stock del producto, no entidad. Fidelidad puede ser atributo del cliente (es_fiel: bool o nivel_fidelidad: int).

Paso 2: identificá atributos

Para cada entidad, listá qué propiedades tiene:

• Cliente: nombre, email, teléfono, fecha_registro.
• Producto: código, nombre, precio, stock, descripción.
• Pedido: id, fecha, total, cliente.

Cuál es la PK: elegí o crea un id. email puede ser clave candidata pero los emails cambian — un id artificial es más robusto.

Paso 3: identificá relaciones

Pares de entidades + verbo:

• Cliente hace Pedido (1:N).
• Pedido contiene Producto (N:M, con cantidad como atributo de la relación).

Paso 4: cardinalidad

¿Cuántas en cada lado?

• Un cliente puede tener 0 o más pedidos. Un pedido pertenece a 0 o 1 clientes (anónimo o no).
• Un pedido contiene 1 o más productos. Un producto aparece en 0 o más pedidos.

Paso 5: dibujá

Con las herramientas que tengas. No tiene que ser perfecto — se itera.

Paso 6: validá con stakeholders

Mostrále el diagrama al cliente, al usuario, a tu equipo. Frecuentemente descubrís entidades faltantes o relaciones mal entendidas.

🛠️ En la práctica

Pattern 1: jerarquías (herencia)

Empleado → tiene subtipos: Gerente, Vendedor, Repartidor.

Tres estrategias:

A. Una tabla con type discriminator:

CREATE TABLE empleado (
    id SERIAL PRIMARY KEY,
    nombre VARCHAR(100),
    tipo VARCHAR(20) CHECK (tipo IN ('gerente', 'vendedor', 'repartidor')),
    sueldo DECIMAL,
    -- columnas específicas, posiblemente NULL si no aplican
    bono_meta DECIMAL,           -- solo vendedores
    moto BOOLEAN                  -- solo repartidores
);

Ventaja: una sola tabla, queries simples. Desventaja: muchas columnas NULL, sin garantía de que solo apliquen a su tipo.

B. Una tabla por subtipo:

CREATE TABLE gerente (...);
CREATE TABLE vendedor (...);
CREATE TABLE repartidor (...);

Ventaja: sin NULL, schema preciso. Desventaja: consultas que tocan "todos los empleados" requieren UNION.

C. Tabla padre + tablas hijo (más usada):

CREATE TABLE empleado (
    id SERIAL PRIMARY KEY,
    nombre VARCHAR(100),
    tipo VARCHAR(20)
);

CREATE TABLE vendedor (
    empleado_id INTEGER PRIMARY KEY REFERENCES empleado(id),
    bono_meta DECIMAL
);

CREATE TABLE repartidor (
    empleado_id INTEGER PRIMARY KEY REFERENCES empleado(id),
    moto BOOLEAN
);

Ventaja: datos comunes en padre, específicos en hijos. Desventaja: JOINs para obtener todo de un empleado.

Cuál usar depende del caso. Si los subtipos son muy distintos, separá. Si son muy similares con pocos campos extras, una sola tabla.

Pattern 2: árbol (auto-referencia)

Categorías de productos en árbol (electrónica → computadoras → laptops):

CREATE TABLE categoria (
    id SERIAL PRIMARY KEY,
    nombre VARCHAR(100),
    padre_id INTEGER REFERENCES categoria(id)
);

padre_id referencia la misma tabla. NULL para raíces.

Pattern 3: histórico / auditoría

Necesitás recordar cómo era un dato en cierto momento.

CREATE TABLE precio_historico (
    producto VARCHAR(10) REFERENCES producto(codigo),
    fecha    DATE,
    precio   DECIMAL(10,2),
    PRIMARY KEY (producto, fecha)
);

Cada cambio de precio insertás una fila. La tabla producto mantiene el actual, precio_historico el archivo.

Pattern 4: many-to-many con atributos

Más allá de la simple FK doble: la relación tiene su propia info.

-- Estudiante toma materia (con nota y semestre)
CREATE TABLE inscripcion (
    estudiante_id INTEGER REFERENCES estudiante(id),
    materia_id INTEGER REFERENCES materia(id),
    semestre VARCHAR(10),
    nota DECIMAL(3,1),
    PRIMARY KEY (estudiante_id, materia_id, semestre)
);

La PK es triple: el mismo estudiante puede repetir la materia en otro semestre.

Pattern 5: soft delete

En vez de borrar, marcar como inactivo:

CREATE TABLE cliente (
    id SERIAL PRIMARY KEY,
    ...
    activo BOOLEAN NOT NULL DEFAULT TRUE,
    eliminado_en TIMESTAMP
);

Ventaja: mantenés la historia, podés recuperar. Desventaja: todas las queries tienen que filtrar WHERE activo = TRUE.