05/06/2011

Caso prctico

Este documento ha sido generado para facilitar la impresin de los contenidos. Los enlaces a otras pginas no sern funcionales.

Caso prctico
Vctor ha aprendido mucho sobre bases de datos, y no tiene demasiados problemas a la hora de hacer los diagramas E-R o el esquema relacional para las bases de datos que van a usar en las distintas aplicaciones que la empresa est desarrollando. o obstante, los diseos que l hace son mejorables en algunos casos, debido a que es posible de la informacin, y evitar problemas en inserciones, modificaciones y borrados, evitando almacenada y permitiendo almacenar toda la informacin que se necesita. A veces los diseos de no son los mejores para conseguir estos fines, y sabe la causa: Todava no ha aprendido nada sobre normalizacin de bases de datos. Por eso se rene con y para tratar este tema: Ha llegado la hora de ensear a la teora y la prctica de la de bases de datos, para que pueda implicarse en proyectos ms ambiciosos, encargndose enteramente del diseo de la base de datos, cumpliendo con todos los requisitos de calidad necesarios. Al principio, no entiende qu es lo que falla en los diseos que l ha hecho, y le muestra como ejemplo el diseo de una base de datos de la consulta de una clnica veterinaria, en la que l haba incluido una nica relacin: MASCOTA(cod_mascota, nombre, fecha_visita, tratamiento) raza, direccion, telefono, enfermedad, color, peso,

Le hace ver que en realidad, aunque toda esa informacin se refiere a la mascota, hay dos hechos distintos: Por un lado los datos de la mascota propiamente dichos, y por otro lado los datos de cada visita que la mascota hace a la clnica y del tratamiento que se le indica en cada caso. Con la estructura que Vctor ha hecho, cada vez que una mascota hace una nueva visita a la clnica, tendramos que aadir una nueva tupla a la tabla correspondiente, en la que habra que meter adems de los datos de la visita (fecha_visita, enfermedad, peso, tratamiento) todos los dems datos de la mascota (cod_mascota, nombre, raza, direccin, telefono, color). Por tanto, si esta mascota ha venido 10 veces, todos esos datos estaran repetidos 10 veces! A Vctor le cuesta reconocer que su diseo estaba mal, y alega que tampoco es tan grave tener que almacenar 10 veces los datos de la mascota, ya que hoy en da cualquier ordenador puede tener una enorme capacidad de almacenamiento en su disco duro, por precios que casi son de risa. Jos y Mara le dicen que no estn del todo de acuerdo. Si en vez de hablar de una clnica veterinaria con cientos de clientes como mucho estuviramos hablando de la base de datos clnicos del SAS (Servicio Andaluz de Salud) en la que hay millones de usuarios, que hacen probablemente cientos o incluso miles de visitas mdicas a lo largo de su vida, tener que almacenar duplicada la informacin personal de cada usuario tendra un coste nada despreciable. Esto convence bastante a Vctor, pero el desperdicio de espacio de almacenamiento no es sin embargo el problema principal, le comenta Jos. Volviendo al caso de la clnica veterinaria, Qu pasara si una mascota cambia por ejemplo de direccin? Evidentemente, para que la informacin de la base de datos fuera correcta, habra que actualizar la direccin en todas las tuplas de la relacin, lo que sin duda hara que la aplicacin invirtiera mucho tiempo actualizando un conjunto grande de tuplas, en lugar de actualizar una sola, lo que incidira en el rendimiento general de la aplicacin. De nuevo podemos pensar en el ejemplo del SAS para ver lo grave que el problema puede ser. Piensa en miles de mdicos esperando a que la aplicacin les responda para poder hacer su trabajo, porque est saturada haciendo miles de actualizaciones realmente redundantes en cientos de miles de registros de los usuarios. A estas alturas Vctor ya est totalmente convencido del error, pero Jos le dice que esto ltimo, an siendo grave, no es tampoco el problema principal. Imagina que al actualizar las tuplas de la relacin, no se ha hecho bien. Existe la posibilidad de que la misma mascota aparezca con una direccin distinta en tuplas distintas, lo que sera una inconsistencia. o tendramos forma de saber cul es la direccin correcta, por lo que ninguna nos resultara fiable. Estas inconsistencias, derivadas de la redundancia de la informacin, seran gravsimas, porque en la prctica supondran que la informacin de la base de datos est corrupta. Vale, vale, protesta Vctor.

juntadeandalucia.es//view2.php?id=4

1/18

05/06/2011 Caso prctico Ya est ms que convencido de que hay que hacer un buen diseo, y que para ello es necesario evitar esos problemas, pero cmo se consigue?
Aplicando la teora de la normalizacin, que es algo que Mara , con la ayuda de Carmen, se van a encargar de ensearte, le dice Jos. Porque debes saber que todava hay ms problemas que los mencionados derivados de un mal diseo, como imposibilidad de representar ciertos datos del problema, violacin de la integridad de la base de datos en los borrados, etc. Y por curiosidad, Cmo quedara el diseo de la clnica para evitar esos problemas?, pregunta Vctor. Sencillo. Basta con dividir la relacin en dos nuevas relaciones, de forma que hechos distintos se almacenen en objetos distintos, aplicando, claro est, la teora de la normalizacin para que la divisin sea correcta: POSTERIORME TE ESTUDIAREMOS CUALES SO LAS LLAVES PRIMARIAS) MASCOTA (cod_mascota, nombre, direccion, telefono, color, raza) VISITA (cod_mascota, fecha_visita, peso, enfermedad, tratamiento)

Introduccin
Como hemos visto en unidades anteriores, uno de los principales objetivos del diseo de la base de datos es conseguir una estructura lgica que: Evite problemas en inserciones, modificaciones y borrados, por lo tanto, no sufra anomalas de almacenamiento. El modelo lgico y fsico puedan modificarse con facilidad si hay una variacin de los requerimientos iniciales, y adems que ambos modelos sean independientes el uno del otro. No es muy difcil intuir que, en todos los modelos tericos, el diseo de una base de datos se puede realizar de dos maneras diferentes: Obteniendo el esquema relacional directamente a partir de la informacin que poseemos acerca del problema a modelizar, de tal manera que obtendremos un conjunto de esquemas de relacin que contendrn los atributos y las restricciones de integridad que representan el anlisis que hemos realizado de nuestro problema a tratar. Realizando el diseo en dos fases , la primera llevando a cabo el diseo conceptual, es decir, obteniendo el diagrama E/R, y en la segunda fase, transformando ste en un esquema relacional como hemos visto en la unidad anterior. Siguiendo cualquiera de los dos mtodos el resultado final es un esquema relacional que debe verificar en todo momento un principio bsico en todo diseo:

Hechos distintos se deben almacenar en objetos distintos.

Es evidente que la siguiente relacin no cumple con este principio bsico: MASCOTA (cod_mascota, nombre, fecha_visita, tratamiento) raza, direccion, telefono, enfermedad, color, peso,

En principio los atributos enfermedad, fecha_visita y tratamiento no explican el mismo "hecho" que el resto, ya que tratan de las visitas, enfermedades y tratamiento de la mascota, mientras que el resto de los atributos da informacin acerca de los datos concretos de la mascota. Adems podemos observar que con este diseo no podramos insertar una nueva mascota en la base de datos de la clnica veterinaria hasta que no hiciera su primera visita. En lugar de la relacin anterior podramos haber diseado el siguiente esquema relacional: MASCOTA (cod_mascota, nombre, direccion, telefono, color, raza) VISITA (cod_mascota, fecha_visita, peso, enfermedad, tratamiento) ste s verifica el principio bsico del diseo de Bases de Datos, y permite insertar mascotas nuevas en la base de datos independientemente de que realice una visita a la clnica veterinaria. Para evitar dichas anomalas y conseguir los objetivos mencionados anteriormente se aplica la Teora de la Normalizacin. Nos preguntamos entonces, qu es la Teora de la ormalizacin? La Teora de la Normalizacin (o simplemente la normalizacin) consiste en aplicar una serie de reglas para asegurarnos la eliminacin de redundancias e inconsistencias en las tablas que constituyen el diseo de nuestra base de datos. En ocasiones esta Normalizacin se traduce en la separacin de los datos en diferentes tablas asegurndonos siempre de que las tablas resultantes mantengan toda la

juntadeandalucia.es//view2.php?id=4

2/18

05/06/2011 Caso prctico informacin original y las distintas dependencias entre los datos almacenados.
Todo esto se traduce en la aplicacin de las Formas ormales que slo son un conjunto de restricciones sobre las tablas que evitan los problemas de redundancia y anomalas de modificacin, insercin y borrado de datos. De esta manera transformamos, si es necesario, las tablas obtenidas en el Modelo Relacional en un conjunto de tablas ms simples y fciles de mantener, tanto desde el punto de vista lgico, como fsico. Seguramente con el tiempo y la prctica conseguirs obtener el esquema relacional directamente del enunciado del problema, pero aunque esto sea as, es recomendable comprobar el diseo obtenido con la teora de la normalizacin. Resumiendo lo visto hasta el momento, la normalizacin consiste en una descomposicin de la relacin universal (toda la informacin en una nica tabla) o de una coleccin de relaciones equivalentes a la misma, en una coleccin de relaciones en la que las anomalas de actualizacin (insercin, borrado y modificacin) no existan o sean mnimas. Las reglas en las que se basa la Teora de la Normalizacin son conocidas con el nombre de Formas ormales . Existen seis formas normales . Las tres primeras reglas de normalizacin fueron perfiladas por el Dr. E.F.Codd en su escrito de 1972, "Further Normalization of the Data Base Relational Model" (Referente a la normalizacin de las Bases de Datos Relacionales). Posteriormente, y como consecuencia de unas anomalas detectadas al utilizar las tres primeras formas normales, Boyce ayud a Codd a redefinir la tercera forma normal en lo que se conoce como la forma normal de Boyce-Codd. Ms tarde Ronald Fagin introdujo la cuarta y quinta forma normal en un intento de mejorar el rendimiento de grandes sistemas transaccionales de las bases de datos modernas.

Para saber ms Si quieres saber algo ms acerca del precursor de la teora de ormalizacin, pulsa el siguiente enlace donde encontrars ms cosas acerca de sus aportaciones al mundo de la informtica: Ronald Fagin

Ventajas y objetivos de la normalizacin

Mara y Carmen ya se han puesto a la tarea, y han comenzado a instruir a Vctor en la teora de la normalizacin de bases de datos. El primer punto es detallarle los objetivos que se persiguen con la normalizacin y las ventajas que presenta su uso. Tras la charla mantenida con Jos, Vctor cree tenerlo bastante claro, pero de todas formas, se encuentra con alguna cuestin nueva, que le resulta muy interesante para tener en cuenta, como por ejemplo, el hecho de que al normalizar se debe cuidar que se conserve toda la informacin del problema, as como las dependencias existentes entre distintos datos, sin que se introduzcan dependencias nuevas que no existan originalmente en el problema real. Pero lo que ms le ha llamado la atencin es que no siempre es posible conseguir todos esos objetivos a la vez. Por tanto, la normalizacin ser un camino para conseguir alcanzar, de forma sistemtica, el mayor nmero de ellos.

Las principales ventajas del uso de la normalizacin son las siguientes: Facilidad de uso y claridad, las tablas recogen los datos de manera clara y sencilla de entender incluso para usuarios poco expertos. Flexibilidad y facilidad de gestin, la informacin que necesitan los usuarios se puede obtener directamente de las tablas o mediante operaciones de lgebra y clculo relacional. Precisin, las relaciones entre las tablas hacen que los datos de distintas tablas se relacionen con toda exactitud. Mnima redundancia, no se guarda informacin duplicada de manera innecesaria. Mximo rendimiento de las aplicaciones , slo se utiliza la informacin que va a servir de utilidad a cada aplicacin. Los principales objetivos que busca un diseo normalizado son los siguientes: Eliminar anomalas de actualizacin, insercin y borrado. Conservar la informacin original (descomposicin sin prdida de informacin). Conservar las dependencias funcionales originales (descomposicin sin prdida de dependencias funcionales). No crear dependencias nuevas o relaciones inexistentes. Facilidad de uso y modificacin de tablas creadas. Eficiencia. Pero siempre tenemos que tener en cuenta una cosa:

juntadeandalucia.es//view2.php?id=4

3/18

05/06/2011

Caso prctico

A veces no es posible conseguir todos esos objetivos a la vez!!

Dependencias funcionales
Mara le explica a Vctor que gran parte del proceso de normalizacin se basa en el concepto de dependencia funcional, por lo que es muy importante que ste le quede totalmente claro, y se lo explica con detalle. Pero no existe un nico tipo de dependencia, por lo que es necesario instruirle en los conceptos de dependencia plena o completa, trivial, elemental, transitiva y transitiva estricta. Detectar las dependencias existentes entre los datos que forman parte de nuestro problema es fundamental, ya que son la base sobre la que aplicar las distintas tcnicas para conseguir que todas las tablas de nuestra base de datos estn en una determinada forma normal que nos hemos propuesto como objetivo. Para que lo entienda mejor, Carmen le propone un ejemplo en el que se trabaja con empleados asignados a proyectos, de forma que se van identificando las distintas dependencias existentes en cada caso.

Todo lo que hemos comentado en el apartado anterior est muy bien como introduccin, pero en qu se basa toda esta Teora de la Normalizacin? Pues en un concepto muy sencillo y que ha permitido un gran avance en el diseo de las bases de datos: el concepto de dependencia funcional. Sabemos que una relacin est formada por un conjunto de atributos, pero ahora afinamos un poco ms y completamos la definicin: Una relacin se compone de un conjunto de atributos y dependencias, R (A, DF). Los atributos (A) sabemos cmo identificarlos, pero las dependencias (DF), cmo sabemos cules son las dependencias y cmo las identificamos? Las dependencias funcionales son propiedades de la semntica de los atributos y no pueden obtenerse de manera automtica en una relacin determinada. Definicin de dependencia Las dependencias funcionales son: Restricciones de integridad establecidas por el usuario que permiten conocer las relaciones que existen entre los atributos del problema planteado. Propiedades inherentes a la semntica del problema. Se han de cumplir para todos los registros de una relacin. Resumiendo, las dependencias funcionales reflejan enlaces semnticos permanentes entre los datos en un diseo concreto. En el siguiente apartado, al definir los tipos de dependencias, te presentamos algunos ejemplos que aclaran este concepto. Tipos de dependencias (I) Consideramos un esquema de relacin general R(A), con A el conjunto de sus atributos, y consideramos X, Y, y Z subconjuntos de A llamados descriptores. Nos encontramos con que podemos definir los siguientes tipos de dependencias: Dependencia funcional. Se dice que un conjunto de atributos (Y) depende funcionalmente de otro conjunto de atributos (X), si para cada valor de X existe un nico valor posible para Y. Se nota por XY. Tambin se dice que X DETERMI A a Y o que X implica a Y. A X se le conoce como determinante o implicante y a Y se le conoce como implicado. Por ejemplo, si consideramos la relacin EMPLEADO (DNI, NOMBRE, DIRECCION, TELEFONO, DEPARTAMENTO) es evidente que el nombre de una persona depende funcionalmente del DNI, es decir, para un DNI determinado existe slo un nombre que le corresponda. Sin embargo, si consideramos el ejemplo al revs, DNI no depende funcionalmente de NOMBRE, ya que para un mismo nombre puede haber muchos DNI diferentes. Piensa en la cantidad de "Pepe y Jos" que hay en este pas... y cada uno tiene su DNI! En este caso, suponemos que cada persona tiene un nico telfono y una nica direccin, y que adems trabaja en un nico departamento de la empresa. Por tanto, las dependencias funcionales quedan como siguen:

juntadeandalucia.es//view2.php?id=4

4/18

05/06/2011

Caso prctico

Donde DNI es el DETERMINANTE y el resto de atributos son las DEPENDENCIAS No obstante, si en nuestro problema necesitramos almacenar (o quisiramos permitir que se almacenara) ms de una direccin para una misma persona, o ms de un telfono, o que trabajara en ms de un departamento, esos tres atributos no dependeran funcionalmente de DNI. A eso es a lo que nos referimos cuando decimos que las dependencias funcionales vienen definidas por la semntica del problema. Dependencia funcional plena o completa. Si el descriptor o DETERMINANTE X es compuesto, X(X1 , X2 ), se dice que Y tiene dependencia funcional completa o plena de X, si depende funcionalmente de X, pero no depende funcionalmente de ningn subconjunto de X, es decir: Y depende funcionalmente de X o bien X determina a Y, pero Y no depende funcionalmente de X1 , ni tampoco de X2 . Se representa:

Una dependencia funcional completa se denota como X Y Si consideramos la relacin: PROYECTO (COD_PROYECTO, DNI_EMPLEADO, FECHA_INCORPORACION, HORAS_DEDICADAS) ...est claro que los atributos FECHA_INCORPORACION y HORAS_DEDICADAS tienen dependencia funcional completa respecto de COD_PROYECTO y DNI_EMPLEADO. Es evidente que la FECHA_INCORPORACION a un proyecto de un empleado depende tanto del proyecto al que se incorpora como del empleado que se incorpora. Un mismo empleado puede pertenecer a varios proyectos a los que se incorpora en diferentes fechas. Igual ocurre con el atributo HORAS_DEDICADAS. La dependencia funcional completa se puede representar mediante un diagrama de dependencias funcionales como sigue:

En cambio, si consideramos la relacin ALUMNO (DNI, NOMBRE, APELLIDOS, NUM_MATRICULA), el conjunto de atributos formado por el NOMBRE y el DNI producen dependencia funcional sobre el atributo APELLIDOS, y si consideramos que el NUM_MATRICULA depende nicamente del atributo DNI podemos representarlo como sigue:

Pero la dependencia de los atributos DNI y NOMBRE no es completa ya que DNI slo, tambin produce dependencia funcional sobre APELLIDOS. De esta manera slo el atributo DNI produce una dependencia funcional completa sobre el campo APELLIDOS. Es ms, DNI produce una dependencia funcional completa sobre el resto de los atributos. Por lo que la dependencia real de la relacin ALUMNO queda:

juntadeandalucia.es//view2.php?id=4

5/18

05/06/2011

Caso prctico

Tipos de dependencias (II) Pero hay ms tipo de dependencias funcionales? Por supuesto. Seguimos mostrndotelas. Dependencia funcional trivial. Una dependencia funcional X --> Y se dice que es trivial si Y es un subconjunto de X (Y c X) Si consideramos el conjunto de atributos NOMBRE, APELLIDOS, DNI y consideramos la dependencia funcional

dicha dependencia es trivial.

o debe haber dependencias funcionales triviales en las relaciones de las bases de datos.

Dependencia funcional elemental. Una dependencia funcional X-->Y es elemental si Y es un atributo nico no incluido en X, y no existe ningn subconjunto de X, llammosle X1 , tal que X1 ( Y, es decir, la dependencia funcional elemental es una dependencia completa no trivial en la que el implicado es un atributo nico. Si consideramos la relacin PROYECTO (COD_PROYECTO, DNI_EMPLEADO, FECHA_INCORPORACION) con FECHA_INCORPORACION dependiendo funcionalmente de COD_PROYECTO y DNI_EMPLEADO, vemos claramente que esta dependencia es una dependencia funcional elemental ya que el implicado est constituido nicamente por el atributo FECHA_INCORPORACION.

Dependencia funcional transitiva. Consideramos la relacin R(X, Y, Z) con las siguientes dependencias funcionales: Es decir:

Z depende funcionalmente de X y de Y, Y depende funcionalmente de X, pero X no depende funcionalmente de Y. Se nota de la siguiente manera:

juntadeandalucia.es//view2.php?id=4

6/18

05/06/2011 Caso prctico En estas condiciones se dice que Z tiene una dependencia funcional transitiva respecto a X, a travs de Y. Es decir, un descriptor Z es transitivamente dependiente de otro X si se puede conoce por diferentes vas, una directamente y otra a partir de otro descriptor intermedio Y.
Si consideramos la siguiente relacin ALUMNO (COD_ALUMNO, GRUPO, AULA) claramente se aprecia que los atributos GRUPO y AULA dependen funcionalmente del atributo COD_ALUMNO, y a su vez el atributo AULA depende funcionalmente del atributo GRUPO, por lo que AULA tiene una dependencia funcional transitiva respecto a COD_ALUMNO a travs de GRUPO.

Dependencia funcional transitiva estricta. Una dependencia funcional transitiva se dice que es estricta si se verifica que

En el caso anterior el atributo GRUPO no depende funcionalmente de AULA.

Dependencia funcional multivaluada. Dada una relacin R (X, Y, Z) con los atributos X, Y y Z, la dependencia multivaluada R.X -->--> R.Y se cumple en R si y slo si el conjunto de valores de Y correspondiente a un par dado (valor de X, valor de Z) en R depende slo del valor de X y es independiente del valor de Z. Si consideramos la relacin AGENDA (DNI, DIRECCION, FECHA_NACIMIENTO, TELEFONO) podemos observar que por cada DNI de la AGENDA puedo tener varios nmeros de TELEFONO independientemente de los valores que tomen direccin y FECHA_NACIMIENTO. Podemos decir que TELEFONO es un atributo multivaluado y que existe la siguiente dependencia multivaluada DNI -->--> TELEFONO D I 24222425 24222425 24222425 71734746 71734746 71734746 DIRECCIO Islas Vrgenes, 20 Islas Vrgenes, 20 Islas Vrgenes, 20 Granada, 18 Granada, 18 Granada, 18 FECHA_ ACIMIE TO 19-04-1975 19-04-1975 19-04-1975 21-06-1969 21-06-1969 21-06-1969 TELEFO O 950202120 67676869 950343536 958192087 667667667 958950950

Para saber ms En esta unidad nicamente se da una definicin general del concepto de dependencia funcional multivaluada, pero si quieres profundizar ms, en los siguientes enlaces encontrars ms informacin: Dependencia funcional multivaluada Dependencia funcional multivaluada [Versin en cach]

Formas ormales 1F , 2F , 3F y F BC

Una vez entendido el concepto de dependencia funcional, y los distintos tipos de dependencias que existen, ha llegado la hora de aplicarlo para conseguir normalizar nuestra base de datos. En este punto, Mara le explica a Vctor que existen distintos "grados de normalizacin", que se van diferenciando entre s, fundamentalmente por el grado de redundancia de la informacin que permiten. Mientras ms alto sea el grado de

juntadeandalucia.es//view2.php?id=4

7/18

05/06/2011 Caso prctico normalizacin, menos redundancia de informacin habr, y menos anomalas o problemas a la hora de insertar, actualizar o borrar informacin en la base de datos, reducindose las posibilidades de errores o inconsistencias.
Esos "grados de normalizacin" se conocen como Formas ormales, y nuestro objetivo es ir asegurndonos de que todas las tablas de nuestro esquema van cumpliendo cada una de esas formas normales, y si no es as, aplicar los criterios de normalizacin para introducir las modificaciones necesarias en el esquema para que s lo estn. Carmen le comenta a Vctor que no siempre es posible conseguir el mximo grado de normalizacin. Siempre es posible llegar a la Tercera Forma ormal, y por tanto es el mnimo exigible. Sin embargo, no siempre es posible conseguir las siguientes formas normales, aunque debemos intentarlo. Por ejemplo, al descomponer la relacin para que est en F BC, a veces se pierden dependencias funcionales, por lo que no sera recomendable pasar de 3F . Usualmente, basta con conseguir la 3F o la Forma ormal de Boyce-Cood. Raramente se normaliza hasta la 4F , y aunque existe la 5F , es posible conseguirla en un nmero reducido de casos muy especficos, que habr que analizar cuidadosamente, y que rara vez se presentan, por lo que no merece la pena, a priori, considerarlos para nuestras aplicaciones de gestin tpicas. Para practicar, Carmen le propone a Vctor un ejercicio de normalizacin para una base de datos de alumnos, asignaturas y calificaciones. Vctor tendr que ir comprobando si est en 1F , luego conseguir que est en 2F , hacer los cambios oportunos para que est en 3F , e intentar conseguir la F BC.

Hasta ahora hemos definido los conceptos necesarios para poder entender las distintas formas normales, pero de aqu en adelante vamos a conocer dichas formas normales y los mecanismos para transformar las relaciones en otras equivalentes normalizadas si las dadas no lo estuvieran. Segn vayamos conociendo las distintas formas normales podremos comprobar que todas ellas van dependiendo de las anteriores, tal y como se refleja en la imagen con la que comienza el apartado. Como vemos en esa imagen del comienzo del apartado, existen ms formas normales aparte de las que veremos en este apartado, y todas ellas continan verificando las dependencias que se indican en la figura. La normalizacin a partir de la F BC rara vez se produce, ya que slo hace falta en sistemas muy concretos e inusuales. En algunos libros se habla hasta de una 6, 7 y 8F , pero dichas formas normales se salen de los objetivos de esta unidad, y de este mdulo profesional. 1F (Primera Forma ormal)

Una relacin est en primera forma normal (1F ) si y slo si todos los atributos no clave dependen funcionalmente de la clave y todos sus atributos son atmicos.

La siguiente relacin no estara en primera forma normal:

D I 76757473 Granada, 21

DIRECCIO

TELEFO Os 950343536 667667667 950505050

24252627

Islas Vrgenes, 20

950343434 696789210

El atributo TELEFONOS no es atmico, ya que para cada algunas tuplas tiene ms de un valor. Cmo podramos solucionar el problema? De manera intuitiva surgen dos posibles soluciones: Si sabemos el nmero exacto de distintos telfonos (CASO PRCTICAME TE IMPOSIBLE) que puede tener cada registro de la tabla, podemos aadir tantos atributos como telfonos se necesiten. O USAR ESTA FORMA E LA PRCTICA D I 76757473 DIRECCIO Granada, 21 TELEFO O_TRABAJO 950343536 TELEFO O_MOVIL 667667667 TELEFO O_CASA

juntadeandalucia.es//view2.php?id=4

8/18

05/06/2011 24252627

Islas Vrgenes, 20

950343434

Caso prctico 696789210

950505050

El problema de esta posible solucin es que O ES PTIMA porque desaprovecha mucho espacio de almacenamiento. Imaginemos por ejemplo a varias personas que slo tienen un telfono, por ejemplo, el telfono del trabajo, pero no tienen ni telfono mvil, ni telfono de casa. Por cada una de estas personas estaremos desaprovechando un espacio reservado para almacenar el telfono mvil y el telfono de casa. Creando una nueva tabla, en la cual almacenemos cada uno de los telfonos que tenga la persona, de la siguiente manera: conservamos la relacin original prescindiendo del campo multivaluado, y creamos una nueva relacin que estar compuesta por la clave primaria (el dni en este caso) y el campo que contena mltiples valores (en este caso el telfono). De este modo, en esta nueva relacin, la clave primaria estar formada por la unin de ambos atributos, es decir, por la pareja dni y telfono. Podemos apreciar tambin, que lo que si antes se almacenaban tres valores en una celda, ahora eso se traduce en tener tres filas en la nueva relacin. OJO! USAR SIEMPRE ESTA FORMA D I 76757473 24252627 Granada, 21 Islas Vrgenes, 20 DIRECCIO

D I 76757473 76757473 24252627 24252627 24252627 950343536 667667667 950505050 950343434 696789210

TELEFO O

En ambos casos las tablas resultantes s estn en primera forma normal, aunque reiteramos, que la mejor forma de normalizar sera la segunda explicada. 2F (Segunda Forma ormal)

Una relacin est en segunda forma normal (2F ) si y slo si est en 1F completo de la clave primaria.

y todos los atributos no clave dependen por

Consideramos la siguiente relacin: ALUMNO ( DNI, COD_ASIGNATURA, NOMBRE, APELLIDOS, NOTA, CURSO, AULA) donde se aprecian las siguientes dependencias funcionales: DNI --> NOMBRE, APELLIDOS DNI, COD_ASIGNATURA --> NOTA COD_ASIGNATURA --> CURSO, AULA Dicha relacin O se encuentra en 2F al estar los atributos NOMBRE y APELLIDOS determinados slo por el atributo DNI y no por la totalidad de la clave principal. Igual ocurre con los atributos CURSO y AULA, que estn determinados slo por COD_ASIGNATURA. Este hecho presenta una serie de inconvenientes tales como: Redundancia de datos: Con cada alumno de una misma asignatura repetimos toda la informacin acerca de la asignatura. Anomalas en la insercin de tuplas: Tenemos anomalas de insercin ya que no se pueden insertar las asignaturas que se imparten en un curso hasta que no insertamos algn alumno matriculado en esas asignaturas. En caso contrario, estaramos violando la regla de integridad de la clave al existir valores nulos en dicha clave. Anomalas en el borrado de tuplas: Igualmente aparecen anomalas en el borrado de tuplas, ya que al eliminar todos los alumnos de una determinada asignatura queda eliminada de manera automtica dicha asignatura. Anomalas en la actualizacin de tuplas: Si se hace un cambio de aula para una asignatura, es necesario modificar todas las tuplas de todos los alumnos matriculados en esa asignatura. Volvemos a ver que existe una gran redundancia de informacin en la Base de Datos.

juntadeandalucia.es//view2.php?id=4

9/18

05/06/2011 Caso prctico Posible inconsistencia de datos en las actualizaciones: o es ms que una consecuencia de las anomalas en la actualizacin de tuplas. Imagina que se te pasa modificar todas las tuplas de todos los alumnos matriculados en una asignatura cuando se producen cambios en la asignatura (por ejemplo, cambia el aula donde se imparte la asignatura). Alumnos distintos podran tener datos distintos para una misma asignatura, por ejemplo, distintas aulas donde se imparte, cuando realmente se imparte en una nica aula. Eso sera una inconsistencia. Imposibilidad de almacenar ciertos datos. o es ms que una consecuencia de las anomalas en la insercin. o nos resultara posible representar datos sobre asignaturas en las que no haya matriculado ningn alumno, o sobre aulas en las que no se imparte ninguna asignatura, cuando es perfectamente posible que queramos almacenar esa informacin.
Pero qu se hace cuando una relacin R no est en 2F ? Se transforma para que s est en 2F , y esta transformacin se realiza de la siguiente manera:

Dada una Relacin R con atributos X, Y, Z simples o compuestos, con la clave (X, Y) si en la relacin existe una dependencia funcional incompleta Y --> Z (Z depende de parte de la clave), entonces: De R se elimina Z. Se construye una nueva relacin R' con: Z como atributo no clave. Y como clave primaria de R'.

Las relaciones R y R' resultantes s estn ahora en segunda forma normal (2F ). Veamos esto con ms claridad con ayuda de un ejemplo. Consideramos la siguiente relacin y comprobamos si est en 2F :

ALUMNO ( DNI, COD_ASIGNATURA, NOMBRE, APELLIDOS, NOTA, CURSO, AULA ) Lo primero que tenemos que comprobar es que dicha relacin est en primera forma normal, como slo tenemos la intencin de la relacin, damos por supuesto que todos los valores de los atributos son atmicos. Ahora hay que comprobar la segunda parte de la definicin de segunda forma normal, es decir, que todos los atributos no clave dependen por completo de la clave primaria. Es decir, se DEBERA verificar las siguientes dependencias: DNI, COD_ASIGNATURA --> NOMBRE (esta dependencia no se cumple) DNI, COD_ASIGNATURA --> APELLIDOS (esta dependencia no se cumple) DNI, COD_ASIGNATURA --> NOTA DNI, COD_ASIGNATURA --> CURSO DNI, COD_ASIGNATURA --> AULA Pero es evidente que los atributos NOMBRE y APELLIDOS no dependen por completo de la clave, ya que slo dependen de DNI, y no de COD_ASIGNATURA. Al igual que CURSO y AULA dependen nicamente de COD_ASIGNATURA.

Cmo solucionamos esta situacin? Sencillamente descomponiendo la relacin dada en otras relaciones que s estn en segunda forma normal, separando los atributos que no tienen dependencia funcional completa respecto de la clave principal en otra tabla, junto con el/los atributo/s que forman la

juntadeandalucia.es//view2.php?id=4

10/18

05/06/2011 Caso prctico clave principal con los que s tienen dependencia funcional completa.
En nuestro caso concreto, la descomposicin sera la siguiente: ALUMNO (DNI, NOMBRE, APELLIDOS) CALIFICACION (DNI, COD_ASIGNATURA, NOTA) ASIGNATURA (COD_ASIGNATURA, CURSO, AULA) Como podemos comprobar, ahora NOMBRE y APELLIDOS s tienen dependencia funcional completa respecto de DNI en la relacin ALUMNO, y en el caso de la relacin CALIFICACION, el atributo NOTA depende completamente de la clave principal compuesta por DNI y COD_ASIGNATURA. Igualmente ocurre en el caso de la relacin ASIGNATURA, en la que tanto CURSO como AULA tienen dependencia funcional completa respecto de COD_ASIGNATURA. Por lo tanto, las tres relaciones estn en 2F , habiendo conseguido conservar las dependencias funcionales originales, la informacin y solucionado todos los problemas mencionados anteriormente. F (Tercera Forma ormal)

Una relacin est en tercera forma normal (3F ) si y slo si esta en 2F y no existen dependencias transitivas entre atributos no primos (los que no son llave).

Es decir, si sus atributos no clave son mutuamente independientes (no existe ningn atributo no clave que dependa funcionalmente de alguna combinacin del resto de atributos no clave) y adems sean por completo dependientes funcionalmente de la clave primaria. Consideramos la relacin ASIG ATURA del ejemplo anterior: ASIGNATURA (COD_ASIGNATURA, CURSO, AULA) En la que existen las siguientes dependencias funcionales: COD_ASIGNATURA --> CURSO CURSO --> AULA es una dependencia transitiva Con estas dependencias surgen una serie de inconvenientes en la relacin: Anomalas en la insercin de tuplas: no se puede insertar un curso si no se indica al menos una de las asignaturas de dicho curso. Estaramos violando la regla de integridad de la clave a insertar una tupla con valores nulos en la clave primaria. Anomalas en el borrado de tuplas: si se borran las tuplas de todas las asignaturas de un curso concreto, se borra de manera automtica dicho curso de la Base de Datos. Anomalas en la actualizacin de tuplas: si se realiza un cambio de aula para un curso determinado, tenemos que cambiar todas las tuplas de las asignaturas de dicho curso, lo que indica que existe una gran redundancia de informacin en la Base de Datos. De esta manera volvemos a cuestionarnos cmo solucionar que una relacin R no est en 3F ... Al igual que en el caso de la 2F , la solucin pasa por una descomposicin de la relacin dada en otras relaciones que s estn en 3F . Esta descomposicin se realiza de la siguiente manera:

Dada una relacin R (X,Y,Z) con atributos X, Y, Z simples o compuestos, con la clave X y atributos no claves Y, Z tal que en la relacin existen las dependencias funcionales: X --> Y ,Z Y --> Z

juntadeandalucia.es//view2.php?id=4

11/18

05/06/2011 Caso prctico ... es decir, una dependencia funcional transitiva X --> Z, entonces la relacin R se descompone como sigue:
De R se elimina Z (el atributo que tiene la dependencia funcional transitiva en la relacin). Se construye una nueva relacin R'con: Z como atributo, pero que no sea clave principal. Y como clave principal de R' . Y --> Z como dependencia funcional.

Las relaciones R y R' resultantes s estn en tercera forma normal. En definitiva, hemos eliminado las dependencias transitivas. Veamos esta descomposicin con el ejemplo anterior: ASIGNATURA (COD_ASIGNATURA, CURSO, AULA) Lo primero que tenemos que hacer es comprobar si la relacin est en 2F , para lo que se tiene verificar que est en 1F y que los atributos no clave tienen dependencia funcional completa respecto de la clave principal. Damos por cierto que todos los atributos toman valores atmicos para que la relacin est en 1F . Comprobamos ahora que en efecto, tanto CURSO como AULA tienen dependencia funcional completa respecto de COD_ASIGNATURA, por lo que la relacin ASIGNATURA est en 2F . Slo nos queda comprobar si existen dependencias funcionales transitivas, en cuyo caso la relacin dada no estara en 3F . Como podemos ver existen las siguientes dependencias en la relacin: COD_ASIGNATURA --> CURSO CURSO --> AULA dependencia transitiva (no cumple la 3FN) ... por lo que existe una dependencia funcional transitiva en la relacin. Cmo eliminamos la dependencia funcional transitiva? Descomponiendo la relacin dada en otras de tal manera que desaparezca dicha dependencia, es decir, separando el/los atributo/s que producen la dependencia funcional transitiva en una nueva relacin de la siguiente manera: ASIGNATURA (COD_ASIGNATURA, CURSO) CURSO (CURSO, AULA) F BC (Forma ormal de Boyce-Codd)

Una relacin est en forma normal Boyce/Codd (BC F) si y slo si todo determinante es una clave candidata.

Si consideramos la siguiente relacin: CALLEJERO (CALLE, CIUDAD, COD_POSTAL) con las siguientes dependencias funcionales: CALLE, CIUDAD --> COD_POSTAL COD_POSTAL --> CIUDAD COD_POSTAL es un determinante que no es clave candidata, por lo que la relacin no est en F BC. En esta ocasin vuelven a aparecer anomalas de insercin, actualizacin y borrado en la Base de Datos, y dichas anomalas desaparecen realizando una descomposicin adecuada de la relacin. En ocasiones esta descomposicin puede dar lugar a una prdida de dependencias funcionales, motivo por el que algunos autores no aconsejan pasar a la FNBC y quedarse en la 3FN. Otros sin embargo, prefieren continuar el proceso de normalizacin hasta sus formas ms avanzadas. En caso de decidir normalizar hasta la FNBC, la descomposicin se realiza de forma genrica como sigue:

Dada una relacin R con atributos X, Y, Z simples o compuestos, con clave {X, Y} y tal que en la relacin existen las siguientes dependencias funcionales:

juntadeandalucia.es//view2.php?id=4

12/18

05/06/2011 {X, Y} --> Z

Z --> Y

Caso prctico

es decir, existe un determinante no clave, y por lo tanto la relacin no est en forma normal de Boyce/Codd. Dicha relacin R se descompone como sigue: En R se deja la parte de la clave que es independiente y todos los atributos no primarios, es decir, R ( X, Z) Se crea otra tabla R' con la parte de la clave restante y el atributo secundario del que depende, siendo ste ltimo la clave de la nueva tabla. Es decir, R' (Y, Z).

Las relaciones R y R' resultantes s estn en forma normal de Boyce/Codd. Vemos esta descomposicin con la relacin CALLEJERO. Cmo podemos hacer que dicha relacin est en forma normal Boyce /Codd? Muy sencillo, siguiendo los pasos indicados ms arriba. Tenemos que separar los atributos origen del conflicto, para ello creamos las relaciones: En R dejamos la parte de la clave de CALLEJERO que es independiente, es decir, CALLE, y todos los atributos no primarios. En este caso slo tenemos el atributo COD_POSTAL. Por lo que R queda: CALLEJERO' (CALLE, COD_POSTAL) En R'(CODIGO_POSTAL) consideramos el resto de la clave primaria de la relacin CALLEJERO, es decir, CIUDAD, y el atributo del que depende, en este caso COD_POSTAL, con lo que R' (CODIGO_POSTAL) nos queda: CODIGO_POSTAL (COD_POSTAL, CIUDAD) Ahora CALLEJERO' y CODIGO_POSTAL s estn en forma normal de Boyce/Codd.

Ms Formas ormales...
No es objeto de esta unidad profundizar en los conceptos relacionados con la cuarta y siguientes formas normales, ya que para un buen diseo de una base de datos basta con normalizar hasta la tercera forma normal o la forma normal de Boyce-Codd (no siempre se puede normalizar hasta esta forma normal sin prdida de informacin o de dependencias funcionales), pero s es recomendable conocer al menos la definicin de la cuarta forma normal. En la mayora de los escritos relacionados con la normalizacin de las Bases de Datos se recomienda no pasar de la tercera forma normal o llegar como mucho a la FNBC para que no haya prdida de dependencias funcionales en las sucesivas descomposiciones que se realizan para alcanzar las distintas formas normales. Alcanzar la 4F o la 5F es posible nicamente en un nmero muy reducido de casos, y siempre hay que observar con detenimiento que se conservan todas las dependencias funcionales que definen el sistema que estamos modelando.

Para saber ms Para profundizar en la teora de las dependencias multivaluadas y las formas normales 4 y 5, entra en los siguientes enlaces donde encontrars ms informacin relacionada con el tema: Dependencias multivaluadas [Versin en cach] Formas normales [Versin en cach] Ms formas normales [Versin en cach]

Una relacin R (X, Y, Z) est en cuarta forma normal si para cada dependencia multivaluada no trivial X -->--> Y, X es una clave primaria de R. Esto es equivalente a decir que R est en 4F si est en F BC y todas las dependencias multivaluadas en R son de hecho dependencias funcionales.

Dada una relacin R (X, Y, Z) con X, Y, Z atributos simples o compuestos, y tal que en la relacin se dan las siguientes dependencias multivaluadas: X-->-->Y

juntadeandalucia.es//view2.php?id=4

13/18

05/06/2011 X-->-->Z

Caso prctico

Para transformar R en una relacin que est en 4F , dicha relacin se descompone en otras dos relaciones de la siguiente manera: R (X, Y) con X-->Y R' (X, Z) con X-->Z Las dos relaciones resultantes, R y R' s estn en 4F . Veamos esta definicin con un ejemplo concreto. Consideramos la siguiente relacin: AGENDA (NOMBRE, TELEFONO, CORREO) Es evidente que tenemos las siguientes dependencias funcionales: NOMBRE -->--> TELEFONO NOMBRE -->--> CORREO por lo que AGENDA no est en 4F . Lo solucionamos considerando las siguientes relaciones: R (NOMBRE, TELEFONO) R' (NOMBRE, CORREO) Ahora las relaciones resultantes R y R' s estn en 4F . En el siguiente enlace tienes una animacin sobre la relacin existente entre unas formas normales y otras. Qu relacin tienen unas formas normales con otras?

Ejemplo 1 de ormalizacin
1. ormalizar hasta la 3F la siguiente tabla: ACTORES(#ACTOR,#PELICULA,DNI,NOMBRE,DIRECTOR,F_INICIO,PAPEL,TIPO,#TIPO,DURACION,PRODUCTOR, TITULO,F_FIN,N_ARTISTICO,F_NAC) Los campos son los siguientes: #ACTOR: Cdigo asignado al actor (nico en la B.D.) #PELICULA: Cdigo asignado a la pelcula (nico en la B.D.) D I: DNI del actor. OMBRE: Nombre real del actor. DIRECTOR: Nombre del director de la pelcula. F_I ICIO: Fecha en la que el actor comienza la pelcula. PAPEL: Papel desempeado por el actor en la pelcula. TIPO: Tipo de pelcula (Intriga, drama, comedia, etc) #TIPO: Cdigo del tipo de pelcula. DURACIO : Duracin en minutos de la pelcula. PRODUCTOR: Nombre del productor de la pelcula. TITULO: Ttulo de la pelcula. F_FI : Fecha en la que el actor termin la pelcula. _ARTISTICO: Nombre artstico del actor. F_ AC: Fecha de nacimiento del actor. Se tienen en cuenta las siguientes suposiciones: a. Slo existe un director por pelcula. b. Slo existe un productor por pelcula. c. Un actor podr interpretar un nico papel por pelcula. Estudio de la 1F Vamos a hacer el estudio de la 1F : Veamos las dependencias funcionales de los distintos atributos: #ACTOR DNI, NOMBRE, N_ARTISTICO ,F_NAC #PELICULA TIPO, #TIPO, DURACION, TITULO, PRODUCTOR, DIRECTOR

juntadeandalucia.es//view2.php?id=4

14/18

05/06/2011 Caso prctico #ACTOR, #PELICULA PAPEL, F_INICIO ,F_FIN

Una vez detectadas todas las dependencias, estudio las relaciones entre los determinantes y veo claramente en este ejemplo que son las siguientes:

#ACTOR #ACTOR, #PELICULA #PELICULA

este smbolo significa que existe una relacin entre determinantes. Una vez hecho el estudio nos encontramos con las siguientes tablas: ACTORES(#ACTOR,DNI,NOMBRE,N_ARTISTICO,F_NAC) 1FN. OTRAS(#PELICULA,DIRECTOR,F_INICIO,PAPEL,TIPO,#TIPO,DURACION,PRODUCTOR,TITULO,F_FIN,#ACTOR) La tabla ACTORES se encuentra en 1FN, por lo que se queda como est y no es necesario descomponerla. La clave #ACTOR determina a todos los campos de la tabla. Vamos a estudiar la tabla OTRAS, para determinar la clave de la nueva tabla estudio las relaciones entre determinantes. Veo claramente que #ACTOR se relaciona con el determinante #ACTOR, #PELICULA por lo que propagar la clave de la entidad ACTORES. Para ponerle un nombre que identifique a esta nueva tabla veo la llave primaria, en este caso (#ACTOR, #PELICULA) a esta nueva tabla la llamaremos REALIZA. Pongo la nueva tabla con sus atributos y su clave primaria. REALIZA (#ACTOR, #PELICULA, DIRECTOR, F_INICIO, APEL, TIPO, #TIPO, DURACION, PRODUCTOR, TITULO, F_FIN) 1FN Esta tabla se encuentra en 1FN ya que la llave determina a todos los atributos. Con el estudio de la 1FN se han producido estas 2 tablas: ACTORES(#ACTOR,DNI,NOMBRE,N_ARTISTICO,F_NAC) 1FN. REALIZA (#ACTOR, #PELICULA, DIRECTOR, F_INICIO, APEL, TIPO, #TIPO, DURACION, PRODUCTOR, TITULO, F_FIN) 1FN Estudio de la 2F Pasemos a realizar el estudio de la 2F . Sobre la tabla ACTORES, esta tabla se encuentra en 2FN ya que los atributos no primos (los no clave) dependen de FORMA FUNCIONAL COMPLETA de la llave primaria (esto siempre ocurre cuando la llave primaria no es compuesta) ACTORES(#ACTOR,DNI,NOMBRE,N_ARTISTICO,F_NAC) 1FN, 2FN. Vamos a estudiar la otra tabla. En este caso la llave es compuesta y se divide en las 2 tablas siguientes (REALIZA y OTRAS): REALIZA (#ACTOR, #PELICULA, F_INICIO, PAPEL, F_FIN) 1FN, 2FN Queda otra tabla: OTRAS(#PELICULA,DIRECTOR,TIPO,#TIPO,DURACION,PRODUCTOR,TITULO) Viendo las relaciones entre los determinantes veo que la llave primaria es el atributo #PELICULA y le cambio el nombre a la tabla pasando a denominarlo PELCULA, una vez hecho esto estudio si se encuentra en 2FN (en este caso as es). PELCULA(#PELICULA,DIRECTOR,TIPO,#TIPO,DURACION,PRODUCTOR,TITULO) 1FN, 2FN Estudio de la 3F Pasemos a realizar el estudio de la 3F . En este caso estudiamos las dependencias transitivas entre atributos no primos sobre las tablas de color naranja.

juntadeandalucia.es//view2.php?id=4

15/18

05/06/2011 Caso prctico ACTORES(#ACTOR,DNI,NOMBRE,N_ARTISTICO,F_NAC)1FN,2FN REALIZA(#ACTOR, #PELICULA, F_INICIO, PAPEL, F_FIN) 1FN,2FN PELCULA(#PELICULA,DIRECTOR,TIPO,#TIPO,DURACION,PRODUCTOR, TITULO) 1FN,2FN
Las tablas ACTORES Y REALIZA SE ENCUENTRAN EN 3FN ACTORES(#ACTOR,DNI,NOMBRE,N_ARTISTICO,F_NAC) 3FN. REALIZA(#ACTOR, #PELICULA, F_INICIO, PAPEL, F_FIN) 3FN Esta tabla no se encuentra en 3FN ya que existen dependencias transitivas entre TIPO,#TIPO PELCULA(#PELICULA,DIRECTOR,TIPO,#TIPO,DURACION,PRODUCTOR,TITULO) 3FN Aplico la 3FN y quedan las siguientes tablas: PELCULA(#PELICULA,DIRECTOR,#TIPO,DURACION,PRODUCTOR,TITULO) 3FN TIPOPELICULA(#TIPO,TIPO) 3FN

Ejemplo 2 de ormalizacin
ormaliza hasta la 3 forma normal la siguiente tabla que almacena suministros de artculos por parte de proveedores TIENDA(#ARTICULO,#PROV, N_UNIDADES, DESCRIPCIN, NOMBRE, F_PEDIDO, COLOR, TAMAO, PAGO, #PAGO, PRECIO, ZONA, PESO, F_SUMINISTRO, F_NAC, #ZONA, TRANSPORTE) Donde los campos tienen los siguientes significados: #ARTICULO: Cdigo asignado al artculo (nico en la Base de datos) #PROV: Cdigo asignado al proveedor (nico en la Base de datos) _U IDADES: Nmero de unidades del artculo suministradas por el proveedor. DESCRIPCI : Descripcin del artculo OMBRE: Nombre del proveedor F_PEDIDO: Fecha en la que se hizo el pedido al proveedor COLOR: Color del artculo TAMAO: Tamao del artculo PAGO: Forma de pago. Ejemplo: cheque, contado, tarjeta #PAGO: Cdigo de la forma de pago: c cheque, t tarjeta PRECIO: Precio del artculo ZO A: Zona en la que el proveedor suministra el artculo PESO: Peso del artculo F_SUMI ISTRO: Fecha en la que el proveedor suministra el artculo F_ AC: Fecha de nacimiento del proveedor #ZO A: Cdigo de la zona en la que distribuye el proveedor TRA SPORTE: Campo lgico que indica si el transporte est incluido en el pedido Se tienen en cuenta las siguientes restricciones Se podrn realizar pedidos a un proveedor de un mismo artculo pero siempre en das diferentes Cada proveedor puede pagar de diferentes formas cada artculo Veamos las dependencias funcionales de los distintos atributos: #ARTICULO DESCRIPCIN, COLOR, TAMAO, PRECIO #PROVEEDOR NOMBRE, F_NAC, #ZONA #ARTICULO, #PROV, F_PEDIDO N_UNIDADES, F_SUMINISTRO, TRANSPORTE, PAGO #ZONA ZONA #PAGO PAGO Una vez detectadas todas las dependencias, se estudian las relaciones entre los determinantes y se ve claramente en este ejemplo que son las siguientes: #ARTICULO #ARTICULO, #PROV, #F_PEDIDO #PROV Estudio de la 1F Vamos a hacer el estudio de la 1F :

juntadeandalucia.es//view2.php?id=4

16/18

05/06/2011 Caso prctico Nos encontramos con las siguientes tablas tras aplicar el primer algoritmo para obtener la primera forma normal a la tabla TIENDA:
TIENDA1 (#ARTICULO,#PROV, DESCRIPCIN, NOMBRE, COLOR, TAMAO, PRECIO, ZONA, PESO, F_NAC, #ZONA) 1FN. Para crear la tabla OTRAS, se aaden los atributos que no estn en primera forma normal y se decide propagar #ARTICULO, #PROVEEDOR porque son necesarios para determinar a estos atributos, como se puede ver en el estudio de determinantes. Adems, en la tabla OTRAS se tiene que aadir el atributo F_PEDIDO a la clave primaria. OTRAS(#ARTICULO,#PROV, N_UNIDADES, F_PEDIDO, 1FN. F_SUMINISTRO, TRANSPORTE, PAGO, #PAGO)

Ya estn las dos tablas en Primera Forma Normal. Recordar que la tabla TIENDA ya no existe, ha sido sustituida por TIENDA1 y OTRAS. Podemos renombrar la tabla OTRAS, para adaptar el nombre a los atributos que contiene, aunque no es un paso un obligatorio, ayuda en el proceso de normalizacin. Un buen nombre sera SUMINISTROS. SUMINISTROS(#ARTICULO,#PROV, N_UNIDADES, F_PEDIDO, F_SUMINISTRO, TRANSPORTE, PAGO, #PAGO) 1FN. Por tanto, tras el estudio de la primera forma normal quedan las siguientes tablas: TIENDA1 (#ARTICULO,#PROV, DESCRIPCIN, NOMBRE, COLOR, TAMAO, PRECIO, ZONA, PESO, F_NAC, #ZONA) 1FN. SUMINISTROS(#ARTICULO,#PROV, #PAGO) 1FN. Estudio de la 2F Vamos a hacer el estudio de la 2F : Una tabla est en 2 Forma Normal si y slo si est en 1 Forma Normal y los atributos no primos tienen una dependencia funcional completa con la clave. Por tanto, comenzamos con la tabla TIENDA1. Hay que ir mirando los atributos no primos y comprobar si dependen completamente de la clave, si por ejemplo slo dependen de un atributo se seala. Para este ejemplo, sealamos en rojo los atributos que dependen de #ARTICULO, en azul los que dependen de #PROV y en verde los que dependen de las dos claves a la vez. TIENDA1(#ARTICULO, #PROV, DESCRIPCIN, NOMBRE, COLOR, TAMAO, PRECIO, ZONA, PESO, F_NAC, #ZONA) SUMINISTROS(#ARTICULO,#PROV, #PAGO) 1FN, 2FN F_PEDIDO, N_UNIDADES, F_SUMINISTRO, TRANSPORTE, PAGO, , F_PEDIDO, N_UNIDADES, F_SUMINISTRO, TRANSPORTE, PAGO,

Por tanto, la tabla TIENDA1 es sustituida por las siguientes tablas. Se renombran de forma adecuada. ARTICULOS (#ARTICULO, DESCRIPCIN, COLOR, TAMAO, PRECIO, PESO) 1FN, 2FN APROVEEDORES (#PROV, NOMBRE, ZONA, F_NAC, #ZONA) 1FN, 2FN Por tanto, tras aplicar la 2 Forma Normal quedan las siguientes tablas: SUMINISTROS(#ARTICULO,#PROV, #PAGO) 1FN, 2FN F_PEDIDO, N_UNIDADES, , F_SUMINISTRO, TRANSPORTE, PAGO,

ARTICULOS(#ARTICULO, DESCRIPCIN, COLOR, TAMAO, PRECIO, PESO) 1FN, 2FN PROVEEDORES (#PROV, NOMBRE, ZONA, F_NAC, #ZONA) 1FN, 2FN Estudio de la 3F Continuamos hacia la 3 Forma ormal. Una relacin est en 3 Forma Normal si y slo si est en 2 Forma Normal y no existen dependencias funcionales transitivas con la clave. Para comprobarlo, hay que mirar que en la tabla ningn atributo no primo se pueda deducir a partir de otro no primo, es decir, estudiar

juntadeandalucia.es//view2.php?id=4

17/18

05/06/2011 las dependencias transitivas entre atributos no primos.

Caso prctico

La tabla ARTICULOS est en 3 Forma Normal. La tabla SUMINISTROS y PROVEEDORES no estn en 3 Forma Normal. Los atributos que no lo cumplen estn sealados en azul. PROVEEDORES(#PROV, NOMBRE, ZONA, F_NAC, #ZONA) SUMINISTROS(#ARTICULO,#PROV, N_UNIDADES, F_PEDIDO, F_SUMINISTRO, TRANSPORTE, PAGO, #PAGO) Se aplica el algoritmo para la 3 Forma Normal. Por tanto, la tabla PROVEEDORES se sustituira por las dos siguientes: PROVEEDORES(#PROV, NOMBRE, F_NAC, #ZONA) ZONAS(#ZONA, ZONA) Y la tabla SUMINISTROS se sustituira por: SUMINISTROS(#ARTICULO,#PROV, N_UNIDADES, F_PEDIDO, F_SUMINISTRO, TRANSPORTE, #PAGO) PAGOS(#PAGO, PAGO) Llegados a este punto, tenemos las siguientes tablas: ARTICULOS (#ARTICULO, DESCRIPCIN, COLOR, TAMAO, PRECIO, PESO) PROVEEDORES (#PROV, NOMBRE, F_NAC, #ZONA) ZONAS (#ZONA, ZONA) SUMINISTROS (#ARTICULO,#PROV, F_PEDIDO N_UNIDADES, , F_SUMINISTRO, TRANSPORTE, #PAGO) PAGOS (#PAGO, PAGO)

juntadeandalucia.es//view2.php?id=4

18/18