Conviene haber comprendido Relaciones y claves.
CONTENIDO ORIGINAL
Avanza en orden. Cada lección está redactada para Palta es Cool, utiliza ejemplos propios y termina con una actividad cuya respuesta puedes desplegar.
ANTES DE EMPEZAR
Ubícate antes de avanzar
Al terminar deberías poder relacionar Historial de cambios con Normalización y resolver un caso nuevo.
Reserva entre 35 y 55 minutos para lectura, ejemplos, tres comprobaciones y cierre.
04 / PREPARA EL LABORATORIO
Las primeras secciones se leen sin instalar nada. Para practicar SQL prepara PostgreSQL o un DBMS equivalente.
Abrir la guía de herramientas →Diagnóstico rápido: ¿cómo se relacionan Historial de cambios y Normalización? ＋
No necesitas acertar todavía. Escribe una hipótesis de dos líneas y compárala con tu respuesta al finalizar; si puedes corregirla y justificar el cambio, hubo aprendizaje.
Aprende el tema paso a paso
Aprenderás a preservar la historia, reducir datos repetidos y convertir reglas del negocio en estructuras físicas verificables.
Al terminar podrás
- El valor actual no siempre cuenta la historia
- Normalizar evita dependencias incorrectas
- La asignación mantiene el significado del diseño
01
Datos que cambian
El valor actual no siempre cuenta la historia
Si una organización necesita saber qué ocurrió y cuándo, sobrescribir un dato elimina evidencia. Se puede registrar cada cambio como un nuevo hecho con fechas de vigencia.
Valor actual: basta cuando el pasado no importa.
Historial: conserva quién, qué y cuándo cambió.
Vigencia: fecha_desde y fecha_hasta sitúan cada valor.
¿Cuándo sería peligroso guardar solo la dirección actual de un cliente?
Mostrar respuesta ＋
Cuando facturas, entregas o auditorías deban reconstruir la dirección utilizada en una fecha pasada.
02
Calidad estructural
Normalizar evita dependencias incorrectas
La normalización separa hechos para que cada uno se almacene donde corresponde. No busca crear tablas por crear, sino impedir anomalías al insertar, actualizar o eliminar.
1FN: un valor por celda, sin grupos repetidos.
2FN: cada atributo depende de toda la clave.
3FN: los atributos no clave no dependen entre sí.
Una tabla DETALLE(id_pedido, id_producto, nombre_producto, cantidad) usa clave compuesta. ¿Qué atributo viola 2FN?
Mostrar respuesta ＋
nombre_producto, porque depende solo de id_producto y no de la clave completa. Debe almacenarse en PRODUCTOS.
03
Del modelo a las tablas
La asignación mantiene el significado del diseño
Al pasar del modelo lógico al físico, las entidades suelen convertirse en tablas, los atributos en columnas y los UID en claves primarias. Las relaciones producen claves foráneas.
Nombre consistente y singular o plural, pero no mezclado.
Cada PK debe ser obligatoria y única.
Cada FK debe apuntar a una PK o clave única compatible.
¿Qué elemento físico representa una relación uno a muchos?
Mostrar respuesta ＋
Una clave foránea en la tabla del lado “muchos”, que referencia la clave primaria del lado “uno”.
Tu recorrido en tres ideas
- El valor actual no siempre cuenta la historia
- Normalizar evita dependencias incorrectas
- La asignación mantiene el significado del diseño
CIERRE DE LA SECCIÓN
Comprueba que puedes usarlo
Antes de continuar, revisa estos tropiezos frecuentes y resuelve un caso sin copiar los ejemplos.
Normalizar de memoria sin identificar primero las dependencias y anomalías.
Sobrescribir un valor cuando el negocio necesita reconstruir la historia.
Ahora hazlo sin guía
Reorganiza una tabla de pedidos que repite nombre de cliente, ciudad y nombre de producto en cada línea.
Mostrar pauta de corrección ＋
Una respuesta sólida:
- Separa hechos de cliente, pedido, producto y detalle.
- Conserva claves que permiten reconstruir el pedido.
- Explica qué anomalía evita cada separación.