Diseñar un esquema de base de datos normalizado

1. Escribe los requisitos como frases sencillas: «un cliente puede tener varias direcciones».
2. Añade las consultas que más usarás; definen los índices.
3. Pega el diagrama Mermaid en un visor compatible para revisarlo.
4. Ejecuta el DDL en una base de datos de pruebas antes de crear las migraciones definitivas.

Aplicación: gestión de una academia · Requisitos: alumnos, cursos, grupos, matrículas y pagos mensuales · Motor: PostgreSQL 16.

4. DDL (extracto, PostgreSQL 16)

CREATE TABLE students (
  id          bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  full_name   text NOT NULL,
  email       text NOT NULL UNIQUE,
  created_at  timestamptz NOT NULL DEFAULT now(),
  deleted_at  timestamptz                -- borrado lógico
);

CREATE TABLE enrollments (
  id              bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  student_id      bigint NOT NULL REFERENCES students (id) ON DELETE RESTRICT,
  class_group_id  bigint NOT NULL REFERENCES class_groups (id) ON DELETE RESTRICT,
  enrolled_on     date NOT NULL DEFAULT current_date,
  UNIQUE (student_id, class_group_id)
);

CREATE TABLE monthly_payments (
  id             bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  enrollment_id  bigint NOT NULL REFERENCES enrollments (id) ON DELETE RESTRICT,
  period         date NOT NULL CHECK (extract(day FROM period) = 1),
  amount_cents   integer NOT NULL CHECK (amount_cents >= 0),
  paid_at        timestamptz,
  UNIQUE (enrollment_id, period)
);

-- Índice parcial para "alumnos con pagos pendientes"
CREATE INDEX idx_payments_unpaid ON monthly_payments (period) WHERE paid_at IS NULL;

ON DELETE RESTRICT evita perder el historial de pagos si alguien borra un alumno; por eso se usa borrado lógico. Los importes van en céntimos para evitar errores de redondeo.

Ambigüedades

• ¿Un pago cubre una matrícula o todas las del alumno en ese mes? [COMPLETAR]…