9/2/2017 Normalizacin

Normalizacin

El diseo lgico de la base de datos, que incluye las tablas y sus relaciones, es la clave de una base de datos relacional
optimizada. Un buen diseo lgico de la base de datos puede ser la base de un rendimiento ptimo de la aplicacin y de la base
de datos. Un diseo lgico deficiente puede comprometer el rendimiento de todo el sistema.

La normalizacin de un diseo lgico de la base de datos implica la utilizacin de mtodos formales para separar los datos en
varias tablas relacionadas. Una caracterstica de una base de datos normalizada es la existencia de varias tablas pequeas con
menos columnas. En las bases de datos no normalizadas, existen menos tablas ms amplias con ms columnas.

Por lo general, una normalizacin razonable permite mejorar el rendimiento. Cuando se dispone de ndices tiles, el optimizador
de consultas de SQL Server es una herramienta adecuada para la seleccin rpida y eficaz de combinaciones entre tablas.

La normalizacin ofrece diversas ventajas, entre las que se incluyen:

Mayor rapidez en la ordenacin y en la creacin de ndices.

Un nmero mayor de ndices clster. Para obtener ms informacin, vea Directrices para disear ndices clster.

ndices ms estrechos y compactos.

Menor nmero de ndices por tabla. De esta forma, se mejora el rendimiento de las instrucciones INSERT, UPDATE y
DELETE.

Menor nmero de valores NULL y menos oportunidades para generar incoherencias. De esta forma, aumenta el
rendimiento.

A medida que progresa la normalizacin, tambin aumenta el nmero y la complejidad de las combinaciones necesarias para
recuperar los datos. Un nmero muy elevado de combinaciones relacionales complejas entre demasiadas tablas puede afectar al
rendimiento. Una normalizacin razonable suele incluir un nmero reducido de consultas que se ejecutan con regularidad y
utilizan combinaciones en las que intervienen ms de cuatro tablas.

A veces, el diseo lgico de la base de datos es fijo y su remodelacin resulta inviable. No obstante, incluso en estos casos
puede normalizarse de forma selectiva una tabla de gran tamao para crear tablas ms pequeas. 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 diseada

En la teora del diseo de bases de datos relacionales, las reglas de normalizacin identifican ciertos atributos que deben estar
presentes o ausentes en una base de datos bien diseada. Una discusin completa de las reglas de normalizacin queda fuera
del mbito de este tema. No obstante, hay algunas reglas que pueden ayudarle a mejorar el diseo de la base de datos:

Una tabla debe tener un identificador.

La regla fundamental de la teora del diseo 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

https://technet.microsoft.com/eses/library/ms191178(v=sql.105).aspx 1/3
9/2/2017 Normalizacin

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 informacin en una tabla, la confiabilidad y la eficacia en la administracin de los datos
de la tabla pueden verse afectadas. En la base de datos de ejemplo AdventureWorks2008R2, la informacin de pedidos
de ventas y de cliente est almacenada en tablas independientes. Puede disponer de columnas con informacin para
los pedidos de ventas y el cliente en una sola tabla; sin embargo, este diseo causa varios problemas. El nombre, la
direccin y la informacin del cliente deben agregarse y almacenarse repetidamente para cada pedido de ventas. De
esta forma, la base de datos utiliza ms espacio. Si cambia la direccin de un cliente, la modificacin debe efectuarse
en cada pedido de ventas. Adems, si el ltimo pedido de ventas de un cliente se quita de la tabla
Sales.SalesOrderHeader, se pierde la informacin 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 ningn valor.
En algunos casos, puede resultar til permitir valores NULL, pero conviene utilizarlos con moderacin. 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 diseo de la tabla principal puede ser simple, pero seguir controlando la necesidad ocasional de
almacenar este tipo de informacin.

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 informacin especfica.
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 solucin
consiste en almacenar el nombre de todos los proveedores en la columna. Sin embargo, de esta forma resulta difcil
mostrar una lista de los proveedores individuales. Otra solucin 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 colocacin de los datos
duplicados en otra tabla con un vnculo a la tabla principal. La base de datos AdventureWorks2008R2 cuenta con una
tabla Production.Product para la informacin del producto, una tabla Purchasing.Vendor para la informacin 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 diseo permite la inclusin de un nmero indeterminado de proveedores
para el mismo producto sin necesidad de modificar la definicin de las tablas y sin asignar espacio de almacenamiento
no utilizado para los productos con un nico proveedor.

Vea tambin
Conceptos
Bases de datos de ejemplo AdventureWorks2008R2
Otros recursos
Disear bases de datos

https://technet.microsoft.com/eses/library/ms191178(v=sql.105).aspx 2/3
9/2/2017 Normalizacin

Adiciones de comunidad

2017 Microsoft

https://technet.microsoft.com/eses/library/ms191178(v=sql.105).aspx 3/3