Normalización
El diseño lógico de la base de datos, que incluye las tablas y sus relaciones, es la clave de una base de datos relacional optimizada. Un buen diseño lógico de la base de datos puede ser la base de un rendimiento óptimo de la aplicación y de la base de datos. Un diseño lógico deficiente puede comprometer el rendimiento de todo el sistema.
La normalización de un diseño lógico de la base de datos implica la utilización de métodos formales para separar los datos en varias tablas relacionadas. Una característica de una base de datos normalizada es la existencia de varias tablas pequeñas con menos columnas. En las bases de datos no normalizadas, existen menos tablas más amplias con más columnas.
Por lo general, una normalización razonable permite mejorar el rendimiento. Cuando se dispone de índices útiles, el optimizador de consultas de SQL Server es una herramienta adecuada para la selección rápida y eficaz de combinaciones entre tablas.
La normalización ofrece diversas ventajas, entre las que se incluyen:
Mayor rapidez en la ordenación y en la creación de índices.
Un número mayor de índices clúster. Para obtener más información, vea Directrices para diseñar ndices clúster.
Índices más estrechos y compactos.
Menor número de índices por tabla. De esta forma, se mejora el rendimiento de las instrucciones INSERT, UPDATE y DELETE.
Menor número de valores NULL y menos oportunidades para generar incoherencias. De esta forma, aumenta el rendimiento.
A medida que progresa la normalización, también aumenta el número y la complejidad de las combinaciones necesarias para recuperar los datos. Un número muy elevado de combinaciones relacionales complejas entre demasiadas tablas puede afectar al rendimiento. Una normalización razonable suele incluir un número reducido de consultas que se ejecutan con regularidad y utilizan combinaciones en las que intervienen más de cuatro tablas.
A veces, el diseño lógico de la base de datos es fijo y su remodelación resulta inviable. No obstante, incluso en estos casos puede normalizarse de forma selectiva una tabla de gran tamaño para crear tablas más pequeñas. Si el acceso a la base de datos se realiza mediante procedimientos almacenados, este cambio del esquema puede llevarse a cabo sin que afecte a las aplicaciones. De lo contrario, puede crearse una vista que oculte el cambio de esquema a las aplicaciones.
Conseguir una base de datos bien diseñada
En la teoría del diseño de bases de datos relacionales, las reglas de normalización identifican ciertos atributos que deben estar presentes o ausentes en una base de datos bien diseñada. Una discusión completa de las reglas de normalización queda fuera del ámbito de este tema. No obstante, hay algunas reglas que pueden ayudarle a mejorar el diseño de la base de datos:
Una tabla debe tener un identificador.
La regla fundamental de la teoría del diseño de bases de datos es que cada tabla tenga un identificador único de fila, una columna o conjunto de columnas utilizados para diferenciar un registro de cualquier otro registro de la tabla. Cada tabla debe tener una columna de Id. y el valor de cada Id. no debe ser compartido por dos registros. Las columnas que funcionan como identificador único de fila para una tabla constituyen la clave principal de la tabla. En la base de datos AdventureWorks2008R2, cada tabla contiene una columna de identidad como columna de clave principal. Por ejemplo, VendorID es la clave principal de la tabla Purchasing.Vendor.
Una tabla solo debe almacenar datos para un único tipo de entidad.
Si intenta almacenar demasiada información en una tabla, la confiabilidad y la eficacia en la administración de los datos de la tabla pueden verse afectadas. En la base de datos de ejemplo AdventureWorks2008R2, la información de pedidos de ventas y de cliente está almacenada en tablas independientes. Puede disponer de columnas con información para los pedidos de ventas y el cliente en una sola tabla; sin embargo, este diseño causa varios problemas. El nombre, la dirección y la información del cliente deben agregarse y almacenarse repetidamente para cada pedido de ventas. De esta forma, la base de datos utiliza más espacio. Si cambia la dirección de un cliente, la modificación debe efectuarse en cada pedido de ventas. Además, si el último pedido de ventas de un cliente se quita de la tabla Sales.SalesOrderHeader, se pierde la información de dicho cliente.
En una tabla deben evitarse las columnas que acepten valores nulos.
Las tablas pueden tener columnas definidas para permitir valores NULL. Un valor NULL indica que no hay ningún valor. En algunos casos, puede resultar útil permitir valores NULL, pero conviene utilizarlos con moderación. Esto se debe a que precisan un control especial que aumenta la complejidad de las operaciones de datos. Si tiene una tabla con varias columnas que aceptan valores NULL y varias filas tienen valores NULL en las columnas, conviene que considere la posibilidad de colocar esas columnas en otra tabla vinculada con la tabla principal. Si almacena los datos en dos tablas distintas, el diseño de la tabla principal puede ser simple, pero seguirá controlando la necesidad ocasional de almacenar este tipo de información.
Una tabla no debe tener valores ni columnas que se repitan.
La tabla para un elemento de la base de datos no debe contener una lista de valores para una información específica. Por ejemplo, un producto de la base de datos AdventureWorks2008R2 se puede adquirir en varios proveedores. Si existe una columna en la tabla Production.Product para el nombre del proveedor, surge un problema. Una solución consiste en almacenar el nombre de todos los proveedores en la columna. Sin embargo, de esta forma resulta difícil mostrar una lista de los proveedores individuales. Otra solución consiste en cambiar la estructura de la tabla para agregar otra columna con el nombre del segundo proveedor. De esta forma, sin embargo, solo se pueden incluir dos proveedores. Si un producto cuenta con tres proveedores, es necesario agregar otra columna.
Si cree que necesita almacenar una lista de valores en una sola columna, o si tiene varias columnas para representar un solo tipo de datos, como TelephoneNumber1 y TelephoneNumber2, conviene que considere la colocación de los datos duplicados en otra tabla con un vínculo a la tabla principal. La base de datos AdventureWorks2008R2 cuenta con una tabla Production.Product para la información del producto, una tabla Purchasing.Vendor para la información de proveedor y una tercera tabla, Purchasing.ProductVendor. Esta tabla solo almacena los valores de Id. de los productos y de los proveedores de los productos. Este diseño permite la inclusión de un número indeterminado de proveedores para el mismo producto sin necesidad de modificar la definición de las tablas y sin asignar espacio de almacenamiento no utilizado para los productos con un único proveedor.
Vea también