Notas de

Clase BD

DISEÑO DE BASES DE DATOS RELACIONALES

El objetivo del diseño de una base de datos relacional es generar un conjunto de

esquemas de relaciones que nos permitan almacenar información con un mínimo de
redundancia, pero que a la vez nos permitan recuperar información fácilmente.
Una técnica consiste en diseñar esquemas que tengan una forma normal adecuada.
Para determinar si un esquema de relaciones tiene una de las formas normales, se
requiere mayor información sobre la “empresa del mundo real “ que se intenta modelar
con la BD. La información adicional la proporciona una serie de limitantes que se
denominan dependencias de los datos.

Peligros en el diseño de BD relacionales: Una BD mal diseñada puede tener los

siguientes defectos:
- Repetir información innecesariamente.
- Incapacidad para representar cierta información.
- Pérdida de información.

Para abordar estos defectos con mayor detalle, tomaremos los esquemas de relaciones:
Sucursales = ( nomb_s, activo, ciudad_s)
Préstamos = ( nro_pres, nomb_s, nomb_cl, valor)

Repetición de la información: Considere un diseño alternativo para la BD del banco en

el que se sustituye el esquema Sucursales y el esquema Préstamos por un solo
esquema:
Prestar = (nomb_s, activo, ciudad_s, nro_pres, nomb_cl, valor)

Un estado de la BD de la relación Prestar que se produce al hacer el producto natural de

las instancias sucursal y préstamo, sería:

nomb_s activo ciudad_s nro_pres nomb_cl valor

Centro 1000 Medellín 17 Carlos Jimenez 1000
Monterrey 10000 Neiva 23 Juan Santamaría 2000
Poblado 300 Bogotá 15 Pedro Hoyos 1500
Centro 1000 Medellín 14 Gloria Aguilar 500
Envigado 500 Medellín 93 Fidel Castro 900
Oviedo 5000 Bogotá 11 Luis Torres 1200
Suramericana 2000 Pereira 29 Elena Restrepo 1300
Laureles 8000 Pasto 16 Angel Pérez 2000
Centro 1000 Medellín 18 Felix Jaramillo 2500
Poblado 300 Bogotá 25 María Gómez 1500
Belén 11200 Montería 10 José Barrera 2200

Una tupla t de la relación Prestar tiene el siguiente significado:

t [activo ] es el activo de la sucursal t [ nomb_s ]
t [ ciudad_s ] es la ciudad donde está situada t [ nomb_s ]
t [ nro_pres ] es el número asignado a un préstamo que hace la sucursal t[nomb_s ] al
cliente t [ nomb_cl ]
José Ignacio Botero O. 52
Margarita María Hincapié V.
 Notas de
Clase BD
t [ valor ] es el valor del préstamo cuyo número es t [ nro_pres ]

Suponga que queremos añadir a la BD un nuevo préstamo el número 30 hecho por la

sucursal Centro al señor Pedro Pérez por valor de 5000 .
En el diseño original se agregaría la tupla: ( 30, “Centro”, “Pedro Pérez”, 5000) a la
relación Préstamos.
Bajo el diseño alternativo, necesitamos una tupla que tenga valores para todos los
atributos del esquema Prestar. Así, debemos repetir los datos de activo y ciudad_s para
cada sucursal Centro y añadir la tupla:
(“Centro”, 1000, “Medellín”, 30, “Pedro Pérez”, 5000) a la relación Prestar.
En general los datos de activo y ciudad_s deben aparecer una vez por cada préstamo
que hace la sucursal.
La repetición de la información que implica el diseño alternativo es inconveniente por
varias razones:
- Se desperdicia espacio de almacenamiento.
- Complica la actualización de la BD. Suponga por ejemplo que se cambia la ciudad de la
sucursal Centro. Bajo el diseño original se necesita cambiar sólo una tupla de la relación
Sucursal. Bajo el diseño alternativo, es necesario cambiar varias tuplas de la relación
Prestar, lo cual hace más costosa la actualización bajo el diseño alternativo que bajo el
diseño original. Además, es necesario asegurarnos de que todas las tuplas se actualicen
para no originar inconsistencia en la BD. Por lo tanto el diseño alternativo es deficiente.

Incapacidad para representar cierta información: Esto significa que si en un diseño se

agrupa mucha información bajo una misma relación, tuplas formadas por parte de ella,
no pueden ser representadas. Ej. no podemos representar directamente la información
referente a una sucursal ( nomb_s, activo, ciudad_s,) a no ser que exista por lo menos
un préstamo en la sucursal.
Esto se debe a que es necesario que las tuplas de la relación Prestar tengan valores
para nro_pres, nomb_cl, valor.
Una solución posible a este problema es introducir valores nulos, pero estos son difíciles
de manejar. Otra forma sería crear la información de la sucursal sólo cuando se haga el
primer préstamo en la sucursal, lo cual implica que se tendría que borrar la información
de la sucursal cuando se cancelen todos los préstamos.
Es claro que este problema no ocurría en el diseño original; allí la información de la
sucursal permanecía estuvieran o no vigentes los préstamos y además se elimina la
necesidad de valores nulos.

Pérdida de información: El ejemplo anterior de un mal diseño sugiere que debemos

descomponer un esquema de relaciones con muchos atributos, en varios esquemas con
menos atributos. De lo contrario, si borramos una tupla que contiene información
importante y es la única tupla que contenía dicha información, ésta se pierde. Ej.: En la
relación Prestar si borro el préstamo de un cliente porque terminó de pagarlo y era el
único préstamo hecho por esa sucursal, se borra también la información de la sucursal,
desapareciendo ésta.
Pero es necesario tener mucho cuidado en la descomposición de las relaciones ya que
también ella puede ser motivo de pérdida de información si no se efectúa correctamente.

Anomalías: Si las relaciones no están en la debida forma normal, pueden ocurrir

diversos tipos de anomalías, tales como:
- De inserción
José Ignacio Botero O. 53
Margarita María Hincapié V.
 Notas de
Clase BD
- De retiro
- De actualización.

La anomalía de inserción ocurre cuando no se puede insertar una ocurrencia de una

tupla dentro de una tabla debido a que el valor de la clave primaria es desconocido en el
momento de hacer la inserción.
Para resolver esta situación hay dos métodos:
- El primero es insertar un valor nulo para la clave primaria lo cual viola la regla de
integridad de la clave, por tanto es inaceptable.
- El segundo método es insertar un valor ficticio para la clave primaria, lo que implicaría
que se tendría que llevar el rastro de cuales claves tienen un valor verdadero y cuales
tienen un valor falso.

La anomalía de retiro se presenta cuando ocurren tres circunstancias:

* Se borra una tupla de una tabla
* La tupla que se borra tiene parte importante de la información.
* Esta tupla es la única en la tabla que contiene esta parte de la información.
El borrado de la tupla causa borrado inadvertido de esta importante parte de la
información.

La anomalía de actualización ocurre cuando se tiene redundancia innecesaria en los

datos. Si se tiene que actualizar el valor de un atributo, se tienen que buscar todas las
ocurrencias de ese valor para cambiarlas.

Existen limitantes para evitar los problemas antes expuestos; entre ellos se encuentran
las Dependencias Funcionales.

DEPENDENCIAS FUNCIONALES (DF): Conducen a varias formas normales de la BD y

son una generalización de la idea de superllave. Las DF permiten expresar ciertos
hechos acerca de la empresa que se va a modelar por medio de la BD.

Dependencia Funcional: “Dada una relación r, el atributo y de r es funcionalmente

dependiente del atributo x de r si y sólo si cada valor de x en r tiene asociado a él
exactamente un valor de y en r (en cualquier instante)”.
Ej.: En la relación Préstamos se satisface que Nro_pres >valor
(número de préstamo determina a valor) ya que en el mundo real un préstamo no
representaría varios valores.
Por tanto es conveniente que en todo momento se exija que en la relación Préstamo se
satisfaga que nro_pres > valor

La DF es un concepto semántico, es decir, entender que significan los datos.

Entonces para diseñar una BD relacional, se hace primero una lista de todas las
dependencias funcionales que siempre se deben cumplir. Para el ej. de la BD bancaria la
lista de dependencias funcionales incluye:
- En el esquema Sucursales: En el esquema Préstamos:
nomb_s > ciudad_s nro_pres > valor
nomb_s >activo nro_pres >nomb_s

- En el esquema Clientes: En el esquema Cuentas:

cedula_cl > nomb_cl nro_cta >saldo
José Ignacio Botero O. 54
Margarita María Hincapié V.
 Notas de
Clase BD
cedula_cl >ciudad_cl nro_cta > nomb_s

Otra definición de DF: “Dada una relación r, el atributo y es funcionalmente dependiente

del atributo x de r, si y sólo si, siempre que dos tuplas de r coincidan en sus valores de
x, también coincidan en sus valores de y. Ej.:
cedula >nombre

Tanto el atributo y como el x pueden ser compuestos.

Un atributo puede depender funcionalmente de un grupo de atributos y no
necesariamente tiene que ser de uno sólo. A esto se denomina DF de un grupo de
atributos. Ej.:
Esquema_actividad_programador =(#nro_progdor, #nro_paquete, nom_progdor,
nom_paquete, total_horas_trabajs)
*nro_progdor
*nro_paquete
*nom_progdor <
*nom_paquete <
total_horas_trabajs<

DF completa: “El atributo y es funcionalmente dependiente en forma completa del

atributo x si es funcionalmente dependiente de x y no depende funcionalmente de
ningún subconjunto propio de x “
Si y es funcionalmente dependiente de x pero no en forma completa, entonces x debe
ser compuesto.

CLAVES: Reforcemos el concepto de claves.

Sea R= ( a1, a2, a3, ..., an)
X es una clave para R si:
1- X es mínima ( es decir, no le sobran atributos)
2- X >a1
X > a2
.
.
X > an
y puede haber mas de un conjunto de atributos que cumplan esta condición; de ello se
desprende el concepto de claves candidato y claves primarias.
Del concepto de clave se derivan dos condiciones de integridad importantes del modelo
relacional:
1- Regla de integridad de la clave: Una clave no puede tener valores nulos (también,
regla de integridad de las entidades).

2- Regla de integridad referencial: Una tupla no puede ser borrada de una relación a
menos que su clave no esté referenciada en alguna otra tupla de otra relación o la
misma.
Ej.: No puedo borrar un departamento si existen empleados adscritos a él.
En síntesis: La clave de una relación normalizada debe tener las siguientes propiedades:
1- Identificación única: Cada ocurrencia de una entidad debe ser identificada de manera
única por su clave.

José Ignacio Botero O. 55

Margarita María Hincapié V.
 Notas de
Clase BD
2- No redundancia: No se debe poder descartar ningún atributo de la clave, sin perder la
propiedad de identificación única.
Ej.: Si la clave de Persona es nombre, dirección, no se puede descartar ninguno de los
dos atributos, ya que ambos forman la clave completa.

NORMALIZACION DE RELACIONES:

Los diseñadores de BD deben escoger entre eficiencia en el mantenimiento de los datos

o facilidades de recuperación de datos de una BD.
Las relaciones que no están en una forma normal apropiada podrían encontrar
problemas (anomalías) durante el mantenimiento de los datos.
El proceso de convertir relaciones a la forma normal apropiada es llamado
normalización.
La normalización usualmente involucra descomposición de relaciones en dos o mas con
menos atributos.
Cuando una relación está en la forma normal apropiada, las anomalías no deben ocurrir.
El problema básico con la conversión de relaciones a la forma normal apropiada es que
las tablas resultantes tendrán que utilizar joins para recuperar datos que se podrían
obtener desde la tabla original.
Cuando las relaciones se normalizan generalmente estamos sacrificando velocidad de
recuperación para prevenir problemas de mantenimiento.

Qué son datos no normalizados?

Son entidades con grupos repetitivos, es decir, con atributos multivaluados. Son archivos
no planos.

Primera forma normal (1NF): Una relación está en 1NF si y sólo si satisface la
restricción de contener únicamente un sólo valor para cada campo en todos los registros.
Son archivos planos o matrices de datos. Ej.: Dado el siguiente registro de datos:

EMPLEADOS= (id_emp, nom_emp, sexo, salario, fecha_nacimiento (dia-mes-año),

nro_habilidades (cod_habil, años_experiencia)).

La fecha de nacimiento ocurre una sola vez en cada instancia de la entidad y por tanto
no causa problema; pero habilidades puede ocurrir varias veces en una instancia y por
tanto puede verse como una tabla de datos. Por este motivo la relación no está en 1NF.
Para llevarla a 1NF debe removerse y colocarse en una relación separada, así:
Esquema_Empleados= (#id_emp, nom_emp, sexo, salario, fecha_nacimiento (dia-mes-
año))
Esquema_Habilidades= (#id_emp +#cod_habil, años_experiencia)

En general una relación que no sea plana se normaliza convirtiéndola en dos o mas
relaciones. Toda relación normalizada está en 1NF.

Ejemplos de entidades no normalizadas:

Esquema_Cuentas= (#cod_cta, nom_cuenta, transacciones(cod_trans, valor,
fecha_trans))

José Ignacio Botero O. 56

Margarita María Hincapié V.
 Notas de
Clase BD
Esquema_Facturas= (#nro_fac, fecha_fac, propietario, detalle( referencia, descripción,
cantidad, valor_unidad).

Segunda forma normal (2NF): Una relación está en 2NF si está en 1NF y todos los
atributos no primos dependen de la clave primaria completa.
Los atributos no primos son aquellos que no hacen parte de la clave primaria.
Para llevar una relación a 2NF se llevan aquellos atributos que no dependen de la clave
completa a otra relación, la cual tendrá como clave la parte de la clave de la cual
dependen estos atributos.
Sólo las claves compuestas se llevan a 2NF.
Ej.: El siguiente esquema tiene como clave primaria cod_artículo, cod_proveedor y no
está en 2NF.
Esquema_artículo_proveedor = (#cod_art, #cod_prov, nom_prov, dir_prov, tel_prov,
precio)
Solamente precio depende completamente de la clave primaria; por tanto el resto de los
atributos se deben mover a otra relación con cod_prov como clave primaria, así:
Esquema_proveedores =( #cod_prov, nom_prov, dir_prov, tel_prov)
Esquema_artículo_proveedor =( #cod_art, #cod_prov, precio)

PROBLEMAS DE UNA RELACIÓN QUE NO SE ENCUENTRA EN 2NF

Anomalía de Inserción: ej.: No se puede insertar información acerca del proveedor

hasta que el proveedor suministre el artículo ( cod_art hace parte de la clave primaria).
Anomalía de Retiro. ej.: Si se suprime la única tupla de un proveedor en particular
porque ha dejado de suministrar un artículo temporalmente, se borrará el detalle del
proveedor y quedaremos sin información sobre éste.
Anomalía de Actualización: ej.: Si el proveedor suministra muchos artículos y éste
cambia de dirección y teléfono, se necesitaría buscar y actualizar todos los registros que
tengan al proveedor como parte de la clave.

Esta situación se resuelve partiendo la relación en dos, cada una en 2NF.

PROBLEMA CON LA 2NF: La dependencia transitiva. Una relación puede tener un
atributo no primo que a su vez identifique o determine a otros atributos. Este problema
se resuelve con 3NF.

Tercera forma normal (3NF): Una relación está en 3NF si y sólo si está en 2NF y todo
atributo no primo es dependiente no transitivamente de la clave primaria. En general
para pasar a 3NF, se parte en dos la relación de la siguiente manera:
Si A---->B y B-----> C esto implica que A------> C
entonces quedaría así: (#A,B) y (#B,C)

Ej.: La siguiente relación no está en 3NF porque fecha_terminación depende de

nro_proyecto y éste depende a su vez de cod_empleado.

Esquema_Empleados =(#cod_emp, nom_emp, salario, nro_proy, fecha_terminac)

Al normalizar se convierte en:
Esquema_Empleados =( #cod_emp, nom_emp, salario, nro_proy)
Esquema_Proyectos =( #nro_proy, fecha_terminac)

José Ignacio Botero O. 57

Margarita María Hincapié V.
 Notas de
Clase BD

OBJECIONES A LA 3NF

1- Se requiere más almacenamiento.

2- Se necesita mas tiempo de procesamiento.
3- Tiene mas relaciones.
Pero se evita la redundancia de valores.

En síntesis los objetivos de la normalización son:

_ Eliminar ciertos tipos de redundancia.
_ Evitar ciertas anomalías en las operaciones básicas.
_ Producir un buen diseño, fácil de entender y base de un crecimiento futuro.

Sin embargo habrá casos en los cuales haya razones válidas para no normalizar
completamente.

José Ignacio Botero O. 58

Margarita María Hincapié V.