Proceso de Diseño básico de BD

Inicio-UF2214

Introducción

¿Qué es el diseño de bases de datos?

El diseño de bases de datos es un proceso sistemático para crear un modelo eficiente que almacene y gestione datos sin redundancias, garantizando integridad y rendimiento. Es fundamental en el desarrollo de aplicaciones modernas.

Objetivos clave

  • Estructurar datos de forma lógica y accesible.
  • Minimizar la redundancia y evitar anomalías en operaciones (inserción, actualización, borrado).
  • Garantizar la integridad referencial entre tablas.
  • Optimizar el rendimiento en consultas frecuentes.

Enfoques principales

Modelo Relacional (SQL)

Basado en tablas con relaciones definidas por claves primarias y foráneas. Ejemplos: MySQL, PostgreSQL.

Modelo NoSQL

Estructuras flexibles como documentos (MongoDB), grafos (Neo4j) o clave-valor (Redis). Ideal para datos no estructurados.

Ejemplo práctico

// Esquema simplificado para un sistema de ventas
CREATE TABLE Clientes (
    id INT PRIMARY KEY,
    nombre VARCHAR(100) NOT NULL
);

CREATE TABLE Pedidos (
    id INT PRIMARY KEY,
    cliente_id INT,
    fecha DATE,
    FOREIGN KEY (cliente_id) REFERENCES Clientes(id)
);

Este diseño básico ilustra una relación 1 a N (un cliente puede tener múltiples pedidos).

↑ Volver arriba

Etapas del Diseño de Bases de Datos

Introducción

El diseño de bases de datos es un proceso fundamental en el desarrollo de sistemas de información. Según estudios, el 70% de los problemas de rendimiento en aplicaciones se originan en un diseño deficiente de la base de datos.

Ventajas de un buen diseño

  • Reducción de redundancias hasta en un 90%
  • Mejora del rendimiento en consultas complejas
  • Facilidad de mantenimiento

Riesgos de un mal diseño

  • Pérdida de integridad de datos
  • Anomalías en actualizaciones
  • Problemas de escalabilidad

Conceptos Básicos

Entidades

Objetos del mundo real (Ej: Cliente, Producto)

Atributos

Características de las entidades (Ej: nombre, precio)

Relaciones

Conexiones entre entidades (1:1, 1:N, N:M)

Figura 1: Ejemplo de diagrama E-R para un sistema de ventas 1

Diagrama ER de sistema de ventas

Diagrama que muestra las entidades con relaciones

Figura 2: Ejemplo de diagrama E-R para un sistema de ventas 2

Diagrama ER de sistema de ventas

Diagrama que muestra las entidades con relaciones

Características de un Diseño Óptimo

Característica Descripción Beneficio
Normalización Estructuración en formas normales (1FN, 2FN, 3FN) Elimina redundancias y anomalías
Índices Estructuras para acelerar búsquedas frecuentes Mejora rendimiento en consultas
Integridad Reglas como claves primarias/foráneas Garantiza consistencia de datos

Actividad Completa: Diseño de BD para Hospital

Paso 1: Requisitos del Sistema

Necesitamos almacenar información sobre:

  • Pacientes (historial médico)
  • Doctores (especialidades)
  • Citas médicas
  • Medicamentos recetados

Paso 2: Diagrama E-R para sistema hospitalario

Diagrama ER Hospital

Modelo con entidades Paciente, Doctor, Cita y Medicamento

Paso 3: Transformación a Esquema Relacional

-- Tabla Pacientes
CREATE TABLE Pacientes (
    id_paciente INT PRIMARY KEY,
    nombre VARCHAR(100) NOT NULL,
    fecha_nacimiento DATE,
    tipo_sangre VARCHAR(3)
);

-- Tabla Doctores
CREATE TABLE Doctores (
    id_doctor INT PRIMARY KEY,
    nombre VARCHAR(100) NOT NULL,
    especialidad VARCHAR(50),
    telefono VARCHAR(15)
);

-- Tabla Citas
CREATE TABLE Citas (
    id_cita INT PRIMARY KEY,
    id_paciente INT,
    id_doctor INT,
    fecha_hora DATETIME,
    motivo VARCHAR(200),
    FOREIGN KEY (id_paciente) REFERENCES Pacientes(id_paciente),
    FOREIGN KEY (id_doctor) REFERENCES Doctores(id_doctor)
);
.......
.......
.......

Paso 4: Normalización

1FN: Atributos atómicos

Dividir campos compuestos (ej: dirección en calle, ciudad, CP)

2FN: Dependencia completa

Eliminar atributos que dependen parcialmente de claves compuestas

3FN: Sin dependencias transitivas

Remover atributos que dependen de otros no clave (ej: edad → fecha_nacimiento)

Modelo Estrella (Data Warehouse)

Estructura para análisis con tablas de hechos y dimensiones

Diferencias en estructura y escalabilidad

Comparativa SQL vs NoSQL

Diagrama ER Hospital

Modelo con entidades Paciente, Doctor, Cita y Medicamento

Resumen Final

Flujo del Proceso de Diseño

1. Requisitos
2. Modelo E-R
3. Esquema SQL
4. Normalización
5. Optimización
↑ Volver arriba

Teoría de la Normalización

Introducción

La normalización es un proceso sistemático para organizar datos en una base de datos relacional, con dos objetivos principales:

Beneficios Clave

  • Eliminar redundancias de datos
  • Prevenir anomalías en operaciones (inserción, actualización, borrado)
  • Garantizar dependencias lógicas entre datos

Problemas sin Normalizar

  • Inconsistencias en updates
  • Espacio desperdiciado
  • Dificultad en mantenimiento

📜 Historia: Desarrollada por Edgar F. Codd en los 70s como parte del modelo relacional. Las primeras tres formas normales (1FN, 2FN, 3FN) son las más utilizadas en aplicaciones prácticas.

Conceptos Fundamentales

Dependencia Funcional

Cuando el valor de un atributo determina otro (ej: ID → Nombre)

Clave Candidata

Atributo(s) que identifican registros únicamente

Clave Primaria

Clave candidata seleccionada como identificador principal

Jerarquía de Formas Normales

BCNF
3FN
2FN
1FN

Formas Normales en Profundidad

1FN - Primera Forma Normal

Regla: Todos los atributos son atómicos (indivisibles)

Ejemplo:

IDNombreTeléfonos (NO 1FN)
1Ana555-1234, 555-5678

➔ Dividir en múltiples registros

2FN - Segunda Forma Normal

Regla: Cumple 1FN + atributos dependen de toda clave primaria

Ejemplo problema:

ID_OrdenID_ProductoCantidadNombre_Producto
100P0012Laptop

➔ Separar en tablas Ordenes y Productos

3FN - Tercera Forma Normal

Regla: Cumple 2FN + no hay dependencias transitivas

Ejemplo problema:

ID_EmpleadoDepartamentoJefe_Departamento
E01VentasJuan Pérez

➔ Crear tabla Departamentos separada

Actividad Práctica: Normalización Paso a Paso

Paso 1: Tabla No Normalizada

CREATE TABLE Pedidos (
    id_pedido INT,
    fecha DATE,
    id_cliente INT,
    nombre_cliente VARCHAR(100),
    direccion_cliente VARCHAR(200),
    id_producto INT,
    nombre_producto VARCHAR(100),
    categoria_producto VARCHAR(50),
    precio DECIMAL(10,2),
    cantidad INT
);

🔴 Problemas detectados: Redundancia de datos, atributos no atómicos, dependencias parciales.

Paso 2: Aplicar 1FN

-- Separar direcciones compuestas
CREATE TABLE Pedidos_1FN (
    id_pedido INT,
    fecha DATE,
    id_cliente INT,
    nombre_cliente VARCHAR(100),
    calle_cliente VARCHAR(100),
    ciudad_cliente VARCHAR(50),
    cp_cliente VARCHAR(10),
    -- ... otros campos
);

Paso 3: Aplicar 2FN

-- Crear tablas separadas
CREATE TABLE Clientes (
    id_cliente INT PRIMARY KEY,
    nombre VARCHAR(100),
    calle VARCHAR(100),
    ciudad VARCHAR(50),
    cp VARCHAR(10)
);

CREATE TABLE Productos (
    id_producto INT PRIMARY KEY,
    nombre VARCHAR(100),
    categoria VARCHAR(50),
    precio DECIMAL(10,2)
);

CREATE TABLE Pedidos_2FN (
    id_pedido INT PRIMARY KEY,
    fecha DATE,
    id_cliente INT,
    FOREIGN KEY (id_cliente) REFERENCES Clientes(id_cliente)
);

Paso 4: Aplicar 3FN

-- Eliminar dependencia transitiva categoría→precio
CREATE TABLE Categorias (
    id_categoria INT PRIMARY KEY,
    nombre VARCHAR(50),
    margen_ganancia DECIMAL(5,2)
);

ALTER TABLE Productos
ADD COLUMN id_categoria INT,
ADD FOREIGN KEY (id_categoria) REFERENCES Categorias(id_categoria);

Resultado Final Normalizado

Diagrama ER normalizado

Resumen y Buenas Prácticas

📌 Cuándo Normalizar

  • Sistemas transaccionales (OLTP)
  • Cuando la integridad es crítica
  • Para evitar redundancias

⚠️ Cuándo Desnormalizar

  • Sistemas analíticos (OLAP)
  • Para optimizar consultas frecuentes
  • En reporting de solo lectura

Guía Rápida de Formas Normales

Forma Normal Regla Solución Típica
1FN Atributos atómicos Dividir campos compuestos
2FN Dependencia completa Separar en tablas relacionadas
3FN No dependencias transitivas Extraer entidades independientes

Ampliación: Formas Normales Avanzadas

Forma Normal de Boyce-Codd (BCNF)

Versión reforzada de 3FN que maneja casos especiales de dependencias funcionales.

Ejemplo: Cuando un atributo no clave determina parte de una clave candidata.

4FN y 5FN

Tratan dependencias multivaluadas y de reunión, usadas en diseños muy especializados.

Aplicación: Sistemas complejos con relaciones muchos-a-muchos multidimensionales.

Evolución del Proceso

Evolución formas normales
↑ Volver arriba

Aplicación Práctica de la Normalización

1FN: Primera Forma Normal

Antes de 1FN

Tabla Estudiantes (No Normalizada)
ID Nombre Teléfonos Cursos
E101 Ana García 555-1234, 555-5678 Matemáticas:8.5, Física:7.9
Problemas:
  • Teléfonos como lista separada por comas
  • Cursos como campo compuesto
  • Datos no atómicos
1FN

Después de 1FN

Estudiantes
ID Nombre
E101 Ana García
Teléfonos
ID_Estudiante Teléfono
E101 555-1234
E101 555-5678
Calificaciones
ID_Estudiante Curso Nota
E101 Matemáticas 8.5
E101 Física 7.9
Beneficios:
  • Datos atómicos en cada campo
  • Eliminación de listas/composiciones
  • Búsquedas más eficientes

Implementación SQL

-- Estructura 1FN
CREATE TABLE Estudiantes (
    ID_Estudiante VARCHAR(10) PRIMARY KEY,
    Nombre VARCHAR(100)
);

CREATE TABLE Telefonos (
    ID_Estudiante VARCHAR(10),
    Telefono VARCHAR(15),
    PRIMARY KEY (ID_Estudiante, Telefono),
    FOREIGN KEY (ID_Estudiante) REFERENCES Estudiantes(ID_Estudiante)
);

CREATE TABLE Calificaciones (
    ID_Estudiante VARCHAR(10),
    Curso VARCHAR(50),
    Nota DECIMAL(3,1),
    PRIMARY KEY (ID_Estudiante, Curso),
    FOREIGN KEY (ID_Estudiante) REFERENCES Estudiantes(ID_Estudiante)
);

2FN: Segunda Forma Normal

Antes de 2FN

Pedidos_Productos (Parcialmente Normalizada)
ID_Pedido Fecha ID_Producto Nombre_Producto Categoría Cantidad
P1001 2023-05-10 PRD001 Laptop Elite Electrónica 2
Problemas:
  • Nombre_Producto depende solo de ID_Producto
  • Redundancia en datos de productos
  • Dependencia parcial de la clave compuesta
2FN

Después de 2FN

Pedidos
ID_Pedido Fecha
P1001 2023-05-10
Productos
ID_Producto Nombre Categoría
PRD001 Laptop Elite Electrónica
Detalle_Pedidos
ID_Pedido ID_Producto Cantidad
P1001 PRD001 2
Beneficios:
  • Eliminación de redundancias
  • Dependencias completas de claves
  • Actualizaciones más eficientes

Implementación SQL

-- Estructura 2FN
CREATE TABLE Pedidos (
    ID_Pedido VARCHAR(10) PRIMARY KEY,
    Fecha DATE
);

CREATE TABLE Productos (
    ID_Producto VARCHAR(10) PRIMARY KEY,
    Nombre VARCHAR(100),
    Categoría VARCHAR(50)
);

CREATE TABLE Detalle_Pedidos (
    ID_Pedido VARCHAR(10),
    ID_Producto VARCHAR(10),
    Cantidad INT,
    PRIMARY KEY (ID_Pedido, ID_Producto),
    FOREIGN KEY (ID_Pedido) REFERENCES Pedidos(ID_Pedido),
    FOREIGN KEY (ID_Producto) REFERENCES Productos(ID_Producto)
);

3FN: Tercera Forma Normal

Antes de 3FN

Empleados_Departamentos
ID_Empleado Nombre Departamento Jefe_Departamento Teléfono_Jefe
EMP101 Carlos Ruiz Ventas María López 555-9876
Problemas:
  • Teléfono_Jefe depende de Jefe_Departamento
  • Jefe_Departamento depende de Departamento
  • Dependencias transitivas
3FN

Después de 3FN

Empleados
ID_Empleado Nombre ID_Departamento
EMP101 Carlos Ruiz DEPT01
Departamentos
ID_Departamento Nombre ID_Jefe
DEPT01 Ventas EMP201
Jefes
ID_Jefe Nombre Teléfono
EMP201 María López 555-9876
Beneficios:
  • Eliminación de dependencias transitivas
  • Mayor consistencia en actualizaciones
  • Estructura más flexible

Implementación SQL

-- Estructura 3FN
CREATE TABLE Jefes (
    ID_Jefe VARCHAR(10) PRIMARY KEY,
    Nombre VARCHAR(100),
    Teléfono VARCHAR(15)
);

CREATE TABLE Departamentos (
    ID_Departamento VARCHAR(10) PRIMARY KEY,
    Nombre VARCHAR(50),
    ID_Jefe VARCHAR(10),
    FOREIGN KEY (ID_Jefe) REFERENCES Jefes(ID_Jefe)
);

CREATE TABLE Empleados (
    ID_Empleado VARCHAR(10) PRIMARY KEY,
    Nombre VARCHAR(100),
    ID_Departamento VARCHAR(10),
    FOREIGN KEY (ID_Departamento) REFERENCES Departamentos(ID_Departamento)
);

Resumen Comparativo

Forma Normal Antes Después Beneficio Clave
1FN Campos compuestos/multivalor Datos atómicos en tablas separadas Elimina redundancia horizontal
2FN Dependencias parciales Tablas especializadas Elimina redundancia vertical
3FN Dependencias transitivas Jerarquía de entidades Mayor consistencia

Evolución del Esquema

1FN
Datos atómicos
3 tablas
2FN
Sin dependencias parciales
5 tablas
3FN
Sin dependencias transitivas
7+ tablas
↑ Volver arriba

Desnormalización de Bases de Datos

¿Qué es la Desnormalización?

Técnica que introduce redundancia controlada en un diseño de base de datos previamente normalizado, con el objetivo de:

Mejorar el rendimiento de consultas

📊

Optimizar sistemas de reporting

🔍

Simplificar consultas complejas

Base de Datos Normalizada

  • Estructura lógica sin redundancia
  • Óptima para transacciones (OLTP)
  • Múltiples JOINs en consultas

Base de Datos Desnormalizada

  • Redundancia estratégica
  • Óptima para análisis (OLAP)
  • Menos JOINs, más rápido acceso

Técnicas de Desnormalización

1. Duplicación de Columnas

Escenario:

Consultas frecuentes que necesitan el nombre del cliente junto con los pedidos

Diseño Normalizado
SELECT p.id, p.fecha, c.nombre
FROM pedidos p
JOIN clientes c ON p.cliente_id = c.id;
Diseño Desnormalizado
ALTER TABLE pedidos
ADD COLUMN cliente_nombre VARCHAR(100);

-- Actualizado con trigger
CREATE TRIGGER actualizar_nombre_cliente
AFTER INSERT ON pedidos
FOR EACH ROW
UPDATE pedidos 
SET cliente_nombre = (SELECT nombre FROM clientes WHERE id = NEW.cliente_id)
WHERE id = NEW.id;

Ventaja: Elimina JOIN en consultas frecuentes

⚠️

Costo: Requiere actualización cuando cambia el nombre

2. Tablas Agregadas

Escenario:

Reportes que calculan totales de ventas por producto

Diseño Normalizado
SELECT p.id, p.nombre, SUM(dp.cantidad) as total_vendido
FROM productos p
JOIN detalles_pedido dp ON p.id = dp.producto_id
GROUP BY p.id, p.nombre;
Diseño Desnormalizado
CREATE TABLE resumen_ventas (
  producto_id INT PRIMARY KEY,
  nombre_producto VARCHAR(100),
  total_vendido INT,
  ultima_actualizacion TIMESTAMP
);

-- Actualizado por job nocturno o triggers

Ventaja: Consultas instantáneas de métricas

⚠️

Costo: Datos pueden estar ligeramente desactualizados

3. Jerarquías Aplanadas

Escenario:

Consultas que acceden frecuentemente a datos de tablas relacionadas

Diseño Normalizado
SELECT a.titulo, u.nombre, c.nombre as categoria
FROM articulos a
JOIN usuarios u ON a.autor_id = u.id
JOIN categorias c ON a.categoria_id = c.id;
Diseño Desnormalizado
ALTER TABLE articulos
ADD COLUMN autor_nombre VARCHAR(100),
ADD COLUMN categoria_nombre VARCHAR(50);

-- Actualizado con triggers o aplicación

Ventaja: Elimina múltiples JOINs

⚠️

Costo: Mayor espacio y complejidad en actualizaciones

Casos de Uso en Sistemas Reales

Product Page de E-Commerce

Problema:

La página de producto requiere datos de 5 tablas diferentes, causando alta latencia.

Solución:
CREATE TABLE producto_detalle (
  producto_id INT PRIMARY KEY,
  nombre VARCHAR(200),
  descripcion TEXT,
  precio DECIMAL(10,2),
  categoria_nombre VARCHAR(50),
  promedio_valoracion DECIMAL(3,2),
  inventario INT,
  atributos JSON, -- {color: "rojo", talla: "XL"}
  ultima_actualizacion TIMESTAMP
);
1200ms → 200ms Tiempo de carga
8 → 1 JOINs eliminados

Feed de Noticias

Problema:

El feed requiere unir datos de usuarios, publicaciones, likes y comentarios.

Solución:
CREATE TABLE feed_usuario (
  usuario_id INT,
  publicacion_id INT,
  contenido TEXT,
  autor_id INT,
  autor_nombre VARCHAR(100),
  autor_foto VARCHAR(255),
  likes INT,
  comentarios INT,
  fecha TIMESTAMP,
  PRIMARY KEY (usuario_id, publicacion_id)
);
3.2s → 450ms Tiempo de carga
+15% Retención usuarios

Dashboard Analítico

Problema:

Reportes ejecutivos tardan minutos en generarse por agregaciones complejas.

Solución:
CREATE TABLE snapshot_metricas (
  fecha DATE PRIMARY KEY,
  ventas_totales DECIMAL(12,2),
  nuevos_usuarios INT,
  pedidos_completados INT,
  productos_populares JSON,
  metricas_region JSON,
  actualizado_a TIMESTAMP
);
4.5min → 2s Generación reporte
98% Reducción CPU

Patrones Arquitectónicos para Desnormalización

1. CQRS (Segregación de Responsabilidades)

Lado de Comando
Modelo Normalizado
Transacciones
Validaciones
⇨ Sincronización ⇨
Lado de Consulta
Modelo Desnormalizado
Vistas Optimizadas
Read-Only
Cuándo usarlo:
  • Sistemas con alta frecuencia de lecturas
  • Cuando las consultas necesitan datos de múltiples agregados
  • Aplicaciones con requisitos complejos de reporting

2. Event Sourcing + Proyecciones

Event Store
Pedido Creado
Item Añadido
Pedido Completado
⇨ Proyecciones ⇨
Vista Pedidos
Resumen Cliente
Inventario
Cuándo usarlo:
  • Cuando necesitas reconstruir estados pasados
  • Sistemas con auditoría crítica
  • Cuando las vistas necesitan combinaciones personalizadas de datos

Ejercicio Práctico: Sistema de Blog

Escenario Actual (Normalizado)

usuarios(id, nombre, email)
articulos(id, titulo, contenido, autor_id, categoria_id)
categorias(id, nombre)
comentarios(id, contenido, articulo_id, usuario_id, fecha)
likes(articulo_id, usuario_id, fecha)

Problema: La página de artículo requiere unir todas estas tablas, causando alta latencia (~1.2s).

Propuesta de Solución

CREATE TABLE vista_articulo (
  articulo_id INT PRIMARY KEY,
  titulo VARCHAR(200),
  contenido TEXT,
  autor_id INT,
  autor_nombre VARCHAR(100),
  categoria_id INT,
  categoria_nombre VARCHAR(50),
  total_comentarios INT,
  total_likes INT,
  ultimos_comentarios JSON, -- [{usuario: "Ana", texto: "..."}]
  fecha_actualizacion TIMESTAMP
);

-- Mecanismos de actualización:
-- 1. Trigger al publicar/editar artículo
-- 2. Job periódico para contadores
-- 3. Eventos en tiempo real para comentarios recientes
Resultados Esperados:
  • Reducción de JOINs: 5 → 0
  • Tiempo de carga: 1200ms → ~200ms
  • Consistencia: Actualización casi en tiempo real
↑ Volver arriba

Actividad Práctica: Desnormalización Controlada

Contexto: Sistema de Biblioteca

Problema Actual

La consulta del catálogo público requiere 4 JOINs, tardando 1.8 segundos con 10k libros.

SELECT 
  l.titulo, 
  a.nombre AS autor, 
  e.nombre AS editorial,
  COUNT(ej.id) AS copias_disponibles
FROM libros l
JOIN autores a ON l.autor_id = a.id
JOIN editoriales e ON l.editorial_id = e.id
LEFT JOIN ejemplares ej ON l.id = ej.libro_id 
WHERE ej.disponible = true
GROUP BY l.id, a.nombre, e.nombre;

Objetivo

  • Reducir tiempo de consulta a menos de 300ms
  • Mantener datos actualizados con máximo 5min de desfase
  • Minimizar impacto en escrituras
1

Paso 1: Análisis de Tablas Normalizadas

LIBROS
id
titulo
autor_id (FK)
editorial_id (FK)
isbn
1:N
AUTORES
id
nombre
nacionalidad
EDITORIALES
id
nombre
pais
1:N
EJEMPLARES
id
libro_id (FK)
disponible
ubicacion

Puntos Críticos

🔍

JOINs costosos para datos estáticos (autor, editorial)

🔄

COUNT sobre ejemplares en cada consulta

📊

Datos cambian ≤5 veces/hora (oportunidad para cache)

2

Paso 2: Diseño de Tabla Desnormalizada

Estrategia

  1. Duplicar nombre_autor y nombre_editorial
  2. Precalcular copias_disponibles
  3. Actualizar mediante trigger + job periódico

Nuevo Esquema

CATALOGO_LIBROS
libro_id
titulo
autor_id
autor_nombre
editorial_id
editorial_nombre
copias_disponibles
ultima_actualizacion

Comparación Visual

Normalizado
Esquema normalizado

⏱️ 1800ms

Desnormalizado
Esquema desnormalizado

⏱️ 250ms

3

Paso 3: Implementación SQL

1. Crear Tabla Desnormalizada

CREATE TABLE catalogo_libros (
  libro_id INT PRIMARY KEY,
  titulo VARCHAR(200),
  autor_id INT,
  autor_nombre VARCHAR(100),
  editorial_id INT,
  editorial_nombre VARCHAR(100),
  copias_disponibles INT,
  ultima_actualizacion TIMESTAMP
);

2. Trigger para Cambios en Libros

CREATE TRIGGER actualizar_catalogo
AFTER INSERT OR UPDATE ON libros
FOR EACH ROW
INSERT INTO catalogo_libros (
  libro_id, titulo, autor_id, autor_nombre, 
  editorial_id, editorial_nombre, ultima_actualizacion
)
SELECT 
  l.id, l.titulo, l.autor_id, a.nombre,
  l.editorial_id, e.nombre, NOW()
FROM libros l
JOIN autores a ON l.autor_id = a.id
JOIN editoriales e ON l.editorial_id = e.id
WHERE l.id = NEW.id
ON DUPLICATE KEY UPDATE
  titulo = VALUES(titulo),
  autor_nombre = VALUES(autor_nombre),
  editorial_nombre = VALUES(editorial_nombre),
  ultima_actualizacion = NOW();

3. Job Periódico para Disponibilidad

-- Ejecutar cada 5 minutos
UPDATE catalogo_libros cl
JOIN (
  SELECT libro_id, COUNT(*) AS disponibles
  FROM ejemplares
  WHERE disponible = true
  GROUP BY libro_id
) ej ON cl.libro_id = ej.libro_id
SET cl.copias_disponibles = ej.disponibles,
    cl.ultima_actualizacion = NOW();
4

Paso 4: Medición de Resultados

7.2x
Mejora de velocidad
5 min
Máximo desfase
+12%
CPU reducido

Comparación de Consultas

Antes
SELECT l.titulo, a.nombre, e.nombre, 
       COUNT(ej.id) AS disponibles
FROM libros l
JOIN autores a ON l.autor_id = a.id
JOIN editoriales e ON l.editorial_id = e.id
LEFT JOIN ejemplares ej ON l.id = ej.libro_id 
WHERE ej.disponible = true
GROUP BY l.id, a.nombre, e.nombre;

⏱️ 1800ms

Después
SELECT 
  titulo, 
  autor_nombre, 
  editorial_nombre,
  copias_disponibles
FROM catalogo_libros;

⏱️ 250ms

Ejercicio: Aplicar a Sistema de Pedidos

Escenario

Tabla pedidos normalizada con múltiples JOINs para reportes:

pedidos(id, cliente_id, fecha)
clientes(id, nombre, email)
detalles_pedido(id, pedido_id, producto_id, cantidad)
productos(id, nombre, precio)

Tareas

  1. Diseñar tabla desnormalizada para reportes
  2. Definir mecanismos de actualización
  3. Calcular impacto esperado
-- Solución Propuesta
CREATE TABLE reporte_pedidos (
  pedido_id INT PRIMARY KEY,
  fecha DATE,
  cliente_id INT,
  cliente_nombre VARCHAR(100),
  total_productos INT,
  monto_total DECIMAL(10,2),
  ultima_actualizacion TIMESTAMP
);

-- Actualización con:
-- 1. Trigger al crear pedido
-- 2. Job nocturno para recálculos
-- 3. Eventos para clientes VIP

Métricas Esperadas:

  • Reducción de 4 JOINs a 0
  • Tiempo de consulta de 3s → ~400ms
  • Actualización horaria
↑ Volver arriba

Diapositivas

↑ Volver arriba

Cuestionario: Diseño de BD

1. ¿Cuál es la primera etapa del diseño de bases de datos?

2. ¿Qué se hace durante el diseño lógico?

3. ¿Cuál es el objetivo del diseño físico?

4. ¿Qué busca evitar la teoría de la normalización?

5. ¿Qué condición debe cumplir una tabla en 1FN?

6. ¿Qué requiere la 2FN además de cumplir la 1FN?

7. ¿Qué se elimina al alcanzar la 3FN?

8. ¿Qué añade la forma normal de Boyce-Codd respecto a la 3FN?

9. ¿Qué tipo de dependencia se elimina en la cuarta forma normal (4FN)?

10. ¿Qué elimina la quinta forma normal (5FN)?

11. ¿Qué caracteriza a una relación desnormalizada?

12. ¿Cuándo se recomienda desnormalizar?

13. ¿Qué es una dependencia funcional?

14. ¿Qué ocurre si una tabla no está normalizada?

15. ¿Qué es una clave candidata?

16. ¿Cuál de los siguientes es un objetivo del diseño conceptual?

17. ¿Qué representa una entidad en un modelo ER?

18. ¿Qué herramienta se usa comúnmente en el diseño conceptual?

19. ¿Qué permite identificar la relación entre entidades?

20. ¿Cuál de los siguientes es un beneficio de la normalización?

Nº de Test: 0

Instrucciones:

  • Enviar Respuestas: Corrige el cuestionario actual, muestra los aciertos, fallos y calificación de este intento.
  • Reiniciar: Borra las respuestas marcadas en esta sesión, incrementa el contador de reinicios, pero no elimina los datos de los intentos.
  • Finalizar: Calcula la nota media de todos los intentos realizados hasta ahora y muestra un resumen general.
  • Reiniciar Todo: Borra todos los datos almacenados (reinicios, intentos, calificaciones) y reinicia el cuestionario completamente.
↑ Índice de Contenidos
↑ Volver arriba