Módulo 2: Diseño de bases de datos, relaciones e integridad

En el módulo anterior aprendiste a crear una tabla, insertar registros y consultar sus columnas. Esa primera tabla permitió organizar información, pero los sistemas reales rara vez pueden representarse correctamente con una sola tabla.

Una clínica necesita pacientes, médicos, especialidades, consultorios y citas. Si toda esa información se guarda en una tabla enorme, los nombres y teléfonos se repetirán, aparecerán contradicciones y cada corrección será más difícil.

En este módulo aprenderás a pensar antes de crear las tablas. Analizarás necesidades, identificarás entidades, definirás relaciones y establecerás reglas que la propia base de datos deberá proteger.

Principio del módulo: una buena base de datos no depende de que todas las personas recuerden las reglas. La estructura debe impedir que los datos lleguen a estados inválidos.

Al completar el módulo serás capaz de:

• Convertir una situación real en requisitos de información.
• Distinguir entidades, atributos y reglas de negocio.
• Elegir claves primarias adecuadas.
• Diferenciar claves naturales, sustitutas, simples y compuestas.
• Crear claves foráneas que protejan relaciones entre tablas.
• Identificar relaciones uno a uno, uno a muchos y muchos a muchos.
• Representar cardinalidad y opcionalidad en un diagrama entidad-relación.
• Resolver relaciones muchos a muchos mediante tablas intermedias.
• Aplicar PRIMARY KEY, FOREIGN KEY, NOT NULL, UNIQUE, CHECK y DEFAULT.
• Activar y comprobar la integridad referencial de SQLite.
• Elegir conscientemente entre RESTRICT, CASCADE y SET NULL.
• Detectar redundancia y anomalías en diseños deficientes.
• Aplicar primera, segunda y tercera forma normal en casos prácticos.
• Realizar cambios básicos del esquema mediante ALTER TABLE.
• Eliminar tablas de práctica mediante un orden seguro.
• Documentar un modelo mediante diagrama, modelo relacional y diccionario de datos.
• Reconocer diferencias importantes entre SQLite y otros motores.

El proyecto principal será la base de datos de una clínica:

clinica.db
├── especialidades
├── medicos
├── medico_especialidad
├── pacientes
├── consultorios
└── citas

Las tablas estarán conectadas mediante claves:

especialidades ──< medico_especialidad >── medicos
                                                │
pacientes ───────────────────────────────< citas >── consultorios

El proyecto no incluirá una aplicación ni una interfaz gráfica. El objetivo es construir una estructura relacional correcta, comprobar sus reglas y documentar las decisiones.

Los tiempos son orientativos. El diseño puede necesitar varias revisiones. Corregir un diagrama antes de construir las tablas forma parte del trabajo profesional.

Del problema real al modelo de datos

Lee esta solicitud:

“Necesitamos una base de datos para una clínica.”

Todavía no existe información suficiente para diseñarla. Antes de escribir SQL debes descubrir:

• Qué actividades realizará la clínica.
• Qué información necesita conservar.
• Qué reglas no se pueden incumplir.
• Qué situaciones pueden ocurrir más de una vez.
• Qué datos son obligatorios y cuáles son opcionales.

Crear tablas sin comprender el problema produce estructuras difíciles de corregir.

El proceso puede dividirse en tres niveles:

REALIDAD Y REQUISITOS
        │
        ▼
MODELO CONCEPTUAL
Entidades, atributos y relaciones
        │
        ▼
MODELO LÓGICO
Tablas, claves y cardinalidades
        │
        ▼
MODELO FÍSICO
CREATE TABLE y reglas del motor

Modelo conceptual

Describe qué existe en el problema, sin preocuparse todavía por una sintaxis concreta.

Modelo lógico

Convierte los conceptos en tablas, columnas, claves y relaciones.

Modelo físico

Implementa el diseño en SQLite mediante tipos, restricciones e instrucciones SQL.

Separar estos niveles evita que una decisión técnica oculte un requisito del negocio.

Una entidad es algo relevante sobre lo que se necesita conservar información.

En una clínica podrían existir:

• Paciente.
• Médico.
• Especialidad.
• Consultorio.
• Cita.

Una entidad suele convertirse en una tabla.

Una palabra no es automáticamente una entidad. Debe tener importancia propia para el sistema y normalmente varias ocurrencias.

Un atributo describe una propiedad de una entidad.

Entidad: paciente
├── nombre
├── documento
├── fecha_nacimiento
├── telefono
└── correo

Los atributos suelen convertirse en columnas.

Pregunta útil

¿Este elemento tiene propiedades propias y varias ocurrencias, o solamente describe otra cosa?

Ejemplo:

• paciente es una entidad.
• telefono normalmente es un atributo del paciente.
• cita es una entidad porque posee fecha, estado, motivo y relaciones propias.

Una regla de negocio describe una condición que debe cumplirse dentro del sistema.

Ejemplos:

• Cada médico posee un número de licencia irrepetible.
• Una cita pertenece a un paciente.
• Una cita es atendida por un médico.
• Un médico puede tener varias especialidades.
• Una especialidad puede corresponder a varios médicos.
• El estado de una cita solo puede ser programada, confirmada, atendida o cancelada.
• Dos médicos diferentes pueden utilizar el mismo consultorio, pero no a la misma hora.

Estas reglas guían el diseño. Algunas se protegerán con restricciones de la base y otras requerirán lógica de aplicación en cursos posteriores.

No conviertas una suposición en una regla sin reconocerla.

Cuando falta información, registra la pregunta. En un proyecto real se consultaría con la persona responsable del proceso.

Práctica guiada 1 — Analizar un centro deportivo

Lee el caso:

Un centro deportivo ofrece clases. Cada clase pertenece a una disciplina y es impartida por un instructor. Los socios pueden inscribirse en varias clases. Cada clase admite muchos socios. El correo de cada socio debe ser único.

Paso 1. Identifica entidades

• Socio.
• Clase.
• Disciplina.
• Instructor.
• Inscripción.

Paso 2. Identifica atributos iniciales

socio: nombre, correo, telefono
clase: nombre, horario, capacidad
disciplina: nombre
instructor: nombre, correo
inscripcion: fecha_inscripcion

Paso 3. Escribe reglas

• Una disciplina puede tener muchas clases.
• Cada clase pertenece a una disciplina.
• Un instructor puede impartir varias clases.
• Cada clase posee un instructor.
• Un socio puede inscribirse en varias clases.
• Una clase puede recibir varios socios.
• Un socio no debe inscribirse dos veces en la misma clase.

Observa que inscripcion aparece porque la relación entre socios y clases necesita conservar información propia y evitar duplicados.

Claves: identidad y referencia

Una clínica puede tener dos pacientes llamados Laura Gómez. El nombre no basta para distinguirlos.

Laura Gómez, documento P-104
Laura Gómez, documento P-281

Una clave permite identificar o relacionar registros sin depender de descripciones ambiguas.

Una clave candidata es un atributo, o conjunto de atributos, capaz de identificar de manera única cada registro.

En una tabla de pacientes podrían considerarse:

• Documento de identidad.
• Número interno de expediente.

Ambos podrían ser únicos, pero se debe elegir cuál será la clave principal.

Una clave natural ya existe en el dominio del problema.

Ejemplos:

• Número de licencia médica.
• ISBN de una edición de un libro.
• Código oficial de un país.

Ventaja: posee significado fuera de la base.

Riesgos:

• Puede cambiar.
• Puede ser larga.
• Puede contener errores de captura.
• Su formato puede depender de una institución externa.

Una clave sustituta se crea únicamente para identificar registros dentro del sistema.

id INTEGER PRIMARY KEY

No describe al paciente ni al médico. Su función es proporcionar una identidad estable y sencilla.

En este curso se utilizará normalmente una clave sustituta id, mientras que las claves naturales importantes se protegerán con UNIQUE.

Ejemplo:

CREATE TABLE pacientes (
    id INTEGER PRIMARY KEY,
    documento TEXT NOT NULL UNIQUE,
    nombre TEXT NOT NULL
);

id identifica internamente. documento conserva su valor real y no permite duplicados.

La clave primaria identifica de manera única cada fila.

Propiedades prácticas:

• No debe repetirse.
• No debe estar ausente.
• Debe permanecer estable.
• Cada tabla posee una clave primaria, que puede estar formada por una o varias columnas.

Ejemplo simple:

id INTEGER PRIMARY KEY

Una clave compuesta utiliza varias columnas.

En una tabla que conecta médicos y especialidades:

PRIMARY KEY (medico_id, especialidad_id)

La combinación no se puede repetir:

Una clave foránea contiene un valor que debe corresponder a una clave de otra tabla.

departamentos
┌────┬──────────────┐
│ id │ nombre       │
├────┼──────────────┤
│ 1  │ Tecnología   │
│ 2  │ Finanzas     │
└────┴──────────────┘

empleados
┌────┬────────────┬─────────────────┐
│ id │ nombre     │ departamento_id │
├────┼────────────┼─────────────────┤
│ 1  │ Ana Mora   │ 1               │
│ 2  │ Luis Vega  │ 2               │
└────┴────────────┴─────────────────┘

empleados.departamento_id hace referencia a departamentos.id.

En SQL:

FOREIGN KEY (departamento_id)
    REFERENCES departamentos(id)

En la relación anterior:

• departamentos es la tabla padre o referenciada.
• empleados es la tabla hija o referente.
• La fila hija depende de que exista una fila padre válida.

Una clave foránea evita empleados que señalen departamentos inexistentes.

departamento_id = 2  → válido si departamentos.id = 2 existe
departamento_id = 99 → inválido si no existe el departamento 99

Práctica guiada 2 — Elegir claves

Para cada entidad, selecciona una clave primaria sustituta y una posible clave natural que debería ser única.

La clave natural no reemplaza obligatoriamente a id. Ambas pueden cumplir funciones diferentes.

Relaciones, cardinalidad y opcionalidad

Una relación responde cómo se asocian las ocurrencias de dos entidades.

Ejemplo:

Un departamento tiene empleados y cada empleado pertenece a un departamento.

No basta con decir que las tablas “están conectadas”. Debes determinar cuántos registros pueden relacionarse y si la relación es obligatoria.

Un departamento puede tener muchos empleados. Cada empleado pertenece a un departamento.

departamentos 1 ─────────── N empleados

La clave foránea se coloca normalmente en el lado “muchos”:

empleados.departamento_id → departamentos.id

Ejemplos comunes:

• Una categoría tiene muchos productos.
• Un paciente tiene muchas citas.
• Un curso tiene muchas lecciones.
• Un hotel tiene muchas habitaciones.

Una persona posee como máximo un expediente adicional y cada expediente pertenece a una persona.

personas 1 ─────────── 1 expedientes

Una forma de protegerla consiste en utilizar la clave de la tabla principal como clave primaria y foránea de la tabla dependiente:

CREATE TABLE usuarios (
    id INTEGER PRIMARY KEY,
    nombre TEXT NOT NULL
);

CREATE TABLE perfiles (
    usuario_id INTEGER PRIMARY KEY,
    biografia TEXT,
    FOREIGN KEY (usuario_id)
        REFERENCES usuarios(id)
        ON DELETE CASCADE
);

Como usuario_id es clave primaria, no puede existir más de un perfil para el mismo usuario.

No dividas automáticamente toda entidad en parejas de tablas. Una relación uno a uno debe responder a una necesidad real, como separar información opcional, sensible o con un ciclo de vida diferente.

Un médico puede poseer varias especialidades y una especialidad puede corresponder a varios médicos.

medicos N ─────────── N especialidades

Una base relacional resuelve esta relación mediante una tabla intermedia:

medicos 1 ──< medico_especialidad >── 1 especialidades

CREATE TABLE medico_especialidad (
    medico_id INTEGER,
    especialidad_id INTEGER,
    PRIMARY KEY (medico_id, especialidad_id),
    FOREIGN KEY (medico_id)
        REFERENCES medicos(id),
    FOREIGN KEY (especialidad_id)
        REFERENCES especialidades(id)
);

La tabla intermedia puede contener atributos propios, por ejemplo, la fecha en que se acreditó la especialidad.

La cardinalidad indica cuántos. La opcionalidad indica si la relación debe existir.

Ejemplo:

• Un paciente puede no tener ninguna cita todavía.
• Cada cita debe tener exactamente un paciente.

paciente 1 ─────────── 0..N citas
cita     1 ─────────── 1 paciente

Una clave foránea con NOT NULL hace obligatoria la relación desde la fila hija:

paciente_id INTEGER NOT NULL

Si se permite NULL, la relación puede estar ausente, salvo que otra regla lo impida.

Una notación común utiliza símbolos en los extremos:

Ejemplo:

departamentos ||────────o{ empleados

Se interpreta así:

• Cada empleado pertenece a exactamente un departamento.
• Un departamento puede tener cero o muchos empleados.

Un diagrama entidad-relación muestra visualmente:

• Entidades.
• Atributos principales.
• Claves.
• Relaciones.
• Cardinalidad.
• Opcionalidad.

Ejemplo:

┌───────────────────┐            ┌────────────────────┐
│ departamentos     │            │ empleados          │
├───────────────────┤            ├────────────────────┤
│ PK id             │ ||─────o{  │ PK id              │
│ UQ nombre         │            │ nombre             │
│ presupuesto       │            │ correo             │
└───────────────────┘            │ FK departamento_id │
                                 └────────────────────┘

Convenciones utilizadas en el curso:

• PK: clave primaria.
• FK: clave foránea.
• UQ: valor único.
• NN: valor obligatorio.

Puedes dibujar a mano durante el análisis y preparar la versión final con:

• 📖diagrams.net, herramienta gratuita de diagramación.
• 📖dbdiagram.io, herramienta especializada en esquemas de bases de datos.

La herramienta no corrige automáticamente las reglas del negocio. Un diagrama atractivo puede contener un diseño incorrecto.

Propósito: observar cómo una situación se convierte en entidades y relaciones antes de crear las tablas.

Práctica guiada 3 — Resolver una relación muchos a muchos

Situación:

Una estudiante puede matricular varios cursos. Un curso puede tener muchos estudiantes. La matrícula debe conservar la fecha y el estado.

Modelo:

estudiantes ||──o{ matriculas }o──|| cursos

Tablas necesarias:

estudiantes
cursos
matriculas

La tabla matriculas contendrá:

• estudiante_id.
• curso_id.
• fecha_matricula.
• estado.

La combinación de estudiante y curso puede funcionar como clave primaria compuesta si una persona solo puede tener una matrícula activa por curso dentro del alcance del sistema.

Restricciones: reglas protegidas por la base

Una restricción es una regla declarada dentro del esquema. SQLite comprueba la regla antes de aceptar ciertos datos.

Intento de inserción
        │
        ▼
Comprobación de restricciones
        │
        ├── Cumple → se acepta
        └── Incumple → se rechaza

Identifica de manera única cada fila.

id INTEGER PRIMARY KEY

Para una tabla intermedia:

PRIMARY KEY (empleado_id, proyecto_id)

Impide que una columna quede sin valor.

nombre TEXT NOT NULL

Utilízalo cuando la entidad no pueda tener sentido sin ese dato.

No marques todo como obligatorio por costumbre. Un segundo teléfono o una observación pueden ser opcionales.

Impide valores duplicados.

correo TEXT UNIQUE

También puede aplicarse a una combinación:

UNIQUE (consultorio_id, fecha_hora)

La combinación evita reservar el mismo consultorio dos veces en la misma fecha y hora.

Comprueba una condición.

salario REAL CHECK (salario > 0)

activo INTEGER CHECK (activo IN (0, 1))

estado TEXT CHECK (
    estado IN ('Planificado', 'En curso', 'Finalizado')
)

La expresión IN indica que el valor debe pertenecer al conjunto mostrado.

Una restricción CHECK protege reglas que dependen de los valores de la misma fila. Las reglas que requieren comparar muchas filas o consultar otras tablas necesitan otras estrategias.

Proporciona un valor cuando la inserción omite una columna.

activo INTEGER NOT NULL DEFAULT 1

estado TEXT NOT NULL DEFAULT 'Programada'

DEFAULT no corrige un valor inválido proporcionado explícitamente. Solo se utiliza cuando el valor no se envía.

Protege la existencia de una relación.

FOREIGN KEY (departamento_id)
    REFERENCES departamentos(id)

Una clave foránea no crea automáticamente una nueva fila padre. El departamento debe existir antes de insertar al empleado.

correo TEXT NOT NULL UNIQUE

El correo es obligatorio y no puede repetirse.

estado TEXT NOT NULL DEFAULT 'Programada'
    CHECK (estado IN ('Programada', 'Confirmada', 'Atendida', 'Cancelada'))

El estado es obligatorio, posee un valor inicial y solo acepta opciones válidas.

Implementar relaciones correctamente en SQLite

En SQLite la comprobación de claves foráneas debe habilitarse para cada conexión.

Ejecuta al inicio de la sesión o del script:

PRAGMA foreign_keys = ON;

Comprueba el estado:

PRAGMA foreign_keys;

Resultado esperado:

1

Si devuelve 0, la comprobación no está activa.

No asumas que DB Browser la activó por ti. Compruébalo siempre antes de probar relaciones.

Orden recomendado:

1. departamentos
2. empleados

La tabla hija hace referencia a la tabla padre, por lo que el script resulta más comprensible si crea primero la estructura referenciada.

PRAGMA foreign_keys = ON;

CREATE TABLE departamentos (
    id INTEGER PRIMARY KEY,
    nombre TEXT NOT NULL UNIQUE,
    presupuesto REAL NOT NULL CHECK (presupuesto >= 0)
);

CREATE TABLE empleados (
    id INTEGER PRIMARY KEY,
    nombre TEXT NOT NULL,
    correo TEXT NOT NULL UNIQUE,
    salario REAL NOT NULL CHECK (salario > 0),
    activo INTEGER NOT NULL DEFAULT 1
        CHECK (activo IN (0, 1)),
    departamento_id INTEGER NOT NULL,
    FOREIGN KEY (departamento_id)
        REFERENCES departamentos(id)
        ON UPDATE CASCADE
        ON DELETE RESTRICT
);

departamentos

• Posee un identificador.
• Su nombre es obligatorio y único.
• El presupuesto no puede ser negativo.

empleados

• Nombre, correo, salario y departamento son obligatorios.
• El correo no puede repetirse.
• El salario debe ser mayor que cero.
• activo utiliza 1 por defecto y solo admite 0 o 1.
• El departamento debe existir.
• No se puede eliminar un departamento que todavía tenga empleados.

INSERT INTO departamentos (id, nombre, presupuesto)
VALUES
    (1, 'Tecnología', 85000.00),
    (2, 'Finanzas', 52000.00),
    (3, 'Operaciones', 68000.00);

Después inserta las filas hijas:

INSERT INTO empleados (
    id,
    nombre,
    correo,
    salario,
    departamento_id
) VALUES
    (1, 'Ana Mora', 'ana.mora@empresa.test', 1800.00, 1),
    (2, 'Luis Vega', 'luis.vega@empresa.test', 1650.00, 2),
    (3, 'Marta Solís', 'marta.solis@empresa.test', 1725.00, 1);

La columna activo se omitió y recibió el valor predeterminado 1.

Ejecuta cada prueba por separado sobre una copia de práctica.

Departamento inexistente

INSERT INTO empleados (
    id,
    nombre,
    correo,
    salario,
    departamento_id
) VALUES (
    4,
    'Carlos Rojas',
    'carlos.rojas@empresa.test',
    1500.00,
    99
);

Debe fallar porque el departamento 99 no existe.

Correo duplicado

INSERT INTO empleados (
    id,
    nombre,
    correo,
    salario,
    departamento_id
) VALUES (
    4,
    'Carlos Rojas',
    'ana.mora@empresa.test',
    1500.00,
    3
);

Debe fallar por UNIQUE.

Salario inválido

INSERT INTO empleados (
    id,
    nombre,
    correo,
    salario,
    departamento_id
) VALUES (
    4,
    'Carlos Rojas',
    'carlos.rojas@empresa.test',
    -100.00,
    3
);

Debe fallar por CHECK.

Nombre ausente

INSERT INTO empleados (
    id,
    nombre,
    correo,
    salario,
    departamento_id
) VALUES (
    4,
    NULL,
    'carlos.rojas@empresa.test',
    1500.00,
    3
);

Debe fallar por NOT NULL.

Una restricción que nunca se prueba podría estar mal escrita o desactivada.

PRAGMA foreign_key_check;

Si la consulta no devuelve filas, no se detectaron violaciones de claves foráneas.

PRAGMA table_info(empleados);

Permite revisar columnas, tipos, valores obligatorios y clave primaria.

PRAGMA foreign_key_list(empleados);

Muestra las claves foráneas declaradas para la tabla.

Práctica guiada 4 — Construir y romper de forma controlada

1. Crea empresa_practica.db.
2. Activa claves foráneas.
3. Crea departamentos y empleados.
4. Inserta los departamentos.
5. Inserta los tres empleados válidos.
6. Comprueba que activo recibió el valor 1.
7. Ejecuta cada prueba inválida por separado.
8. Anota qué restricción rechazó cada intento.
9. Ejecuta PRAGMA foreign_key_check.
10. Conserva capturas de dos errores distintos.

Acciones referenciales y cambios del esquema

Supón que un departamento tiene empleados. Si alguien intenta eliminarlo, la base debe decidir qué ocurre con las filas hijas.

Las acciones más importantes son:

FOREIGN KEY (departamento_id)
    REFERENCES departamentos(id)
    ON DELETE RESTRICT

Es apropiado cuando eliminar la fila padre dejaría datos sin significado y se prefiere obligar a resolver primero las dependencias.

FOREIGN KEY (medico_id)
    REFERENCES medicos(id)
    ON DELETE CASCADE

Si se elimina el médico, también se eliminan sus filas en una tabla intermedia.

Utilízalo cuando la fila hija no tenga sentido sin la fila padre. No lo elijas solo porque resulta cómodo: una cascada puede eliminar muchos registros.

medico_asignado_id INTEGER,
FOREIGN KEY (medico_asignado_id)
    REFERENCES medicos(id)
    ON DELETE SET NULL

La fila hija se conserva, pero queda sin médico asignado. La columna debe permitir NULL.

ON UPDATE CASCADE

Si cambia la clave referenciada, la actualización se propaga a las claves hijas. Las claves primarias deberían cambiar muy rara vez, pero declarar la acción hace explícita la decisión.

Pregunta:

1. ¿La fila hija conserva significado sin el padre?
2. ¿Debe preservarse por historial?
3. ¿La relación puede quedar temporalmente ausente?
4. ¿Eliminar automáticamente sería peligroso?

Ejemplos razonables:

No existe una acción universalmente correcta. La regla depende del negocio.

ALTER TABLE empleados
ADD COLUMN telefono TEXT;

ALTER TABLE empleados
RENAME COLUMN correo TO correo_institucional;

ALTER TABLE empleados
RENAME TO colaboradores;

SQLite admite cambios básicos directamente. Las modificaciones complejas pueden requerir crear una tabla nueva, copiar los datos y reemplazar la estructura. Esa migración debe planificarse y probarse.

DROP TABLE empleados;

DROP TABLE elimina la estructura y sus datos. Utilízalo solamente en bases de práctica o cuando la eliminación forme parte de un cambio autorizado.

Si existen relaciones, elimina primero las tablas hijas y después las tablas padre:

1. empleados
2. departamentos

No practiques DROP TABLE sobre el único archivo de tu proyecto. Trabaja con una copia que puedas reemplazar.

Práctica guiada 5 — Elegir acciones referenciales

Decide una acción y justifica la elección:

1. Eliminar una factura que posee líneas de detalle.
2. Eliminar una categoría que tiene productos activos.
3. Eliminar un usuario que posee una configuración personal sin valor histórico.
4. Eliminar un paciente con citas registradas.

No busques una palabra “correcta” sin contexto. Escribe qué debe conservar el negocio y qué pérdida sería aceptable.

Normalización práctica

La normalización ayuda a reducir repetición innecesaria y prevenir inconsistencias.

Considera:

¿Cuál teléfono es correcto? La repetición permitió una contradicción.

Anomalía de actualización

Para cambiar el teléfono de una paciente deben modificarse varias filas. Si una queda sin actualizar, aparecen versiones contradictorias.

Anomalía de inserción

No se puede registrar un médico nuevo hasta que tenga una cita, porque toda la información está mezclada en la misma tabla.

Anomalía de eliminación

Si se elimina la única cita de un médico, también se pierde su información profesional.

Separar entidades reduce estas anomalías.

Una tabla en primera forma normal debe evitar grupos repetidos y valores que contengan listas difíciles de consultar.

Diseño problemático:

La columna almacena dos valores dentro de una celda.

Otro diseño problemático:

La cantidad de columnas depende del número de teléfonos.

Diseño normalizado cuando el sistema necesita varios teléfonos:

pacientes
├── id
└── nombre

telefonos_paciente
├── id
├── paciente_id
├── numero
└── tipo

No es necesario crear una tabla separada si el requisito permite exactamente un único teléfono. La estructura debe responder a la realidad del sistema.

La segunda forma normal resulta relevante especialmente cuando existe una clave primaria compuesta.

Diseño problemático:

detalle_pedido
PK pedido_id
PK producto_id
cantidad
nombre_producto
fecha_pedido

La clave completa es (pedido_id, producto_id), pero:

• nombre_producto depende solamente de producto_id.
• fecha_pedido depende solamente de pedido_id.
• cantidad depende de la combinación completa.

Diseño mejorado:

pedidos
├── id
└── fecha_pedido

productos
├── id
└── nombre

detalle_pedido
├── pedido_id
├── producto_id
└── cantidad

Una tabla con clave simple y que ya cumple 1FN normalmente no presenta una dependencia parcial de la clave.

La tercera forma normal evita que una columna no clave dependa de otra columna no clave.

Diseño problemático:

empleados
├── id
├── nombre
├── departamento_id
└── departamento_nombre

departamento_nombre depende de departamento_id, no directamente del empleado.

Diseño mejorado:

departamentos
├── id
└── nombre

empleados
├── id
├── nombre
└── departamento_id

Normalizar no significa convertir cada columna en una tabla.

Diseño innecesario:

personas
nombres_persona
apellidos_persona
ciudades_persona
correos_persona

La separación debe resolver repetición, dependencias o reglas reales. Un diseño excesivamente fragmentado puede ser difícil de comprender y utilizar.

Para cada tabla, pregunta:

1. ¿Qué representa una fila?
2. ¿Existe alguna columna con una lista de valores?
3. ¿Existen columnas numeradas como telefono_1, telefono_2 y telefono_3?
4. ¿Se repite información descriptiva de otra entidad?
5. ¿Un cambio obliga a modificar muchas filas?
6. ¿Se perdería información importante al eliminar el último registro de una actividad?
7. ¿Cada columna depende de la identidad completa de la fila?

Propósito: reforzar las tres formas normales mediante ejemplos y reconocer problemas de repetición.

Diccionario de datos y modelo relacional

Además del diagrama, documenta cada tabla en una forma compacta:

DEPARTAMENTOS(
    id PK,
    nombre UQ NN,
    presupuesto NN
)

EMPLEADOS(
    id PK,
    nombre NN,
    correo UQ NN,
    salario NN,
    activo NN,
    departamento_id FK → DEPARTAMENTOS.id NN
)

Un diccionario de datos explica el propósito y las reglas de cada columna.

Un buen diccionario evita que otra persona tenga que deducir el significado de nombres o códigos.

1. Descripción del problema.
2. Alcance y exclusiones.
3. Reglas de negocio.
4. Diagrama entidad-relación.
5. Modelo relacional.
6. Diccionario de datos.
7. Decisiones de integridad referencial.
8. Evidencias de validación.

Diferencias entre SQLite y otros motores

Los conceptos del modelo relacional se transfieren, pero algunos detalles físicos cambian.

No memorices todas las variantes. Aprende a reconocer qué parte pertenece al modelo relacional y consulta la documentación del motor cuando cambies de entorno.

Buenas prácticas y errores frecuentes

No toda palabra es una entidad. nombre, estado y telefono pueden ser atributos.

Los nombres pueden repetirse, corregirse o cambiar. Prefiere una clave estable y protege las claves naturales importantes con UNIQUE.

En una relación uno a muchos, la clave foránea suele colocarse en el lado muchos.

departamento 1 ─── N empleados
empleados.departamento_id

Evita columnas como:

especialidades = 'Pediatría, Cardiología, Medicina general'

Utiliza una tabla intermedia.

En SQLite debes ejecutar y comprobar:

PRAGMA foreign_keys = ON;
PRAGMA foreign_keys;

Una cascada puede eliminar todas las filas relacionadas. Decide primero qué debe conservarse.

Si una cita no puede existir sin paciente, utiliza NOT NULL en paciente_id.

Un valor predeterminado no debe inventar información real. No asignes un documento, correo o médico ficticio solo para evitar NULL.

El diagrama comunica el diseño. El script implementa y protege las reglas. Ambos deben coincidir.

Una restricción demuestra su valor cuando rechaza un caso inválido. Incluye pruebas controladas.

Videos recomendados del módulo

Tema exacto: análisis y construcción de un diagrama entidad-relación. Momento recomendado: después de estudiar cardinalidades. Objetivo: observar un proceso completo de diseño antes de escribir SQL.

Tema exacto: normalización mediante primera, segunda y tercera forma normal. Momento recomendado: antes de revisar el diseño de la clínica. Objetivo: reconocer redundancia, dependencias y separación correcta de tablas.

Los videos complementan la práctica. El dominio se demuestra diseñando, implementando y probando las restricciones.

Documentación y recursos de lectura

• 📖Claves foráneas en SQLite — documentación oficial
• 📖`CREATE TABLE` y restricciones — documentación oficial de SQLite
• 📖Tipos y afinidad en SQLite — documentación oficial

• 📖`ALTER TABLE` — documentación oficial de SQLite
• 📖`DROP TABLE` — documentación oficial de SQLite

• 📖Tablas `STRICT` — documentación oficial de SQLite
• 📖Modelo entidad-relación: elementos y ejemplo — iLERNA
• 📖diagrams.net — herramienta gratuita de diagramación

No necesitas memorizar la sintaxis completa de la documentación. Busca la restricción que estás implementando, revisa un ejemplo mínimo y comprueba su comportamiento en una base de práctica.

Glosario

Resumen del módulo

Diseñar una base de datos comienza por comprender el problema. Las entidades representan elementos importantes, los atributos describen sus propiedades y las reglas de negocio determinan qué estructuras y restricciones son necesarias.

Requisitos
   ↓
Entidades y atributos
   ↓
Claves y relaciones
   ↓
Normalización
   ↓
CREATE TABLE y restricciones
   ↓
Pruebas válidas e inválidas

Las claves primarias identifican filas. Las claves foráneas conectan tablas y protegen la existencia de las referencias. Las relaciones pueden ser uno a uno, uno a muchos o muchos a muchos; estas últimas necesitan una tabla intermedia.

Las restricciones permiten que la base proteja reglas:

PRIMARY KEY
FOREIGN KEY
NOT NULL
UNIQUE
CHECK
DEFAULT

En SQLite debes activar las claves foráneas en cada conexión:

PRAGMA foreign_keys = ON;

La normalización práctica evita listas dentro de celdas, dependencias parciales y datos descriptivos repetidos que pertenecen a otras entidades.

Ahora puedes:

• Analizar requisitos antes de crear tablas.
• Dibujar un diagrama entidad-relación.
• Elegir claves primarias y naturales.
• Implementar relaciones mediante claves foráneas.
• Resolver relaciones muchos a muchos.
• Aplicar restricciones de integridad.
• Elegir acciones referenciales.
• Detectar anomalías y normalizar hasta 3FN.
• Documentar el modelo mediante un diccionario de datos.
• Probar que la base acepta casos válidos y rechaza casos inválidos.
• Reconocer particularidades de SQLite y conceptos transferibles.

Comprueba que puedes explicar y demostrar:

• Por qué no se debe comenzar creando tablas sin analizar requisitos.
• Qué diferencia existe entre entidad y atributo.
• Qué diferencia existe entre clave primaria y clave foránea.
• Dónde se coloca la clave foránea en una relación 1:N.
• Cómo se resuelve una relación N:M.
• Qué ocurre si SQLite no tiene las claves foráneas activas.
• Cuándo utilizar RESTRICT, CASCADE o SET NULL.
• Qué problemas corrigen 1FN, 2FN y 3FN.
• Cómo comprobar que no existen referencias inválidas.
• Cómo reconstruir el proyecto completo desde el script.

No continúes con el Módulo 3 hasta que el proyecto de la clínica haya sido aprobado. El siguiente módulo utilizará estas estructuras para insertar, actualizar y eliminar información mediante procedimientos seguros y transacciones.