Beruflich Dokumente
Kultur Dokumente
El proceso de normalizacin
El proceso de normalizacin consiste en comprobar en secuencia si el esquema original est en 1FN, 2FN y 3FN, analizando las dependencias funcionales en cada paso. Un ejemplo completo Tenemos una empresa pblica donde los puestos de trabajo estn regulados por el Estado, de modo que las condiciones salariales estn determinadas por el puesto. Se ha creado el siguiente esquema relacional EMPLEADOS(nss, nombre, puesto, salario, emails) con nss como clave primaria. salari emails o 111 Juan Prez Jefe de rea 3000 juanp@ecn.es; nss nombre puesto
jefe2@ecn.es 222 Jos Snchez ... Administrati 1500 jsanchez@ecn.es vo Administrati adiaz@ecn.es; 1500 vo ana32@gmail.com ... ... ... 5
Primera forma normal (1FN) Una tabla est en 1FN si sus atributos contienen valores atmicos. En el ejemplo, podemos ver que el atributo emails puede contener ms de un valor, por lo que viola 1FN. En general, tenemos una relacin R con clave primaria K. Si un atributo M viola la condicin de 1FN, tenemos dos opciones. Solucin 1: duplicar los registros con valores repetidos En general, esta solucin pasa por sustituir R por una nueva relacin modificada R', en la cual:
El atributo M que violaba 1FN se elimina. Se incluye un nuevo atributo M' que solo puede contener valores simples, de modo que si R'[M'] es uno de los valores que tenamos en R[M], entonces R'[K] = R[K]. En otras palabras, para una tupla con n valores duplicados en M, en la nueva relacin habr n tuplas, que slo varan en que cada una de ellas guarda uno de los valores que haba en M. La clave primaria de R' es (K, M'), dado que podr haber valores de K repetidos, para los valores multivaluados en M.
Siguiendo el ejemplo, tendramos el siguiente esquema para la nueva tabla EMPLEADOS'(a) con clave primaria (nss, email): salari email o 111 Juan Prez Jefe de rea 3000 juanp@ecn.es 111 Juan Prez Jefe de rea 3000 jefe2@ecn.es Jos Administrati jsanchez@ecn.e 222 1500 Snchez vo s Administrati 333 Ana Daz 1500 adiaz@ecn.es vo Administrati ana32@gmail.c 333 Ana Daz 1500 vo om ... ... ... ... ... nss nombre puesto
Solucin 2: separar el atributo que viola 1FN en una tabla En general, esta solucin pasa por: sustituir R por una nueva relacin modificada R' que no contiene el atributo M. Crear una nueva relacin N(K, M'), es decir, una relacin con una clave ajena K referenciando R', junto al atributo M', que es la variante monovaluada del atributo M. La nueva relacin N tiene como clave (K, M'). Siguiendo el ejemplo, tendramos el siguiente esquema para la nueva tabla EMPLEADOS'(b) nss 111 222 333 ... salari o Juan Prez Jefe de rea 3000 Jos Administrati 1500 Snchez vo Administrati Ana Daz 1500 vo ... ... ... nombre puesto 5
Y adems tendramos una nueva tabla EMAILS con clave primaria (nss, email): ns s 11 1 11 1 22 2 33 3 33 3 ... email juanp@ecn.es jefe2@ecn.es jsanchez@ecn.e s adiaz@ecn.es ana32@gmail.c om ...
Est en 1FN. Todos sus atributos que no son de la clave principal tienen dependencia funcional completa respecto de todas las claves existentes en el esquema. En otras palabras, para determinar cada atributo no clave se necesita la clave primaria completa, no vale con una subclave. La 2FN se aplica a las relaciones que tienen claves primarias compuestas por dos o ms atributos. Si una relacin est en 1FN y su clave primaria es simple (tiene un solo atributo), entonces tambin est en 2FN. Por tanto, de las soluciones anteriores, la tabla EMPLEADOS'(b) est en 1FN (y la tabla EMAILS no tiene atributos no clave), por lo que el esquema est en 2FN. Sin embargo, tenemos que examinar las dependencias funcionales de los atributos no clave de EMPLEADOS'(a). Las dependencias funcionales que tenemos son las siguientes: nss->nombre, salario, email puesto->salario Como la clave es (nss, email), las dependencias de nombre, salario y email son incompletas, por lo que la relacin no est en 2FN. En general, tendremos que observar los atributos no clave que dependan de parte de la clave. Para solucionar este problema, tenemos que hacer lo siguiente para los grupos de atributos con dependencia incompleta M: Eliminar de R el atributo M. Crear una nueva relacin N con el atributo M y la parte de la clave primaria K de la que depende, que llamaremos K'. La clave primaria de la nueva relacin ser K'. Siguiendo el ejemplo anterior, crearamos una nueva relacin con los atributos que tienen dependencia incompleta: salari o 111 Juan Prez Jefe de rea 3000 Jos Administrati 222 1500 Snchez vo Administrati 333 Ana Daz 1500 vo nss nombre puesto 5
...
...
...
...
Y al eliminar de la tabla original estos atributos nos quedaran: nss email 111 juanp@ecn.es 111 jefe2@ecn.es jsanchez@ecn.e 222 s 333 adiaz@ecn.es ana32@gmail.c 333 om ... ... Como vemos, la solucin a la que llegamos es la misma que en la otra opcin de solucin para el problema de 1FN. Tercera forma normal (3FN) Una relacin est en tercera forma normal si, y slo si: est en 2FN y, adems, cada atributo que no est incluido en la clave primaria no depende transitivamente de la clave primaria. Por lo tanto, a partir de un esquema en 2FN, tenemos que buscar dependencias funcionales entre atributos que no estn en la clave. En general, tenemos que buscar dependencias transitivas de la clave, es decir, secuencias de dependencias como la siguiente: K->A y A->B, donde A y B no pertenecen a la clave. La solucin a este tipo de dependencias est en separar en una tabla adicional N el/los atributos B, y poner como clave primaria de N el atributo que define la transitividad A. Siguiendo el transitividad: nss->puesto puesto->salario Por lo tanto la descomposicin sera la siguiente: nss nombre puesto ejemplo anterior, podemos detectar la siguiente
111 Juan Prez Jefe de rea Jos Administrati 222 Snchez vo Administrati 333 Ana Daz vo ... ... ... En la nueva tabla PUESTOS, la clave sera el puesto, que tambin queda como clave ajena referenciando la tabla EMPLEADOS. El resto de las tablas quedan como estaban. 5
A travs del siguiente ejercicio se intenta afirmar los conocimientos de normalizacin con un ejemplo simplificado de una base de datos para una pequea biblioteca. CodLi bro
1001 1004 1005 1006
Titulo
Variable compleja Visual Basic 5 Estadstica
Autor
Murray Spiegel E. Petroustsos Murray Spiegel
Editorial
McGraw Hill Anaya McGraw Hill y Oracle Corp.
Ros Tern, Ana Roca, Ren Garca Luis Prez Juan Roque,
1007
McGraw Hill
Gmez,
18/04/2005
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 paterno, apellido materno y nombres. Tal como se muestra en la siguiente tabla.
1NF
CodLi bro
1001 1004 1005 1006 1006 1007
Titulo
Variable compleja Visual 5
Autor
Murray Spiegel
Como se puede ver, hay cierta redundancia caracterstica de 1NF. 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
CodLib Titulo ro
1001 1004 1005 1006 1006 1007 Variable compleja Visual Basic 5 Estadstica Oracle University Oracle University Clipper 5.01
5 Autor
Murray Spiegel E. Petroustsos Murray Spiegel Nancy Greenberg Priya Nathan Ramalho
Editorial
McGraw Hill Anaya McGraw Hill Oracle Corp. Oracle Corp. McGraw Hill
Matern Nombre o s
Gmez Tern Juan Ana Ren Luis
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: CodLib CodLect FechaDev ro or
1001 1004 1005 501 502 503 15/04/2005 17/04/2005 16/04/2005
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
CodLib Titulo ro
1001 1004 1005 1006 1007 Variable compleja Visual Basic 5 Estadstica Oracle University Clipper 5.01
CodAut Autor or
801 802 803 804 806 Murray Spiegel E. Petroustsos Nancy Greenberg Priya Nathan Ramalho
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.
CodLib codAut ro or
1001 1004 1005 1006 1006 1007 801 802 801 803 804 806
CodLect Pater or no
501 502 503 504 Prez Ros Roca Garca
Matern Nombre o s
Gmez Tern Juan Ana Ren Roque Luis