Unidad 2

Modelo Relacional

 En esta etapa transformaremos el modelo entidad

relacionamiento obtenido en la fase anterior a un esquema
relacional. Este esquema sigue siendo independiente del
SGBD que se utilizar en la siguiente etapa.
El paso del esquema E/R al relacional se basa en los
siguientes principios:
Todo tipo de entidad se convierte en una relacin
Todo tipo de interrelacin N:M se transforma en una
relacin
Todo tipo de interrelacin 1:N se traduce en el fenmeno
de propagacin de la clave o bien se crea una nueva
relacin.

 i) Interrelaciones N:M
Se transforma en una relacin que tendr como
clave primaria la concatenacin de los AIP de las
entidades que asocia. Cada uno de estos
atributos que forman parte de la clave primaria
son clave fornea respecto a las tablas en donde
son claves primarias. Esto se representa por al
clusula FOREING KEY dentro del comando
CREATE TABLE de la relacin.

 ii ) Interrelaciones 1:N
Propagar el AIP de la entidad que tiene
cardinalidad mxima 1 a la que tiene n.
Transformarlo en una relacin, como si se tratara
de una interrelacin N:M. Esto es ms
conveniente cuando:
El nmero de ocurrencias de la entidad que propaga
su clave es muy pequeo, evitando los valores nulos.
Cuando se prev que en el futuro dicha interrelacin
se convierta en una N:M

 Cuando la interrelacin tiene atributos propios

Un aspecto importante en estas interrelaciones se
relaciona con las cardinalidades mnimas. Si la
cardinalidad mnima de la entidad que se propaga
es 1, significa que no pueden admitirse valores
nulos en la clave fornea (clave propagada). En
cambio, si es 0, si se admiten valores nulos.

 iii ) Interrelaciones 1:1

Son casos en donde se puede crear una relacin o bien propagar la

clave. Esto ltimo puede ser en ambas direcciones.

Si las entidades que se asocian tienen ambas cardinalidades (0,1):

En el MR: MATRIMONIO(cod_hombre , cod_mujer)
HOMBRE(cod_hombre,....)
MUJER(cod_mujer,....)
As, se evitan los valores nulos que apareceran en caso de propagar
la clave de la entidad MUJER a la entidad HOMBRE o viceversa.
Recordar que no todos los hombres ni todas las mujeres estn
casados.

 Una de las entidades tiene cardinalidad (0,1) y

la otra (1,1), conviene propagar la clave de la
entidad con cardinalidad (1,1) a la tabla
resultante de la entidad de cardinalidad (0,1).
En MR: EMPLEADO(cod_empleado,...)
DEPTO(cod_depto,cod_empleado) , clave
fornea, NOT NULL

 En el caso de que ambas entidades tengan

cardinalidades (1,1), se puede propagar la
clave en cualquier direccin. Sera
conveniente tener en cuenta acceso ms
frecuentes y prioritarios de los datos.

 -Transformacin de atributos de
interrelaciones

Es conveniente que aquellas interrelaciones

que posean atributos propios se transformen
en una relacin en donde aquellos atributos
pasan a ser columnas de dicha relacin.

 Transformacin de restricciones

Las restricciones son por ejemplo rango de

valores para un determinado dominio. Muchas
de las restricciones no se representan en el
esquema conceptual por lo que no existen reglas
claras para transformarlas. Usualmente las
restricciones se consideran en la fase siguiente y
se implementan a travs de funcionalidades
particulares que ofrecen los SGBD comerciales.
Tpicamente esto es a travs de triggers.

 Transformacin de dependencias en identificacin

y en existencia
En MR: LIBRO(cod_libro,...)
EJEMPLAR(cod_libro, cod_ejemplar,...)
clave fornea, NOT NULL, ON DELETE CASCADE,
ON UPDATE CASCADE.
Para dependencia en identificacin, la clave
primaria de la entidad dbil debe estar formada
por la concatenacin de las claves de las dos
entidades participantes en la interrelacin.

Conceptos de Normalizacin
El diseo de esquemas para generar bases de
datos relacionales debe considerar el objetivo
de almacenar informacin sin redundancia
innecesaria, pero que a la vez nos permitan
recuperar informacin fcilmente. Una tcnica
consiste en disear esquemas que tengan una
forma normal adecuada.

Conceptos de Normalizacin
Las propiedades indeseables que trae un mal
diseo son bsicamente

repeticin de informacin
incapacidad para representar cierta informacin
prdida de informacin.

Conceptos de Normalizacin
Las formas normales, definidas en la teora relacional,
nos permiten evitar que estas propiedades indeseables
aparezcan en una base de datos basada en un esquema
mal diseado. Un esquema debe estar a lo menos en
tercera forma normal, para que sea aceptable.
Hay que considerar que las reglas de normalizacin
estn dirigidas a la prevencin de anomalas de
actualizacin e inconsistencias en los datos. Ellas no
reflejan ninguna consideracin de rendimiento. En
cierta forma pueden ser visualizados como orientadas
por el supuesto de que todos los atributos no clave
sern actualizados frecuentemente.

Formas Normales.

PRIMERA FORMA NORMAL

Una relacin est en primera forma normal
(1FN) si y slo si todos los dominios simples
subyacentes contienen slo valores atmicos.

Formas Normales.
Otra forma de expresar la primera forma normal
es decir que todas las ocurrencias de un tipo de
registro deben contener el mismo nmero de
campos.
Ejemplo.
Consideremos el caso de agentes que
representan compaas que fabrican productos.
Una relacin sin normalizar que indique los
productos que venden los representantes es:

Formas Normales.

Formas Normales.
SEGUNDA FORMA NORMAL
Una relacin est en segunda forma normal
(2FN) si y slo si est en 1FN y todos los
atributos no clave dependen por completo de
la clave primaria.

Formas Normales.
La segunda forma normal es transgredida
cuando un campo no clave es un dato sobre
un subconjunto de una clave (compuesta).
Ejemplo.
Consideremos
el
siguiente
esquema
propuesto para un registro de inventario

Formas Normales.
Aqu, la clave est formada por (ARTCULO,BODEGA).
Se puede observar fcilmente que DIRECCIN-BODEGA es
un dato acerca de BODEGA y no de ARTICULO, por lo que
no se estara cumpliendo con la segunda forma normal.
Los problemas bsicos de diseo son:
La direccin de la bodega se repite para cada artculo que se almacena
en esa bodega (redundancia).
Si la direccin de bodega cambia, cada registro que se refiera a un
artculo almacenado en esa bodega debe ser actualizado. Debido a la
redundancia, los datos pueden llegar a ser inconsistentes, con
diferentes registros indicando diferentes direcciones para la misma
bodega (integridad).
Si en algn momento no hubiera partes almacenadas en alguna
bodega, no habra un registro para anotar la direccin de la bodega
(anomala).

Formas Normales.
Para satisfacer la segunda forma normal, el
esquema anterior debe ser reemplazado por
el siguiente:

Formas Normales.
TERCERA FORMA NORMAL
Una relacin est en tercera forma normal (3FN)
si y slo si est en 2FN y todos atributos no
clave dependen de manera no transitiva de la
clave primaria.

Formas Normales.
La tercera forma normal es transgredida cuando una propiedad no
identificada (no clave) es un dato acerca de otro campo no clave.
Ejemplo.
El esquema siguiente no est en 3FN.