John Freddy Duitama Mu

1
Diseño de Bases de DatosRelacionales

• John Freddy Duitama Muñoz
• Juan Camilo Alzate Restrepo
• Facultad de Ingeniería
• U.de.A.

2
Normalización

• La Normalización, abarca dos tópicos
• Dependencia Funcional Técnica de diseño que
  permite examinar las relaciones entre los
  atributos.
• Formas Normales Pruebas para el agrupamiento
  óptimo de los atributos.

3
Con la normalización se pretende que

• Los atributos con una relación lógica fuerte
  (dependencia funcional) se encuentren en la misma
  relación.
• Se defina el número mínimo de atributos
  necesarios para soportar requisitos de datos de
  una organización.
• La información tengan una redundancia mínima.
  Cada atributo se representa una sola vez, con
  excepción de las claves foráneas.
• Actualización con un mínimo de operaciones.
• Reduce posibles inconsistencias de datos.
• Reduce espacio de almacenamiento.

?
4
DEPENDENCIA FUNCIONAL

• DEF Sean a y b atributos de la relación R.
• Decimos que a determina funcionalmente a b en R,
• denotado por a ? b
• También se puede decir que
• b depende funcionalmente de a
• Si y sólo si
• Para todos los pares de tuplas t1, t2 de la
  relación R, tales que t1a t2a también se
  cumple que t1b t2b
• Ejemplo cédula --gt nombre.
• Cada vez que se tiene un número de cédula, esta
  debe coincidir con el mismo nombre.

Si t1 y t2 coinciden en el atributo a, Entonces
deben coincidir también en el atributo b.
5
Ejemplos de dependencias Funcionales

• Sean las relaciones
• Préstamo (númeroPréstamo, sucursal, cliente,
  valor)
• Cliente (cedula, nombreCliente, dirección, ciudad
  )
• Si NúmeroPréstamo --gt cliente.
• Un préstamo sólo puede efectuarse a un cliente.
• Un cliente puede tener varios préstamos.
• NúmeroPréstamo --gtvalor es cierta en
  préstamo?
• dirección --gt ciudad es cierta en
  cliente?

El diseño de una Base de Datos relacional
requiere definir aquellas dependencias
funcionales (D.F.) que se deben cumplir siempre.
6
CLAVE CANDIDATA

• Sea K un conjunto de uno o más atributos de la
  relación R.
• DEF
• K es una clave candidata para la relación R si
• Si K ? todos los atributos de R
• Ningún subconjunto de K determina funcionalmente
  a todos los demás atributos de R.

7
DEP. FUNCIONAL COMPLETA

• DEF Sean a y b atributos de la relación R.
• Decimos que b depende funcionalmente de manera
  completa de a
• Si y sólo si
• b depende funcionalmente de a pero no de ningún
  subconjunto propio de a.
• Es decir, Una dependencia funcional a?b es
  completa si la eliminación de cualquier atributo
  de a hace que la dependencia deje de existir.
• Cedula, nombre ? salario
• Si se quita el nombre la dependencia continúa
• Cedula ? salario
• Entonces no era completa

8
Axiomas de Armstrong

• 1. Reglas de reflexividad (dependencia trivial)
• Si a y b son conjuntos de atributos y b Í a,
  entonces se cumple que a--gt b .
• Si los atributos (TipoDoc,numero) de una
  persona son su ID, entonces con ellos podemos
  determinar el TipoDoc y el número.
• 2. Regla de aumento
• Si para los conjuntos de atributos a y b se
  cumple que a --gt b y g es un conjunto de
  atributos, entonces se cumple que a g --gt b g
  .
• (cedula, teléfono) ? (nombre, teléfono)
• 3. Regla de la transitividad
• Si se cumple a --gt b y se cumple b --gt g
  , entonces se cumple a -- gt g .

9
Reglas adicionales - Armstrong

• Reglas adicionales, derivadas de las anteriores
• 4. Regla de unión
• Si se cumple a --gt b y a --gt g se cumple a
  --gt b g .
• Cédula ? nombre y cédula ? teléfono
• Cédula ? (nombre ,
  teléfono)
• 5. Regla de la descomposición
• Si se cumple a --gt b g entonces se cumple a
  --gt b y a --gt g .
• cédula ? (apellido,
  dirección)
• cédula ? apellido y
  cedula ? dirección
• 6. Regla de la pseudo-transitividad
• Si a --gt b y g b --gt d entonces se cumple
  ag --gt d.
• Cédula ? Ciudad_residencia
• (Teléfono, Ciudad_residencia) ?
  dirección_residencia
• (Cédula,Teléfono) ? dirección_residencia

10
Implicación lógica de las D.F.

• Ejemplo
• Sea la relación R (A, B, C, G, H, I)
• Con el conjunto de Dependencias Funcionales
• F A ? B, A ? C, CG ? I, CG ? H, B ? H
• Puedo hallar nuevas dependencias funcionales
  implicadas lógicamente por F
• A ? B y B ? H luego A? H. por axioma-3.
• CG ? H y CG ? I luego CG ? HI por axioma-4
• A ? C luego AG ? CG por axioma-2
• AG ? CG y CG ? I luego AG ? I por axioma-3
• AG ? CG y CG ? H luego AG ? H por axioma-3.

11
Problemas en el diseño de una B. de D.

• Objetivo Almacenar la información con un mínimo
  de redundancia y fácil recuperación.
• Problemas Repetición de la información.
• Representación de la información
• Pérdida de información.

Prestamo
nombre_sucursal activos Ciudad-sucursal Número_préstamo Cliente Valor
Centro 9000.000 Arganzuela 17 1.109.564.267 1.000
Moralzarzal 2100.000 La Granja 23 71.587.456 2.000
Navacerrada 1700.000 Aluche 15 43.678.980 1.500
Centro 9000.000 Arganzuela 14 1.009.899.776 1.500
Becerril 400.000 Aluche 93 70.456.819 500
Collado Mediano 8000.000 Aluche 11 43.987.065 900

• Qué ocurre al agregar un préstamo ?
• Qué ocurre si una sucursal cambia de activos ?
• Qué ocurre con las sucursales que no tengan
  préstamos?
• Qué ocurre si eliminamos el último préstamo de
  una sucursal?

?
12
Problemas en el diseño de una B. de D.

• En otras palabras
• Una sucursal existe independiente de los
  préstamos que haga.
• Una sucursal está situada exclusivamente en una
  ciudad.
• una sucursal tiene solo un valor total de
  activos.
• Una sucursal puede efectuar muchos préstamos.
• Un préstamo solo se otorga en una sucursal.
• Solución
• Sucursal (nombre_sucursal, activos, ciudad-suc)
• Préstamo (número_préstamo, cliente, valor,
  nombre_sucursal)

13
Cómo descomponer una relación en varias?

• Objetivo evitar la pérdida de información.
• Cómo descomponer la relación préstamos en varias
  relaciones sin pérdida de información?
• préstamo (nombre-sucursal, activos, ciudad-suc,
  número-préstamo, cliente, valor)
• Sean
• Sucursal (nombre-sucursal, activos, ciudad-suc,
  valor)
• Préstamos (número-préstamo, cliente, valor)
• Dos proyecciones de la relación original, nótese
  que valor actúa como si fuera clave foránea.
• Qué ocurre si pretendo reconstruir a préstamo?
• Si hay varios préstamos con el mismo valor
  significa que no podemos identificar a qué
  sucursal corresponde que préstamo.

14
Descomposición sin pérdida

• Sea R una relación.
• Una descomposición R1, R2, ..., Rn de R es una
  
• descomposición de producto sin pérdida
• si
• R p R1(R) Ä p R2(R) Ä ... Ä pRn (R)
• Se debe Verificar
• R1 y R2 forman una descomposición sin pérdida de
  R, si por lo menos una de las D.F. siguientes se
  cumple
• R1 Ç R2 --gt R1.
• R1 Ç R2 --gt R2.
• Veamos un Ejemplo

15
Ejemplo de descomposición sin pérdida

• Prestar (nombre-sucursal, activos, ciudad-suc,
  préstamo, valor, cliente)
• F nombre-sucursal ? activos, nombre-sucursal
  ? ciudad-suc,
• préstamo ? cliente, valor,
  nombre-sucursal
• Si la descomponemos en
• Sucursal (nombre-sucursal, activos, ciudad-suc)
• Préstamo (nombre-sucursal, préstamo, cliente,
  valor)
• Debemos probar
• Sucursal Ç préstamo ? Sucursal
• es decir
• nombre-sucursal ? nombre-sucursal, activo,
  ciudad-suc.
• Por unión nombre-sucursal ? activo, ciudad-suc
• Por aumento nombre-sucursal ? nombre-sucursal,
  activo, ciudad-suc.

16
NORMALIZACIÓN
17
Normalización

• Es la técnica utilizada para diseñar buenas
  relaciones desde el punto de vista de
• Minimizar la redundancia
• Minimizar el mantenimiento de datos
• Minimizar el impacto de futuros cambios de
  datos e ingreso de información

Anomalías de Actualización y Borrado
Anomalías de Inserción
18
FORMAS NORMALES
19

• 6 formas normales clásicas
• 1NF, 2NF, 3NF, BCNF (Boyce Codd Normal Form),
  4NF, 5NF
• Mientras una relación esté en una forma normal
  más alta mucho mejor
• Generalmente se acepta normalizar hasta BCNF
• Las formas normales 4 y 5 son casos especiales

20

• Si una relación cumple una forma normal n
  automáticamente cumplirá las n-1 formas normales
  anteriores, es decir, cada forma normal es más
  fuerte que sus predecesoras.
• El análisis de 1NF, 2NF y 3NF considera sólo
  relaciones con una sola clave candidata.
• Para relaciones con más de 1 clave candidata
  directamente se aplica BCNF

21
Primera Forma Normal 1FN

• Dominio Atómico. Los elementos del dominio son
  indivisibles.
• Ejemplos
• Libros (código, titulo, autoresi, editorial)
• No está en primera forma normal.
• Posible solución
• Libros (código, titulo, editorial)
• Autor (autor, codigo_libro)

• Primera Forma normal 1FN
• Una relación está en primera forma normal si y
  sólo si todos los
• dominios de los atributos son atómicos.

Aplicar la primera forma normal es muy simple,
bastará con dividir cada columna no atómica en
tantas columnas atómicas como sea necesario
22
Primera Forma Normal 1FN

• Empleado (código, nombre, teléfono)
• código 016-242224 donde
• 016 departamento
• 242224 código empleado
• No está en primera forma normal.
• Posible solución
• Empleado(departamento, cod-empleado, nombre,
  teléfono)
• Que pasa con los datos tipo XMLTYPE?

• Primera Forma normal 1FN
• Una relación está en primera forma normal si y
  sólo si todos los
• dominios de los atributos son atómicos.

23
Segunda Forma Normal 2FN

• Ejemplo, sea la relación
• venta (nro-factura, id-producto, ced-cliente,
  unidades, fecha)
• clave primaria número-fac, id-producto.

• Una relación está en 2FN, si y sólo si está en
  1FN y todos los
• atributos no clave dependen funcionalmente de
  manera completa
• (DFC) de la clave primaria.

Esta regla significa que en una relación sólo se
debe almacenar información sobre un tipo de
entidad, y se traduce en que los atributos que no
aporten información directa sobre la clave
principal deben almacenarse en una relación
separada.
24
Ejemplo de Segunda Forma Normal

• Las unidades DFC de la clave primaria?
• (número-fac, id-producto) ? unidades
• Comprobar si al quitar alguno de los atributos
  del lado izquierdo, se conserva la dependencia
  funcional.
• número-fac ? unidades F
• id-producto ? unidades F
• Al quitar el atributo producto o el número-fac
  la dependencia NO se conserva, entonces
  (número-fac , producto) si DFC a unidades. Sin
  embargo, falta comprobar

25
Ejemplo de Segunda Forma Normal

• La fecha DFC de la clave primaria?
• (número-fac , id-producto) ? fecha
• Comprobamos
• número-fac ? fecha V
• producto ? fecha F
• Al quitar el atributo id-producto, la
  dependencia se conserva, entonces (número-fac ,
  producto) NO DFC a fecha.
• Es decir (número-fac , id-producto) ? fecha de
  manera parcial. Entonces no se cumple la 2NF

26
Ejemplo de Segunda Forma Normal

• El Cliente DFC de la clave primaria?
• (número-fac , id-producto) ? cliente
• Comprobamos
• número-fac ? cliente V
• id-producto ? cliente F
• Al quitar el atributo id-producto, la dependencia
  se conserva, entonces (número-fac , producto) NO
  DFC a cliente.
• Es decir (número-fac , id-producto) ? cliente
  de manera parcial. Entonces no se cumple la 2NF

27
Ejemplo de Segunda Forma Normal

• Posible solución
• Dependencias funcionales completas
• número-fac ? cliente, fecha
• número-fac, id-producto ? unidades
• Se descompone en
• Factura (número-fac, id-cliente, fecha)
• Venta (número-fac, producto, unidades)
• numero-fac clave foránea de Factura
• Que pasa con atributos como valor unitario, valor
  total?

28
Tercera Forma Normal 3FN

• Equivalentemente.
• Una relación está en 3FN si y sólo si los
  atributos no clave son
• Mutuamente independientes.
• Dependen por completo de la clave primaria.
• Dicho de otro modo
• R(A,B,C) con clave primaria A.
• R.B --gt R.C y R.A--gtR.B
• se descompone en
• R1(B,C) con clave primaria B.
• R2(A,B) con clave primaria A y B clave ajena de
  R1.

Una relación está en 3FN si y solo si está en 2FN
y todos los atributos no claves dependen de
manera directa de la clave primaria.
En la práctica significa que se debe eliminar
cualquier relación que permita llegar a un mismo
dato de dos o más formas diferentes
29
Ejemplo de Tercera Forma Normal

• R(número-fac, id-cliente, fecha-fac,
  teléfono-cliente)
• Con número-fac --gt cliente
• número-fac --gt fecha-fac
• cliente --gt teléfono-cliente
• Clave primaria número-fac
• Se descompone en
• R1(cliente, teléfono-cliente) clave
  primaria(cliente)
• R2(número-fac, cliente, fecha-fac)
• clave primaria (número-fac) cliente clave
  foránea de R1.

30
Forma Normal Boyce/Codd
Ejemplo Ciudadano (tipo_documento, numero,
id_seguridad_social, nombre, fecha_nacimiento)
tipo_documento, numero ? Nombre tipo_documento,
numero ? fecha_nacimiento Id_seguridad_social?
nombre Id_seguridad_social ? fecha_nacimiento

• Una relación está en FNBC, si cumple la 3FN, y
  si y solo si cada
• determinante, atributo o conjunto de atributos
  que determina
• completamente a otro, es clave candidata.

Todos los determinantes de la tabla son clave
candidata.
31
Conservación de dependencias en BCNF

• PROBLEMA
• Sea asesor (sucursal, nombre-cliente,
  nombre-asesor)
• F nombre-asesor ? sucursal,
• sucursal, nombre-cliente ?
  nombre-asesor
• Asesor no está en BCNF.
• Como descomponer asesor para hallar dos
  relaciones en BCNF?
• R/ Ninguna descomposición BCNF de esta relación
  conserva todas las dependencias originales.
• SLN Debo abandonar BCNF para conservar las
  dependencias.

32
BIBLIOGRAFÍA

• Thomas M. Connolly, Carolyn E Begg. Sistemas de
  bases de datos. Un enfoque práctico para diseño,
  implementación y gestión. Cuarta edición. Pearson
  Addison-Wesley 2005.
• Peter Rob / Carlos Coronel. Sistemas de bases de
  datos. Diseño, implementación y administración.
  International thomson editores. 2004.
• C.J. Date. Introducción a los sistemas de Bases
  de Datos. Sexta edición. Volúmen 1.
  Addison-Wesley. 1995.
• Jeffrey D. Ullman. Principles of Database and
  Knowledge-Base System. Volúmenes I. Computer
  Science Press. 1988. Capítulo 7.
• Henry F. Korth, Abraham Silberschatz.
  Fundamentos de Bases de Datos. Tercera edición.
  1998.