DP-900: comprender y usar la normalización en bases de datos relacionales
Voy a enseñar la competencia de normalización de esquemas relacionales (1NF–3NF) — una habilidad clave en la sección "Datos relacionales en Azure" del DP-900. Saber normalizar te ayuda a diseñar bases de datos eficientes y a reducir la redundancia, lo cual importa tanto para el examen como para soluciones reales en Azure SQL Database o en SQL Server. Además de teoría, explico pasos concretos, trade-offs de rendimiento y formas prácticas de experimentar en un entorno Azure o local.
Qué necesitas saber
La normalización es un conjunto de reglas para organizar atributos y tablas con el fin de reducir la redundancia y evitar anomalías de inserción/actualización/eliminación. Las formas normales más relevantes para el nivel Fundamentals son:
- 1NF (Primera Forma Normal): cada columna debe contener valores atómicos (sin listas ni estructuras) y cada fila debe ser única (clave primaria). Por ejemplo, no pongas una columna "Products" con una lista separada por comas — cada producto debe ser una fila.
- 2NF (Segunda Forma Normal): además de estar en 1NF, todos los atributos no clave deben depender totalmente de la clave primaria. Esto es importante especialmente cuando tienes claves compuestas (por ejemplo, OrderID + ProductID). La 2NF elimina dependencias parciales que causan repetición innecesaria.
- 3NF (Tercera Forma Normal): además de 2NF, no puede haber dependencias transitivas entre atributos no clave. Es decir, un atributo no clave no debe depender de otro atributo no clave; si eso ocurre, mueve esa parte a una nueva tabla.
Ejemplo simple: un registro de pedidos. Un esquema no normalizado puede tener: OrderID, CustomerName, CustomerAddress, ProductID, ProductName, Quantity en una única tabla. Esto causa redundancia — si un pedido tiene 5 líneas (5 productos), los datos del cliente se repiten 5 veces. En conjuntos de datos reales (por ejemplo, 100 000 filas de pedidos) esta repetición puede aumentar el espacio usado y complicar actualizaciones: cambiar la dirección del cliente exigiría actualizar muchas filas.
Cómo funciona (paso a paso)
Sigue un proceso práctico para normalizar hasta 3NF, usando un ejemplo de Pedidos:
- Identificar entidades y repeticiones: examina los datos y separa conceptos — Pedido, Cliente, Producto. Cuenta cuántas veces se repite cada dato (por ejemplo, si el 10% de las filas repite el mismo CustomerName, es señal de redundancia).
- Asegurar 1NF: reemplazar campos multivalorados por filas separadas. Si el pedido tiene varios productos, cada producto es una fila en OrderItems con OrderID repetido pero clave compuesta (OrderID, ProductID). Esto transforma listas en registros atómicos.
- Aplicar 2NF: detectar claves compuestas. Si OrderItems usa (OrderID, ProductID) como clave, atributos como ProductName o UnitPrice no deben depender solo de una parte (ProductID). Moviéndolos a una tabla Products evitas la repetición de nombre y precio en cada línea de pedido.
- Aplicar 3NF: eliminar dependencias transitivas. Si en la tabla Customers existe
CustomerCityyCityRegion, y CityRegion depende de City, crea una tabla Cities (CityID, CityName, Region) y referencia por clave. Así, cambios en la región provocan una sola modificación.
-- Esquema normalizado (ejemplo conceptual)
Customers(CustomerID PK, CustomerName, CustomerAddress)
Products(ProductID PK, ProductName, UnitPrice)
Orders(OrderID PK, OrderDate, CustomerID FK)
OrderItems(OrderID FK, ProductID FK, Quantity, PRIMARY KEY(OrderID, ProductID))
Este diseño centraliza la información del cliente y del producto, facilitando el mantenimiento y permitiendo la aplicación de constraints y transacciones para mantener la integridad en Azure SQL Database.
En la práctica — recomendaciones para Azure
Cuando implementes en Azure SQL Database o en Managed Instance, considera estos puntos prácticos:
- Define claves primarias y foráneas para reforzar la integridad referencial; esto permite al motor del SQL validar relaciones automáticamente.
- Crea índices en columnas de unión (por ejemplo, un non-clustered index en Orders.CustomerID) para acelerar joins; sin índices, una query de join puede costar varios cientos de ms o más en tablas grandes.
- Analiza el plan de ejecución (Query Plan) para entender el coste de los joins; si una consulta de lectura crítica hace 5 joins y está lenta, considera materializar resultados con vistas indexadas o desnormalización controlada.
- Equilibra normalización con requisitos de rendimiento: en escenarios de lectura intensiva (por ejemplo, informes en Power BI), cierta desnormalización (duplicar un campo que rara vez cambia) puede reducir 2–3 joins y acelerar consultas de lectura; documenta siempre las razones e impactos en las operaciones de escritura.
Errores comunes
Algunas trampas típicas y cómo evitarlas:
- Confundir normalización con eliminación total de la duplicación: normalizar hasta formas muy avanzadas puede crear demasiadas tablas y muchos joins, penalizando las lecturas. Evalúa el equilibrio entre escritura y lectura.
- Olvidar claves naturales frente a claves artificiales: usar nombre o email como clave natural puede romper la integridad si el valor cambia. Prefiere claves sustitutas (IDs enteros autoincrementados) para estabilidad y rendimiento en joins.
- Ignorar operaciones de lectura/escritura: normalizar en exceso aumenta el número de operaciones de escritura (más tablas que actualizar) y puede inducir contención. Prueba con cargas representativas (por ejemplo, 1000 inserts/sec) para medir el impacto.
Cómo practicar
Practica modelado y normalización usando un entorno de pruebas en Azure (por ejemplo, una instancia de Azure SQL Database en la capa gratuita/créditos) o un servidor local con SQL Server Developer. Pasos sugeridos:
- Crea un esquema desnormalizado, puebla con algunos miles de filas (por ejemplo 10k–100k) y mide el tamaño y tiempos de consultas básicas (SELECT, UPDATE).
- Normaliza a 3NF según el proceso anterior, puebla las tablas normalizadas y compara espacio ocupado, tiempo de consultas y número de joins. Documenta diferencias porcentuales — en muchos casos observarás reducción de redundancia y facilitación de actualizaciones, y un pequeño aumento en el coste de lectura si no hay índices apropiados.
- Usa las herramientas de monitorización de Azure (Query Performance Insight, Query Store) para analizar queries reales.
Para la preparación del examen: usa el Practice Assessment OFICIAL de Microsoft (gratuito) y la study guide oficial de Microsoft (gratuita). Estos recursos te ayudan a verificar los conocimientos medidos sin recurrir a material prohibido.
En resumen
- La normalización (1NF–3NF) organiza datos para reducir la redundancia y evitar anomalías de datos.
- 1NF exige valores atómicos; 2NF elimina dependencias parciales; 3NF remueve dependencias transitivas.
- En Azure SQL Database, combina normalización con índices e integridad referencial para lograr buen rendimiento; prueba con cargas reales y ajusta si es necesario.
- Practica con esquemas reales y usa los recursos oficiales gratuitos de Microsoft para preparar el DP-900, respetando siempre las buenas prácticas de modelado y evaluación de rendimiento.