Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Al igual que con otras muchas reglas y especificaciones formales, en los escenarios
reales no siempre se cumplen los estndares de forma perfecta. En general, la
normalizacin requiere tablas adicionales y algunos clientes consideran ste un trabajo
considerable. Si decide infringir una de las tres primeras reglas de la normalizacin,
asegrese de que su aplicacin se anticipa a los problemas que puedan aparecer,
como la existencia de datos redundantes y de dependencias incoherentes.
No use varios campos en una sola tabla para almacenar datos similares. Por ejemplo,
para realizar el seguimiento de un elemento del inventario que proviene de dos
orgenes posibles, un registro del inventario puede contener campos para el Cdigo de
proveedor 1 y para el Cdigo de proveedor 2.
Los registros no deben depender de nada que no sea una clave principal de una tabla,
una clave compuesta si es necesario. Por ejemplo, considere la direccin de un cliente
en un sistema de contabilidad. La direccin se necesita en la tabla Clientes, pero
tambin en las tablas Pedidos, Envos, Facturas, Cuentas por cobrar y Colecciones.
En lugar de almacenar la direccin de un cliente como una entrada independiente en
cada una de estas tablas, almacnela en un lugar, ya sea en la tabla Clientes o en una
tabla Direcciones independiente.
Los valores de un registro que no sean parte de la clave de ese registro no pertenecen
a la tabla. En general, siempre que el contenido de un grupo de campos pueda
aplicarse a ms de un nico registro de la tabla, considere colocar estos campos en
una tabla independiente. Por ejemplo, en una tabla Contratacin de empleados, puede
incluirse el nombre de la universidad y la direccin de un candidato. Pero necesita una
lista completa de universidades para enviar mensajes de correo electrnico en grupo.
Si la informacin de las universidades se almacena en la tabla Candidatos, no hay
forma de enumerar las universidades que no tengan candidatos en ese momento.
Cree una tabla Universidades independiente y vinclela a la tabla Candidatos con el
cdigo de universidad como clave.
Puede ser ms factible aplicar la tercera forma normal slo a los datos que cambian
con frecuencia. Si quedan algunos campos dependientes, disee la aplicacin para
que pida al usuario que compruebe todos los campos relacionados cuando cambie
alguno.
La cuarta forma normal, tambin llamada Forma normal de Boyce Codd (BCNF, Boyce
Codd Normal Form), y la quinta forma normal existen, pero rara vez se consideran en
un diseo real. Si no se aplican estas reglas, el diseo de la base de datos puede ser
menos perfecto, pero no debera afectar a la funcionalidad.
Esta tabla no cumple el requisito de la Primera Forma Normal (1NF) de slo tener campos
atmicos, pues el nombre del lector es un campo que puede (y conviene) descomponerse en
apellido y nombres. Tal como se muestra en la siguiente tabla.
1NF
CodLibro Titulo Autor Editorial Apellido Nombres FechaDev
Variable
1001 Murray Spiegel McGraw Hill Prez Juan 15/04/2005
compleja
1004 Visual Basic 5 E. Petroustsos Anaya Ros Ana 17/04/2005
1005 Estadstica Murray Spiegel McGraw Hill Roca Ren 16/04/2005
1006 OracleUniversity NancyGreenberg Oracle Corp. Garca Luis 20/04/2005
1006 OracleUniversity Priya Nathan Oracle Corp. Garca Luis 20/04/2005
1007 Clipper 5.01 Ramalho McGraw Hill Prez Juan 18/04/2005
La Segunda Forma Normal (2NF) pide que no existan dependencias parciales o dicho de otra
manera, todos los atributos no clave deben depender por completo de la clave primaria.
Actualmente en nuestra tabla tenemos varias dependencias parciales si consideramos como
atributo clave el cdigo del libro.
Por ejemplo, el ttulo es completamente identificado por el cdigo del libro, pero el nombre del
lector en realidad no tiene dependencia de este cdigo, por tanto estos datos deben ser
trasladados a otra tabla.
2NF
CodLibro Titulo Autor Editorial
Hemos creado una tabla para contener los datos del lector y tambin tuvimos que crear la
columna CodLector para identificar unvocamente a cada uno. Sin embargo, esta nueva
disposicin de la base de datos necesita que exista otra tabla para mantener la informacin de
qu libros estn prestados a qu lectores. Esta tabla se muestra a continuacin:
Para la Tercera Forma Normal (3NF) la relacin debe estar en 2NF y adems los atributos no
clave deben ser mutuamente independientes y dependientes por completo de la clave primaria.
Tambin recordemos que dijimos que esto significa que las columnas en la tabla deben
contener solamente informacin sobre la entidad definida por la clave primaria y, por tanto, las
columnas en la tabla deben contener datos acerca de una sola cosa.
En nuestro ejemplo en 2NF, la primera tabla conserva informacin acerca del libro, los autores
y editoriales, por lo que debemos crear nuevas tablas para satisfacer los requisitos de 3NF.
3NF
CodLibro Titulo
1005 Estadstica
802 E. Petroustsos
806 Ramalho
CodEditorial Editorial
902 Anaya
Aunque hemos creado nuevas tablas para que cada una tenga slo informacin acerca de una
entidad, tambin hemos perdido la informacin acerca de qu autor ha escrito qu libro y las
editoriales correspondientes, por lo que debemos crear otras tablas que relacionen cada libro
con sus autores y editoriales.
CodLibro codAutor
1001 801
1004 802
1005 801
1006 803
1006 804
1007 806
CodLibro codEditorial
1001 901
1004 902
1005 901
1006 903
1007 901