Cuando hablamos de analizar una base de datos para ver si cumple las formas normales, nos referimos a estudiar la estructura de las tablas, sus relaciones y las dependencias entre los atributos. El objetivo principal del análisis es encontrar violaciones de normalización y evaluar cómo afectan al rendimiento, la integridad y la facilidad de uso de los datos.
En pocas palabras, es como una auditoría de contabilidad: revisas que el dinero no esté tirado por ahí, sino bien repartido en las partidas correctas.
Enfoque práctico para analizar una base de datos
En cualquier base de datos, empezamos haciéndonos tres preguntas clave, que corresponden a las tres formas normales.
Supongamos que tenemos una base de datos de almacén con una tabla de la siguiente estructura:
| product_id | product_name | supplier_name | supplier_phone | stock_quantity |
|---|---|---|---|---|
| 1 | Clavos | StroyKomplekt | +12301112233 | 150 |
| 2 | Tornillos | KrepyoshPro | +12306667788 | 200 |
| 3 | Tuercas | StroyKomplekt | +12301112233 | 100 |
¿Cómo comprobamos si esta tabla cumple las formas normales?
Recuerda, una tabla está en 1NF si:
- Cada celda contiene un solo valor.
- No hay columnas repetidas para el mismo tipo de datos.
En nuestro ejemplo, no hay violación de la 1NF: cada celda tiene un valor atómico. Eso significa que la tabla está en 1NF. ¡Bien! Vamos al siguiente paso.
Una tabla está en 2NF si:
- Está en 1NF.
- Todos los atributos que no son clave dependen solo de toda la clave primaria (no solo de una parte).
En esta tabla vemos que supplier_name y supplier_phone dependen solo de product_id — la clave primaria. Pero aquí hay duplicación de datos: para el mismo proveedor guardamos su nombre y teléfono en varias filas.
Para llevar la tabla a 2NF, podemos dividirla en dos tablas:
Tabla Products:
| product_id | product_name | supplier_id | stock_quantity |
|---|---|---|---|
| 1 | Clavos | 1 | 150 |
| 2 | Tornillos | 2 | 200 |
| 3 | Tuercas | 1 | 100 |
Tabla Suppliers:
| supplier_id | supplier_name | supplier_phone |
|---|---|---|
| 1 | StroyKomplekt | +78901112233 |
| 2 | KrepyoshPro | +78906667788 |
Ahora cada proveedor aparece solo una vez, y la relación entre tablas se hace a través de la clave foránea supplier_id.
Una tabla está en 3NF si:
- Está en 2NF.
- Todos los atributos que no son clave dependen solo de la clave primaria, y no de otros atributos que no son clave.
En el caso de las tablas normalizadas Products y Suppliers no vemos dependencias transitivas. Eso significa que las tablas están en 3NF.
Ejercicio práctico
Supón que tenemos la tabla original "Universidad"
| student_id | student_name | course_name | professor_name | professor_email |
|---|---|---|---|---|
| 101 | Otto Lin | Matemáticas | Peter Pen | pen@university.com |
| 102 | Anna Song | Física | Alex Sid | sid@university.com |
| 103 | Otto Lin | Física | Alex Sid | sid@university.com |
- Comprueba si la tabla cumple las formas normales.
- Llévala a 1NF, 2NF y 3NF si hace falta.
Solución
PASO 1: Comprobación de 1NF
La tabla ya está en 1NF: cada celda tiene un solo valor.
PASO 2: Comprobación de 2NF
La tabla viola la 2NF: la info de los profes (nombre y email) se repite. Podemos sacarla a una tabla aparte:
Tabla Students:
| student_id | student_name |
|---|---|
| 101 | Otto Lin |
| 102 | Anna Song |
Tabla Courses:
| course_id | course_name | professor_id |
|---|---|---|
| 1 | Matemáticas | 1 |
| 2 | Física | 2 |
Tabla Professors:
| professor_id | professor_name | professor_email |
|---|---|---|
| 1 | Peter Pen | pen@university.com |
| 2 | Alex Sid | sid@university.com |
Tabla Enrollments:
| enrollment_id | student_id | course_id |
|---|---|---|
| 1 | 101 | 1 |
| 2 | 102 | 2 |
| 3 | 103 | 2 |
PASO 3: Comprobación de 3NF
En la nueva estructura no hay dependencias transitivas. Las tablas cumplen la 3NF.
Consejos prácticos
- No busques la perfección si no hace falta. A veces una normalización excesiva complica las consultas.
- Analiza como un detective. Busca duplicados, dependencias innecesarias y otras "anomalías".
- No te olvides del rendimiento. La normalización es un equilibrio entre la pureza de los datos y la velocidad de procesamiento.
Ahora que sabes encontrar problemas en una base de datos y arreglarlos, podrías hacer una "auditoría" honesta de cualquier base, sea del tamaño que sea. Recuerda: una buena base de datos no solo es funcional, sino también bonita (o sea, normalizada).
GO TO FULL VERSION