Diseño de base de datos con desnormalización
Las reglas de normalización no consideran el rendimiento. En algunos casos, es necesario considerar la desnormalización para mejorar el rendimiento.
Durante el diseño físico, los analistas transforman las entidades en tablas y los atributos en columnas. Considere de nuevo el ejemplo del apartado Segunda forma normal. La columna de dirección de almacén aparece primero como parte de una tabla que contiene información sobre componentes y almacenes. Para normalizar adicionalmente el diseño de la tabla, los analistas eliminan la columna de dirección de almacén de la tabla. Los analistas también definen la columna como parte de una tabla que contiene información únicamente sobre almacenes.
La normalización de tablas es la propuesta que se suele recomendar. Pero ¿qué sucede si las aplicaciones necesitan información sobre componentes y almacenes, incluidas las direcciones de los almacenes? La premisa de las reglas de normalización es que las sentencias de SQL pueden recuperar la información uniendo las dos tablas. El problema es que, en algunos casos, se pueden producir problemas de rendimiento como resultado de una normalización. Por ejemplo, algunas consultas de usuario pueden ver datos que están en una o más tablas relacionadas; el resultado es demasiadas uniones. A medida que crece el número de tablas, los costes de acceso pueden aumentar, según el tamaño de las tablas, los índices disponibles, etc. Por ejemplo, si no hay índices disponibles, la unión de numerosas tablas grandes puede tardar demasiado tiempo. Puede que necesite desnormalizar las tablas. La desnormalización es la duplicación intencionada de columnas en varias tablas y esto aumenta la redundancia de datos.
Cuando crea el diseño físico, el usuario y sus colegas necesitan decidir si deben desnormalizarse los datos. Específicamente, necesita decidir si deben combinarse tablas o partes de tablas a las que accedan con frecuencia uniones que tienen requisitos de alto rendimiento. Se trata de una decisión compleja sobre la cual esta información no puede proporcionar un consejo específico. Para tomar esta decisión necesita evaluar los requisitos de rendimiento, los diferentes métodos de acceder a los datos y los costes de desnormalización de los datos. Debe tener en cuenta el coste y el resultado; ¿es la duplicación, en varias tablas, de columnas solicitadas con frecuencia menos costosa que el tiempo de llevar a cabo las uniones?
- No desnormalice tablas a menos que tenga una buena comprensión de los datos y las transacciones empresariales que acceden a los datos. Consulte con los desarrolladores de aplicaciones antes de desnormalizar tablas para mejorar el rendimiento de las consultas de los usuarios.
- Cuando decida si va a desnormalizar una tabla, considere todos los programas que accedan de forma regular a la tabla, tanto para lectura como para actualización. Si los programas actualizan con frecuencia una tabla, la desnormalización de la tabla afecta al rendimiento de los programas de actualización puesto que las actualizaciones se aplican más a varias tablas que a una sola tabla.
En la figura siguiente, la información sobre componentes, almacenes y direcciones de almacenes aparecen en dos tablas, ambas en la forma normal.
![Inicio de la descripción de la figura. Esta figura muestra dos tablas que cumplen la segunda forma normal. Fin de la descripción de la figura.](../art/bkndd012.gif)
La siguiente figura ilustra la tabla desnormalizada.
![Inicio de la descripción de la figura. Esta figura muestra una tabla desnormalizada. Fin de la descripción de la figura.](../art/bkndd013.gif)
La resolución de relaciones de varios con varios es una actividad especialmente importante puesto que ayuda a mantener la claridad e integridad en el diseño físico de bases de datos. Para resolver relaciones de varios con varios, se introducen tablas asociativas, que son tablas intermedias que se utilizan para enlazar, o asociar, dos tablas entre sí.
Otra decisión que debe tomar está relacionada con la utilización de grupos repetitivos.