UNIDAD V

DISEO DE BASES DE DATOS RELACIONALES

5.1.- Descomposicin y Normalizacin

Siempre que un analista de sistemas de base de datos arma una BD, queda a su cargo descomponer dicha base en grupos y segmentos de registros. Este proceso es la descomposicin. Sin embargo, para la base de datos relacional, la accin correspondiente puede dividirse y expresarse en trminos formales y se denomina normalizacin a la misma.

5.1.- Descomposicin y Normalizacin

La normalizacin convierte una relacin en varias subrelaciones, cada una de las cuales obedece a reglas. Estas reglas se describen en trminos de dependencia. Una vez que hayamos examinado las distintas formas de dependencia, encontraremos procedimientos a aplicar a las relaciones de modo tal que las mismas puedan descomponerse de acuerdo a la dependencia que prevalece. Esto no llevar a formar varias subrelaciones a partir de la nica relacin preexistente.

5.1.1.- DEPENDENCIA FUNCIONAL

Las dependencias funcionales desempean un papel fundamental en la diferenciacin entre los buenos diseos de bases de datos y los malos. Una dependencia funcional es un tipo de restriccin que constituye una generalizacin del concepto de clave. Las dependencias funcionales son restricciones del conjunto de relaciones legales. Permiten expresar hechos sobre la empresa que se modela con la base de datos.

5.1.1.- DEPENDENCIA FUNCIONAL

Consideremos el siguiente esquema: Esquema-info-prstamo=(nmero-prstamo, importe)

nombre-sucursal,

nombre-cliente,

El conjunto de dependencias funcionales que se espera que se cumplan en este esquema relacin son: Nota: Las dependencias funcionales que se cumplan deben de identificar de manera nica los que apunta la

5.1.1.- DEPENDENCIA FUNCIONAL

Se dice que importe es funcionalmente dependiente de Nmero-prstamo Nmero-prstamo importe Ejemplo: P12 = 1,000 Ejemplo: P13 = 2,000 Se dice que nombre-sucursal es funcionalmente dependiente de Nmeroprstamo Nmero-prstamo nombre-sucursal Ejemplo: P12 = Centro Ejemplo: P13 = Centro Ejemplo: P14 = Navacerrada

5.1.1.- DEPENDENCIA FUNCIONAL

Sin embargo, no se espera que se cumpla la dependencia funcional Nmero-prstamo nombre-cliente, ya que en general, cada prstamo se puede conceder a ms de un cliente (por ejemplo, a los dos integrantes de una pareja marido-mujer).

5.1.1.- DEPENDENCIA FUNCIONAL

Una dependencia funcional es tambin una conexin entre uno o ms atributos. Por ejemplo si conocemos el valor de FechaDeNacimiento podemos conocer el valor de Edad. Las dependencias funcionales del sistema se escriben utilizando una flecha, de la siguiente manera: FechaDeNacimiento Edad Aqu a FechaDeNacimiento se le conoce como un determinante. Se puede leer de dos formas FechaDeNacimiento determina a Edad o Edad es funcionalmente dependiente de FechaDeNacimiento. De la normalizacin (lgica) a la implementacin (fsica o real) puede ser sugerible tener stas dependencias funcionales para lograr la eficiencia en las tablas.

5.1.1.- DEPENDENCIA TRANSITIVA

Sean X, Y, Z tres atributos (o grupos de atributos) de la misma entidad. Si Y depende funcionalmente de X y Z de Y, pero X no depende funcionalmente de Y, se dice que Z depende transitivamente de X. Simblicamente sera: X Y Z entonces X Z FechaDeNacimiento Edad Edad Conducir FechaDeNacimiento Edad Conducir Entonces tenemos que FechaDeNacimiento determina a Edad y la Edad determina a Conducir, indirectamente podemos saber a travs de FechaDeNacimiento a Conducir (En muchos pases , una persona necesita ser mayor de cierta edad para poder conducir un automvil, por eso se utiliza este ejemplo).

5.1.2.- ANOMALIAS
Entre las anomalas indeseables que puede tener un mal diseo estn: Repeticin de la informacin Imposibilidad de la representacin de determinada informacin. Ejemplo: La informacin relativa a los prstamos se guarda en una sola relacin prstamos, que se define mediante el siguiente esquema de relacin: Esquema-prstamos = (nombre-sucursal, ciudad-sucursal, activo, nombre-cliente, nmero-prstamo, importe)

5.1.2.- ANOMALIAS

5.1.2.- ANOMALIAS

5.1.2.- ANOMALIAS
Supongamos que deseamos aadir un nuevo prstamo a la base de datos. Digamos que el prstamo se lo concede la sucursal de Navacerrada a la Seora Fernndez por un importe de 1,500 euros, el nmero de prstamo que se la asigna es el P-31. En el diseo hace falta una tupla con los valores de todos los atributos de Esquema-prstamos. Por lo tanto hay que repetir los datos del activo y de la ciudad de la sucursal de Navacerrada y aadir la tupla a la relacin prstamos. En general los datos del activo y de la ciudad deben aparecer una vez para cada prstamo concedido por esa sucursal.

5.1.2.- ANOMALIAS
La repeticin de la informacin en el diseo alternativo no es deseable. La repeticin de la informacin desaprovecha el espacio. Adems complica la actualizacin de la base de datos. Supongamos por ejemplo, que el activo de la sucursal Navacerrada cambia de 1,700,000 a 1,900,000. con el diseo original hay que modificar una tupla de la relacin sucursal. Con el diseo alternativo hay que modificar muchas tuplas de la relacin prstamos. Por lo tanto, las actualizaciones resultan ms costosas con el diseo alternativo que con el diseo original. Cuando se lleva a cabo la actualizacin en la base de datos alternativa, hay que asegurarse de que se actualicen todas las tuplas correspondientes a la sucursal Navacerrada, o la base de datos mostrar dos valores diferentes del activo para esa sucursal.

5.1.2.- ANOMALIAS
1Otro problema del diseo Esquema-prstamos es que no se puede representar de manera directa la informacin relativa a cada sucursal(nombresucursal, ciudad-sucursal, activo), a menos que haya como mnimo un prstamo en esa sucursal. Esto se debe a que las tuplas de las relacin prstamos exigen los valores de nmero-prstamo, importe y nombre-cliente

5.1.3.- NORMALIZACIN
La normalizacin es el proceso mediante el cual se transforman datos complejos a un conjunto de estructuras de datos ms pequeas, que adems de ser ms simples y ms estables, son ms fciles de mantener. Tambin se puede entender la normalizacin como una serie de reglas que sirven para ayudar a los diseadores de bases de datos a desarrollar un esquema que minimice los problemas de lgica. Cada regla est basada en la que le antecede. La normalizacin se adopt porque el viejo estilo de poner todos los datos en un solo lugar, como un archivo o una tabla de la base de datos, era ineficiente y conduca a errores de lgica cuando se trataban de manipular los datos.

5.1.3.- NORMALIZACIN
La normalizacin tambin hace las cosas fciles de entender. Los seres humanos tenemos la tendencia de simplificar las cosas al mximo. Lo hacemos con casi todo, desde los animales hasta con los automviles. Vemos una imagen de gran tamao y la hacemos ms simple agrupando cosas similares juntas. Las guas que la normalizacin provee crean el marco de referencia para simplificar una estructura de datos compleja. Otra ventaja de la normalizacin de base de datos es el consumo de espacio. Una base de datos normalizada ocupa menos espacio en disco que una no normalizada. Hay menos repeticin de datos, lo que tiene como consecuencia un mucho menor uso de espacio en disco.

5.1.3.- NORMALIZACIN

El proceso de normalizacin tiene un nombre y una serie de reglas para cada fase. Esto puede parecer un poco confuso al principio, pero poco a poco se va entendiendo el proceso, as como las razones para hacerlo de esta manera.

5.1.4.- FORMAS NORMALES

Formas Normales: Son las reglas que debemos cumplir para evitar: existencia redundancia de datos. Problemas de actualizacin de la base de datos y mantener la integridad de las tablas que componen la base de datos

5.1.4.- Primera Forma Normal(1FN)

Una relacin esta en primera forma normal (1FN) si y solo si todos los dominios base de los campos tienen valores atmicos. Es decir, un campo solo tiene un valor y no un conjunto de valores.

5.1.4.- Primera Forma Normal(1FN)

No esta en 1FN

5.1.4.- Primera Forma Normal(1FN)

5.1.4.- Primera Forma Normal(1FN)

juanp@ecn.es; jefe2@ecn.es

111

Juan Prez

Jefe de rea

3000

222

Jos Snchez

Administrativo

1500

jsanchez@ecn.es

333

Ana Daz

Administrativo

1500

adiaz@ecn.es; ana32@gmail.com

...

...

... TABLE 1

...

...

5.1.4.- Primera Forma Normal(1FN)

111 111 222 Juan Prez Juan Prez Jos Snchez Jefe de rea Jefe de rea 3000 3000 juanp@ecn.es jefe2@ecn.es jsanchez@ecn.es

Administrativo 1500

333

Ana Daz

Administrativo 1500

adiaz@ecn.es

333 ...

Ana Daz ...

Administrativo 1500 ... TABLE 2 ...

ana32@gmail.com ...

5.1.4.- Primera Forma Normal(1FN)

111 222 333 ...

Juan Prez Jos Snchez Ana Daz ...

Jefe de rea Administrativo Administrativo ... TABLE 3

3000 1500 1500 ...

5.1.4.- Primera Forma Normal(1FN)

111 111 222 333 333 ... juanp@ecn.es jefe2@ecn.es jsanchez@ecn.es adiaz@ecn.es ana32@gmail.com ... TABLE 4

5.1.4.- Segunda Forma Normal(2FN)

Una relacin est en segunda forma normal si est en 1FN y adems cumple la condicin de que cada atributo no-llave depende de la llave primaria.

5.1.4.- Segunda Forma Normal(2FN)

5.1.4.- Segunda Forma Normal(2FN)

5.1.4.- Segunda Forma Normal(2FN)

5.1.4.- Segunda Forma Normal(2FN)

5.1.4.- Segunda Forma Normal(2FN)

5.1.4.- Segunda Forma Normal(2FN)

5.1.4.- Segunda Forma Normal(2FN)

5.1.4.- Tercera Forma Normal(3FN)

Una relacin R est en 3FN si y solo si esta en 2FN y todos sus atributos no claves dependen no transitivamente de la llave primaria. Consiste en eliminar la dependencia transitiva que queda en una segunda forma normal, en pocas palabras una relacin esta en tercera forma normal si est en segunda forma normal y no existen dependencias transitivas entre los atributos, nos referimos a dependencias transitivas cuando existe ms de una forma de llegar a referencias a un atributo de una relacin.

5.1.4.- Tercera Forma Normal(3FN)

ID_ESTUDIANTE
01234 22346 11349 01234 08349 03472 22346 01234 33461 03472

ID-CLASE
FIS-1A FIS-1A QUIM-2B QUIM-2B MUS-5 ARTE-3A QUIM-1A MUS-5 ARTE-3A MUS-1

CALIFICACION
A B A A B C B -

PROFESOR
Vsquez, N. Vsquez, N. Pardo, L. Pardo, L. Hurtado, R Hurtado, R. Pardo, L. Hurtado, R. Hurtado, R. Hurtado, R

OFICINA
M11 M11 CT2 CT2 M22 M22 CT2 M22 M22 M22

5.1.4.- Tercera Forma Normal(3FN)

ID-CLASE (clave) PROFESOR OFICINA
FIS-1A Vzquez, N. M11

MUS-1

Hurtado, R

M22

QUIM-2B

Pardo, L.

CT2

QUIM-1

Pardo, L.

CT2

MUS-5

Hurtado, R

M22

ARTE-3A

Hurtado, R

M22

5.1.4.- Tercera Forma Normal(3FN)

(Clave) ID-ESTUDlANTE
01234 22346 11349 01234 08349 03472 22346 01234 33461 03472

(Clave) ID-CLASE
FIS-1A FIS-1A QUIM-2B QUIM-2B MUS-5 ARTE-3A QUIM-1A MUS-5 ARTE-3A MUS1

CALIFICACION

A B A A B C B -

5.1.4.- Tercera Forma Normal(3FN)

ID-CLASE (clave)
FIS-1A MUS-1 QUIM-2B QUIM-1 MUS-5 ARTE-3A

PROFESOR
Vzquez, N. Hurtado, R

PROFESOR
Vzquez, N.

OFICINA
M11

Hurtado, R Pardo, L. Pardo, L. Hurtado, R Hurtado, R Pardo, L.

M22

CT2

5.1.4.- Tercera Forma Normal(3FN)

No-Ctrl_Alu

Nom_Alu Esp_Alu

Cve_Mat

Nom_Mat Creditos_Mat Cve_Mae Nom_Mae Plaza_Mae RFC_Mae

5.1.4.- Tercera Forma Normal(3FN)

No-Ctrl_Alu

Nom_Alu Esp_Alu

5.1.4.- Tercera Forma Normal(3FN)

Cve_Mat

Nom_Mat Creditos_Mat

5.1.4.- Tercera Forma Normal(3FN)

Cve_Mae Nom_Mae Plaza_Mae RFC_Mae

5.1.4.- Tercera Forma Normal(3FN)

Cve_Mae Nom_Mae Plaza_Mae

5.1.4.- Tercera Forma Normal(3FN)

RFC_Mae

Nom_Mae

5.1.4.- Cuarta Forma Normal(4FN)

La 4NF se asegura de que los hechos multivalores independientes estn correcta y eficientemente representados en un diseo de base de datos. La definicin de la 4NF confa en la nocin de una dependencia multivalorada. Una tabla con una dependencia multivalorada es una donde la existencia de dos o ms relaciones independientes muchos a muchos causa redundancia; y es esta redundancia la que es suprimida por la cuarta forma normal.

5.1.4.- Cuarta Forma Normal(4FN)

Restaurante Vincenzo's Pizza Vincenzo's Pizza Vincenzo's Pizza Vincenzo's Pizza Elite Pizza Elite Pizza A1 Pizza A1 Pizza A1 Pizza A1 Pizza A1 Pizza A1 Pizza Variedad de Pizza Corteza gruesa Corteza gruesa Corteza fina Corteza fina Corteza fina Corteza rellena Corteza gruesa Corteza gruesa Corteza gruesa Corteza rellena Corteza rellena Corteza rellena rea de envo Springfield Shelbyville Springfield Shelbyville Capital City Capital City Springfield Shelbyville Capital City Springfield Shelbyville Capital City

5.1.4.- Cuarta Forma Normal(4FN)

Debido a que las variedades de pizza que un restaurante ofrece son independientes de las reas a las cuales el restaurante enva, hay redundancia en la tabla: por ejemplo, nos dicen tres veces que A1 Pizza ofrece la Corteza rellena, y si A1 Pizza comienza a producir pizzas de Corteza de queso entonces necesitaremos agregar mltiples registros, uno para cada una de las reas de envo de A1 Pizza. En trminos formales, esto se describe como que Variedad de pizza est teniendo una dependencia multivalorada en Restaurante.

5.1.4.- Cuarta Forma Normal(4FN)

Para satisfacer la 4NF, debemos poner los hechos sobre las variedades de pizza ofrecidas en una tabla diferente de los hechos sobre reas de envo:
Variedades por restaurante Restaurante Vincenzo's Pizza Vincenzo's Pizza Elite Pizza Elite Pizza A1 Pizza A1 Pizza Variedad de pizza Corteza gruesa Corteza fina Corteza fina Corteza rellena Corteza gruesa Corteza rellena

5.1.4.- Cuarta Forma Normal(4FN)

Para satisfacer la 4NF, debemos poner los hechos sobre las variedades de pizza ofrecidas en una tabla diferente de los hechos sobre reas de envo:
Restaurante Vincenzo's Pizza Vincenzo's Pizza Elite Pizza A1 Pizza A1 Pizza A1 Pizza rea de envo Springfield Shelbyville Capital City Springfield Shelbyville Capital City

5.1.4.- Cuarta Forma Normal(4FN)

5.1.4.- Cuarta Forma Normal(4FN) El tipo de vehculos depende del conductor y el tipo de vehculo depende de la carga. En este caso hay dependencias funcionales multivaloradas, ya que algunos atributos que forman la clave dependen de otro atributo que tambin la forman.

5.1.4.- Cuarta Forma Normal(4FN)

5.1.4.- Cuarta Forma Normal(4FN)