UNIVERSIDAD NACIONAL TECNOLGICA DE LIMA SUR

ESCUELA PROFESIONAL DE INGENIERIA DE SISTEMAS

BASE DE DATOS

Docente: Ing. Daz Leyva Teodoro

Tema: MODELO RELACIONAL - NORMALIZACIN
MODELO RELACIONAL
Uno de los modelos matemticos ms importantes y actuales para la representacin
de las bases de datos, es el enfoque relacional.
Se basa en la teora matemtica de las relaciones, suministrndose por ello una
fundamentacin terica que permite aplicar todos los resultados de dicha teora a
problemas tales como el diseo de sublenguajes de datos y otros.
El trmino relacin se puede definir matemticamente como sigue:
Definicin: Relacin
Dados los conjuntos D1, D2, ...., Dn (no necesariamente distintos), R es una relacin
sobre esos n conjuntos si est constituida por un conjunto de n-tuplos ordenados
d1,d2,...dn tales que d1 D1, d2 D2, ..., dn Dn.
Los conjuntos D1, D2, ..., Dn se llaman dominios de R y n constituye el grado de la
relacin. La cantidad de tuplas constituye la cardinalidad (tipo de relacin de
correspondencia 1-1, 1-n, n-1 y n-n)
Es conveniente representar una relacin como una tabla bidimensional donde cada fila
representa un n-tuplo.

COLUMNAS(atributos)

Pgina 1 de 23

FILAS(ocurrencias)

UNIVERSIDAD NACIONAL TECNOLGICA DE LIMA SUR

ESCUELA PROFESIONAL DE INGENIERIA DE SISTEMAS

En el modelo relacional, tanto los objetos o entidades, como las relaciones que se
establecen entre ellos, se representan a travs de "tablas", que en la terminologa
relacional se denominan relaciones.
Cada relacin est compuesta de filas (las ocurrencias de los objetos) y se les
denomina, en la terminologa relacional, como tuplos, tuplas o uplos, uplas (en
realidad, n-tuplos, pero en muchos casos se suprime la n cuando no existe posibilidad
de confusin).
Tambin la relacin est compuesta por columnas (los atributos o campos que toman
valores en sus respectivos dominios).
Es importante lo siguiente:
1. No hay dos filas (tuplas) iguales.
2. El orden de las filas no es significativo.
(1 y 2 se deben a que la relacin es un conjunto)
Siendo rigurosos, el orden de las columnas s es significativo, pues representa el
orden de los dominios implicados, pero como siempre nos referimos a una columna
por su nombre y nunca por su posicin relativa:
3. El orden de las columnas no es significativo.
4. Cada valor dentro de la relacin (cada valor de un atributo) es un dato atmico(o
elemental), es decir, no descomponible; por ejemplo: un nmero, una cadena de
caracteres. En otras palabras, en cada posicin fila, columna existe un solo valor,
nunca un conjunto de valores.
Una relacin que satisface este ltimo punto se denomina "normalizada", aunque
veremos ms adelante que, en realidad, lo que ocurre es que est en Primera Forma
Normal.
La teora de la normalizacin se basa en la necesidad de encontrar una representacin
del conjunto de relaciones que en el proceso de actualizacin sea ms adecuada.
Llevar una relacin no normalizada a normalizada es muy simple.
Existen diferentes niveles de normalizacin que se llaman formas normales que
veremos ms adelante.

Pgina 2 de 23

UNIVERSIDAD NACIONAL TECNOLGICA DE LIMA SUR

ESCUELA PROFESIONAL DE INGENIERIA DE SISTEMAS

Ejemplo:
Veamos cmo nuestro ejemplo de suministrador y producto se puede representar fcil
y claramente mediante el modelo relacional.
Los atributos de estas dos entidades son:
Suministrador: Nmero, que lo identifica, Nombre, Tipo y Distrito donde radica.
Producto: Nmero, que lo identifica, Nombre, Precio unitario y Peso.
Adems, un suministrador puede suministrar muchos productos y un producto puede
ser suministrado por varios suministradores. Se conoce la cantidad de un determinado
producto que suministra un suministrador dado.

La representacin en el modelo relacional es ms simple que con el modelo jerrquico

y el modelo reticular, ya que con tres (3) tablas se tiene todo el modelo representado.
En el modelo relacional, el resultado de una demanda es tambin una relacin y las
demandas simtricas (en el sentido de ser una la inversa de la otra; por ejemplo,
recuperar los nmeros de los suministradores que suministran el producto P4 y
recuperar los nmeros de los productos que suministra el suministrador S2) requieren
operaciones simtricas.

Las diversas formas de expresar las recuperaciones dan lugar a los lenguajes
relacionales cuyas formas ms representativas son:

lgebra relacional (basado en las operaciones del lgebra de relaciones)

Clculo relacional (basado en el clculo de predicados)

Pgina 3 de 23

UNIVERSIDAD NACIONAL TECNOLGICA DE LIMA SUR

ESCUELA PROFESIONAL DE INGENIERIA DE SISTEMAS

Ventajas del modelo relacional:

Una de las principales ventajas es su simplicidad, pues el usuario formula sus

demandas en trminos del contenido informativo de la base de datos sin tener
que atender a las complejidades de la realizacin del sistema, lo que implica
gran independencia de los datos.

La informacin se maneja en forma de tablas, lo que constituye una manera

familiar de representarla.

Al igual que en el modelo reticular, si se tienen relaciones normalizadas, no

surgen dificultades grandes en la actualizacin.

Veamos en el modelo del SUMINISTRADOR-PRODUCTO presentado anteriormente,

un ejemplo de cada tipo de operacin de actualizacin:
Creacin: Aadir un producto P7. Se agrega la nueva ocurrencia en la tabla
PRODUCTO. Es posible hacerlo aunque ningn suministrador lo suministre.
Eliminacin: Se puede eliminar el suministrador S1 sin perder el producto P6, a pesar
de que es el nico suministrador que lo suministra.
Modificacin: Se puede cambiar el precio del producto P2 sin necesidad de
bsquedas adicionales ni posibilidad de inconsistencias.
No obstante, veremos que el proceso de normalizacin no es suficiente hasta el punto
aqu visto.
Desventajas:
Se dice que la fundamental consiste en la dificultad de logra productividad adecuada
de los sistemas, ya que no se emplean los medios tcnicos idneos, tales como las
memorias asociativas, siendo necesario simular este proceso, pero, en realidad, la
eficiencia y productividad de los sistemas actuales resultan realmente muy
satisfactorias.
Ejemplos de SGBD relacionales:
Query By Example (QBE)(IBM)
dBase, FoxPro, Informix, Oracle, SQL Server

Pgina 4 de 23

UNIVERSIDAD NACIONAL TECNOLGICA DE LIMA SUR

ESCUELA PROFESIONAL DE INGENIERIA DE SISTEMAS

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.D. 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.

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)
Forma Normal de Boyce-Codd (FNBC)
Existen, adems, la Cuarta (4FN) y la Quinta (5FN) Formas Normales.
Las relaciones en 1FN son un subconjunto del universo de todas las relaciones
posibles. Las relaciones en 2FN son un subconjunto de las que estn en 1FN y as
sucesivamente.

Pgina 5 de 23

UNIVERSIDAD NACIONAL TECNOLGICA DE LIMA SUR

ESCUELA PROFESIONAL DE INGENIERIA DE SISTEMAS

1. 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:

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

: nmero del pedido

FEC_PED

: fecha en que se realiza el pedido

NUM_PROV

: nmero del proveedor

NOM_PROV

: nombre del proveedor

DIR_PROV

: direccin del proveedor

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 producto; corresponde a la

columna TOTAL

PR_PED

: precio a pagar por todo el pedido; corresponde al IMPORTE

TOTAL

Pgina 6 de 23

UNIVERSIDAD NACIONAL TECNOLGICA DE LIMA SUR

ESCUELA PROFESIONAL DE INGENIERIA DE SISTEMAS

b.

El nmero de pedido es nico y se utiliza para referirse a un pedido, por tanto, se

usar como clave (llave).

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 producto; corresponde a la

columna TOTAL

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_PROD,
DES_PROD,
PR_PROD_PED, PR_PED)

NUM_PROV, NOM_PROV, DIR_PROV,

PR_UN_PROD,
CANT_PROD_PED,

Definicin: Primera Forma Normal (1FN)

La definicin formal de 1FN es: una relacin est en 1FN si cumple la propiedad de
que sus dominios no tienen elementos que, a su vez, sean conjuntos.
Los valores que puede tomar un atributo de una relacin son los elementos contenidos
en su correspondiente dominio.
Si se permitiera que un elemento del dominio de un atributo fuera un conjunto,
entonces dicho atributo pudiera tomar como valor ese conjunto de valores. Eso
implicara que en una posicin fila, columna habra un conjunto de valores y no un
nico valor, como hemos visto que debe ocurrir en el modelo relacional.

Otra 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)

Pgina 7 de 23

UNIVERSIDAD NACIONAL TECNOLGICA DE LIMA SUR

ESCUELA PROFESIONAL DE INGENIERIA DE SISTEMAS

Se puede observar que la relacin PEDIDO contiene 5 atributos repetitivos:

NUM_PROD
DES_PROD
PR_UN_PROD
CANT_PROD_PED
PR_PROD_PED
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 cada uno de ellos.
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 20lneas 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.
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,
CANT_PROD_PED, PR_PROD_PED)

Pgina 8 de 23

DES_PROD,

PR_UN_PROD,

UNIVERSIDAD NACIONAL TECNOLGICA DE LIMA SUR

ESCUELA PROFESIONAL DE INGENIERIA DE SISTEMAS

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.
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.
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 PED-PROD, que repite la informacin sobre ste. Si cambia
algn atributo del producto, entonces es necesario hacer muchas actualizaciones.
Entonces ser necesario aplicar formas normales ms fuertes a este modelo para
eliminar los problemas de actualizacin que presenta.

Pgina 9 de 23

UNIVERSIDAD NACIONAL TECNOLGICA DE LIMA SUR

ESCUELA PROFESIONAL DE INGENIERIA DE SISTEMAS

2.

SEGUNDA FORMA NORMAL (2FN)

DEPENDENCIA FUNCIONAL Y OTROS CONCEPTOS

Antes de pasar a la 2FN, es necesario abordar algunas definiciones previas que son
imprescindibles para explicar las siguientes formas normales:
Dependencia funcional
Definicin: Dependencia Funcional (DF)
Dada una relacin R, se dice que el atributo Y de R es funcionalmente dependiente del
atributo X de R, si y slo si, cada valor X en R tiene asociado a l, precisamente, un
valor de Y en R en cualquier momento del tiempo.
Y depende funcionalmente de X se denota como:

Ejemplo en la relacin SUMINISTRADOR:

SNOM, TIPO y DIST son funcionalmente dependientes cada uno de SNUM, ya que
para un valor de SNUM existe un valor correspondiente de SNOM, TIPO y DIST.

Estas cuatro (4) representaciones son formas de mostrar las dependencias

funcionales.
El reconocimiento de las dependencias funcionales es una parte esencial de la
comprensin de la semntica, del significado del dato. El hecho de que DIST dependa
funcionalmente de SNUM significa que cada suministrador est situado en un distrito.
La nocin de dependencia funcional puede ser extendida hasta cubrir el caso en que
X, Y o ambos atributos sean compuestos.

Pgina 10 de 23

UNIVERSIDAD NACIONAL TECNOLGICA DE LIMA SUR

ESCUELA PROFESIONAL DE INGENIERIA DE SISTEMAS

Dependencia funcional completa

Definicin: Dependencia funcional completa
El atributo Y es funcionalmente y completamente dependiente del atributo X, si es
funcionalmente dependiente de X y no es funcionalmente dependiente de algn
subconjunto de X.
En algunos textos lo representan como: X ==> Y
Ejemplo en la relacin SP:
El atributo CANT es funcionalmente dependiente del par de atributos (SNUM=
nmero del suministrador proveedor - y PNUM= nmero del producto).
Por ello, se podra denotar CANT como CANT_PRO_SUM, que en el diccionario de
datos se detallara como la cantidad de productos provista por un suministrador.
Esta ltima explicacin muestra que la cantidad tiene dependencia funcional completa
tanto del suministrador como del producto (Entidades Fuertes)

Llave
Al hablar de entidad en el modelo entidad - relacin, se asumi que existe una llave
para cada entidad, formada por un conjunto de atributos que definen de forma nica la
entidad. Un concepto anlogo se define para las relaciones o tablas en el modelo
relacional.
Definicin: Llave
Sean:
R una relacin con atributos A1, A2, ...., An y
X un subconjunto de A1, A2, ..., An
Se dice que X es una llave de R si:
a) XA1, A2, ..., An
O sea, todos los atributos de la relacin dependen funcionalmente de X
b)

Y X | Y A1, A2, , An
Lo planteado en el punto 2. es una condicin de minimalidad que no se
requera para el concepto de llave en el modelo entidad - relacin.
Pgina 11 de 23

UNIVERSIDAD NACIONAL TECNOLGICA DE LIMA SUR

ESCUELA PROFESIONAL DE INGENIERIA DE SISTEMAS

Una relacin puede tener varias llaves. Una de ellas se nombra "llave primaria" (la
que se escoja para trabajar) y las restantes se nombran "llaves candidatas".
Una superllave ser cualquier superconjunto de una llave. Entonces, una llave es un
caso especial de superllave.
DEFINICIN: SEGUNDA FORMA NORMAL (2FN)
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.
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:

Esta relacin no est en 2FN, pues DES_PROD y PR_UN_PROD no dependen

funcional y completamente de la llave (NUM_PED, NUM_PROD).
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).
Pgina 12 de 23

UNIVERSIDAD NACIONAL TECNOLGICA DE LIMA SUR

ESCUELA PROFESIONAL DE INGENIERIA DE SISTEMAS

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.
PRODUCTO (NUM_PROD, DES_PROD, PR_UN_PROD)
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.
Pero an tenemos problemas en este caso que son similares a las 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 redundancia.

3.

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.

Pgina 13 de 23

UNIVERSIDAD NACIONAL TECNOLGICA DE LIMA SUR

ESCUELA PROFESIONAL DE INGENIERIA DE SISTEMAS

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:

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 de los cuales existe la
dependencia transitiva.
PROVEEDOR (NUM_PROV, NOM_PROV, DIR_PROV)
Pgina 14 de 23

UNIVERSIDAD NACIONAL TECNOLGICA DE LIMA SUR

ESCUELA PROFESIONAL DE INGENIERIA DE SISTEMAS

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)
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.
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 de datos se convierte en una herramienta
imprescindible, que garantiza un diseo idneo de los datos.
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
Pgina 15 de 23

UNIVERSIDAD NACIONAL TECNOLGICA DE LIMA SUR

ESCUELA PROFESIONAL DE INGENIERIA DE SISTEMAS

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, que son, precisamente, los que se tratan de evitar
con la 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).

Para solucionar algunos problemas de dependencias funcionales, que no se podan

resolver solo con la normalizacin en 3FN, se han propuesto tres formas normales
adicionales. La normalizacin ms all de 3FN queda al juicio del diseador de la base
de datos. A partir de esa forma normal, la eliminacin de dependencias funcionales
pasa por la creacin de tablas con multitud de informacin redundante, con un posible
aumento de tamao, por lo que se ha de optar entre una optimizacin del diseo y una
optimizacin del tamao. Llegndose a diversas soluciones de compromiso entre
ambos parmetros. Salvo excepciones, con la 3FN o a lo sumo, la FNBC (que
veremos a continuacin) es ms que suficiente, y llevar la normalizacin ms all ser
ms perjudicial que beneficioso.

4.

FORMA NORMAL DE BOYCE-CODD (FNBC)

Antes de explicar la FNBC, es preciso definir el concepto de determinante.

Definicin: Determinante
Un determinante es cualquier atributo o conjunto de atributos del cual depende
funcional y completamente cualquier otro atributo. O sea, la parte izquierda de la
implicacin cuando la dependencia funcional es completa.
Ejemplo en la relacin SUMINISTRADOR:
SNUM es un determinante.
La definicin de la 3FN puede resultar inadecuada en el caso de una relacin donde
ocurre lo siguiente:
1. La relacin tiene varias llaves candidatas, donde
2. esas llaves candidatas son compuestas y
3. esas llaves candidatas se solapan (o sea, tienen, al menos, un atributo comn)
Pgina 16 de 23

UNIVERSIDAD NACIONAL TECNOLGICA DE LIMA SUR

ESCUELA PROFESIONAL DE INGENIERIA DE SISTEMAS

Es decir, para una relacin donde no tengan lugar las tres condiciones anteriores, la
FNBC es idntica a la 3FN. Esas tres condiciones son necesarias, pero no suficientes,
para que la relacin no est en FNBC.
Definicin: Forma Normal de Boyce-Codd (FNBC)
Una relacin R est en FNBC si, y slo si, cada determinante es una superllave
(candidata o primaria).
Obsrvese que se habla en trminos de llaves candidatas y no slo de la llave
primaria, ya que una llave es un caso especial de superllave y la llave puede ser
candidata o primaria.
Adems, la definicin de FNBC es conceptualmente ms simple, aunque es una
FN ms "fuerte". Una relacin que est en FNBC est tambin en 1FN, 2FN y 3FN.

Por ejemplo, la relacin

PRODUCTO (NUM_PROD, NOM_PROD, PRE_PROD, PESO_PROD)
con las DF

: NUM_PRODNOM_PROD, PRE_PROD, PESO_PROD

NOM_PRODNUM_PROD, PRE_PROD, PESO_PROD

es decir, suponiendo que NUM_PROD y NOM_PROD sean llaves candidatas, est en

FNBC, ya que, en todas las DF que existen, los determinantes son llaves candidatas y,
por tanto, superllaves de PRODUCTO.

Analicemos otro ejemplo:

TUTORIA (DNI, ASIGNATURA, TUTOR)
Esa tabla est en tercera forma normal (no hay dependencias transitivas), pero no en
forma de Boyce - Codd, ya que: (DNI, Asignatura)Tutor y Tutor Asignatura en
este caso la redundancia ocurre por mala seleccin de clave. La redundancia de la
asignatura es completamente evitable. La solucin sera:

TUTORIA (DNI, TUTOR)

ASIGNATURA-TUTORIA ( ASIGNATURA, TUTOR)
5.

CUARTA FORMA NORMAL(4FN)

Una relacin est en 4FN si y solo si se encuentra en 3FN y se cumple que no
existan dependencias multivaluadas en alguno de los atributos no claves. Un
Pgina 17 de 23

UNIVERSIDAD NACIONAL TECNOLGICA DE LIMA SUR

ESCUELA PROFESIONAL DE INGENIERIA DE SISTEMAS

atributo multivaluado es aquel que tiene varios posibles valores para una sola
instancia de la entidad.
Por ejemplo: tenemos una entidad Cliente, cada uno de los clientes registrados
puede tener varios telfonos y email alternativos, entonces estamos ante una
dependencia multivaluada entre ambos atributos y el atributo no clave NOM_CLI.
CLIENTE (NUM_CLI, NOM_CLI, DIR_CLI, RUC_CLI, TEL_CLI, EMAIL_CLI)

Debemos resolver creando dos nuevas relaciones con los atributos multivaluados
para evitar as la redundancia de datos.
CLI-TEL (NUM_CLI, TEL_FIJO,TEL_CEL)
CLI-EMAIL (NUM_CLI, EMAIL_CLI1, EMAIL_CLI2)

6.

QUINTA FORMA NORMAL(5FN)

La Quinta Forma Normal (5FN) trata con casos donde la informacin puede ser
reconstruida de muchas piezas de informacin las cuales pueden ser mantenidas con
poca redundancia.
La Segunda, Tercera y Cuarta Formas Normales tambin sirven a este propsito pero
la Quinta Forma Normal generaliza los casos no cubiertos por ellas. No intentaremos
una exposicin amplia de la Quinta Forma Normal pero ilustraremos el concepto
central con un ejemplo, a saber:

Entidades: AGENTES, COMPANIAS y PRODUCTOS.

Si los AGENTES representan COMPAIAS, las COMPAAS fabrican

PRODUCTOS, y los AGENTES venden PRODUCTOS, entonces nosotros
querramos tener guardado un registro de cules agentes venden cules
productos para cul compaa.

Esta informacin puede ser guardada en un registro con tres campos:

Esta forma es necesaria en el caso general. Ahora bien, aunque el agente PARRA
vende autos hechos por FORD y camiones hechos por GENERAL MOTORS; l no
vende camiones FORD ni autos GM. Esto es, necesitamos la combinacin de los tres
campos para saber cules combinaciones son vlidas y cules no.
Pgina 18 de 23

UNIVERSIDAD NACIONAL TECNOLGICA DE LIMA SUR

ESCUELA PROFESIONAL DE INGENIERIA DE SISTEMAS

Ahora bien, supongamos la siguiente regla: si un agente vende cierto producto y l

representa la compaa que lo fabrica, entonces l vende un producto para esa
compaa.

En este caso, resulta que podemos reconstruir todos los datos reales de una forma
normalizada consistente de tres tipos de registros separados, cada uno conteniendo
dos campos:

Estos tres registros estn en la Quinta Forma Normal, puesto que el correspondiente
registro de tres campos presentado previamente no lo est.

Pgina 19 de 23

UNIVERSIDAD NACIONAL TECNOLGICA DE LIMA SUR

ESCUELA PROFESIONAL DE INGENIERIA DE SISTEMAS

Ejercicios:
1.

Normalice el documento y genere el modelo relacional correspondiente

Pgina 20 de 23

UNIVERSIDAD NACIONAL TECNOLGICA DE LIMA SUR

ESCUELA PROFESIONAL DE INGENIERIA DE SISTEMAS

2.

En los formularios que se presentan a continuacin:

a. Normalice cada documento.
b. Genere el modelo relacional correspondiente

2.1

El siguiente documento muestra un anlisis de precios y requerimientos tanto

de materiales, personal, as como de los equipos y herramientas necesarios
para realizar una obra.

Pgina 21 de 23

UNIVERSIDAD NACIONAL TECNOLGICA DE LIMA SUR

ESCUELA PROFESIONAL DE INGENIERIA DE SISTEMAS

2.2

El siguiente documento representa la labor realiza por los empleados de

Confecciones HILOS DE ORO. Permite controlar el trabajo realizado al
registrar la cantidad de los tipos de prendas producidas por da, por ejemplo: el
registro de las prendas programadas, prendas confeccionadas o prendas
daadas por da. Asimismo, se registra el tipo de hora (ingreso o salida) y se
especifica la hora por da.

Por ltimo, se registran las ocurrencias que se han suscitado durante la

semana especificada.

Pgina 22 de 23

UNIVERSIDAD NACIONAL TECNOLGICA DE LIMA SUR

ESCUELA PROFESIONAL DE INGENIERIA DE SISTEMAS

Referencias

http://www.scourdesign.com/articulos/BD-FN.php
http://bulma.net/body.phtml?nIdNoticia=483
Concepcin y diseo de bases de datos,Adoracin de Miguel, Mario
Piattini, RA-MA Editorial (1993)
http://www.inf.udec.cl/~mvaras/modulo30/04-norma.html

Pgina 23 de 23