Clase 04 - Base de Datos

LOGO
BASE DE DATOS
Normalizacin
ING. REGF
Base de datos Normalizacin

Normalizacin
Habitualmente, el diseo de una base de datos termina en
el paso del modelo entidad-relacin al modelo relacional.
No obstante, siempre que se disea un sistema, no solo una
base de datos, sino tambin cualquier tipo de solucin
informtica, se ha de medir la calidad de la misma, y si no
cumple determinados criterios de calidad, hay que realizar,
de forma iterativa, sucesivos refinamientos en el diseo,
para alcanzar la calidad deseada.
Uno de los parmetros que mide la calidad de una base de
datos es la forma normal en la que se encuentra su diseo.
Esta forma normal puede alcanzarse cumpliendo ciertas
restricciones que impone
cada forma normal
al conjunto de
2
ING. REGF

Normalizacin
ING. REGF

Normalizacin
La teora de la normalizacin se ha desarrollado para
obtener estructuras de datos eficientes que eviten las
anomalas de actualizacin.
El concepto de normalizacin fue introducido por E.F. Codd
y fue pensado para aplicarse a sistemas relacionales. Sin
embargo, tiene aplicaciones ms amplias.
La normalizacin es la expresin formal del modo de
realizar un buen diseo.
Provee los medios necesarios para describir la estructura
lgica de los datos en un sistema de informacin.
4
ING. REGF

Normalizacin
Las formas normales pretenden alcanzar dos objetivos:
1. Almacenar en la base de datos cada hecho solo una
vez, es decir, evitar la redundancia de datos. De esta
manera se reduce el espacio de almacenamiento.
2. Que los hechos distintos se almacenen en sitios
distintos. Esto evita ciertas anomalas a la hora de
operar con los datos.
En la medida que se alcanza una forma normal ms

avanzada, en mayor medida se cumplen estos objetivos.
Hay definidas 5 formas normales, cada una agrupa a las
anteriores, de forma que, por ejemplo, la forma normal 3
cumple la forma normal 2 y la forma normal 1.
5
ING. REGF

Normalizacin
Ventajas de la normalizacin:
Evita anomalas en la actualizacin.
Mejora la independencia de los datos, permitiendo realizar
extensiones de la base de datos, afectando muy poco, o
nada, a los programas de aplicacin existentes que
accedan la base de datos.
La normalizacin involucra varias fases que se realizan en
orden. La realizacin de la 2da. fase supone que se ha
concluido la 1ra. y as sucesivamente. Tras completar cada
fase se dice que la relacin est en:
Primera Forma Normal (1FN)
Segunda Forma Normal (2FN)
Tercera Forma Normal (3FN)
6
Forma Normal de Boyce-Codd
(FNBC)
ING. REGF

Normalizacin
PRIMERA FORMA NORMAL (1FN)
Para las explicaciones de los contenidos correspondientes a
las formas normales de la 1FN hasta la 3FN,
desarrollaremos un ejemplo que consiste en el diseo de
la base de datos para la automatizacin del control de los
pedidos de productos y que se presenta a continuacin.
Supongamos que los modelos para pedir los productos sean
como se muestra en la siguiente figura:
ING. REGF

Normalizacin
PASO 1: se lista los atributos y se determina la llave de toda
la relacin.
a) El anlisis de este modelo de pedido de productos
muestra que los atributos que se listan a continuacin
son de inters:
NUM_PED:
FEC_PED:
NUM_PROV:
NOM_PROV:
DIR_PROV:
NUM_PROD:
nmero del pedido

fecha en que se realiza el pedido
nmero del proveedor
nombre del proveedor
direccin del proveedor
nmero del producto
8
ING. REGF

Normalizacin
DES_PROD:
descripcin del producto
PR_UN_PROD:
precio unitario del producto
CANT_PROD_PED: cantidad de unidades del producto
que se solicita
PR_PROD_PED:
precio a pagar por concepto de ese
producto; corresponde a la columna TOTAL
PR_PED:
precio a pagar por todo el pedido;
corresponde al IMPORTE TOTAL.
ING. REGF

Normalizacin
b) El nmero de pedido es nico y se utiliza para referirse a
un pedido, por tanto, se usar como clave (llave).
Nota: esta es una suposicin inicial, que luego se discutir.
c) Se determina los subconjuntos posibles.
NUM_PROD: nmero del producto
DES_PROD: descripcin del producto
PR_UN_PROD: precio unitario del producto
CANT_PROD_PED: cantidad de unidades del producto que
se solicita.
PR_PROD_PED: precio a pagar por concepto de ese
ING. REGF
producto; corresponde10a la columna TOTAL

Normalizacin
d) Se determina el atributo del cual dependen los dems
atributos total o parcialmente, en este caso es
NUM_PROD, para crear la clave compuesta.
e) Luego, se determina la relacin resultante:
PEDIDO (NUM_PED, FEC_PED, NUM_PROV,
NOM_PROV, DIR_PROV, NUM_PROD, DES_PROD,
PR_UN_PROD, CANT_PROD_PED, PR_PROD_PED,
PR_PED)
11
ING. REGF

Normalizacin
Definicin: Primera Forma Normal (1FN)
Definicin: toda relacin normalizada, o sea, con valores
atmicos de los atributos, est en 1FN.
Otra definicin: una relacin est en 1FN si no incluye
ningn grupo repetitivo.
(Un grupo repetitivo es un atributo que contiene un conjunto
de valores y no un nico valor)
12
ING. REGF

Normalizacin
Se puede observar que la relacin PEDIDO contiene 5
atributos repetitivos:
- NUM_PROD
- DES_PROD
- PR_UN_PROD
- CANT_PROD_PED
- PR_PROD_PED
13
ING. REGF

Normalizacin
Ya que un pedido puede contener ms de una lnea de
pedido y, por lo tanto, puede contener varios nmeros de
producto (NUM_PROD), varias descripciones de producto
(DES_PROD), varios precios unitarios (PR_UN_PROD),
varias cantidades (CANT_PROD_PED) y varios precios por
concepto del producto (PR_PROD_PED).
Esta situacin acarrea problemas de actualizacin, pues
habra que decidir la cantidad mxima de lneas de pedido
de productos que se permitira en un pedido, dado que los
campos de la tabla PEDIDO deben tener un tamao dado y,
entonces, seran capaces de almacenar slo una
determinada cantidad mxima
de valores ING.
cada
uno de ellos.
14
REGF

Normalizacin
Esto sera agregar una limitacin en el modelo pues no tiene
ese comportamiento en la realidad.
Adems, en general, se desaprovechara memoria, dado
que si se decide, por ejemplo, que se va a permitir hasta 20
lneas de pedido en cada pedido, habra que definir tamaos
de campos para los grupos repetitivos que permitieran
almacenar esa cantidad de valores.
Entonces, si en un pedido se solicitan menos de 20
productos, lo cual puede ser muy frecuente, no se utilizara
parte del espacio reservado para cada campo.
15
ING. REGF

Normalizacin
PASO 2: determinar las relaciones de grupos repetidos de
los que no lo son Hay que eliminar esos grupos repetitivos
para que la relacin est en 1FN. Para ello, se crea:
1. Una relacin para los campos que sean nicos, es decir,
se dejan en la relacin original slo los atributos que no
son repetitivos:
PEDIDO (NUM_PED, FEC_PED, NUM_PROV,
NOM_PROV, DIR_PROV, PR_PED)
2. Se crea una relacin para los grupos repetitivos.
Adems, se crea una llave compuesta formada por la
llave primaria de la relacin original (NUM_PED) y el
atributo del cual dependen los dems atributos repetidos
total o parcialmente, en este caso es NUM_PROD:
PED-PROD (NUM_PED, NUM_PROD, DES_PROD,
16
ING. REGF
PR_UN_PROD, CANT_PROD_PED,
PR_PROD_PED)

Normalizacin
PASO 3: determinacin de la llave de cada relacin
Ambas tienen como llave, o parte de la llave, a NUM_PED.
Pero en PED-PROD es necesario la llave compuesta para
identificar los productos individuales pues, por ejemplo,
CANT_PROD_PED se refiere a la cantidad en que se pide
un determinado producto en un pedido dado (el producto
puede solicitarse en otros pedidos en diferentes cantidades
y en el pedido se pueden estar pidiendo otros productos en
diferentes cantidades) y, por lo tanto, para identificar una
cantidad dada es necesario referirse al pedido y al
producto correspondientes.
17
ING. REGF

Normalizacin
PASO 3: determinacin de la llave de cada relacin
Ahora estas nuevas dos relaciones en 1FN modelan el que
nos ocupa. Los problemas de actualizacin mencionados
anteriormente quedan resueltos con este nuevo modelo.
En lugar de tener varios valores en cada campo de acuerdo
a la cantidad de lneas de pedido, tal y como ocurra en la
tabla PEDIDO original, se tienen varias ocurrencias en la
tabla PED-PROD, una por cada producto que se solicita en
el pedido. Esto permite que se soliciten tantos productos
como se desee en cada pedido, pues slo significa agregar
una nueva ocurrencia en la relacin PEDPROD por cada
producto solicitado.
18
ING. REGF

Normalizacin
Sin embargo, este modelo en 1FN tiene an problemas de
actualizacin, como se muestra en las siguientes
operaciones:
Creacin: la informacin sobre un nuevo producto no se
puede insertar si no hay un pedido que lo incluya.
Eliminacin: eliminar una lnea de pedido que sea la nica
que pida un producto implica perder la informacin del
producto.
Modificacin: por cada lnea de pedido en la que se solicite
determinado producto se tiene una ocurrencia en PED19
ING. REGF
PROD, que repite la informacin
sobre ste.
Si cambia

Normalizacin
Entonces ser necesario aplicar formas normales ms
fuertes a este modelo para eliminar los problemas de
actualizacin que presenta, como veremos en las siguientes
normalizaciones.
20
ING. REGF

Normalizacin
AUTOEVALUACIN
Ejercicio 1:
En un laboratorio productor de medicamentos se tiene una
relacin para almacenar la informacin acerca de la
composicin de cada medicamento, de modo de saber cada
compuesto que contiene el medicamento y la cantidad de
ste necesario para su elaboracin:
medicamento (cd_med, nom_med, presentacin,
nom_comp, cant_unid_comp)
por lo que una ocurrencia de esta relacin podra ser, por
ejemplo:
21
ING. REGF
Base de datos Diseo lgico relacional

Normalizacin
Antes de abordar las distintas formas normales, es
necesario definir los siguientes conceptos:
Dependencia funcional: Se dice que un atributo Y depende
funcionalmente de otro atributo X, o que X > Y, si cada
valor de X tiene asociado en todo momento un nico valor
de Y. Tambin se dice que X implica Y, y por tanto, que X es
el implicante. Por ejemplo:
PRODUCTOS (CdigoProducto, Nombre, Precio,
Descripcin) CdigoProducto > Nombre, puesto que un
cdigo de producto solo puede tener asociado un nico
nombre, dicho de otro modo, a travs del cdigo de
producto se localiza un nico nombre.
22
ING. REGF

Normalizacin
Dependencia funcional completa: Dado una combinacin
de atributos X(X1,X2,), se dice que Y tiene dependencia
funcional completa de X, o que X=>Y, si depende
funcionalmente de X, pero no depende de ningn
subconjunto del mismo. Por ejemplo:
COMPRAS (CdigoProducto, CdigoProveedor, Cantidad,
FechaCompra) CdigoProducto, CdigoProveedor =>
FechaCompra, puesto que la FechaCompra es nica para
la combinacin de CdigoProducto y CdigoProveedor
(se puede hacer un pedido al da de cada producto a, cada
proveedor), y sin embargo, se pueden hacer varios pedidos
del mismo producto a. diferentes proveedores, es decir,
CdigoProducto
Fecha.
23
ING. REGF

Normalizacin
Dependencia funcional transitiva: Dada la tabla T, con
atributos (X,Y,Z), donde X > Y, Y>Z e Y X, se dice que
X depende transitivamente de Z, o que, X - > Z.
Ejemplo 1:
PRODUCTOS (CdigoProducto, Nombre, Fabricante, Pas)
CdigoProducto > Fabricante
Fabricante > Pas
CdigoProducto - > Pas, es decir, CdigoProducto
depende transitivamente de Pas.
24
ING. REGF

Normalizacin
SEGUNDA FORMA NORMAL (2FN)
Definicin: Segunda Forma Normal Una relacin R se dice
que est en 2FN si est en 1FN y si, y slo si, los atributos
no llaves (ni primarias, ni candidatas) de R, si los hubiese,
son funcional y completamente dependientes de la llave
primaria de R.
Entonces, se aplica slo a relaciones con llaves
compuestas, pues no es posible que en una relacin cuya
llave primaria sea simple (compuesta por un solo atributo)
haya atributos que dependan de parte de la llave primaria.
Una relacin que est en 1FN y que tenga una llave
primaria simple, est en 2FN.
25
ING. REGF

Normalizacin
Continuando con el ejemplo de los pedidos de productos,
habamos visto que en la relacin PED-PROD subsistan
problemas de actualizacin. Analicemos las Dependencia
funcionales que existen en dicha relacin:
26
ING. REGF

Normalizacin
Paso nico: se determina si existen relaciones con clave
compuesta. Si NO las hay, las relaciones obtenidas en la
Primera Forma Normal se encuentran en Segunda Forma
Normal. De lo contrario, se efecta lo siguiente:
1. Se crea una relacin para todos los atributos que
dependen funcional y completamente de la llave (y los
atributos que no se analizan por ser atributos llaves,
pertenecientes a claves candidatas).
PED-PROD (NUM_PED, NUM_PROD, CANT_PROD_PED,
PR_PROD_PED)
2. Se crea una relacin para los atributos que dependan de

cada parte (subconjunto) de la llave. La llave de la
relacin as formada ser la parte (subconjunto) de la
llave primaria de la cual dependen los atributos.
27
ING. REGF

Normalizacin
Los problemas planteados en la 1FN se resuelven con la
2FN. Veamos:
Creacin: se puede insertar la informacin sobre un
producto aunque no haya un pedido que lo solicite.
Eliminacin: se puede eliminar una lnea de pedido y no se
pierde la informacin sobre el producto, aunque sea el
nico pedido que pide ese producto.
Modificacin: si cambia un atributo del producto, slo hay
que cambiarlo en un lugar. Se elimina redundancia.
28
ING. REGF

Normalizacin
Pero an tenemos problemas en este caso que son
similares a los ya vistos, pero con la relacin PEDIDO y,
especficamente, cuando se trata de insertar, eliminar o
modificar la informacin de proveedores:
Creacin: no podemos insertar la informacin de un
proveedor, a menos que haya un pedido para l.
Eliminacin: se perder la informacin sobre un proveedor
al borrar un pedido que era el nico que se le haca a ese
proveedor.
Modificacin: para cambiar informacin sobre un proveedor,
hay que recorrer todos los pedidos de ese proveedor. Hay
29
redundancia.
ING. REGF

Normalizacin
TERCERA FORMA NORMAL (3FN)
Definicin: Tercera Forma Normal
Una relacin R est en 3FN si est en 2FN y si, y slo si, los
atributos no llaves son independientes de cualquier otro
atributo no llave primaria.
Esto es lo mismo que decir que se deben eliminar las
dependencias transitivas de atributos no llaves respecto a la
llave primaria, estando ya la relacin en 2FN.
Definicin: Dependencia transitiva
Sean A, B y C conjuntos de atributos de una relacin R. Si
B es dependiente funcionalmente de A y C lo es de B,
entonces C depende transitivamente de A.
30
ING. REGF

Normalizacin
Este paso se ejecuta examinando todas las relaciones para
ver si hay atributos no llaves que dependan unos de otros.
Si se encuentran, se forma una nueva relacin para ellos.
Analicemos las dependencias funcionales que existen en la
relacin PEDIDO:
31
ING. REGF

Normalizacin
Paso 1: se remueven los atributos que no dependen de
la llave
1. Se crea una relacin para los atributos no llaves que no
dependen transitivamente de la llave primaria (y los
atributos que no se analizan por ser atributos llaves,
pertenecientes a claves candidatas).
PEDIDO (NUM_PED, FEC_PED, NUM_PROV, PR_PED)
Paso 2: se remueven los atributos que dependen de la

llave
2. Se crea una relacin para los atributos no llaves que
dependen transitivamente de la llave primaria a travs
de otro atributo o conjunto de atributos no llave primaria
(que no son parte de la llave primaria.) La llave primaria
de la relacin as formada ser el atributo o conjunto de
atributos a travs 32de los cuales existe
la dependencia
ING. REGF

Normalizacin
Es necesario analizar las otras relaciones. Puede
comprobarse que en las otras relaciones no hay
dependencia entre atributos no llaves, por lo que estn en
3FN.
Entonces el modelo de datos relacional en 3FN que
representa el de los pedidos de productos est formado por
las siguientes relaciones:
PEDIDO (NUM_PED, FEC_PED, PR_PED, NUM_PROV)
PED-PROD (NUM_PED, NUM_PROD, CANT_PROD_PED,
PR_PROD_PED)
PRODUCTO (NUM_PROD, DES_PROD, PR_UN_PROD)
PROVEEDOR (NUM_PROV, NOM_PROV, DIR_PROV)
33
ING. REGF

Normalizacin
La 3FN ha eliminado los problemas asociados con la
informacin sobre el proveedor en la 2FN. Veamos:
Creacin: se puede insertar la informacin de un
proveedor, aunque no haya un pedido para l.
Eliminacin: al borrar un pedido que era el nico que se le
haca a un proveedor, no se perder la informacin sobre el
proveedor.
Modificacin: la informacin sobre un proveedor est en
una sola ocurrencia, por lo que, para cambiar cierta
informacin de ste, slo hay que hacerlo en dicha
ocurrencia.
34
ING. REGF

Normalizacin
Ya en esta etapa se puede optimizar la 3FN. Puede haber
relaciones degeneradas que contengan slo la clave y que
la informacin que aportan est considerada en otra
relacin, por lo que se pueden eliminar.
Puede que varias relaciones tengan la misma clave, por lo
que se pueden combinar en una sola, siempre que el
resultado sea lgico y tenga sentido.
Los analistas y diseadores con experiencia producen
relaciones en 3FN casi sin saber o preocuparse de esto y es
que utilizan el sentido comn y la experiencia para escribir
relaciones normalizadas.
No obstante, no siempre la intuicin es suficiente y la
metodologa para normalizar
las bases deING.datos
se
35
REGF

Normalizacin
Merece la pena destacar en este momento algunas otras
cuestiones que, aunque no estn relacionadas directamente
con la teora de la normalizacin, s propician tambin la
realizacin de un buen diseo de la base de datos:
1. En el ejemplo, se consideran atributos calculables, o
tambin llamados secundarios, que no deben aparecer
en el modelo lgico de la base de datos, como, por
ejemplo, PR_PROD_PED y PR_PED.
La modificacin del precio unitario de un producto
(PR_UN_PROD), que se logr que apareciera como una
nica ocurrencia de ese atributo, gracias a la aplicacin
de la 2FN, implicara que hubiera que modificar el valor
de los atributos calculables PR_PROD_PED y PR_PED
en todas aquellas ocurrencias relacionadas con el
producto cuyo precio se modifica, donde quiera que
aparecieran, lo cual trae problemas de actualizacin,
36
ING. REGF

Normalizacin
Por ello, en el modelo lgico, no deben aparecer
atributos calculables. (Se incluyeron en el ejemplo para
poder realizar la presente explicacin).
2. Siempre que en una relacin se escoja correctamente la
llave primaria, esa relacin ya est en 1FN, debido a la
propia definicin de llave. En este ejemplo, inicialmente,
se parti de trabajar con el atributo NUM_PED como
llave primaria cuando, en realidad, no lo es. La llave
primaria sera el par de atributos NUM_PED,
NUM_PROD, que son los que garantizan que cada
ocurrencia de atributo tenga un solo valor. (Se parti de
esa llave no correcta para poder aplicar la 1FN).
37
ING. REGF
LOGO
BASE DE DATOS
Diseo Lgico Relacional
38
ING. REGF

Clase 04 - Base de Datos

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Clase 04 - Base de Datos

Transféré par

Droits d'auteur :

Formats disponibles

LOGO

Base de datos Normalizacin

Base de datos Normalizacin

Base de datos Normalizacin

Base de datos Normalizacin

En la medida que se alcanza una forma normal ms

Base de datos Normalizacin

Base de datos Normalizacin

Base de datos Normalizacin

nmero del pedido

Base de datos Normalizacin

Base de datos Normalizacin

Base de datos Normalizacin

Base de datos Normalizacin

Base de datos Normalizacin

Base de datos Normalizacin

Base de datos Normalizacin

Base de datos Normalizacin

Base de datos Normalizacin

Base de datos Normalizacin

Base de datos Normalizacin

Base de datos Normalizacin

Base de datos Normalizacin

Base de datos Diseo lgico relacional

Base de datos Diseo lgico relacional

Base de datos Diseo lgico relacional

Base de datos Diseo lgico relacional

Base de datos Diseo lgico relacional

Base de datos Diseo lgico relacional

2. Se crea una relacin para los atributos que dependan de

Base de datos Diseo lgico relacional

Base de datos Diseo lgico relacional

Base de datos Diseo lgico relacional

Base de datos Diseo lgico relacional

Base de datos Diseo lgico relacional

Paso 2: se remueven los atributos que dependen de la

Base de datos Diseo lgico relacional

Base de datos Diseo lgico relacional

Base de datos Diseo lgico relacional

Base de datos Diseo lgico relacional

Base de datos Diseo lgico relacional

Vous aimerez peut-être aussi