Fundamentos de Bases de Datos

I.C. Uther Alef Rosales Hernndez

Unidad 3 Diseo de B.D. Relacionales

Objetivo. Aplicar los conocimientos y habilidades adquiridas, en el diseo de bases de datos relacionales.
3.1. Consideraciones de diseo. 3.2. Normalizacin.
3.2.1. Dependencias funcionales. 3.2.2. Primeras formas normales. 3.2.2.1. 1FN. 3.2.2.2. 2FN. 3.2.2.3. 3FN y FNBC(forma normal Boyce-Cood). 3.2.3. Normalizacin adicional. 3.2.3.1. Dependencia multivaluada y 4FN. 3.2.3.2. Dependencia de juntura y 5FN.

Unidad 3 Diseo de B.D. Relacionales

3.3. Integridad de bases de datos.
3.3.1. Concepto. 3.3.2. Restricciones bsicas (not null, llave primaria, orden, verificacin y asercin). 3.3.3. Integridad de entidad. 3.3.4. Integridad referencial. 3.3.5. Reglas de relacin. 3.3.6. Reglas de base de datos. 3.3.7. Reglas de negocios.

3.4. Seguridad de bases de datos.

3.4.1. Concepto de seguridad. 3.4.2. Autenticacin y autorizacin. 3.4.3. Rol y privilegios de usuarios. 3.4.4. Vistas y seguridad.

Unidad 3 Diseo de B.D. Relacionales

3.5. Recuperacin de bases de datos.
3.5.1. Transacciones. 3.5.1.1. Definicin de transaccin. 3.5.1.2 Propiedades de Atomicidad, Consistencia, Aislamiento y Durabilidad (ACID). 3.5.1.3. Estados de las transacciones. 3.5.2. Bitcora. 3.5.2.1. Tipos de bitcora. 3.5.2.2. Contenido de la bitcora.

3.6. Diccionario de datos.

3.6.1. Concepto. 3.6.2. Contenido y funcin. 3.6.3. Tipos.

3.1. Consideraciones de diseo.

Para poder realizar un diseo relacional de una base de datos, se puede conseguir de dos formas: 1. Obtener el esquema relacional directamente de la observacin y anlisis del problema

Cualquiera de las dos formas, podra ocasionar problemas en caso de no realizarse correctamente, por eso existen tcnicas que permiten mejorar los diseos.

2. Realizar el modelo E/R y transformarlo en un modelo relacional

3.1.1 Del modelo E/R al relacional

El paso de un esquema E/R a un diseo relacional est basado en 3 principios: 1. Todo tipo de entidad se convierte en una relacin (tabla) 2. Todo tipo de relacin muchos a muchos se transforma en una tabla 3. Las interrelaciones de uno a muchos se transforman mediante un fenmeno de propagacin de clave, o se crea una nueva relacin. Aunque con dichas transformaciones se puede perder cierta semntica, si se hacen las conversiones de manera adecuada y correcta, entonces no se afecta ni la integridad ni el buen funcionamiento de la base de datos.

3.1.1 Del modelo E/R al relacional (2)

Ejemplo.

Diagrama E/R:

Esquema Relacional: Editorial(Nombre_E, ) Libro(Cdigo_L, ) Escribe(Nombre_A, Cdigo_L, ) Autor(Nombre_A, )

3.1.1.2 Transformacin de entidades

La transformacin es directa (nombre de la

entidad-tabla, clave y atributo) Ej. Diagrama E/R

Esquema Relacional
Socio(Cod_Socio, Tipo, Telfono, Nombre, Apellido)

Socio
Cod_Soci Nombre o Apellido Domicilio Telfono Tipo

3.1.1 Del modelo E/R al relacional (3)

3.1.1.3. Transformacin de atributos Cada Atributo se convierte en un ttulo de columna 3.1.1.4. Transformacin de relaciones Para esta transformacin se tienen 3 casos: 1. Las relaciones muchos a muchos 2. Las relaciones uno a muchos (o muchos a uno) 3. Las relaciones uno a uno

3.1.1.4.1 Relaciones muchos a muchos

Una interrelacin de muchos a muchos se

transforma en una relacin con llave primaria formada por la concatenacin de los atributos primarios de las entidades que asocia. Ej. Diagrama E/R

Esquema Relacional
Escribe(Nombre_A, Cdigo_L, )

3.1.1.4.2 Relaciones uno a muchos

Existen 2 soluciones posibles para este tipo de

ejercicios 1. Propagar el atributo primario de la entidad con cardinalidad 1 a la de cardinalidad muchos, y desaparece el nombre de la relacin. Ej. Diagrama E/R
Esquema Relacional:
Editorial(Nombre_E, ) Libro(Cdigo_L, ,Nombre_E)

3.1.1.4.2 Relaciones uno a muchos(2)

2.

Transformar la interrelacin en otra tabla como en el caso de muchos a muchos.

Esta opcin se sugiere cuando: El nmero de ocurrencias relacionadas de la entidad que propaga su clave es muy pequeo y cabe, por tanto, la posibilidad de que existan muchos valores nulos Cuando la (inter)relacin tiene atributos propios
Ej. Diagrama E/R

Esquema Relacional
Profesor(Prof_ID, Nombre, Direccin, Telfono) Depto(Depto_ID, Descripcin, Director,) Academia(Prof_ID, Depto_ID)

3.1.1.4.3 Relaciones uno a uno

No hay una regla fija para su transformacin, se

puede crear una nueva tabla, o transformarla mediante propagacin de clave. Ej. Diagrama E/R

Esquema Relacional
Hombre(Cod_H, ) Muertimonio(Cod_H, Cod_M, ) Mujer(Cod_M, )

3.2. Normalizacin
Cuando se realiza un modelo relacional se tienen diferentes alternativas y se pueden obtener diversos esquemas, dnde no todos ellos sern equivalentes, alguno podr representar mejor la informacin que otros.

Un diseo inadecuado puede ocasionar:

Incapacidad de representar ciertos hechos Redundancia en la informacin incoherencia Ambigedades Anomalas de modificacin, insercin y borrado.

3.2. Normalizacin(2)
La normalizacin emplea una serie de pruebas

(descritas como formas normales) para tratar de identificar el agrupamiento ptimo de los atributos, con el fin de identificar un conjunto de relaciones que soporten adecuadamente los requisitos de una organizacin. Tcnica para producir un conjunto de relaciones con una serie de propiedades deseables, partiendo de los requisitos de datos de una organizacin (Connolly)

Redundancias de datos y anomalas de actualizacin

Para ejemplificar ms todo esto, consideremos la siguiente relacin:
Empleado(No_Emp, Nombre_Emp, puesto, salario, No_suc, Direccin_suc)

En este caso, la informacin de las sucursales se repite para cada empleado que trabaja en una sucursal. Las relaciones con datos redundantes pueden presentar problemas que se denominan anomalas de actualizacin, clasificndose dichos problemas como:
Anomalas de insercin Anomalas de borrado Anomalas de modificacin

Anomalas de insercin
Para insertar un nuevo empleado, es necesario

asegurarse de que los valores de sucursal sean coherentes Para insertar una nueva sucursal sin empleados, se debern dejar nulos los datos de empleado, pero como No_Emp es llave primaria, se viola la integridad referencial y la operacin no es permitida.

Anomalas de borrado
Si se borra el ltimo empleado de una sucursal,

se pierden los detalles correspondientes a la sucursal

Anomalas de modificacin
Si queremos cambiar la direccin de una

sucursal, se tienen que actualizar las tuplas de todos los empleados de esa sucursal, de lo contrario hay incoherencia (por ej. Una sucursal con muchas direcciones)

Descomposicin sin prdida

Se refiere a la proyeccin, o ms bien al conjunto

de proyecciones de una relacin R, tales que al reunirlas se tiene el esquema original, es decir, es reversible. P. ej: Si tenemos las siguientes tablas: Proveedor Calidad Ciudad
P3 B Toluca

P5

Mxico

Descomposicin sin prdida (2)

Se pueden realizar las siguientes descomposiciones: Proveedo Calidad Proveedor P3 a) r
P3 P5 B B P5

Ciudad
Toluca Mxico

b)

Proveedor Calidad

Calidad
B B

Ciudad
Toluca Mxico

P3 P5

B B

En a) no se pierde informacin, es decir es una descomposicin sin prdida En b) si hay perdida, sabemos la calidad del proveedor, pero no su ciudad, ni siquiera al reunir sus tablas.

3.2.1 Dependencias Funcionales

Una dependencia funcional describe la relacin entre

atributos de una relacin. Por ejemplo, si A y B son atributos de la relacin R, B ser funcionalmente dependiente de A (denotado por AB) si cada valor de A est asociado con exactamente un valor de B.
En este caso, cuando 2 o ms tuplas tienen el mismo

valor de A, tienen tambin el mismo valor de B, sin embargo, para un determinado valor de B puede haber varios valores diferentes de A.
Una manera alternativa de describir la relacin entre

3.2.1 Dependencias Funcionales(2)

3.2.1 Dependencias Funcionales(3)

De la figura anterior se cumplen las siguientes dependencias funcionales: Num_Prov ciudad Num_Prov,Num_Parte cantidad Num_Prov, Num_Parte ciudad Num_Prov, Num_Parte Num_Prov Num_Prov, Num_Parte Num_Prov, Num_Parte, Ciudad, Cantidad Num_Prov cantidad * Cantidad Num_Prov * * Estas dependencias no son independientes en el tiempo.