¿Qué es la Normalización (o Normalización)? [cerrado]
¿Por qué los chicos de bases de datos siguen hablando de normalización?
¿Qué es? ¿Cómo ayuda?
¿Se aplica a algo fuera de las bases de datos?
La normalización consiste básicamente en diseñar un esquema de base de datos de modo que se eviten datos duplicados y redundantes. Si la misma información se repite en varios lugares de la base de datos, existe el riesgo de que se actualice en un lugar pero no en el otro, lo que provocará corrupción de datos.
Hay varios niveles de normalización desde 1. forma normal hasta 5. forma normal. Cada forma normal describe cómo deshacerse de algún problema específico.
La primera forma normal (1NF) es especial porque no se trata de redundancia. 1NF no permite tablas anidadas, más específicamente columnas que permiten tablas como valores. En primer lugar, SQL no admite tablas anidadas, por lo que la mayoría de las bases de datos relacionales normales estarán en 1NF de forma predeterminada. Así que podemos ignorar 1NF durante el resto de las discusiones.
Las formas normales 2NF a 5NF se refieren a escenarios en los que la misma información se representa varias veces en la misma tabla.
Por ejemplo, considere una base de datos de lunas y planetas:
Moon(PK) | Planet | Planet kind
------------------------------
Phobos | Mars | Rock
Daimos | Mars | Rock
Io | Jupiter | Gas
Europa | Jupiter | Gas
Ganymede | Jupiter | Gas
La redundancia es obvia: el hecho de que Júpiter sea un planeta gaseoso se repite tres veces, una por cada luna. Esto es una pérdida de espacio, pero lo que es mucho más grave es que este esquema hace posible información inconsistente :
Moon(PK) | Planet | Planet kind
------------------------------
Phobos | Mars | Rock
Deimos | Mars | Rock
Io | Jupiter | Gas
Europa | Jupiter | Rock <-- Oh no!
Ganymede | Jupiter | Gas
Ahora una consulta puede dar resultados inconsistentes que pueden tener consecuencias desastrosas.
(Por supuesto, una base de datos no puede proteger contra la introducción de información incorrecta , pero puede proteger contra información inconsistente , que es un problema igualmente grave).
El diseño normalizado dividiría la tabla en dos tablas:
Moon(PK) | Planet(FK) Planet(PK) | Planet kind
--------------------- ------------------------
Phobos | Mars Mars | Rock
Deimos | Mars Jupiter | Gas
Io | Jupiter
Europa | Jupiter
Ganymede | Jupiter
Ahora ningún hecho se repite varias veces, por lo que no hay posibilidad de que haya datos inconsistentes. (Puede parecer que todavía hay cierta repetición ya que los nombres de los planetas se repiten, pero repetir valores de clave primaria como claves externas no viola la normalización ya que no introduce un riesgo de datos inconsistentes).
Regla general Si la misma información se puede representar con menos valores de celda individuales, sin contar las claves externas, entonces la tabla debe normalizarse dividiéndola en más tablas. Por ejemplo, la primera tabla tiene 12 valores individuales, mientras que las dos tablas solo tienen 9 valores individuales (no FK). Esto significa que eliminamos 3 valores redundantes.
Sabemos que la misma información sigue ahí, ya que podemos escribir una joinconsulta que devuelva los mismos datos que la tabla original no normalizada.
¿Cómo evito este tipo de problemas? Los problemas de normalización se evitan fácilmente dándole un poco de reflexión al modelo conceptual, por ejemplo dibujando un diagrama entidad-relación. Los planetas y las lunas tienen una relación de uno a muchos, lo que significa que deben representarse en dos tablas diferentes con una asociación de clave externa. Los problemas de normalización ocurren cuando varias entidades con una relación de uno a muchos o de muchos a muchos se representan en la misma fila de la tabla.
¿Es importante la normalización? Sí, es muy importante. Al tener una base de datos con errores de normalización, se corre el riesgo de introducir datos no válidos o corruptos en la base de datos. Dado que los datos "viven para siempre", es muy difícil deshacerse de los datos corruptos cuando ingresan por primera vez a la base de datos.
Pero realmente no creo que sea importante distinguir entre las diferentes formas normales, desde 2NF hasta 5NF. Por lo general, es bastante obvio cuando un esquema contiene redundancias: si se viola 3NF o 5NF es menos importante siempre que se solucione el problema.
(También hay algunas formas normales adicionales como DKNF y 6NF que solo son relevantes para sistemas de propósito especial como almacenes de datos).
No tengas miedo de la normalización . Las definiciones técnicas oficiales de los niveles de normalización son bastante obtusas. Parece que la normalización es un proceso matemático complicado. Sin embargo, la normalización es básicamente cuestión de sentido común, y descubrirá que si diseña un esquema de base de datos utilizando el sentido común, normalmente estará completamente normalizado.
Existen varios conceptos erróneos sobre la normalización:
algunos creen que las bases de datos normalizadas son más lentas y que la desnormalización mejora el rendimiento. Sin embargo, esto sólo es cierto en casos muy especiales. Normalmente, una base de datos normalizada también es la más rápida.
A veces, la normalización se describe como un proceso de diseño gradual y hay que decidir "cuándo detenerse". Pero en realidad los niveles de normalización simplemente describen diferentes problemas específicos. Los problemas resueltos por formas normales por encima del 3er NF son problemas bastante raros en primer lugar, por lo que es probable que su esquema ya esté en 5NF.
¿Se aplica a algo fuera de las bases de datos? No directamente, no. Los principios de normalización son bastante específicos para bases de datos relacionales. Sin embargo, el tema general subyacente (que no se deben tener datos duplicados si las diferentes instancias pueden desincronizarse) se puede aplicar ampliamente. Este es básicamente el principio DRY .
Lo más importante es que sirve para eliminar la duplicación de los registros de la base de datos. Por ejemplo, si tiene más de un lugar (tablas) donde podría aparecer el nombre de una persona, mueva el nombre a una tabla separada y haga referencia a él en cualquier otro lugar. De esta manera, si necesitas cambiar el nombre de la persona más adelante, solo tendrás que cambiarlo en un lugar.
Es crucial para el diseño adecuado de la base de datos y, en teoría, debería utilizarlo tanto como sea posible para mantener la integridad de sus datos. Sin embargo, al recuperar información de muchas tablas, se pierde algo de rendimiento y es por eso que a veces se pueden ver tablas de bases de datos desnormalizadas (también llamadas aplanadas) utilizadas en aplicaciones críticas para el rendimiento.
Mi consejo es comenzar con un buen grado de normalización y solo desnormalizar cuando sea realmente necesario.
PD: consulte también este artículo: http://en.wikipedia.org/wiki/Database_normalization para leer más sobre el tema y sobre las llamadas formas normales.
