TEMA: NORMALIZACION

Ejemplo de normalizacin

ejemplo de relacin de varios a varios (con su respectiva solucin)

A travs del siguiente ejercicio se intenta afirmar los conocimientos de normalizacin

con un ejemplo simplificado de una base de datos para una pequea biblioteca.

CodLibr
o

Titulo

Autor

Editorial

NombreLector

FechaDev

1001

Variable compleja

Murray Spiegel

McGraw Hill

Prez Gmez,
Juan

15/04/200
5

1004

Visual Basic 5

E. Petroustsos

Anaya

Ros Tern, Ana

17/04/200
5

1005

Estadstica

Murray Spiegel

McGraw Hill

Roca, Ren

16/04/200
5

1006

Oracle University

Nancy Greenberg
y Priya Nathan

Oracle Corp.

Garca Roque,
Luis

20/04/200
5

1007

Clipper 5.01

Ramalho

McGraw Hill

Prez Gmez,
Juan

18/04/200
5

Esta tabla no cumple el requisito de la Primera Forma Normal (1NF) de slo tener
campos atmicos, pues el nombre del lector es un campo que puede (y conviene)
descomponerse en apellido paterno, apellido materno y nombres. Tal como se muestra
en la siguiente tabla.

CodLibr
o

1NF
Titulo

Autor

Editorial

Patern
o

Matern
o

Nombre
s

FechaDev

1001

Variable
compleja

Murray Spiegel

McGrawHil
l

Prez

Gmez

Juan

15/04/200
5

1004

Visual Basic 5

E. Petroustsos

Anaya

Ros

Tern

Ana

17/04/200
5

1005

Estadstica

Murray Spiegel

McGrawHil
l

Roca

Ren

16/04/200
5

1006

OracleUniversit
y

NancyGreenber
g

OracleCorp.

Garca

Roque

Luis

20/04/200
5

1006

OracleUniversit

Priya Nathan

OracleCorp.

Garca

Roque

Luis

20/04/200

y
1007

Clipper 5.01

Ramalho

McGrawHil
l

Prez

Titulo

Autor

Editorial

1001

Variable compleja

Murray Spiegel

McGrawHill

1004

Visual Basic 5

E. Petroustsos

Anaya

1005

Estadstica

Murray Spiegel

McGrawHill

1006

Oracle University

NancyGreenberg

Oracle Corp.

1006

Oracle University

Priya Nathan

Oracle Corp.

1007

Clipper 5.01

Ramalho

McGrawHill

Juan

18/04/200
5

Como se puede ver, hay cierta redundancia caracterstica de 1NF.

La Segunda Forma Normal (2NF) pide que no existan dependencias parciales o
dicho de otra manera, todos los atributos no clave deben depender por completo
de la clave primaria. Actualmente en nuestra tabla tenemos varias dependencias
parciales si consideramos como atributo clave el cdigo del libro.
Por ejemplo, el ttulo es completamente identificado por el cdigo del libro, pero
el nombre del lector en realidad no tiene dependencia de este cdigo, por tanto
estos datos deben ser trasladados a otra tabla.
2NF

CodLibr
o

Gmez

La nueva tabla slo contendr datos del lector.

CodLecto
r

Patern
o

Matern
o

Nombre
s

501

Prez

Gmez

Juan

502

Ros

Tern

Ana

503

Roca

504

Garca

Ren
Roque

Luis

Hemos creado una tabla para contener los datos del lector y tambin tuvimos
que crear la columna CodLector para identificar unvocamente a cada uno. Sin
embargo, esta nueva disposicin de la base de datos necesita que exista otra

tabla para mantener la informacin de qu libros estn prestados a qu lectores.

Esta tabla se muestra a continuacin:
CodLibr
o

CodLect
or

FechaDe
v

1001

501

15/04/200
5

1004

502

17/04/200
5

1005

503

16/04/200
5

1006

504

20/04/200
5

1007

501

18/04/200
5

Para la Tercera Forma Normal (3NF) la relacin debe estar en 2NF y adems los
atributos no clave deben ser mutuamente independientes y dependientes por
completo de la clave primaria. Tambin recordemos que dijimos que esto
significa que las columnas en la tabla deben contener solamente informacin
sobre la entidad definida por la clave primaria y, por tanto, las columnas en la
tabla deben contener datos acerca de una sola cosa.
En nuestro ejemplo en 2NF, la primera tabla conserva informacin acerca del
libro, los autores y editoriales, por lo que debemos crear nuevas tablas para
satisfacer los requisitos de 3NF.
3NF
CodLibro

Titulo

1001

Variable compleja

1004

Visual Basic 5

1005

Estadstica

1006

Oracle University

1007

Clipper 5.01

CodAutor

Autor

801

Murray Spiegel

802

E. Petroustsos

803

NancyGreenberg

804

Priya Nathan

806

Ramalho

CodEditorial

Editorial

901

McGraw Hill

902

Anaya

903

Oracle Corp.

Aunque hemos creado nuevas tablas para que cada una tenga slo informacin
acerca de una entidad, tambin hemos perdido la informacin acerca de qu
autor ha escrito qu libro y las editoriales correspondientes, por lo que debemos
crear otras tablas que relacionen cada libro con sus autores y editoriales.

CodLibro

codAutor

1001

801

1004

802

1005

801

1006

803

1006

804

1007

806

CodLibro

codEditorial

1001

901

1004

902

1005

901

1006

903

1007

901

DEFINICION NORMALIZACION DE BASE DE DATOS

El proceso de normalizacin de bases de datos consiste en designar y

aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo
entidad-relacin almodelo relacional.
Las bases de datos relacionales se normalizan para:

Evitar la redundancia de los datos.

Disminuir problemas de actualizacin de los datos en las tablas.

Proteger la integridad de los datos.

En el modelo relacional es frecuente llamar tabla a una relacin, aunque para

que una tabla sea considerada como una relacin tiene que cumplir con
algunas restricciones:

Cada tabla debe tener su nombre nico.

No puede haber dos filas iguales. No se permiten los duplicados.

Todos los datos en una columna deben ser del mismo tipo.

EJEMPLO DE RELACIN DE VARIOS A VARIOS (CON SU RESPECTIVA

SOLUCIN)
Relaciones entre tablas
Una de las grandes ventajas de las bases de datos es que podemos tener toda la informacin que
necesitamos almacenar en varias tablas, relacionadas entre ellas, en lugar de una nica tabla
enorme con toda la informacin.
Qu conseguimos con esto? Para responder a esta pregunta mejor pongamos un ejemplo:
imaginemos que se quiere guardar el gnero cinematogrfico de las pelculas que se van
almacenando. Se podra pensar en aadir una nueva columna a la tabla Peliculas que se llamara
Gnero, de manera que por cada pelcula almacenada tambin tuviera su gnero. Esta posible
solucin se muestra en la figura 4.1.

Figura 4.1 Tabla pelculas con el gnero de cada pelcula

Si nos fijamos en esta solucin podemos ver que se est repitiendo el mismo valor muchas veces,
por ejemplo, Ciencia-Ficcin aparece en cuatro filas y Drama en otras tantas. Es decir, se est
obligando a teclear varias veces el mismo valor lo que, entre otras cosas, puede provocar que en
algn momento nos equivoquemos al teclear, y escribamos, por ejemplo, Ciencia-Fusin, y ya
tengamos un nuevo gnero que no corresponde a ninguna pelcula ya que ni siquiera existe (por lo
menos, en el momento de escribir esto); es decir, al introducir el mismo valor de forma redundante
se est posibilitando que en algn momento lo escribamos mal.
Puede pasarnos tambin que todos los crticos de cine se pongan de acuerdo y decidan que el
gnero Ciencia-Ficcin no tiene un nombre adecuado y que es ms adecuado llamarlo FiccinCientfica. Entonces, si se tiene en la tabla Peliculas cuatro pelculas de ese gnero, se debe ir una
a una cambiando el nombre y con cuidado de no equivocarse al teclear. Quizs si tenemos cuatro
pelculas de este gnero no nos parezca un gran problema hacer este cambio cuatro veces pero si
resulta que se tiene en la coleccin trescientas pelculas de este gnero puede que el problema
parezca ms importante.
La solucin a los problemas anteriores est en separar la informacin que aparece repetida
continuamente en una nueva tabla (ver figuras 4.2 y 4.3) e indicar de alguna forma en nuestra base
de datos que hay filas de la tabla Peliculas y de la tabla Generos que estn relacionadas (figura 4.4).

Figura 4.2. Diseo de la tabla Generos

Figura 4.3. Posible contenido de la tabla Generos

Figura 4.4. Filas relacionadas entre tabla Peliculas y tabla Generos

Antes de entrar en detalle en las relaciones entre tablas vamos a ver otro ejemplo que nos ayude a
comprender an mejor la necesidad de poder establecer relaciones entre tablas. Vamos a suponer
que quisiramos almacenar informacin (apellidos, nombre y nacionalidad) acerca de los principales
interpretes con cada una de nuestra pelculas. A pesar de haber creado una tabla Interpretes en la
segunda unidad de este curso y, con el conocimiento de bases de datos que tenemos hasta ahora,
no nos quedara otra opcin que aadir nuevas columnas a nuestra tabla Peliculas donde guardar la
informacin acerca de sus protagonistas. Es decir, podramos pensar en una solucin como la de la
figura 4.5.

Figura 4.5. Diseo de la tabla Peliculas junto con informacin de interpretes

Pero esta solucin nos deja muchas incgnitas sin resolver. Por ejemplo, si no se conoce el nombre
de ninguno de los interpretes de una pelcula se va a tener que dejar en blanco esos tres campos
para cada una de las pelculas para las que no se conocen sus interpretes. O, por ejemplo, si de una
pelcula se conoce ms de un interprete se tendr que optar entre slo almacenar uno de ellos (con
lo cual estaramos perdiendo informacin y perder informacin es algo que, en general, hay que
desechar). O bien, repetir en nuevas filas toda la informacin de las pelculas para las que se
conoce ms de un protagonista junto con cada uno de los intrpretes de dicha pelcula. Para
entender mejor los problemas expuestos tenemos la figura 4.6 que muestra un posible contenido de
la tabla Peliculas que acabamos de modificar.

Figura 4.6. Tabla Peliculas con posibles datos

Con el ejemplo de la figura 4.6 que tan solo contiene diez pelculas ya podemos ver los problemas a
que hacamos referencia en el prrafo anterior. As, podemos ver que hemos tenido que repetir
informacin de dos pelculas (La Comunidad del Anillo y Million Dollar Baby) porque conocamos dos
intrpretes de las mismas y que hay intrpretes (Harrison Ford, Liv Tyler y Javier Bardem) que nos
aparecen varias veces por ser protagonistas en varias de nuestras pelculas.
Los problemas que tenamos al incluir el campo Generos se hacen en este caso ms crticos. Si un
intrprete decide cambiar de nombre, ya tenemos dos campos a modificar en cada fila de las que
aparezca. Pensemos adems un supuesto que no nos habamos planteado con los gneros
cinematogrficos, como podra ser, si le dejamos alguna pelcula a alguien que no nos la devuelve
nunca (un ejemplo bastante real), y, al cabo del tiempo, decidimos borrar esa pelcula de nuestra
base de datos nos podemos enfrentar a varios problemas. Uno de ellos es que, si esa era la nica
pelcula que tena de un intrprete voy a perder toda la informacin de ese intrprete (en la figura 4.6
si tuviera que borrar Gladiator perdera la informacin de Russell Crowe) y el otro problema es que si
de esa pelcula tenemos guardados varios de sus protagonistas, tendremos que borrar varias filas
de la tabla.

Por tanto, parece ms recomendable dejar la tabla Peliculas como estaba al inicio de esta unidad y
tener por otro lado la tabla Interpretes (Figuras 4.7 y 4.8) que creamos en la segunda unidad,
intentando indicar de alguna manera que van a existir relaciones entre filas de la tabla Peliculas con
filas de la tabla Interpretes (Figura 4.9).

Figura 4.7. Diseo de la tabla Interpretes

Figura 4.8. Contenido de la tabla Interpretes

Figura 4.9 Filas relacionadas entre tabla Peliculas y tabla Interpretes

Una vez que ya tenemos claro que algunas veces vamos a necesitar indicar que tenemos tablas que
estn relacionadas vamos en primer lugar, a ver qu tipo de relaciones pueden existir y, segundo,
cmo indicar las relaciones en OOo Base cada uno de esos tipos de relaciones.