Diseo de Base de Datos

DISEO Y NORMALIZACIN DE LAS BASES DE DATOS.

Concepto de Normalizacin.
Normalizacin:
Normalizacin es el proceso de convertir una relacin (Tabla) en otras de
forma tal que se cumplan ciertas restricciones.
El proceso de normalizacin consiste bsicamente en obtener un conjunto de
tablas, dichas tablas se obtendrn utilizando proyecciones de la tabla original.
Una caracterstica fundamental de dichas proyecciones es que deben ser sin
perdida ni ganancia, esto se refiere a que debe ser posible deducir de las
tablas proyectadas la informacin original, ni ms ni menos.
Formas Normales:
Dentro de la literatura se han definido diversas formas normales, pero las ms
difundidas se ilustran en la siguiente figura:
Universo de relaciones Normalizadas y no Normalizadas
1FN
2 FN
3 FN
FNBC
4 FN

FN/PR (5FN)

Primera, Segunda y Tercera Formas Normales.

Primera Forma Normal (1FN)
Una relacin esta en primera forma normal (1FN) sii (lase si solo si) todos
los dominios base de los campos tienen valores atmicos. Es decir, un campo
solo tiene un valor y no un conjunto de valores.
Tomemos como ejemplo el caso de una relacin para llevar la informacin de
materias y calificaciones de alumnos, un posible diseo seria el siguiente:

MCE. Jess Carlos Snchez Guzmn

Diseo de Base de Datos

MATRICULA

CALIFS

331678

CB-001 10, MA-001 9

337890

FS-001 7, HD-002 8

337777

CB-002 7, CS-056 8

446789

MA-031 7, CB-072 8, HD-002 9

Observando la relacin anterior nos damos cuenta que el dominio del campo
MATRICULA si cumple la caracterstica de tener valores atmicos, pero el
campo CALIFS tiene el problema de que el dominio utilizado proporciona un
conjunto de valores, es decir, no esta en 1FN. Por lo tanto, se deduce que toda
relacin normalizada se encuentra en 1FN.
Un posible mejor diseo seria entonces:
MATRICULA

CLAVE

CALIF

331678

CB-001

10

331678

MA-001

337890

FS-001

337890

HD-002

337777

CB-002

337777

CS-056

446789

MA-031

446789

CV-072

446789

HD-002

Revisando esta relacin observamos que todos los dominios de los campos
proporcionan valores atmicos, es decir, ninguno de los campos tiene un
conjunto de valores; por lo tanto esta relacin ya esta en 1FN.
Segunda Forma Normal (2FN)
Una relacin est en segunda forma normal sii est en 1FN y adems cumple
la condicin de que cada atributo no-llave depende de la llave primaria.
La llave primaria es el conjunto mnimo de atributos que cumplen la
caracterstica de unicidad y que se escogi para ser la llave. Si existe ms de
un conjunto mnimo de atributos que cumplen la unicidad, al conjunto
escogido como llave se le llama llave primaria y a los dems conjuntos se les
llama llaves candidato.
Supongamos que tenemos una relacin que permite llevar la informacin de
los proveedores de una empresa junto con las partes y la cantidad en la que
son suministradas:
MCE. Jess Carlos Snchez Guzmn

Diseo de Base de Datos

NUM_PROV
S1

NOM_PROV

CIUDAD

ESTATUS

NO_PARTE

JUAN

ACAPULCO

P1

ACAPULCO

CANTIDAD
10

S1

JUAN

P2

10

S2

PEDRO

MERIDA

P1

200

S2

PEDRO

MERIDA

P3

10

S2

PEDRO

MERIDA

P5

300

S3

ANA

TIJUANA

P3

200

S3

ANA

TIJUANA

P4

10

S3

ANA

TIJUANA

P5

300

S4

P1

200

S5

PATRICIA

RENE

REYNOSA

DF

P1

10

S5

PATRICIA

REYNOSA

P4

200

S6

RENATA

OAXACA

P5

10

Considerando que la llave primaria es NUM_PROV, NUM_PARTE,

tendramos las siguientes relaciones de dependencia entre los campos no
llave y los campos de la llave candidato:

NOM_PROV

NUM_PROV

CIUDAD

ESTATUS

NUM_PARTE

CANTIDAD

De la figura anterior podemos deducir que:

Los atributos NOM_PROV, CIUDAD y ESTATUS dependen de NUM_PROV,
mientras que el atributo CANTIDAD depende de NUM_PROV +
NUM_PARTE.
De lo anterior podemos concluir que la relacin no est en 2NF (pero si est
en 1FN) debido a que no todos los campos llave dependen de la llave
primaria, pues existen dependencias de otros atributos no-llave como lo es el
atributo NUM_PARTE del cual depende el valor de CANTIDAD, dicho de
otro modo, la CANTIDAD depende de NUM_PARTE.

MCE. Jess Carlos Snchez Guzmn

Para normalizar esta relacin es necesario realizar una proyeccin dando

como resultado una tabla con los atributos que se muestran a continuacin a
la cual podramos denominar Tabla S.

NUM_PROV

NOM_PROV

CIUDAD

ESTATUS

S1

JUAN

ACAPULCO

S2

PEDRO

MERIDA

S3

ANA

TIJUANA

S4

RENE

DF

S5

PATRICIA

REYNOSA

S6

RENATA

OAXACA

NOM_PROV

NUM_PROV

CIUDAD

ESTATUS

Adems obtendremos una tabla ms denominada tabla SP la cual se muestra

a continuacin:
NUM_PROV

NUM_PARTE

CANTIDAD

S1

P1

10

S1

P2

10

S2

P1

200

S2

P3

10

S2

P5

300

S3

P3

200

S3

P4

10

S3

P5

300

S4

P1

200

S5

P1

10

S5

P4

200

S6

P5

10

NUM_PROV
CANTIDAD
NUM_PARTE

As pues podemos concluir que: Dado que en las dos tablas obtenidas los
atributos no-llave dependen solo del atributo llave, ambas tablas se
encuentran en la 2FN.
Tercera Forma Normal (3FN):

Una relacin esta en 3FN sii esta en 2FN y adems se cumple que todos los
atributos de la relacin no dependen transitivamente de la llave primaria.
Es decir no se da la situacin de que un campo dependa de la llave y otro
dependa del primero.
Tomando como ejemplo la tabla siguiente:

NUM_PROV

NOM_PROV

CIUDAD

ESTADO

S1

JUAN

ACAPULCO

S2

PEDRO

MERIDA

S3

ANA

MERIDA

RENE

S4

ACAPULCO

S5

PATRICIA

REYNOSA

S6

RENATA

REYNOSA

Haciendo un anlisis de los atributos de la relacin anterior, podemos

observar que el atributo ESTADO depende realmente de CIUDAD y no
directamente del NUM_PROV, es decir se tiene la siguiente relacin de
dependencia:
ms claramente;
NOM_PROV
NUM_PROV

NOM_PROV

CIUDAD

NUM_PROV

CIUDAD

ESTADO

ESTADO

Para poder normalizar la relacin anterior es necesario realizar dos

proyecciones y las tablas resultantes serian:
NUM_PROV

NOM_PROV

CIUDAD

S1

JUAN

ACAPULCO

S2

PEDRO

MERIDA

S3

ANA

MERIDA

S4

RENE

ACAPULCO

S5

PATRICIA

REYNOSA

S6

RENATA

REYNOSA

CIUDAD

ESTADO

ACAPULCO

MERIDA

REYNOSA

Forma Normal Boyce-Code

Forma Normal de Boyce-Codd (FNBC)
Para ilustrar la necesidad de una forma normal adicional daremos un
ejemplo:
Supongamos que deseamos llevar la informacin de qu materias lleva cada
alumno y qu profesor se las imparte. Se sabe adems de que:
1. Un alumno lleva una o ms materias.
2. Un profesor imparte slo una materia.
3. Una materia puede ser impartida por uno o ms profesores.
4. En una materia puede haber inscritos uno o ms alumnos.
Un posible diseo sera (considerando que ya se definieron previamente los
atributos de cada entidad):
MATR , NOM_ALU, CARR

NEMP , NOMBRE, GRADO

ALUMNOS

PROFESORES

MATR,

NEMP , CLAVE

GRUPOS

CLAVE, NOM_MATERIA,

MATERIAS

Pero como un profesor slo imparte una materia no es posible que un alumno
lleve dos o ms materias con el mismo profesor, de donde concluimos que no
se requiere que la llave primaria de la relacin GRUPOS sea
MATR+NEMP+CLAVE sino solamente MATR+CLAVE MATR+NEMP. Es
decir que tenemos dos llaves candidato.

De tal forma que dos mejores diseos serian:

MATR , NOM_ALU, CARR

NEMP , NOMBRE, GRADO

ALUMNOS

PROFESORES

MATR, NEMP , CLAVE

MATR

CLAVE

GRUPOS
NEMP
CLAVE, NOM_MATERIA,

MATERIAS

NOTA: La flecha de NEMP a CLAVE en ambos casos, indica que el profesor

determina la materia, puesto que solo imparte una.

MATR , NOM_ALU, CARR

NEMP , NOMBRE, GRADO

ALUMNOS

PROFESORES

MATR,

NEMP

, CLAVE

GRUPOS

MATR

NEMP

CLAVE

CLAVE, NOM_MATERIA, DESCRIPCION

MATERIAS

En cualquiera de los dos casos podemos observar que la relacin GRUPOS

est en 3FN porque todos los campos no-llave no dependen transitivamente
de la llave primaria. Pero an as la relacin tiene ciertas anomalas.
Por ejemplo: si solo se tiene a un alumno inscrito en una materia impartida
por un profesor, al dar de baja a dicho alumno, se pierde la informacin de
que materia imparte dicho profesor.
Para evitar este tipo de anomalas se ha definido la FNBC que dice:

Una relacin est en FNBC sii cada determinante es una llave candidato.

Un Determinante es cualquier atributo o conjunto de atributos del cul otro

atributo es dependiente funcionalmente en forma completa.
Analizando el diagrama de dependencias y las llaves candidato tenemos lo
siguiente:
Las llaves candidato son:
MATR+CLAVE
MATR+NEMP
Los determinantes son:
MATR+CLAVE
MATR+NEMP
NEMP (Puesto que determina la CLAVE)
De donde concluimos que la relacin GRUPOS no est en FNBC. Para poner a
GRUPOS en FNBC tenemos que analizar sus posibles proyecciones:
PROYECCION
GRUPOS[MATR,CLAVE]

COMENTARIO
Se pierde la informacin de que profesor le da clase s un alumno, puesto
hay varios profesores para una materia

GRUPOS[MATR,NEMP]

OK, pero se requiere adicionalmente la proyeccion GRUPOS [NEMP,CLAVE]

para tener la informacion original.

GRUPOS[NEMP,CLAVE]

OK, pero se requiere adicionalmente la proyeccion GRUPOS [MATR,NEMP]

para recuperar la informacin original.

As concluimos que la relacin grupos debe descomponerse en las

proyecciones: GRUPO[MATR,NEMP] y GRUPOS[NEMP,CLAVE], teniendo
as el diseo de la base de datos de la siguiente manera:

MATR , NOM_ALU, CARR

NEMP , NOMBRE, GRADO

ALUMNOS

PROFESORES

MATR,

NEMP

ALU_PROF

NEMP , CLAVE

PROF_MAT

CLAVE, NOM_MATERIA,

MATERIAS

De lo anterior podemos observar que ALU_PROF ya est en FNBC (es toda

llave) y que PROF_MAT ya est en FNBC puesto que solo existe un
determinante (que es NEMP). Adicionalmente se puede verificar que la
anomala de perder informacin de que materia da un profesor al borrar al
nico alumno que estaba inscrito se ha evitado.
Nota: Generalmente se cumple que una relacin no est en FNBC si las llaves
candidato se traslapan.
MATR , NOM_ALU, CARR

NEMP , NOMBRE, GRADO

ALUMNOS

PROFESORES

MATR,

NEMP

ALU_PROF

NEMP , CLAVE

PROF_MAT

CLAVE, NOM_MATERIA,

MATERIAS

De lo anterior podemos observar que ALU_PROF ya est en FNBC (es toda

llave) y que PROF_MAT ya est en FNBC puesto que solo existe un
determinante (que es NEMP). Adicionalmente se puede verificar que la
anomala de perder informacin de que materia da un profesor al borrar al
nico alumno que estaba inscrito se ha evitado.
Nota: Generalmente se cumple que una relacin no est en FNBC si las llaves

candidato se traslapan.

Cuarta Forma Normal.

Existen algunas relaciones que a pesar de estar en FNBC presenta cierto grado
de redundancia. Lo cual a su vez tiene como consecuencia que tengamos
anomalas al realizar altas y cambios.
Para ilustrar esto, consideraremos que en una universidad se desea
llevar el control de materias, profesores y libros de texto.
Se tienen las siguientes reglas del negocio:
Una materia puede ser impartida por uno o ms profesores.
Una materia tiene asociados uno o ms libros de texto.
Un profesor puede impartir una o ms materias
Un profesor al impartir una materia usa todos los libros de texto de esa
materia.
Un libro de texto puede ser utilizado en una o ms materias.

De este modo un posible diseo sera:

Analizando en detalle la relacin GRUPOS nos podemos dar cuenta que

requiere que todos los atributos sean la llave, puesto que:
Un mismo libro se puede repetir para diferentes combinaciones de profesor
y materia.
Un mismo profesor se puede repetir para diferentes combinaciones de
materias y libros.
Una misma materia se puede repetir para diferentes combinaciones de
profesor y libro.
En este sentido al ser todos los atributos la LLAVE ya est en FNBC pero
tiene algunos problemas:
Al dar de alta a un nuevo profesor para una materia tenemos el problema
de dar de alta tantos registros como libros haya para la materia.

 Al dar de alta un libro para una materia, se tienen que dar de alta tantos
registros como profesores haya para la materia.
La FNBC no nos ayuda a corregir estos problemas, por lo que se requiere una
forma normal adicional:
Una relacin esta en Cuarta Forma Normal (4FN) sii al tener dependencias
multivaluadas de la forma A-->>B todas las dependencias funcionales
dependen de A. Es decir todas las dependencias multivaluadas son
dependencias funcionales.
Para el caso de la relacin analizada tenemos:
CLAVE -->> NEMP
CLAVE -->> LIBRO
Para este caso un mejor diseo separara las dependencias multivaluadas
dando:

Quinta Forma Normal (PJ/NF 5FN)

Dentro del proceso de normalizacin presentado, se ha visto que se realizan
proyecciones sin prdida y sin ganancia. Normalmente se tiene que una
relacin es descompuesta en dos de sus proyecciones y al realizar el JOIN de
dichas proyecciones se recupera la tabla original. Existen algunas relaciones
en las cuales el realizar dos proyecciones de la tabla original no es suficiente
para tener una descomposicin sin perdida ni ganancia.
Tomemos el caso de PROVEEDORES, PARTES y PROYECTOS en donde se
tiene que:
Un proveedor puede suministrar diferentes partes a diferentes proyectos.

 Una parte puede ser usada por diferentes proyectos y suministrada por
diferentes proveedores.
Un proyecto puede usar diferentes partes las cuales pueden ser
suministradas por diferentes proveedores
En este sentido un posible diseo sera:

Al analizar la relacin SPJ podemos ver que se requiere que toda sea llave y
una posible descomposicin sera:
SP (SNO, PNO) y PJ(PNO,JNO)
Considerando que el contenido de SPJ es:
SNO
S1
S1
S2
S1

PNO
P1
P2
P1
P1

JNO
J2
J1
J1
J1

Entonces SP sera:
SNO
S1
S1
S2

PNO
P1
P2
P1

PNO
P1
P2
P1

JNO
J2
J1
J1

y PJ sera:

Al realizar el join de SP con PJ produce:

SNO
S1

PNO
P1

JNO
J2

S1
S1
S2
S1

P1
P2
P1
P1

J1
J1
J2
J1

De donde se concluye que se tiene un registro adicional que es S2, P1, J2.
Para poder tomar proyecciones sin prdida ni ganancia de la tabla SPJ es
necesario tomar 3 proyecciones, y realizar joins entre ellos. La proyeccin que
hace falta es: SJ(SNO, JNO)
Que al realizar el join de ((SP JOIN PJ) JOIN SJ) produce la tabla original
eliminando la ganancia obtenida.
De lo anterior concluimos que:
SI, Sx Py aparece en SP
Y Py, Jw aparece en PJ
Y Sx, Jw aparece en SJ
Entonces: Aparece Sx, Py, Jw en SPJ.
En este sentido se define la dependencia al join (JD) de la siguiente forma:
Una relacin satisface una JD sii la relacin original se produce por la juntura
de las proyecciones indicadas en JD
Si la relacin R consta de campos A, B, C satisface la dependencia JD(AB, AC)
sii R se produce de AB JOIN AC
Corolario: Esto implica que:
A-->>B y A-->>C es decir que JD es mas general que las dependencias multivaluadas, o que
las dependencias multivaluadas son un caso especial de las dependencias a la juntura (JD).

De este modo la definicin de la 5FN es:

Una relacin esta en 5FN sii cada dependencia a la juntura es una
consecuencia de sus llaves candidato. Es decir si se pueden deducir las
dependencias de la juntura directamente de sus llaves candidatos.
Para el caso de SPJ se satisface JD(SP, PJ, SJ) pero esto no puede ser
deducido de la llave candidato (SNO, PNO, JNO) por lo que no esta en 5FN.
Pero las relaciones SP, PJ, SJ si estn en 5FN.
Comprobacin de la 5 forma normal