Pregunta clásica de diseño que sigue generando dudas: ¿hasta qué forma normal merece la pena llegar en un proyecto real, no en un examen?
La primera forma normal (sin valores repetidos ni listas dentro de una misma columna) y la segunda (sin dependencias parciales de una clave compuesta) casi nunca se discuten, son de sentido común una vez las entiendes y evitan problemas reales de integridad.
La tercera forma normal (sin dependencias transitivas, cada columna depende solo de la clave, no de otra columna que a su vez depende de la clave) es donde para la mayoría de proyectos tiene sentido detenerse. Más allá de ahí (Boyce-Codd, cuarta, quinta forma normal) existen y tienen su utilidad en casos concretos, pero en la práctica del día a día rara vez compensan la complejidad extra que añaden a las consultas.
Y después está la desnormalización deliberada: en tablas de lectura intensiva (dashboards, reportes), duplicar deliberadamente algo de dato para evitar un JOIN costoso puede compensar, siempre que sea una decisión consciente y documentada, no el resultado de no haber normalizado nunca.
Mi regla práctica: normalizar hasta 3FN por defecto, y desnormalizar puntos muy concretos solo cuando un problema de rendimiento real (no hipotético) lo justifique, nunca al revés.
¿Alguna vez os arrepentisteis de desnormalizar demasiado pronto?
Pablo
En la práctica, tercera forma normal es el punto donde yo también me quedo para el grueso del modelo. Llegar más allá (BCNF, cuarta forma normal) casi siempre es más un ejercicio académico que algo que aporte valor real en un sistema transaccional normal, y el coste en JOINs adicionales no suele compensar la pureza teórica ganada.
Lo que sí hago de forma consciente es desnormalizar puntos muy concretos, casi siempre relacionados con lectura intensiva: tablas de reporting/agregados que se recalculan periódicamente, o algún campo calculado que se consulta constantemente y cuyo cálculo en tiempo real sería costoso. La clave para mí es que la desnormalización sea una decisión explícita y documentada (con su proceso de sincronización claro), no algo que se cuela poco a poco en el diseño porque "así es más rápido escribir la query".
Sara