Está en la página 1de 31

176 C A P T U L O 6

Para tener una mejor idea del proceso de normalizacin, considere las actividades simplificadas de una base de datos
de una compaa constructora que maneja varios proyectos. Cada proyecto tiene su propio nmero de identificacin,
nombre, empleados asignados al mismo, etc. Cada empleado tiene un nmero, nombre y clasificacin de trabajo; por
ejemplo, ingeniero o tcnico en computadoras.
La compaa cobra a sus clientes al facturar las horas empleadas en cada contrato. El costo por hora depende del
puesto del empleado. Por ejemplo, una hora de tiempo de un tcnico en computadoras se factura a un costo diferente
que una hora de tiempo de un ingeniero. Peridicamente se genera un informe que contiene la informacin que se ve
en la tabla 6.1.
El cargo total de la tabla 6.1 es un atributo derivado y, en este punto, no se guarda en la tabla.
La forma ms fcil a corto plazo para generar el informe requerido parece ser una tabla cuyo contenido corresponde a
necesidades de informacin (figura 6.1).
Observe que los datos de la figura 6.1 reflejan la asignacin de empleados a proyectos. En apariencia, un empleado
puede ser asignado a ms de un proyecto. Por ejemplo, Darlene Smithson (EMP_NUM = 112) ha sido asignada a dos
proyectos: Amber Wave y Starflight. Dada la estructura del conjunto de datos, cada proyecto incluye slo una instancia
de cualquier empleado. Por tanto, saber el valor de PROJ_NUM y EMP_NUM permitir encontrar la clasificacin del
trabajo y su cargo por hora. Adems, el lector conocer el nmero total de horas que cada empleado trabaj en cada
proyecto. (El cargo total, que es atributo derivado cuyo valor se puede calcular multiplicando las horas facturadas y el
cargo por hora, no se ha incluido en la figura 6.1. No hay dao estructural si se incluye este atributo derivado.)
FIGURA Representacin tabular del formato de informe
6.1
Nombre de la tabla: RPT_FORMAT Nombre de la base de datos: Ch06_ConstructCo
Las bases de datos para ilustrar el material de este captulo se encuentran en el sitio web Premium para
este libro.
C O N T E N I D O E N L N E A
N O R M A L I Z A C I N D E T A B L A S D E B A S E S D E D A T O S 177
T
A
B
L
A
M
u
e
s
t
r
a

d
e
l

d
i
s
e

o

d
e

u
n

i
n
f
o
r
m
e
6
.
1
N

M
E
R
O

D
E

P
R
O
Y
E
C
T
O
N
O
M
B
R
E

D
E
L

P
R
O
Y
E
C
T
O
N

M
E
R
O

D
E

E
M
P
L
E
A
D
O
N
O
M
B
R
E
D
E

E
M
P
L
E
A
D
O
C
L
A
S
E

D
E
T
R
A
B
A
J
O
C
A
R
G
O
/
H
O
R
A
H
O
R
A
S
F
A
C
T
U
R
A
D
A
S
C
A
R
G
O
T
O
T
A
L
1
5
E
v
e
r
g
r
e
e
n
1
0
3
1
0
1
1
0
5
1
0
6
1
0
2
J
u
n
e

E
.

A
r
b
o
u
g
h
J
o
h
n

G
.

N
e
w
s
A
l
i
c
e

K
.

J
o
h
n
s
o
n

*
W
i
l
l
i
a
m

S
m
i
t
h


e
l
d
D
a
v
i
d

H
.

S
e
n
i
o
r
I
n
g
e
n
i
e
r
o

e
l
e
c
t
r
i
c
i
s
t
a
D
i
s
e

a
d
o
r

d
e

b
a
s
e

d
e

d
a
t
o
s
D
i
s
e

a
d
o
r

d
e

b
a
s
e

d
e

d
a
t
o
s
P
r
o
g
r
a
m
a
d
o
r
A
n
a
l
i
s
t
a

d
e

s
i
s
t
e
m
a
s
$


8
5
.
5
0
$
1
0
5
.
0
0
$
1
0
5
.
0
0
$


3
5
.
7
5
$


9
6
.
7
5
2
3
.
8
1
9
.
4
3
5
.
7
1
2
.
6
2
3
.
8
$


2
,
0
3
4
.
9
0
$


2
,
0
3
7
.
0
0
$


3
,
7
4
8
.
5
0
$





4
5
0
.
4
5
$


2
,
3
0
2
.
6
5
S
u
b
t
o
t
a
l
$
1
0
,
5
7
3
.
5
0
1
8
A
m
b
e
r

W
a
v
e
1
1
4
1
1
8
1
0
4
1
1
2
A
n
n
e
l
i
s
e

J
o
n
e
s
J
a
m
e
s

J
.

F
r
o
m
m
e
r
A
n
n
e

K
.

R
a
m
o
r
a
s

*
D
a
r
l
e
n
e

M
.

S
m
i
t
h
s
o
n
D
i
s
e

a
d
o
r

d
e

a
p
l
i
c
a
c
i
o
n
e
s
A
p
o
y
o

g
e
n
e
r
a
l
A
n
a
l
i
s
t
a

d
e

s
i
s
t
e
m
a
s
A
n
a
l
i
s
t
a

d
e

D
S
S
$


4
8
.
1
0
$


1
8
.
3
6
$


9
6
.
7
5
$


4
5
.
9
5
2
5
.
6
4
5
.
3
3
2
.
4
4
5
.
0
$


1
,
1
8
3
.
2
6
$





8
3
1
.
7
1
$


3
,
1
3
4
.
7
0
$


2
,
0
6
7
.
7
5
S
u
b
t
o
t
a
l
$


7
,
2
6
5
.
5
2
2
2
R
o
l
l
i
n
g

T
i
d
e
1
0
5
1
0
4
1
1
3
1
1
1
1
0
6
A
l
i
c
e

K
.

J
o
h
n
s
o
n
A
n
n
e

K
.

R
a
m
o
r
a
s
D
e
l
b
e
r
t

K
.

J
o
e
n
b
r
o
o
d
G
e
o
f
f

B
.

W
a
b
a
s
h
W
i
l
l
i
a
m

S
m
i
t
h
f
i
e
l
d
D
i
s
e

a
d
o
r

d
e

b
a
s
e

d
e

d
a
t
o
s
A
n
a
l
i
s
t
a

d
e

s
i
s
t
e
m
a
s
D
i
s
e

a
d
o
r

d
e

a
p
l
i
c
a
c
i
o
n
e
s
A
p
o
y
o

d
e

o
f
i
c
i
n
a
P
r
o
g
r
a
m
a
d
o
r
$
1
0
5
.
0
0
$


9
6
.
7
5
$


4
8
.
1
0
$


2
6
.
8
7
$


3
5
.
7
5
6
5
.
7
4
8
.
4
2
3
.
6
2
2
.
0
1
2
.
8
$


6
,
9
9
8
.
5
0
$


4
,
6
8
2
.
7
0
$


1
,
1
3
5
.
1
6
$





5
9
1
.
1
4
$





4
5
7
.
6
0
S
u
b
t
o
t
a
l
$
1
3
,
7
6
5
.
1
0
2
5
S
t
a
r
f
l
i
g
h
t
1
0
7
1
1
5
1
0
1
1
1
4
1
0
8
1
1
8
1
1
2
M
a
r
i
a

D
.

A
l
o
n
z
o
T
r
a
v
i
s

B
.

B
a
w
a
n
g
i
J
o
h
n

G
.

N
e
w
s

*
A
n
n
e
l
i
s
e

J
o
n
e
s
R
a
l
p
h

B
.

W
a
s
h
i
n
g
t
o
n
J
a
m
e
s

J
.

F
r
o
m
m
e
r
D
a
r
l
e
n
e

M
.

S
m
i
t
h
s
o
n
P
r
o
g
r
a
m
a
d
o
r
A
n
a
l
i
s
t
a

d
e

s
i
s
t
e
m
a
s
D
i
s
e

a
d
o
r

d
e

b
a
s
e

d
e

d
a
t
o
s
D
i
s
e

a
d
o
r

d
e

a
p
l
i
c
a
c
i
o
n
e
s
A
n
a
l
i
s
t
a

d
e

s
i
s
t
e
m
a
s
A
p
o
y
o

g
e
n
e
r
a
l
A
n
a
l
i
s
t
a

d
e

D
S
S
$


3
5
.
7
5
$


9
6
.
7
5
$
1
0
5
.
0
0
$


4
8
.
1
0
$


9
6
.
7
5
$


1
8
.
3
6
$


4
5
.
9
5
2
5
.
6
4
5
.
8
5
6
.
3
3
3
.
1
2
3
.
6
3
0
.
5
4
1
.
4
$





9
1
5
.
2
0
$


4
,
4
3
1
.
1
5
$


5
,
9
1
1
.
5
0
$


1
,
5
9
2
.
1
1
$


2
,
2
8
3
.
3
0
$





5
5
9
.
9
8
$


1
,
9
0
2
.
3
3
S
u
b
t
o
t
a
l
$
1
7
,
5
9
5
.
5
7
T
o
t
a
l
$
4
9
,
1
9
9
.
6
9
N
o
t
a
:

*

i
n
d
i
c
a

l

d
e
r

d
e

p
r
o
y
e
c
t
o
178 C A P T U L O 6
Desafortunadamente, la estructura del conjunto de datos de la figura 6.1 no se apega a los requisitos expresados en el
captulo 3 ni maneja datos muy bien. Considere las siguientes deficiencias:
1. El nmero de proyecto (PROJ_NUM) est aparentemente destinado a ser una llave primaria o al menos parte de
una PK, pero contiene valores nulos. (Dada la exposicin precedente, se sabe que PROJ_NUM + EMP_NUM
definir cada rengln.)
2. Las entradas de la tabla invitan a inconsistencias de datos. Por ejemplo, el valor JOB_CLASS Elect. Engineer
podra introducirse como Elect.Eng. en algunos casos, El.Eng. en otros y EE en otros.
3. La tabla presenta redundancias de datos, las cuales dan las siguientes anomalas:
a) Anomalas de actualizacin. Modificar la JOB_CLASS para el empleado 105 requiere (potencialmente)
muchas alteraciones, una para cada EMP_NUM = 105.
b) Anomalas de insercin. Slo para completar la definicin de un rengln, un nuevo empleado debe asignar-
se a un proyecto. Si el empleado todava no es asignado, un proyecto fantasma debe crearse para completar
la entrada de datos del empleado.
c) Anomalas de eliminacin. Suponga que slo un empleado est asociado con un proyecto dado. Si ese
empleado abandona la compaa y sus datos se borran, la informacin del proyecto tambin se borrar. Para
impedir la prdida de la informacin del proyecto, debe ser creado un empleado ficticio slo para salvar la
informacin del proyecto.
A pesar de esas deficiencias estructurales, la estructura de tabla parece funcionar; el informe se genera con facilidad.
Desafortunadamente, podra dar resultados variables dependiendo de qu anomala de datos haya ocurrido. Por ejem-
plo, si se desea imprimir un informe para mostrar el valor total de horas trabajadas por la clasificacin de trabajo
Diseador de base de datos, ese informe no incluir datos para los registros DB Design y Database Design. Estas
anomalas en los informes causan una multitud de problemas a gerentes y no pueden ser corregidas mediante progra-
macin de aplicacin.
Incluso si una muy cuidadosa auditora de entrada de datos puede eliminar casi todos los problemas en los informes
(a un alto costo), es fcil demostrar que hasta una entrada de datos sencilla se hace ineficiente. Dada la existencia de
anomalas de actualizacin, suponga que Darlene M. Smithson es asignada a trabajar en el proyecto Evergreen. La
capturista debe actualizar el archivo PROJECT con la entrada:
15 Evergreen 112 Darlene M Smithson Analista DSS $45.95 0.0
para que haya correspondencia con los atributos PROJ_NUM, PROJ_NAME, EMP_NUM, EMP_NAME, JOB_CLASS,
CHG_HOUR y HOURS. (Cuando Ms. Smithson acaba de ser asignada al proyecto, todava no ha trabajado, de modo
que el nmero total de horas trabajadas es 0.0.)
Nota
Recuerde que la convencin de dar nombres facilita ver qu significa cada atributo y cul es su probable ori-
gen. Por ejemplo, PROJ_NAME usa el prefijo PROJ para indicar que el atributo est asociado con la tabla
PROJECT, en tanto que el componente NAME se explica por s mismo, tambin. No obstante, recuerde que
la longitud del nombre tambin debe tenerse en cuenta, en especial en la designacin del prefijo. Por esa
razn, el prefijo CHG se utiliz en lugar de CHARGE. (Dado el contexto de la base de datos, no es probable
que ese prefijo se malentienda.)
Cada vez que otro empleado sea asignado a un proyecto, algunas entradas de datos (por ejemplo PROJ_NAME,
EMP_NAME y CHG_HOUR) sern innecesariamente repetidos. Imagine el trabajo de introducir datos cuando deban
hacerse 200 o 300 entradas de tabla. Ntese que la entrada del nmero de empleado debe ser suficiente para identificar
a Darlene M. Smithson, la descripcin de su trabajo y su cargo por hora. Como hay slo una persona identificada por
el nmero 112, las caractersticas de esa persona (nombre, clasificacin de trabajo, etc.), no debe introducirse cada vez
que se actualice el archivo. Desafortunadamente, la estructura que se ve en la figura 6.1 no tiene tolerancia para esa
posibilidad.
N O R M A L I Z A C I N D E T A B L A S D E B A S E S D E D A T O S 179
La redundancia de datos evidente en la figura 6.1 lleva a espacio desperdiciado en el disco. An ms, produce anomalas
de datos. Suponga que la capturista ha introducido los datos como
15 Evergreen 112 Darla Smithson Analista DCS $4.95 0.0
A primera vista parece que la entrada de datos es correcta pero, Evergreen es el mismo proyecto que Evergreen? Y
se supone que Analista DCS es Analista DSS? Darla Smithson es la misma persona que Darlene M. Smithson? Esta
confusin es un problema de integridad de datos que fue causado porque la entrada de datos no se apegaba a la regla
de que todas las copias de datos redundantes deben ser idnticas.
La posibilidad de introducir problemas de integridad de datos causados por redundancia debe ser considerada cuando
se disee una base de datos. El ambiente de bases de datos relacional se presta especialmente bien para ayudar al di-
seador a superar esos problemas.
6.3 EL PROCESO DE NORMALIZACIN
En esta seccin aprenderemos a usar normalizacin para producir un conjunto de tablas normalizadas para guardar los
datos que se usarn para generar la informacin requerida. El objetivo de normalizacin es asegurar que cada tabla se
apegue al concepto de relaciones bien formadas, es decir, tablas que tienen las siguientes caractersticas:
Cada tabla representa un solo tema. Por ejemplo, una tabla de curso contendr slo datos que directamente
pertenecen a cursos. Del mismo modo, una tabla de estudiante contendr slo datos de estudiante.
Ningn tem de datos se guardar innecesariamente en ms de una tabla (en pocas palabras, las tablas tienen
mnima redundancia controlada). La razn para este requisito es asegurar que los datos se actualicen en slo un
lugar.
Todos los atributos no primos de una tabla son dependientes de la llave primaria; toda la llave primaria es nada
ms que la llave primaria. La razn para este requisito es asegurar que los datos sean identificables de manera
nica por un valor de llave primaria.
Cada tabla est libre de anomalas de insercin, actualizacin o eliminacin. Esto es para asegurar la integridad
y consistencia de los datos.
Para lograr el objetivo, el proceso de normalizacin nos lleva por los pasos que conducen a formas normales sucesi-
vamente ms altas. Las formas normales ms comunes y sus caractersticas bsicas aparecen en la tabla 6.2. Apren-
deremos los detalles correspondientes en las secciones indicadas.
El concepto de llaves es central para entender la normalizacin. Recuerde del captulo 3 que una llave candidata es
una superllave mnima (irreductible). La llave primaria es la llave candidata seleccionada para ser el medio primario
empleado para identificar los renglones de la tabla. Aun cuando la normalizacin se presenta por lo general desde la
perspectiva de llaves candidatas, por sencillez mientras se explica inicialmente el proceso de normalizacin, haremos
la suposicin de que por cada tabla hay slo una llave candidata y, por tanto, esta es la llave primaria.
Desde el punto de vista del modelador de datos, el objetivo de la normalizacin es asegurar que todas las tablas que-
dan al menos en tercera forma normal (3NF). Incluso existen formas normales de orden superior, pero las formas nor-
males, como la quinta forma normal (5NF), y forma normal llave dominio (DKNF) no son probables de encontrarse
TABLA Formas normales
6.2
FORMA NORMAL CARACTERSTICA SECCIN
Primera forma normal (1NF) Formato de tabla, sin grupos repetidos y PK identificada 6.3.1
Segunda forma normal (2NF) 1NF y sin dependencias parciales 6.3.2
Tercera forma normal (3NF) 2NF y sin dependencias transitivas 6.3.3
Forma normal Boyce-Codd (BCNF) Todo determinante es llave candidata (caso especial de 3NF) 6.6.1
Cuarta forma normal (4NF) 3NF y sin dependencias de valor mltiple independientes 6.6.2
180 C A P T U L O 6
en un ambiente de negocios y son, principalmente, de inters terico. Con ms frecuencia, estas formas normales
de orden superior aumentan combinaciones (haciendo lenta la operacin) sin agregar ningn valor en la eliminacin de
redundancia de datos. Algunas aplicaciones muy especializadas, por ejemplo investigacin estadstica, podran reque-
rir normalizacin superior a 4NF, pero caen fuera del propsito de casi todas las operaciones de negocios. Como esta
obra se enfoca en aplicaciones prcticas de tcnicas de bases de datos, las formas normales de orden superior no se
tratan.
Dependencia funcional
Antes de resumir el proceso de normalizacin, es buena idea repasar los conceptos de determinacin y dependencia
funcional que se trataron en detalle en el captulo 3. La tabla 6.3 resume los conceptos principales.
Es esencial entender estos conceptos porque se usan para derivar el conjunto de dependencias funcionales para
una relacin determinada. El proceso de normalizacin trabaja una relacin a la vez, identificando sus dependencias
y normalizando la relacin. Como se ver en las siguientes secciones, la normalizacin empieza por identificar las
dependencias de una relacin determinada y progresivamente descomponiendo la relacin (tabla) en un conjunto de
nuevas relaciones (tablas) basadas en las dependencias identificadas.
Dos tipos de dependencias funcionales que son de especial inters en la normalizacin son las parciales y las transitivas.
Una dependencia parcial existe cuando hay una dependencia funcional en la que el determinante es slo parte de
la llave primaria (recuerde que estamos suponiendo que hay slo una llave candidata). Por ejemplo, si (A, B) (C, D),
B C y (A, B) es la llave primaria, entonces la dependencia funcional B C es una dependencia parcial porque slo
parte de la llave primaria (B) se necesita para determinar el valor de C. Las dependencias parciales tienden a ser ms
bien sencillas y fciles de identificar.
Existe dependencia transitiva cuando hay dependencias funcionales tales que X Y, Y Z y X es la llave prima-
ria. En ese caso, la dependencia X Z es una dependencia transitiva porque X determina el valor de Z por medio de Y.
A diferencia de las dependencias parciales, las dependencias transitivas son ms difciles de identificar entre un conjunto
de datos. Por fortuna, hay una forma ms fcil para identificar dependencias transitivas. Se presentar una dependen-
cia transitiva slo cuando existe dependencia funcional entre atributos no primos. En el ejemplo previo, la dependencia
transitiva real es X Z. No obstante, la dependencia Y Z es seal de que existe una dependencia transitiva. En
consecuencia, en toda la exposicin del proceso de normalizacin, la existencia de una dependencia funcional entre
atributos no primos ser considerada como signo de una dependencia transitiva. Para resolver los problemas relaciona-
dos con dependencias transitivas, los cambios a la estructura de la tabla se hacen con base en la dependencia funcional
que seala la existencia de dependencia transitiva. Por tanto, para simplificar la descripcin de la normalizacin, de
ahora en adelante nos referiremos a la dependencia indicadora como la dependencia transitiva.
TABLA Conceptos de dependencia funcional
6.3
CONCEPTO DEFINICIN
Dependencia funcional El atributo B es funcionalmente dependiente en forma completa en el atributo A si cada valor
de A determina un valor de B y slo uno.
Ejemplo: PROJ_NUM PROJ_NAME (lase como PROJ_NUM funcionalmente determina
PROJ_NAME)
En este caso, el atributo PROJ_NUM se conoce como atributo determinante y el atributo
PROJ_NAME como atributo dependiente.
Dependencia funcional
(definicin generalizada)
El atributo A determina al atributo B (esto es, B es funcionalmente dependiente de A) si todos
los renglones de la tabla que concuerdan en valor para el atributo A tambin concuerdan en
valor para el atributo B.
Dependencia totalmente funcional
(llave compuesta)
Si el atributo B es funcionalmente dependiente de una llave compuesta A pero no de ningn
subconjunto de ella, el atributo B es funcionalmente dependiente en forma completa de A.
N O R M A L I Z A C I N D E T A B L A S D E B A S E S D E D A T O S 181
6.3.1 Conversin a la primera forma normal
Debido a que el modelo relacional los ve como parte de una tabla o un conjunto de tablas en las que todos los valores
llave deben estar identificados, los datos descritos en la figura 6.1 no podran guardarse como se muestra. Ntese que
esa figura contiene lo que se conoce como grupos repetidores. Un grupo repetidor deriva su nombre del hecho de
que un grupo de mltiples entradas del mismo tipo pueden existir para cualquier instancia de atributo llave individual.
En la figura 6.1, observe que cada instancia de nmero individual de proyecto (PROJ_NUM) puede hacer referencia a un
grupo de entradas de datos relacionados. Por ejemplo, el proyecto Evergreen (PROJ_NUM = 15) muestra cinco entradas
en este punto y esas entradas estn relacionadas porque cada una de ellas comparte la caracterstica PROJ_NUM = 15.
Cada vez que un nuevo registro se introduzca para el proyecto Evergreen, el nmero de entradas del grupo crece en uno.
Una tabla relacional no debe contener grupos repetidores. La existencia de grupos repetidores da evidencia de que
la tabla RPT_FORMAT de la figura 6.1 no satisface incluso los requisitos mnimos de la forma normal, reflejando as
redundancias de datos.
Normalizar la estructura de tabla reducir las redundancias de datos. Si existen grupos repetidores, deben ser eliminados
al asegurarse que cada rengln define una sola entidad. Adems, las dependencias deben ser identificadas para diag-
nosticar la forma normal, cuya identificacin permitir saber en dnde estamos en el proceso de normalizacin. ste
empieza con un sencillo procedimiento de tres pasos.
Paso 1: eliminar los grupos repetidores
Empecemos por presentar los datos en un formato tabular, donde cada celda tiene un solo valor y donde no hay grupos
repetidores. Para eliminar stos, elimine los valores nulos asegurndose que el atributo de cada uno de los grupos repeti-
dores contiene un valor apropiado de datos. Ese cambio convierte la tabla de la figura 6.1 a 1NF en la figura 6.2.
Paso 2: identificar la llave primaria
El diseo de la figura 6.2 representa ms de un simple cambio cosmtico. Incluso un observador indiferente notar que
PROJ_NUM no es una llave primaria adecuada porque el nmero de proyecto no identifica de manera nica a todos
los atributos restantes de entidad (rengln). Por ejemplo, el valor 15 de PROJ_NUM puede identificar a cualquiera de
FIGURA Tabla en primera forma normal
6.2
Nombre de la tabla: DATA_ORG_1NF Nombre de la base de datos: Ch06_ConstructCo
182 C A P T U L O 6
cinco empleados. Para mantener una llave primaria apropiada que identificar de manera nica el valor de cualquier
atributo, la nueva llave debe estar compuesta de una combinacin de PROJ_NUM y EMP_NUM. Por ejemplo, usando
los datos que se muestran en la figura 6.2, si sabemos que PROJ_NUM = 15 y EMP_NUM = 103, las entradas para los
atributos PROJ_NAME, EMP_NAME, JOB_CLASS, CHG_HOUR y HOURS debe ser Evergreen, June E. Arbough,
ingeniero electricista, $84.50 y 23.8, respectivamente.
Paso 3: identificar todas las dependencias
La identificacin de la llave primaria (PK) en el paso 2 significa que ya ha identificado la siguiente dependencia:
PROJ_NUM, EMP_NUM PROJ_NAME, EMP_NAME, JOB_CLASS, CHG_HOUR, HOURS
Esto es, los valores de PROJ_NAME, EMP_NAME, JOB_CLASS, CHG_HOUR y HOURS son todos ellos dependien-
tes de (es decir, estn determinados por) la combinacin de PROJ_NUM y EMP_NUM. Hay dependencias adicionales.
Por ejemplo, el nmero de proyecto identifica (determina) el nombre del proyecto. En otras palabras, el nombre del
proyecto es dependiente del nmero de proyecto. Se puede escribir esa dependencia como
PROJ_NUM PROJ_NAME
Tambin, si conocemos el nmero de empleado, tambin conocemos su nombre, clasificacin del trabajo y el cargo por
hora. Por tanto, se puede identificar la dependencia mostrada a continuacin:
EMP_NUM EMP_NAME, JOB_CLASS, CHG_HOUR
No obstante, dados los componentes previos de dependencia, se puede ver que conocer la clasificacin del trabajo
significa conocer el cargo por hora correspondiente. En otras palabras, se puede identificar una ltima dependencia:
JOB_CLASS CHG_HOUR
Existe esta dependencia entre dos atributos no primos; en consecuencia, es una seal de que existe dependencia transi-
tiva y nos referiremos a ella de esta manera. Las dependencias que acabamos de examinar tambin se pueden describir
con ayuda del diagrama que se muestra en la figura 6.3. Debido a que ese diagrama describe todas las dependencias
encontradas dentro de una estructura determinada de tabla, se conoce como diagrama de dependencia. Los dia-
gramas de dependencia son muy tiles para tener una vista global de todas las relaciones entre los atributos de una tabla
y su uso los hace menos probables de que descuidemos una dependencia importante.
Al examinar la figura 6.3, observe las siguientes caractersticas de un diagrama de dependencia:
1. Los atributos de llave primaria estn en negritas, subrayados y sombreados en color diferente.
2. Las flechas arriba de los atributos indican todas las dependencias deseables, es decir, las que estn basadas en
la llave primaria. En este caso, ntese que los atributos de entidad son dependientes de la combinacin de
PROJ_NUM y EMP_NUM.
3. Las flechas abajo del diagrama de dependencia indican dependencias menos deseables. Existen dos tipos de
stas:
a) Dependencias parciales. Es necesario conocer slo PROJ_NUM para determinar el PROJ_NAME; esto es,
el PROJ_NAME depende slo de parte de la llave primaria. Y slo es necesario conocer el EMP_NUM para
encontrar el EMP_NAME, la JOB_CLASS y el CHG_HOUR. Una dependencia basada en slo una parte de
una llave primaria compuesta es una dependencia parcial.
b) Dependencias transitivas. Observe que CHG_HOUR depende de JOB_CLASS. Como ni CHG_HOUR ni
JOB_CLASS es un atributo primo, esto es, ningun atributo es al menos parte de una llave, la condicin es
una dependencia transitiva. En otras palabras, una dependencia transitiva es una dependencia de un atributo
no primo de otro atributo no primo. El problema con dependencias transitivas es que todava dan anomalas
de datos.
N O R M A L I Z A C I N D E T A B L A S D E B A S E S D E D A T O S 183
Observe que la figura 6.3 incluye el esquema relacional para la tabla en 1NF y una notacin textual por cada depen-
dencia identificada.
Nota
El trmino primera forma normal (1NF) describe el formato tabular en el que:
Todos los atributos llave estn definidos.
No hay grupos repetidores en la tabla. En otras palabras, cada interseccin de rengln/columna contie-
ne un y slo un valor, no un conjunto de ellos.
Todos los atributos son dependientes de la llave primaria.
Todas las tablas relacionales satisfacen los requisitos de la 1NF. El problema con la estructura de la tabla 1NF que se ve
en la figura 6.3 es que contiene dependencias parciales, es decir, dependencias basadas en slo una parte de la llave
primaria.
Si bien es cierto que a veces se usan dependencias parciales por razones de operacin, deben usarse con precaucin.
(Si los requisitos de informacin parecen dictar el uso de dependencias parciales, es tiempo de evaluar la necesidad de
un diseo de almacn de datos, lo cual se estudia en el captulo 13.) Esa precaucin se justifica porque una tabla que
contiene dependencias parciales est todava sujeta a redundancias de datos y, por tanto, a varias anomalas. Ocurren
redundancias de datos porque toda entrada de rengln requiere duplicacin de datos. Por ejemplo, si Alice K. Johnson
enva su bitcora de trabajo, entonces el usuario tendra que hacer mltiples entradas durante el curso de un da. Por
cada entrada, las EMP_NAME, JOB_CLASS y CHG_HOUR deben introducirse cada vez, aun cuando los valores de
atributo sean idnticos por cada rengln introducido. Esa duplicacin de trabajo es muy ineficiente. Lo que es ms, el
trabajo de duplicacin ayuda a crear anomalas; nada impide que el usuario teclee versiones ligeramente diferentes del
nombre del empleado, su puesto y la paga por hora. Por ejemplo, el nombre del empleado para EMP_NUM = 102
podra escribirse como Dave Senior o D. Senior. El nombre del proyecto tambin podra introducirse correctamente
como Evergreen o escribirse mal como Evergreen. Tales anomalas de datos violan las reglas de integridad y consisten-
cia de la base de datos relacional.
FIGURA Diagrama de dependencia de primera forma normales (1NF)
6.3
PROJ_NUM EMP_NUM PROJ_NAME EMP_NAME JOB_CLASS CHG_HOUR HOURS
Dependencia parcial
Dependencias parciales
1NF (PROJ_NUM, EMP_NUM, PROJ_NAME, EMP_NAME, JOB_CLASS, HOURS, HOUR)
DEPENDENCIAS PARCIALES:
(PROJ_NUM PROJ_NAME)
(EMP_NUM EMP_NAME, JOB_CLASS, CHG_HOUR)
DEPENDENCIA TRANSITIVA:
JOB_CLASS CHG_HOUR)
Dependencia
transitiva
184 C A P T U L O 6
6.3.2 Conversin a la segunda forma normal
La conversin a 2NF se hace slo cuando la 1NF tiene una llave primaria compuesta. Si la 1NF tiene una llave primaria
de un solo atributo, entonces la tabla est automticamente en la 2NF. La conversin de 1NF a 2NF es sencilla. Empe-
zando con el formato 1NF que se ve en la figura 6.3, se hace lo siguiente:
Paso 1: hacer nuevas tablas para eliminar dependencias parciales
Por cada componente de la llave primaria que acte como determinante en una dependencia parcial, genere una nueva
tabla con una copia de ese componente como llave primaria. Mientras estos componentes se coloquen en las nue-
vas tablas, es importante que tambin permanezcan en la original. Es primordial que los determinantes continen en
la tabla original porque sern llaves forneas para las relaciones que se requieren para vincular estas nuevas tablas
a la original. Para la construccin de nuestro diagrama de dependencia revisado, escriba cada componente de llave en
un rengln separado; a continuacin escriba la llave original (compuesta) en el ltimo rengln. Por ejemplo,
PROJ_NUM
EMP_NUM
PROJ_NUM EMP_NUM
Cada componente se convertir en la llave en una nueva tabla. En otras palabras, la tabla original ahora est dividida en
tres tablas (PROJECT, EMPLOYEE y ASSIGNMENT).
Paso 2: reasignar atributos dependientes correspondientes
Use la figura 6.3 para determinar los atributos que sean dependientes en las dependencias parciales. Las dependen-
cias para los componentes de la llave original se encuentran si se examinan las flechas que apuntan hacia abajo en el
diagrama de dependencia que se ve en la figura 6.3. Los atributos que son dependientes en una dependencia parcial
se remueven de la tabla original y se colocan en la nueva tabla con su determinante. Cualesquier atributos que no sean
dependientes en una dependencia parcial permanecern en la tabla original. En otras palabras, a las tres tablas que re-
sulten de la conversin a 2NF se les dan nombres apropiados (PROJECT, EMPLOYEE y ASSIGNMENT) y son descritas
por los siguientes esquemas relacionales:
PROJECT (PROJ_NUM, PROJ_NAME)
EMPLOYEE (EMP_NUM, EMP_NAME, JOB_CLASS, CHG_HOUR)
ASSIGNMENT (PROJ NUM, EMP _NUM, ASSIGN_HOURS)
Como el nmero de horas empleadas en cada proyecto por cada trabajador es dependiente de PROJ_NUM y de EMP_
NUM en la tabla ASSIGNMENT, se dejan esas horas en la tabla ASSIGNMENT como ASSIGN_HOURS. Ntese que
la tabla ASSIGNMENT contiene una llave primaria compuesta formada por los atributos PROJ_NUM y EMP_NUM.
Observe que dejando los determinantes de la tabla original, as como convirtindolos en las llaves primarias de las nuevas
tablas, se han creado las relaciones de llave primaria/(llave fornea). Por ejemplo, en la tabla EMPLOYEE, EMP_NUM
es la llave primaria. En la tabla ASSIGNMENT, EMP_NUM es parte de la llave primaria compuesta (PROJ_NUM,
EMP_NUM) y es una llave fornea que relaciona la tabla EMPLOYEE con la tabla ASSIGNMENT.
Los resultados de los pasos 1 y 2 se muestran en la figura 6.4. En este punto, casi todas las anomalas estudiadas antes
se han eliminado. Por ejemplo, si se desea agregar, cambiar o eliminar un registro PROJECT, slo es necesario ir a la
tabla PROJECT y hacer el cambio a slo un rengln.
Debido a que puede existir una dependencia parcial slo cuando la llave primaria de una tabla est compuesta de varios
atributos, una tabla cuya llave primaria est formada por un solo atributo est automticamente en 2NF una vez que
est en 1NF.
La figura 6.4 todava muestra una dependencia transitiva, que puede generar anomalas. Por ejemplo, si el cargo por
hora cambia para una clasificacin de trabajo obtenida por muchos empleados, ese cambio debe ser hecho por cada
N O R M A L I Z A C I N D E T A B L A S D E B A S E S D E D A T O S 185
uno de ellos. Si usted olvida actualizar algunos de los registros de empleado que son afectados por el cambio del cargo
por hora, diferentes empleados con la misma descripcin de trabajo van a generar distintos cargos por hora.
Nota
Una tabla est en segunda forma normal (2NF) cuando:
Est en 1F.
y tambin
No incluye dependencias parciales; esto es, ningn atributo es dependiente de slo una parte de la llave
primaria.
Ntese que todava es posible que una tabla en 2NF exhiba dependencia transitiva; esto es, la llave pri-
maria puede apoyarse en uno o ms atributos no primos para determinar funcionalmente otros atributos no
primos, como est indicado por una dependencia funcional entre los atributos no primos.
6.3.3 Conversin a la tercera forma normal
Las anomalas de datos creadas por la organizacin de base de datos que se ven en la figura 6.4 se eliminan fcilmente
al completar los dos pasos siguientes:
Paso 1: hacer nuevas tablas para eliminar dependencias transitivas
Por cada dependencia transitiva, escriba una copia de su determinante como llave primaria para una nueva tabla. Un de-
terminante es cualquier atributo cuyo valor determina otros valores dentro de un rengln. Si tenemos tres dependen-
cias transitivas diferentes, tendremos tres determinantes. Al igual que con la conversin a 2NF, es importante que el
determinante permanezca en la tabla original para servir como llave fornea. La figura 6.4 muestra slo una tabla que
contiene una dependencia transitiva.
PROJ_NUM PROJ_NAME
EMP_NUM
PROJ_NUM
EMP_NAME
EMP_NUM
JOB_CLASS
ASSIGN_HOURS
CHG_HOUR
Nombre de la tabla: PROJECT PROJECT (PROJ_NUM, PROJ_NAME)
Nombre de la tabla: EMPLOYEE EMPLOYEE (EMP_NUM, EMP_NAME, JOB_CLASS, CHG_HOUR)
Dependencia
transitiva
Nombre de la tabla: ASSIGNMENT ASSIGMENT (PROJ_NUM, EMP_NUM, ASSIGN_HOURS)
DEPENDENCIA TRANSITIVA
(JOB_CLASS CHG_HOUR)
FIGURA Resultados de la conversin a segunda forma normales (2NF)
6.4
186 C A P T U L O 6
Por tanto, escriba el determinante para esta dependencia transitiva como:
JOB_CLASS
Paso 2: reasignar atributos dependientes correspondientes
Con el uso de la figura 6.4, identifique los atributos dependientes de todo determinante identificado en el paso 1 y
pngalos en las nuevas tablas con sus determinantes; remuvalos de sus tablas originales. En este ejemplo, elimine
CHG_HOUR de la tabla EMPLOYEE mostrada en la figura 6.4 para dejar la definicin de dependencia de la tabla
EMPLOYEE como:
EMP_NUM EMP_NAME, JOB_CLASS
Trace un nuevo diagrama de dependencia para mostrar todas las tablas que haya definido en los pasos 1 y 2. Aplique
nombre a la tabla para reflejar su contenido y funcin. En este caso, JOB parece apropiado. Revise todas las tablas para
asegurarse que cada tabla tenga un determinante y que ninguna tabla contenga dependencias inapropiadas. Cuando
haya completado estos pasos, ver los resultados de la figura 6.5.
En otras palabras, despus de completada la conversin a 3NF, su base de datos contendr cuatro tablas:
PROJECT (PROJ_NUM, PROJ_NAME)
EMPLOYEE (EMP_NUM, EMP_NAME, JOB_CLASS)
JOB (JOB_CLASS, CHG_HOUR)
ASSIGNMENT (PROJ_NUM, EMP_NUM, ASSIGN_HOURS)
Ntese que esta conversin ha eliminado la dependencia transitiva original de la tabla EMPLOYEE; ahora se dice que
las tablas estn en la tercera forma normal (3NF).
FIGURA Resultados de la conversin de la tercera forma normal (3NF)
6.5
PROJ_NUM EMP_NUM ASSIGN_HOURS
EMP_NUM EMP_NAME JOB_CLASS PROJ_NUM PROJ_NAME
JOB_CLASS CHG_HOUR
Nombre de la tabla: PROJECT Nombre de la tabla: EMPLOYEE
PROJECT (PROJ_NUM, PROJ_NAME) EMPLOYEE (EMP_NUM, EMP_NAME, JOB_CLASS)
Nombre de la tabla: JOB Nombre de la tabla: ASSIGNMENT
JOB (JOB_CLASS, CHG_HOUR) ASSIGMENT (PROJ_NUM, EMP_NUM, ASSIGN_HOURS)
N O R M A L I Z A C I N D E T A B L A S D E B A S E S D E D A T O S 187
Nota
Una tabla est en tercera forma normal (3NF) cuando:
Est en 2NF
y adems
No contiene dependencias transitivas.
Es interesante observar las similitudes entre resolver problemas de 2NF y 3NF. Para convertir una tabla de 1NF a 2NF
es necesario eliminar las dependencias parciales. Para convertir una tabla de 2NF a 3NF es preciso eliminar las depen-
dencias transitivas. No importa si la dependencia problema es suprimir la dependencia parcial o transitiva, la solucin
es la misma. Genere una nueva tabla por cada dependencia problema. El determinante de la dependencia proble-
ma permanece en la tabla original y se coloca como llave primaria de la nueva tabla. Los dependientes de la depen-
dencia problema se suprimen de la tabla original como atributos no primos de la nueva tabla.
No obstante lo anterior, tenga presente que si bien la tcnica es la misma, es imperativo que se alcance la 2NF antes de
continuar a 3NF; asegrese de resolver las dependencias parciales antes de encarar las transitivas, pero recuerde que
la suposicin hecha al principio de la exposicin sobre el proceso de normalizacin, de que cada tabla tiene slo una
llave candidata, que es la llave primaria. Si una tabla tiene mltiples llaves candidatas, entonces el proceso general sigue
siendo el mismo, pero hay consideraciones adicionales.
Por ejemplo, si una tabla tiene mltiples llaves candidatas y una de ellas es una llave compuesta, la tabla puede tener
dependencias parciales con base en esta llave candidata compuesta, aun cuando la llave primaria escogida sea un solo
atributo. En esos casos, siguiendo el proceso descrito lneas antes, esas dependencias se percibiran como transitivas y
no se resolveran hasta 3NF. El proceso simplificado descrito antes permitir al diseador llegar al resultado correcto,
pero por medio de la prctica debera reconocer todas las llaves candidatas y sus dependencias como tales y resolver-
las en forma apropiada. La existencia de mltiples llaves candidatas tambin puede influir en la identificacin de
dependencias transitivas. Previamente, una dependencia transitiva se defina como existente cuando un atributo no
primo determinaba otro atributo no primo. En presencia de mltiples llaves candidatas, la definicin de un atributo
no primo como atributo que no sea parte de cualquier llave candidata es crtica. Si el determinante de una dependencia
funcional no es la llave primaria sino que es parte de otra llave candidata, entonces no es atributo primo y no indica la
presencia de una dependencia transitiva.
6.4 MEJORAMIENTO DEL DISEO
Las estructuras de tabla se limpian para eliminar las dependencias parciales y transitivas problemticas. Ahora pode-
mos concentrarnos en mejorar la capacidad de la base de datos para dar informacin y en mejorar sus caractersticas
operacionales. En los siguientes prrafos aprenderemos acerca de varios tipos de problemas que es necesario resolver
para obtener un buen conjunto normalizado de tablas. Observe que por razones de espacio cada seccin presenta
slo un ejemplo; el diseador debe aplicar el principio a todas las tablas del diseo restantes. Recuerde que para hacer
buenos diseos no podemos apoyarnos en la normalizacin por s sola, pero es valiosa porque su uso ayuda a eliminar
redundancias de datos.
Evaluar asignaciones de una PK
Cada vez que un nuevo empleado sea introducido en la tabla EMPLOYEE, debe introducirse un valor JOB_CLASS.
Desafortunadamente, es demasiado fcil cometer errores de entrada de datos que llevan a violaciones de integridad
referencial. Por ejemplo, introducir DB Designer (Diseador de DB) en lugar de Database Designer (Diseador de bases
de datos) para el atributo JOB_CLASS en la tabla EMPLOYEE activar esa violacin. Por tanto, sera mejor agregar un
atributo JOB_CODE para crear un identificador nico. La adicin de un atributo JOB_CODE produce la dependencia:
JOB_CODE JOB_CLASS, CHG_HOUR
188 C A P T U L O 6
Si suponemos que la JOB_CODE es una llave primaria apropiada, este nuevo atributo produce la dependencia:
JOB_CLASS CHG_HOUR
Pero esta dependencia no es transitiva porque el determinante es una llave candidata. Adems, la presencia de JOB_
CODE reduce de forma considerable la probabilidad de violaciones de integridad referencial. Observe que la nueva tabla
JOB ahora tiene dos llaves candidatas, JOB_CODE y JOB_CLASS. En este caso, JOB_CODE es la llave primaria es-
cogida tambin como sustituta. Una llave sustituta, como recordaremos, es una llave primaria (PK) artificial introducida
por el diseador con el fin de simplificar la asignacin de llaves primarias a tablas. Las llaves sustitutas por lo general son
numricas, son generadas en forma automtica por el DBMS, estn libres de contenido semntico (no tienen significado
especial) y estn ocultas a usuarios finales.
Evaluar convenciones para dar nombre
Es mejor apegarse a las convenciones para dar nombre que se indican en el captulo 2. Por tanto, CHG_HOUR se cam-
biar a JOB_CHG_HOUR para indicar su asociacin con la tabla JOB. Adems, el nombre de atributo JOB_CLASS
no describe por completo entradas como System Analyst (Analista de sistemas), Database Designer, etc.; la leyenda
JOB_DESCRIPTION se ajusta mejor a las entradas. Tambin es posible que hayamos observado que HOURS se cam-
bi a ASSIGN_HOURS en la conversin de 1NF a 2NF. Ese cambio permite asociar las horas trabajadas con la tabla
ASSIGNMENT.
Refinar atomicidad de atributo
En general suele ser buena prctica poner atencin al requisito de atomicidad. Un atributo atmico es el que no
puede subdividirse ms; se dice que tal atributo muestra atomicidad. Es claro que el uso del EMP_NAME en la tabla
EMPLOYEE no es atmico porque se puede descomponer en un apellido, nombre y una inicial. Al mejorar el grado
de atomicidad tambin se obtiene flexibilidad de consulta. Por ejemplo, si usamos EMP_LNAME, EMP_FNAME y
EMP_INITIAL, con toda facilidad se pueden generar listas de telfonos al ordenar apellidos, nombres e iniciales. Ese tra-
bajo sera muy difcil si los componentes del nombre estuvieran dentro de un solo atributo. En general, los diseadores
prefieren usar atributos sencillos, de un solo valor, como indican las reglas de negocios y requisitos de procesamiento.
Identificar nuevos atributos
Si la tabla EMPLOYEE se usara en un ambiente real, tendran que agregarse otros varios atributos. Por ejemplo, pa-
gos de salario bruto de ao a la fecha, pagos al Seguro Social y pagos al Servicio Mdico seran deseables. El atributo
de fecha de contratacin de un empleado (EMP_HIREDATE) podra usarse para dar seguimiento a la longevidad del
empleado en el trabajo y servir como base para otorgar bonos a empleados de mucha antigedad y otras medidas que
aumentan la moral. El mismo principio debe aplicarse a todas las otras tablas del diseo.
Identificar nuevas relaciones
De acuerdo con el informe original, los usuarios necesitan rastrear cul empleado est actuando como gerente de
cada proyecto. Esto puede implementarse como una relacin entre EMPLOYEE y PROJECT. Del informe original, es
evidente que cada proyecto tiene slo un gerente. Por tanto, la capacidad del sistema para dar informacin detallada
acerca del gerente de cada proyecto est asegurada con el uso de EMP_NUM como llave fornea en PROJECT. Esa
accin asegura que se puede tener acceso a detalles de los datos del gerente de cada PROJECT sin producir duplica-
cin de datos innecesaria e indeseable. El diseador debe tener cuidado de poner los atributos correctos en las tablas
correspondientes mediante el uso de los principios de normalizacin.
Refinar llaves primarias segn sea necesario para granularidad de datos
La granularidad se refiere al nivel de detalle representado por los valores guardados en el rengln de una tabla. Se
dice que los datos guardados en su nivel de granularidad ms bajo son datos atmicos, como ya dijimos antes. En la
figura 6.5, la tabla ASSIGNMENT en 3NF usa el atributo ASSIGN_HOURS para representar las horas trabajadas por
un empleado en un proyecto dado. Pero, esos valores estn registrados a su nivel de granularidad ms bajo? En otras
N O R M A L I Z A C I N D E T A B L A S D E B A S E S D E D A T O S 189
palabras, ASSIGN_HOURS representa el total por hora, total diario, total semanal, total mensual o total anual?
Claramente, ASSIGN_HOURS requiere de una ms cuidadosa definicin. En este caso, la pregunta relevante sera
como sigue: Para qu marco de tiempo (hora, da, semana, mes, etc.) desea registrar los datos en ASSIGN_HOUR?
Suponga que la combinacin de EMP_NUM y PROJ_NUM es una llave primaria (compuesta) aceptable en la tabla
ASSIGNMENT. Esa llave primaria es til para representar slo el nmero total de horas que un empleado trabaj en
un proyecto desde que empez. El uso de una llave primaria sustituta como ASSIGN_NUM da granularidad ms baja y
mayor flexibilidad. Por ejemplo, suponga que la combinacin EMP_NUM y PROJ_NUM se usa como llave primaria
y despus un empleado hace dos entradas de horas trabajadas en la tabla ASSIGNMENT. Esa accin viola el requisito
de integridad de entidad; incluso si se agrega ASSIGN_DATE como parte de una PK compuesta, todava se genera una
violacin a integridad de entidad si cualquier empleado hace dos o ms entradas para el mismo proyecto el mismo da.
(El empleado podra haber trabajado en el proyecto unas pocas horas en la maana y luego trabajado despus el mismo
da.) La misma entrada de datos no da problemas cuando ASSIGN_NUM se usa como llave primaria.
Nota
En un mundo ideal (de diseo de base de datos), el nivel de granularidad deseado se determina en el diseo
conceptual o en la fase de recoleccin de requisitos. No obstante, como ya hemos visto en este captulo,
numerosos diseos de bases de datos comprenden el refinamiento de requisitos de datos existentes, activan-
do as modificaciones de diseo. En un ambiente real, cambiar requisitos de granularidad podra dictar modi-
ficaciones en la seleccin de una llave primaria, las cuales podran en ltima instancia requerir el uso de llaves
sustitutas.
Mantener precisin histrica
Escribir el cargo por hora de trabajo en la tabla ASSIGNMENT es crucial para mantener la precisin histrica de los
datos en la tabla ASSIGNMENT. Sera apropiado dar nombre a este atributo como ASSIGN_CHG_HOUR. Aun cuando
este atributo parecera tener el mismo valor que JOB_CHG_HOUR, esto es cierto slo si el valor JOB_CHG_HOUR
permanece siempre igual. Sin embargo, es razonable suponer que el cargo por hora de trabajo cambiar con el tiempo.
Pero imaginemos que los cargos a cada proyecto se calcularon (y facturaron) multiplicando las horas trabajadas en el
proyecto, que se encuentran en la tabla ASSIGNMENT, por el cargo por hora y se encuentran en la tabla JOB. Esos
cargos siempre mostraran el cargo actual por hora guardado en la tabla JOB, ms que el cargo por hora que estaba
en efecto al momento de la asignacin.
Evaluar con el uso de atributos derivados
Por ltimo, se puede usar un atributo derivado en la tabla ASSIGNMENT para guardar el cargo actual hecho a un
proyecto. Ese atributo derivado, al que se dar nombre de ASSIGN_CHARGE, es el resultado de multiplicar ASSIGN_
HOURS por ASSIGN_CHG_HOUR. Esto crea una dependencia transitiva tal que
(ASSIGN_CHARGE + ASSIGN_HOURS) ASSIGN_CHG_HOUR.
Desde un punto de vista estrictamente de base de datos, esos valores de atributo derivado se pueden calcular
cuando sean necesarios para escribir informes o facturas. No obstante, guardar el atributo derivado en la tabla facilita
escribir el software de aplicacin para producir los resultados deseados. Tambin, si muchas transacciones deben ser in-
formadas o resumidas, la disponibilidad del atributo derivado ahorrar tiempo de informe. (Si el clculo se realiza al mo-
mento de hacer la entrada de datos, se completar cuando el usuario final pulse la tecla Enter, lo cual acelera el proceso.)
Las mejoras descritas en las secciones precedentes se ilustran en las tablas y diagramas de dependencia que se muestran
en la figura 6.6.
190 C A P T U L O 6
La figura 6.6 es una gran mejora sobre el diseo original de la base de datos. Si el software de aplicacin se disea
en forma apropiada, la tabla ms activa (ASSIGNMENT) requiere slo la introduccin de los valores de PROJ_NUM,
EMP_NUM y ASSIGN_HOURS.
FIGURA La base de datos completa
6.6
PROJ_NUM PROJ_NAME EMP_NUM JOB_CODE JOB_DESCRIPTION JOB_CHG_HOUR
ASSIGN_NUM ASSIGN_DATE PROJ_NUM EMP_NUM ASSIGN_HOURS ASSIGN_CHG_HOUR ASSIGN_CHARGE
Nombre de la tabla: PROJECT
Nombre de la tabla:
JOB
Nombre de la base de datos: Ch06_ConstructCo
Nombre de la tabla: ASSIGNMENT
Nombre de la tabla: ASSIGNMENT
Nombre de la tabla: PROJECT
Nombre de la tabla: ASSIGNMENT
N O R M A L I Z A C I N D E T A B L A S D E B A S E S D E D A T O S 191
Los valores para los atributos ASSIGN_NUM y ASSIGN_DATE pueden ser generados por la aplicacin. Por ejemplo, el
ASSIGN_NUM puede ser creado con el uso de un contador y el ASSIGN_DATE puede ser la fecha del sistema leda por
la aplicacin e introducida en forma automtica en la tabla ASSIGNMENT. Adems, el software de aplicacin puede in-
sertar automticamente el valor correcto de ASSIGN_CHG_HOUR al escribir el valor apropiado de JOB_CHG_HOUR
de la tabla JOB en la tabla ASSIGNMENT. (Las tablas JOB y ASSIGNMENT estn relacionadas por medio del atributo
JOB_CODE.) Si cambia el valor JOB_CHG_HOUR de la tabla JOB, la siguiente insercin de ese valor en la tabla AS-
SIGNMENT reflejar el cambio automticamente. La estructura de tabla en esta forma reduce al mnimo la necesidad
de intervencin humana. De hecho, si el sistema requiere que los empleados introduzcan sus propias horas de trabajo,
pueden escanear sus EMP_NUM en la tabla ASSIGNMENT mediante el uso de una tarjeta magntica lectora que intro-
duce su identidad. As, la estructura de la tabla ASSIGNMENT puede preparar el escenario para mantener cierto nivel
de seguridad deseado.
6.5 CONSIDERACIONES DE LLAVE SUSTITUTA
Aun cuando este diseo satisface los requisitos vitales de integridad referencial y de entidad, el diseador debe todava
resolver algunos problemas. Por ejemplo, una llave primaria compuesta puede ser demasiado engorrosa para usar
cuando crece el nmero de atributos. (Se hace difcil crear una llave fornea apropiada cuando la tabla relacionada usa
una llave primaria compuesta. Adems, una llave primaria compuesta hace ms difcil escribir rutinas de bsqueda.)
O bien, un atributo de llave primaria podra simplemente tener demasiado contenido descriptivo para ser til, que es
por lo cual el atributo JOB_CODE se agreg a la tabla JOB para servir como llave primaria de esa tabla. Cuando, por
cualquier razn, la llave primaria sea considerada inapropiada, los diseadores usan llaves sustitutas, como se explic
en el captulo previo.
FIGURA La base de datos completa (contina)
6.6
EMP_NUM EMP_LNAME EMP_FNAME EMP_INITIAL EMP_HIREDATE JOB_CODE
Nombre de la tabla: EMPLOYEE
Nombre de la tabla: EMPLOYEE
192 C A P T U L O 6
A nivel de implementacin, una llave sustituta es un atributo definido por el sistema generalmente creado y administra-
do por el DBMS. Por lo general, una llave sustituta definida por el sistema es numrica y su valor automticamente se
incrementa por cada rengln. Por ejemplo, Microsoft Access usa un tipo de datos AutoNumber, Microsoft SQL Server
usa una columna de identidad y Oracle usan un objeto de sucesin.
Recuerde de la seccin 6.4 que el atributo JOB_CODE fue diseado para ser la llave primaria de la tabla JOB. No
obstante, recuerde que JOB_CODE no impide que se hagan entradas duplicadas, como se ve en la tabla JOB de la
tabla 6.4.
Claramente, las entradas de datos de la tabla 6.4 son inapropiadas porque duplican registros existentes, pero todava
no ha habido violacin de integridad de entidad ni de integridad referencial. Este problema de mltiples registros
duplicados se cre cuando el atributo JOB_CODE se agreg como la PK. (Cuando la JOB_DESCRIPTION fue desig-
nada inicialmente para ser la PK, el DBMS asegurara valores nicos para todas las entradas de descripcin de trabajo
cuando se le pidi aplicar la integridad de entidad. Pero esa opcin cre los problemas que causaron el uso del atributo
JOB_CODE en el primer lugar.) En cualquier caso, si JOB_CODE ha de ser la PK sustituta, todava debemos asegurar
la existencia de valores nicos en la JOB_DESCRIPTION mediante el uso de un ndice nico.
Observe que todas las tablas restantes (PROJECT, ASSIGNMENT y EMPLOYEE) estn sometidas a las mismas limita-
ciones. Por ejemplo, si usamos el atributo EMP_NUM en la tabla EMPLOYEE como la PK, se pueden hacer mltiples
entradas para el mismo empleado. Para evitar ese problema, podra crearse un ndice nico para EMP_LNAME, EMP_
FNAME y EMP_INITIAL. Pero, cmo se maneja entonces el caso de dos empleados llamados Joe B. Smith? En ese
caso, podra usarse otro atributo (de preferencia definido externamente) para servir como la base para un ndice nico.
Merece la pena repetir que el diseo de base de datos comprende concesiones y el ejercicio de juicio profesional. En un
ambiente del mundo real se debe alcanzar un equilibrio entre integridad y flexibilidad de diseo. Por ejemplo, podramos
disear la tabla ASSIGNMENT para usar un ndice nico en PROJ_NUM, EMP_NUM y ASSIGN_DATE si se desea
limitar un empleado a slo una entrada de ASSIGN_HOURS por fecha. Esa limitacin asegurara que los empleados no
podran introducir las mismas horas muchas veces para cualquier fecha determinada. Desafortunadamente, es probable
que esa limitacin sea indeseable desde un punto de vista gerencial. Despus de todo, si un empleado trabaja varias
ocasiones en un proyecto durante cualquier da debe ser posible hacer mltiples entradas para ese mismo empleado y
el mismo proyecto durante ese da. En ese caso, la mejor solucin podra ser agregar un nuevo atributo externamente
definido, por ejemplo, un fragmento (pequea rutina de software), comprobante o nmero de boleto, para asegurar que
sea nico. En cualquier caso, frecuentes auditoras de datos seran apropiadas.
6.6 FORMAS NORMALES DE NIVEL SUPERIOR
Las tablas en 3NF funcionarn apropiadamente en bases de datos transaccionales de negocios. Sin embargo, hay
ocasiones en las que formas normales de orden superior son tiles. En esta seccin, aprenderemos acerca de un caso
especial de 3NF, conocido como forma normal de Boyce-Codd (BCNF) y de la cuarta forma normal (4NF).
6.6.1 La forma normal de Boyce-Codd (BCNF)
Una tabla est en la forma normal de Boyce-Codd (BCNF) cuando todo determinante de ella sea una llave candi-
data. (Recuerde del captulo 3 que una llave candidata tiene las mismas caractersticas que una llave primaria, pero, por
alguna razn, no se seleccion para ser llave primaria.) Claramente, cuando una tabla contiene slo una llave candidata,
la 3NF y la BCNF son equivalentes.
TABLA Entradas duplicadas en la tabla Job
6.4
JOB_CODE JOB_DESCRIPTION JOB_CHG_HOUR
511 Programador $35.75
512 Programador $35.75
N O R M A L I Z A C I N D E T A B L A S D E B A S E S D E D A T O S 193
Poniendo esa proposicin en otra forma, la BCNF puede ser violada slo cuando la tabla contenga ms de una llave
candidata.
Nota
Una tabla est en la forma normal de Boyce-Codd (BCNF) cuando todo determinante de la tabla es
una llave candidata.
Casi todos los diseadores consideran que la BCNF es un caso especial de la 3NF. De hecho, si se usan las tcnicas
que se muestran aqu, casi todas las tablas se apegan a los requisitos de la BCNF una vez alcanzada la 3NF. Entonces,
cmo puede estar una tabla en 3NF y no en BCNF? Para contestar esta pregunta hay que recordar que existe una
dependencia transitiva cuando un atributo no primo es dependiente de otro atributo no primo.
En otras palabras, una tabla est en 3NF cuando est en 2NF y no hay dependencias transitivas. Pero, qu pasa en un
caso en el que un atributo no llave es el determinante de un atributo llave? Esa condicin no viola la 3NF, pero tampoco
satisface los requisitos de la BCNF porque sta requiere que todo determinante de la tabla sea una llave candidata. La
situacin que acabamos de describir (una tabla en 3NF que no satisfaga los requisitos de la BCNF) se presenta en la
figura 6.7.
Observe estas dependencias funcionales en la figura 6.7:
A+B C, D
A+C B, D
C B
Ntese que esta estructura tiene dos llaves candidatas:
(A + B) y (A + C). La estructura de tabla que se muestra en la
figura 6.7 no tiene dependencias parciales ni transitivas. (La
condicin C B indica que un atributo no llave determina
parte de la llave primaria y esa dependencia no es transiti-
va o parcial porque el dependiente es un atributo primo.) As,
la estructura de tabla de la figura 6.7 satisface los requisitos
de 3NF. No obstante, la condicin C B hace que la tabla
no satisfaga los requisitos de la BCNF.
Para convertir la estructura de la tabla de la figura 6.7 en estructuras de tabla que estn en 3NF y en BCNF, prime-
ro cambie la llave primaria a A + C. Esa es una accin apropiada porque la dependencia C B significa que C es,
en efecto, un superconjunto de B. En este punto, la tabla est en 1NF porque contiene una dependencia parcial,
C B. A continuacin, siga los procedimientos normales de descomposicin para producir los resultados que se ven
en la figura 6.8.
Para ver cmo se puede aplicar este procedimiento a un problema real, examine la muestra de datos de la tabla 6.5.
TABLA Datos de muestra para una conversin a BCNF
6.5
STU_ID STAFF_ID CLASS_CODE ENROLL_GRADE
125 25 21334 A
125 20 32456 C
135 20 28458 B
144 25 27563 C
144 20 32456 B
FIGURA Una tabla que est en 3NF
6.7 pero no en BCNF
A B C D
194 C A P T U L O 6
La tabla 6.5 refleja las siguientes condiciones:
Cada CLASS_CODE identifica una clase de manera nica. Esta condicin ilustra el caso en el que un curso po-
dra generar muchas clases. Por ejemplo, un curso llamado INFS 420 podra impartirse en dos clases (secciones),
cada una de ellas identificada por un cdigo nico para facilitar el registro. As, la CLASS_CODE 32456 podra
identificar a INFS 420, seccin 1 de clase, en tanto que la CLASS_CODE 32457 podra identificar a INFS 420,
seccin 2 de clase. O la CLASS_CODE 28458 podra identificar a QM 362, seccin 5 de clase.
Un estudiante puede tomar muchas clases. Observe, por ejemplo, que el estudiante 125 ha tomado las clases
21334 y 32456, obteniendo calificaciones de A y C, respectivamente.
Un miembro del personal puede impartir muchas clases, pero cada clase es impartida por slo un miembro
del personal. Observe que el miembro del personal nmero 20 imparte las clases identificadas como 32456 y
28458.
La estructura que se muestra en la tabla 6.5 se refleja en el panel A de la figura 6.9:
STU_ID + STAFF_ID CLASS_CODE, ENROLL_GRADE
CLASS_CODE STAFF_ID
El panel A de la figura 6.9 presenta una estructura que est claramente en 3NF, pero la tabla representada por esta
estructura tiene un problema importante: est tratando de describir dos cosas: asignaciones de personal a clases e infor-
macin de inscripcin de estudiantes. Esa estructura de tabla de doble propsito causar anomalas. Por ejemplo, si un
miembro diferente del personal es asignado para impartir la clase 32456, dos renglones requerirn actualizaciones, pro-
duciendo as una anomala de actualizacin. Y si el estudiante 135 abandona la clase 28458, se pierde la informacin
A B C D
A C B D
A C D C
3NF, pero no BCNF
1NF
Dependencia parcial
B
3NF y BCNF 3NF y BCNF
FIGURA Descomposicin a BCNF
6.8
N O R M A L I Z A C I N D E T A B L A S D E B A S E S D E D A T O S 195
acerca de quin imparti esa clase, producindose as una anomala de eliminacin. La solucin al problema es descom-
poner la estructura de la tabla, siguiendo el procedimiento ya antes sealado. Ntese que la descomposicin del panel
B que se ve en la figura 6.9 da dos estructuras de tabla que se apegan a los requisitos tanto de 3NF como de BCNF.
Recuerde que una tabla est en BCNF cuando todo determinante de esa tabla sea una llave candidata. Por tanto, cuando
una tabla contenga slo una llave candidata, 3NF y BCNF son equivalentes.
FIGURA Otra descomposicin de una BCNF
6.9
CLASS_CODE STAFF_ID STU_ID CLASS_CODE ENROLL_GRADE
STU_ID STAFF_ID CLASS_CODE ENROLL_GRADE
Panel A: 3NF, pero no BCNF
Panel B: 3NF y BCNF
196 C A P T U L O 6
6.6.2 Cuarta forma normal (4NF)
Podramos encontrarnos con bases de datos mal diseadas, o que nos pidan convertir hojas de clculo en un formato
de base de datos en el que existan varios atributos de valores mltiples. Por ejemplo, considere la posibilidad de que un
empleado puede tener diversas asignaciones y tambin puede participar en varias organizaciones de servicio. Suponga
que el empleado 10123 realiza trabajo de voluntario para la Cruz Roja y United Way (camino unido). Adems, el mis-
mo empleado podra estar asignado a trabajar en tres proyectos: 1, 2 y 4. La figura 6.10 ilustra el modo en que ese
conjunto de datos puede registrarse en varias formas.
Hay un problema con las tablas de la figura 6.10. Los atributos ORG_CODE y ASSIGN_NUM pueden tener cada uno
muchos valores diferentes. En terminologa de normalizacin, esta situacin se conoce como dependencia de valores
mltiples. Una de estas dependencias puede presentarse cuando una llave determina valores mltiples de otros dos
atributos y esos son independientes entre s. (Un empleado puede tener muchas entradas de servicio y muchas entradas
de asignacin. Por tanto, un EMP_NUM puede determinar mltiples valores de ORG_CODE y mltiples valores de
ASSIGN_NUM; pero, ORG_CODE y ASSIGN_NUM son independientes entre s.) La presencia de una dependencia
de valores mltiples significa que si se implementan las versiones 1 y 2, es probable que las tablas contengan unos
cuantos valores nulos; de hecho, las tablas ni siquiera tienen una llave candidata viable. (Los valores EMP_NUM no son
nicos, de modo que no pueden ser las PK. Ninguna combinacin de los atributos en las versiones 1 y 2 de la tabla
se puede usar para crear una PK porque algunos de ellos contienen valores nulos.) Esa condicin no es deseable, en
especial cuando hay miles de empleados, muchos de los cuales pueden tener mltiples asignaciones de trabajo y muchas
actividades de servicio. La versin 3 al menos tiene una PK, pero est compuesta por todos los atributos de la tabla. En
realidad, la versin 3 satisface los requisitos de una 3NF, pero contiene numerosas redundancias que claramente son
indeseables.
La solucin es eliminar los problemas causados por la dependencia de valores mltiples. Se hace esto al crear nuevas ta-
blas para los componentes de dicha dependencia. En este ejemplo, la dependencia de valores mltiples se descompone
al crear las tablas ASSIGNMENT y SERVICE_V1 descritas en la figura 6.11. Observe que, en la figura 6.11, ni la tabla
ASSIGNMENT ni la SERVICE_V1 contienen dependencia de valores mltiples. Se dice que esas tablas estn en 4NF.
Si se siguen los procedimientos adecuados de diseo ilustrados en este libro, el lector no debe encontrar el problema
previamente descrito. De manera especfica, la exposicin de 4NF es acadmica en su mayor parte si usted se asegura
que sus tablas se apegan a las siguientes dos reglas:
1. Todos los atributos deben depender de la llave primaria, pero ser independientes entre s.
2. Ningn rengln puede contener dos o ms datos de valores mltiples acerca de una entidad.
FIGURA Tablas con dependencias de valor mltiple
6.10
Nombre de la base de datos: Ch06_Service
Nombre de la tabla: VOLUNTEER_V1 Nombre de la tabla: VOLUNTEER_V2
Nombre de la tabla: VOLUNTEER_V3
N O R M A L I Z A C I N D E T A B L A S D E B A S E S D E D A T O S 197
Nota
Una tabla est en cuarta forma normal (4NF) cuando est en 3NF y no tiene dependencias de valores
mltiples.
6.7 NORMALIZACIN Y DISEO DE BASES DE DATOS
Las tablas que se muestran en la figura 6.6 ilustran el modo en que se pueden usar procedimientos de normaliza-
cin para producir buenas tablas a partir de unas malas. Es probable que tengamos buenas oportunidades de poner
en prctica este conocimiento cuando empecemos a trabajar con bases de datos reales. La normal debe ser parte del
proceso de diseo. Por tanto, asegrese que las entidades propuestas satisfagan la forma normalizada requerida antes
de crear las estructuras de tabla. Recuerde que si sigue los procedimientos de diseo que se explican en los captulos 3
y 4, la probabilidad de anomalas de datos ser pequea. Pero se sabe que hasta los mejores diseadores de bases de
datos cometen errores ocasionales que aparecen durante revisiones de normalizacin. No obstante, muchas de las bases
reales que encuentre habrn sido diseadas de manera incorrecta o cargadas de anomalas si se modifican inapropia-
damente con el tiempo. Y eso significa que podran pedirle redisear y modificar bases de datos existentes que son, en
efecto, trampas de anomalas. Por tanto, debemos estar conscientes de buenos principios y procedimientos de diseo
as como de procedimientos de normalizacin.
En primer trmino, un diseo de relacin de entidad (ERD) se crea mediante un proceso iterativo. Se empieza por iden-
tificar entidades relevantes, sus atributos y relaciones. A continuacin se usan los resultados para identificar entidades y
atributos adicionales. El ERD da la gran imagen, o macroimagen, de las necesidades de informacin y de las operaciones
de una organizacin.
FIGURA Conjunto de tablas en 4NF
6.11
Nombre de la base de datos: CH06_Service
Nombre de la tabla: PROJECT Nombre de la tabla: EMPLOYEE
Nombre de la tabla: ASSIGNMENT
Nombre de la tabla: ORGANIZATION
Nombre de la tabla: SERVICE_V1
Diagrama relacional
198 C A P T U L O 6
Despus de crear el ERD inicial que se ilustra en la figura
6.12, las formas normales se definen:
PROJECT est en 3NF y no necesita modificacin en
este punto.
EMPLOYEE requiere escrutinio adicional. El atributo
JOB_DESCRIPTION define clasificaciones de traba-
jo tales como Systems Analyst (Analista de sistemas),
Database Designer (Diseador de bases de datos) y
Programmer (Programador). A su vez, esas clasifica-
ciones determinan el sueldo para facturar, JOB_
CHG_HOUR. Por tanto, EMPLOYEE contiene una
dependencia transitiva.
En segundo lugar, la normalizacin se concentra en las caractersticas de entidades especficas; esto es, la normaliza-
cin representa una vista microscpica de las entidades dentro del ERD. Como aprendimos en las secciones previas, el
proceso de normalizacin podra dar entidades y atributos adicionales para ser incorporados en el ERD. Por tanto, es
difcil separar el proceso de normalizacin del proceso de modelado entidad-relacin (ER); las dos tcnicas se usan en
un proceso iterativo e incremental.
Para ilustrar la funcin correcta de la normalizacin en el proceso de diseo, reexaminemos las operaciones de la com-
paa contratista cuyas tablas se normalizaron en las secciones precedentes. Esas operaciones se pueden resumir con
el uso de las siguientes reglas de negocios:
La compaa maneja muchos proyectos.
Cada proyecto requiere los servicios de muchos empleados.
Un empleado puede ser asignado a varios proyectos.
Algunos empleados no son asignados a un proyecto y realizan trabajos no relacionados especficamente a un
proyecto; son parte de un grupo de trabajo, para ser compartidos por todos los equipos del proyecto. Por ejem-
plo, la secretaria ejecutiva de la compaa no sera asignada a ningn proyecto en particular.
Cada empleado tiene una sola clasificacin primaria de trabajo. Esa clasificacin determina el sueldo por hora
para la facturacin.
Muchos empleados pueden tener la misma clasificacin de trabajo. Por ejemplo, la compaa emplea ms de un
ingeniero electricista.
Dada esa sencilla descripcin de las operaciones de la compaa, dos entidades y sus atributos se definen inicialmente:
PROJECT (PROJ_NUM, PROJ_NAME)
EMPLOYEE (EMP_NUM, EMP_LNAME, EMP_FNAME, EMP_INITIAL, JOB_DESCRIPTION, JOB_CHG_
HOUR)
Esas dos entidades constituyen el ERD inicial que se ilustra en la figura 6.12.
La remocin de la dependencia transitiva de EMPLOYEE da tres entidades:
PROJECT (PROJ_NUM, PROJ_NAME)
EMPLOYEE (EMP_NUM, EMP_LNAME, EMP_FNAME, EMP_INITIAL, JOB_CODE)
JOB (JOB_CODE, JOB_DESCRIPTION, JOB_CHG_HOUR)
Como el proceso de normalizacin da una entidad adicional (JOB), el ERD inicial se modifica como se muestra en la
figura 6.13.
Para representar la relacin M:N entre EMPLOYEE y PROJECT, debemos pensar que podran usarse dos relaciones
1:M: un empleado puede ser asignado a muchos proyectos y cada proyecto puede tener asignados muchos empleados
asignados (figura 6.14). Desafortunadamente, esa representacin da un diseo que no puede implementarse de manera
correcta.
Debido a que la relacin M:N entre EMPLOYEE y PROJECT no se puede implementar, el ERD de la figura 6.14 debe
ser modificado para incluir la entidad ASSIGNMENT para dar seguimiento a la asignacin de empleados a proyectos,
dando as el ERD que se muestra en la figura 6.15. La entidad ASSIGNMENT de la figura 6.15 usa las llaves primarias
FIGURA ERD inicial de la compaa
6.12 contratista
EMPLOYEE
PROJECT
PK EMP_NUM
EMP_LNAME
EMP_FNAME
EMP_INITIAL
JOB_DESCRIPTION
JOB_CHG_HOUR
PK PROJ_NUM
PROJ_NAME
N O R M A L I Z A C I N D E T A B L A S D E B A S E S D E D A T O S 199
de las entidades PROJECT y EMPLOYEE para servir como sus llaves forneas. Sin embargo, observe que en esta im-
plementacin, la llave primaria sustituta de la entidad ASSIGNMENT es ASSIGN_NUM, para evitar el uso de una llave
primaria compuesta. Por tanto, la relacin entra entre EMPLOYEE y ASSIGNMENT y la relacin requiere entre
PROJECT y ASSIGNMENT se muestran como dbiles o que no identifican.
Observe que, en la figura 6.15, el atributo ASSIGN_HOURS est asignado a la entidad compuesta llamada ASSIGN-
MENT. Como es probable que usted necesite informacin detallada acerca de cada gerente del proyecto, es til la crea-
cin de una relacin administra. La relacin administra es implementada por medio de la llave fornea en PROJECT.
Por ltimo, algunos atributos adicionales pueden ser creados para mejorar la capacidad del sistema para generar infor-
macin adicional. Por ejemplo, puede que se incluya la fecha en la que el empleado fue contratado (EMP_HIREDATE)
FIGURA Representacin incorrecta de una relacin M:N
6.14
PROJECT
JOB
EMPLOYEE
PK EMP_NUM
EMP_LNAME
EMP_FNAME
EMP_INITIAL
FK1 PROJ_NUM
FK2 JOB_CODE
PK PROJ_NUM
PROJ_NAME
FK1 EMP_NUM
PK JOB_CODE
JOB_DESCRIPTION
JOB_CHG_HOUR
es asignado a
requiere
tenido por
FIGURA ERD modificado de la compaa contratista
6.13
EMPLOYEE PROJECT
JOB
PK EMP_NUM
EMP_LNAME
EMP_FNAME
EMP_INITIAL
FK1 JOB_CODE
PK PROJ_NUM
PROJ_NAME
PK JOB_CODE
JOB_DESCRIPTION
JOB_CHG_HOUR
Cada EMPLOYEE tiene una clasi!cacin (principal) JOB.
Cualquier clasi!cacin JOB puede ser tenida por muchos EMPLOYEEs.
A algunas clasi!caciones JOB todava no se les asigna personal.
Por tanto, EMPLOYEE es opcional a JOB.
tenido por
200 C A P T U L O 6
para dar seguimiento de la longevidad del trabajador. Con base en esta ltima modificacin, el modelo debe incluir
cuatro entidades y sus atributos:
PROJECT (PROJ_NUM, PROJ_NAME, EMP_NUM)
EMPLOYEE (EMP_NUM, EMP_LNAME, EMP_FNAME, EMP_INITIAL, EMP_HIREDATE, JOB_CODE)
JOB (JOB_CODE, JOB_DESCRIPTION, JOB_CHG_HOUR)
ASSIGNMENT (ASSIGN_NUM, ASSIGN_DATE, PROJ_NUM, EMP_NUM, ASSIGN_HOURS, ASSIGN_CHG_
HOUR, ASSIGN_CHARGE)
El proceso de diseo est ahora en la va correcta. El ERD representa con toda precisin las operaciones y las entidades
ahora reflejan el apego a 3NF. La combinacin de normalizacin y modelado de ER da un til ERD, cuyas entida-
des pueden traducirse ahora a estructuras de tabla apropiadas. En la figura 6.15, observe que PROJECT es opcional a
EMPLOYEE en la relacin administra. Esta opcionalidad existe porque no todos los empleados administran proyec-
tos. El contenido final de la base de datos se presenta en la figura 6.16.
6.8 DESNORMALIZACIN
Es importante recordar que la implementacin opcional de una base de datos relacional requiere que todas las tablas
estn al menos en la tercera forma normales (3NF). Un buen DBMS relacional es estupendo para manejar relaciones
normalizadas; esto es, relaciones exentas de cualesquiera redundancias innecesarias que pudieran causar anomalas en
los datos. Aun cuando la creacin de relaciones normalizadas es un importante objetivo del diseo de bases de datos,
es slo uno de ellos. Un buen diseo de bases de datos tambin considera procesar (o informar) requisitos y rapidez de
procesamiento. El problema con la normalizacin es que como las tablas se descomponen para apegarse a los requi-
sitos de normalizacin, se expande el nmero de tablas de la base de datos. Por tanto, para generar informacin, los
datos deben sacarse juntos de varias tablas. Combinar un gran nmero de tablas requiere de operaciones adicionales
de entrada/salida (I/O) y de procesamiento lgico, con lo cual se reduce la rapidez del sistema. Casi todos los siste-
mas de bases de datos relacionales pueden manejar combinaciones con gran eficiencia, pero circunstancias raras y oca-
sionales pueden permitir algn grado de desnormalizacin y con ello la rapidez de procesamiento puede aumentarse.
FIGURA ERD final de la compaa contratista
6.15
administra
requiere
entra
tenido por
EMPLOYEE
PK EMP_NUM
EMP_LNAME
EMP_FNAME
EMP_INITIAL
EMP_HIREDATE
FK1 JOB_CODE
ASSIGNMENT PROJECT
JOB
PK ASSIGN_NUM
ASSIGN_DATE
FK1 PROJ_NUM
FK2 EMP_NUM
ASSIGN_HOURS
ASSIGN_CHG_HOUR
ASSIGN_CHARGE
PK PROJ_NUM
PROJ_NAME
FK1 EMP_NUM
PK JOB_CODE
JOB_DESCRIPTION
JOB_CHG_HOUR
N O R M A L I Z A C I N D E T A B L A S D E B A S E S D E D A T O S 201
Recuerde que la ventaja de mayor rapidez de procesamiento debe valorarse cuidadosamente contra la desventaja de
anomalas de datos. Por otra parte, algunas anomalas son slo de inters terico. Por ejemplo, las personas de un
ambiente real de base de datos deben preocuparse que ZIP_CODE determine CITY, en una tabla CUSTOMER cuya
llave primaria sea el nmero de cliente? Es realmente prctico producir una tabla separada para que
ZIP (ZIP_CODE, CITY)
elimine una dependencia transitiva de la tabla CUSTOMER? (Quiz la respuesta del lector a esa pregunta cambie si est
en el negocio de producir listas de correo.) Como ya se explic, el problema con relaciones desnormalizadas y datos
redundantes es que la integridad de datos podra comprometerse debido a la posibilidad de anomalas de datos (anoma-
las de insertar, actualizar y eliminar). El consejo es sencillo: use el sentido comn durante el proceso de normalizacin.
FIGURA Base de datos implementada
6.16
Nombre de la base de datos: Ch06_ConstructCo
Nombre de la tabla: JOB
Nombre de la base de datos: EMPLOYEE
Nombre de la tabla: PROJECT
Nombre de la tabla: ASSIGNMENT
202 C A P T U L O 6
Adems, el proceso de diseo de bases de datos podra, en algunos casos, introducir algn grado pequeo de datos
redundantes en el modelo (como se ve en el ejemplo previo). Esto, en efecto, crea relaciones desnormalizadas. La
tabla 6.6 muestra algunos ejemplos comunes de redundancia de datos que por lo general se encuentran en implemen-
taciones de bases de datos.
Un ejemplo ms completo de la necesidad de normalizacin debida a requisitos de informar es el caso de un reporte
de evaluacin de profesorado en el que cada rengln contiene las calificaciones obtenidas durante los ltimos cuatro
semestres impartidos (figura 6.17).
Aun cuando este informe parece suficientemente sencillo, el problema surge del hecho que los datos estn guardados
en una tabla normalizada en la que cada rengln representa una calificacin diferente para un miembro determinado
del profesorado en un semestre especfico (figura 6.18).
La dificultad de trasponer datos de varios renglones a datos en varias columnas se complica por el hecho de que los
ltimos cuatro semestres impartidos no son necesariamente iguales para todos los miembros del profesorado (algunos
TABLA Ejemplos comunes de desnormalizacin
6.6
CASO EJEMPLO RAZN FUNDAMENTAL Y CONTROLES
Datos
redundantes
Guardar atributos ZIP y CITY en la tabla
CUSTOMER cuando ZIP determina CITY.
(Vase tabla 1.4.)
Evitar operaciones de combinacin extra.
El programa puede validar ciudad (caja
descendente) con base en el cdigo zip
(postal).
Datos derivados Guardar STU_HOURS y STU_CLASS (clasificacin
de estudiante) cuando STU_HOURS determina
STU_CLASS. (Vase figura 3.29.)
Evitar operaciones de combinacin extra.
El programa puede validar clasificacin
(buscar) basada en las horas de
estudiante.
Datos agregados
antes (tambin
datos derivados)
Guardar el valor agregado del promedio de
calificaciones del estudiante (STU_GPA) en la tabla
STUDENT cuando esto pueda calcularse de las
tablas ENROLL y COURSE. (Vase figura 3.29.)
Evitar operaciones de combinacin extra.
El programa calcula el GPA cada vez que
se introduzca o actualice una calificacin.
STU_GPA puede ser actualizado slo
mediante rutina administrativa.
Requisitos de
informacin
Usar una tabla desnormalizada temporal para tener
datos de informes. Esto se requiere cuando se
calcula un informe tabular en el que las columnas
representan datos que estn guardados en la tabla
como renglones. (Vase figuras 6.17 y 6.18.)
Imposible generar los datos requeridos
por el informe usando SQL.
No hay necesidad de mantener tabla.
Una tabla temporal se elimina una vez
hecho el informe.
La rapidez de procesamiento no es
problema.
FIGURA Informe de evaluacin de profesorado
6.17
N O R M A L I Z A C I N D E T A B L A S D E B A S E S D E D A T O S 203
podran haber tomado sabticos, otros podran haber tenido citas de investigacin, algunos podran ser maestros nuevos
con slo dos semestres en el trabajo, etc.). Para generar este informe se usaron las dos tablas que se ven en la figura
6.18. La tabla EVALDATA es la tabla de datos maestra que contiene las calificaciones de evaluacin para cada miembro
de la facultad por cada semestre impartido; esta tabla est normalizada. La tabla FACHIST contiene los ltimos cuatro
puntos de datos, esto es, calificacin de evaluacin y semestre, por cada miembro de la facultad. La tabla FACHIST es
una tabla desnormalizada temporal creada a partir de la tabla EVALDATA por medio de una serie de consultas. (La tabla
FACHIST es la base para el informe que se muestra en la figura 6.17.)
Como se ve en el informe de evaluacin de los acadmicos, los conflictos entre eficiencia de diseo, requisitos de in-
formacin y rendimiento a veces se resuelven por medio de concesiones que pueden incluir desnormalizacin. En este
caso y suponiendo que haya suficiente espacio de almacenamiento, las opciones del diseador se pueden reducir a:
Guardar los datos en una tabla desnormalizada permanente. sta no es la solucin recomendada porque la tabla
desnormalizada est sujeta a anomalas de datos (insertar, actualizar y eliminar). Esta solucin es viable slo si el
rendimiento es un problema.
Crear una tabla desnormalizada temporal a partir de tabla(s) normalizada(s) permanente(s). Como la tabla des-
normalizada existe slo el tiempo que tarde en generar el informe, desaparece despus de producido ste. Por
tanto, no hay problemas de anomalas de datos. Esta solucin es prctica slo si el rendimiento no es problema
y no haya otras opciones viables de procesamiento.
Como se ve, a veces es difcil sostener la pureza de normalizacin en el moderno ambiente de bases de datos. En
el captulo 13 aprenderemos que las formas ms bajas de normalizacin se presentan (y hasta se requieren) en bases
de datos especializadas conocidas como almacenes de datos. Estas bases de datos especializadas reflejan la siempre
creciente demanda de alcance y profundidad ms grandes en los datos en los que dependen cada vez ms los sistemas
de soporte para decisiones. Descubriremos que el almacn de datos rutinariamente utiliza estructuras 2NF en su ambien-
te de datos complejo, de mltiples niveles y fuentes. En pocas palabras, aun cuando la normalizacin es muy importante,
en especial en el llamado ambiente de produccin de bases de datos, las 2NF ya no se menosprecia como antes.
FIGURA Tablas EVALDATA y FACHIST
6.18
Nombre de la tabla: EVALDATA Nombre de la tabla: FACHIST Nombre de la base de datos: Ch06_EVAL
Desnormalizado
Normalizado
Grupo repetidor
204 C A P T U L O 6
Aun cuando las tablas en 2NF no siempre se pueden evitar, el problema de trabajar con tablas que contienen depen-
dencias parciales o transitivas en un ambiente de bases de datos de produccin no debe minimizarse. Adems de la
posibilidad de crearse engorrosas anomalas de datos, las tablas no normalizadas en una base de datos de produccin
tienden a sufrir de estos defectos:
Las actualizaciones de datos son menos eficientes porque los programas que leen y actualizan las tablas deben
manejar tablas ms grandes.
La indizacin es ms engorrosa. Simplemente no es prctico construir todos los ndices requeridos para los
muchos atributos que podran estar ubicados en una sola tabla no normalizada.
Las tablas no normalizadas no dan estrategias sencillas para crear tablas virtuales conocidas como vistas. Apren-
deremos a crear y usar vistas en el captulo 7.
Recuerde que no se puede crear un buen diseo en los programas de aplicacin que usan una base de datos. Tambin
recuerde que, con frecuencia, las tablas de bases de datos no normalizadas llevan a varios desastres de redundancia
de datos y a bases de datos de produccin tales como los examinados hasta aqu. En otras palabras, con todo cuidado
utilice la normalizacin y asegrese que pueda explicar por qu las tablas no normalizadas son una mejor opcin en
ciertas situaciones que sus similares normalizadas.
6.9 LISTA DE VERIFICACIN DE MODELADO DE DATOS
En los captulos de la parte II, usted aprendi la forma en que el modelado de datos traduce un ambiente real especfico
en un modelo de datos que representa los datos, usuarios, procesos e interacciones reales. Las tcnicas de modelado
que ha aprendido hasta aqu le darn las herramientas necesarias para producir excelentes diseos de bases de datos,
pero, as como un buen piloto utiliza una lista de verificacin para asegurarse que todo est bien para tener un vuelo exi-
toso, la lista de verificacin del modelado de datos que se ve en la tabla 6.7 ayudar a asegurarse que usted realiza con
todo xito las tareas de modelado de datos con base en los conceptos y herramientas que ha aprendido en este texto.
Nota
Para fcil consulta, tambin puede encontrar esta lista de verificacin de modelado de datos en al final de
este libro.
N O R M A L I Z A C I N D E T A B L A S D E B A S E S D E D A T O S 205
TABLA Lista de verificacin de modelado de datos
6.7
LISTA DE VERIFICACIN DE MODELADO DE DATOS
REGLAS DE NEGOCIOS

Documentar y verificar correctamente todas las reglas de negocios con los usuarios finales.

Asegurarse que todas las reglas de negocios se escriban en forma precisa, clara y sencilla. Las reglas de negocios
deben ayudar a identificar entidades, atributos, relaciones y restricciones.

Identificar la fuente de todas las reglas de negocios y asegurarse que cada una de ellas justificada, con fecha y
firmada por una autoridad facultada para aprobar.
MODELADO DE DATOS
Convenciones para dar nombre: todos los nombres deben estar limitados en longitud (tamao dependiente de la
base de datos).

Nombres de entidad:

Deben ser sustantivos conocidos para el negocio y deben ser breves y significativos

Deben documentar abreviaturas, sinnimos y alias para cada entidad

Deben ser nicos dentro del modelo

Para entidades compuestas, pueden incluir una combinacin de nombres de entidades abreviados
vinculados por medio de la entidad compuesta

Nombres de atributo:

Deben ser nicos dentro de la entidad

Deben usar la abreviatura de entidad como prefijo

Deben ser descriptivos de la caracterstica

Deben usar prefijos como _ID, _NUM, o _CODE para el atributo PK

No deben ser una palabra reservada

No deben contener espacios o caracteres especiales como @, !, o &

Nombres de relaciones:

Deben ser verbos activos o pasivos que indiquen claramente la naturaleza de la relacin
Entidades:

Cada entidad debe representar un solo sujeto.

Cada entidad debe representar un conjunto de instancias de entidad distinguibles.

Todas las entidades deben estar en 3NF o superiores. Cualesquiera identidades debajo de 3NF deben
justificarse.

La granularidad de la instancia de entidad debe estar claramente definida.

La PK debe estar definida claramente y soportar la granularidad de datos seleccionada.


Atributos:

Deben ser sencillos y de un solo valor (datos atmicos)

Deben documentar valores predefinidos, restricciones, sinnimos y alias

Los atributos derivados deben estar claramente identificados e incluir fuente(s)

No deben ser redundantes a menos que esto se requiera para precisin y operacin de transaccin o para
mantener una historia

Los atributos no llave deben ser totalmente dependientes del atributo PK


Relaciones:

Deben identificar claramente a los participantes de la relacin

Deben definir claramente la participacin, conectividad y documentar cardinalidad


Modelo de ER

Debe estar validado contra procesos esperados: inserciones, actualizaciones y eliminaciones

Debe evaluar dnde, cundo y cmo mantener una historia

No debe contener relaciones redundantes excepto cuando sea necesario (vase atributos)

Debe minimizar redundancia de datos para asegurar actualizaciones en un solo lugar

Debe apegarse a la regla de datos mnimos: todo lo necesario est ah y todo lo que est ah es necesario.
206 C A P T U L O 6
R E S U M E N
La normalizacin es una tcnica empleada para disear tablas en las que las redundancias de datos se minimizan.
Las primeras tres formas normales (1NF, 2NF y 3NF) se encuentran con ms frecuencia. Desde un punto de
vista estructural, las formas normales ms altas son mejores que las ms bajas porque dan relativamente menos
redundancias de datos en la base de datos. Casi todos los diseos de negocios usan 3NF como forma normal
ideal. Tambin se usa una 3NF especial, ms restringida, conocida como forma normal de Boyce-Codd, o
BCNF.
Una tabla est en 1NF cuando todos los atributos clave estn definidos y cuando todos los atributos restantes son
dependientes de la llave primaria, pero una tabla en 1NF todava puede contener tanto dependencias parciales
como transitivas. (Una dependencia parcial es aquella en la que un atributo es funcionalmente dependiente de
otro atributo no llave.) Una tabla con una llave primaria de un solo atributo no puede exhibir dependencias par-
ciales.
Una tabla est en 2NF cuando est en 1NF y no contiene dependencias parciales. Por tanto, una tabla en 1NF
est automticamente en 2NF cuando su llave primaria est basada en slo un atributo. Una tabla en 2NF toda-
va puede contener dependencias transitivas.
Una tabla est en 3NF cuando est en 2NF y no contiene dependencias transitivas. Dada esta definicin de 3NF,
la forma normal de Boyce-Codd (BCNF) es simplemente un caso especial de la 3NF en el que todas las llaves
determinantes son llaves candidatas. Cuando una tabla tiene slo una llave candidata, una tabla en 3NF est
automticamente en BCNF.
Una tabla que no est en 3NF puede dividirse en nuevas tablas hasta que todas satisfagan los requisitos de 3NF.
La normalizacin es una parte importante, pero no la nica, del proceso de diseo. Cuando entidades y atributos
se definen durante el proceso de modelado ER, someta cada entidad (conjunto) a revisiones de normalizacin y
forme nueva entidad (conjuntos) segn sea necesario. Incorpore las entidades normalizadas en el ERD y contine
el proceso de ER iterativo hasta que todas las entidades y atributos estn definidos y todas las tablas equivalentes
estn en 3NF.
Una tabla en 3NF podra contener dependencias de valores mltiples que produce valores nulos numerosos o
datos redundantes. Por tanto, podra ser necesario convertir una tabla en 3NF a la cuarta forma normal (4NF)
dividindola para eliminar las dependencias de valores mltiples. As, una tabla est en 4NF cuando est en 3NF
y no contiene dependencias de valores mltiples.
Cuanto ms grande sea el nmero de tablas, se requieren ms operaciones de entrada/salida (I/O) y lgica de
procesamiento para combinarlas. Por tanto, las tablas a veces se desnormalizan para dar menos operaciones
de I/O para aumentar la rapidez de procesamiento. Desafortunadamente, con tablas ms grandes, se paga la
mayor rapidez de procesamiento con hacer menos eficientes las actualizaciones de datos, con hacer ms engo-
rrosa la indizacin y con introducir redundancias de datos que es probable den anomalas. En el diseo de bases
de datos de produccin, con todo cuidado y escasamente use desnormalizacin.
La lista de verificacin de modelado de datos es una forma de que el diseador verifique que el ERD satisface un
conjunto de requisitos mnimos.
T R M I N O S C l a v e
atomicidad, 188
atributo atmico, 188
atributo llave, 175
atributo no llave, 175
atributo no primo, 175
atributo primo, 175
cuarta forma normal
(4NF), 197
dependencia parcial, 180
dependencia transitiva, 180
desnormalizacin, 175
determinante, 185
diagrama de dependencia, 182
forma normal de Boyce-Codd
(BCNF), 192
granularidad, 188
grupo repetidor, 181
normalizacin, 175
primera forma normal
(1NF), 183
segunda forma normal
(2NF), 185
tercera forma normal
(3NF), 187