Normalizacin

La normalizacin es una tcnica para disear la estructura lgica de los datos de un sistema de
informacin en el modelo relacional, desarrollada por E. F. Codd en 1972. Las ventajas de la
normalizacin son las siguientes:

Evita anomalas en inserciones, modificaciones y borrados.

Mejora la independencia de datos.
No establece restricciones artificiales en la estructura de los datos.

En el proceso de normalizacin se debe ir comprobando que cada relacin (tabla) cumple una
serie de reglas que se basan en la clave primaria y las dependencias funcionales. Cada regla que
se cumple aumenta el grado de normalizacin. Si una regla no se cumple, la relacin se debe
descomponer en varias relaciones que s la cumplan.
La normalizacin se lleva a cabo en una serie pasos. Cada paso corresponde a una forma normal
que tiene unas propiedades. Conforme se va avanzando en la normalizacin, las relaciones tienen
un formato ms estricto (ms fuerte) y, por lo tanto, son menos vulnerables a las anomalas de
actualizacin. El modelo relacional slo requiere un conjunto de relaciones en primera forma
normal. Las restantes formas normales son opcionales. Sin embargo, es recomendable llegar al
menos a la tercera forma normal, un modelo de tablas que cumple con la tercera forma normal se
lo denomina como Normalizado.
Primera forma normal (1FN)
Una relacin est en primera forma normal si y slo si, todos los dominios de la misma contienen
valores atmicos, es decir, no hay grupos repetitivos. Si se ve la relacin grficamente como una
tabla, estar en 1FN si tiene un solo valor en la interseccin de cada fila con cada columna.
Si una relacin no est en 1FN, hay que eliminar de ella los grupos repetitivos. Un grupo repetitivo
ser el atributo o grupo de atributos que tiene mltiples valores para cada tupla de la relacin. Hay
dos formas de eliminar los grupos repetitivos. En la primera, se repiten los atributos con un solo
valor para cada valor del grupo repetitivo. De este modo, se introducen redundancias ya que se
duplican valores, pero estas redundancias se eliminarn despus mediante las restantes formas
normales. La segunda forma de eliminar los grupos repetitivos consiste en poner cada uno de
ellos en una relacin aparte, heredando la clave primaria de la relacin en la que se encontraban.
Un conjunto de relaciones se encuentra en 1FN si ninguna de ellas tiene grupos repetitivos.
Segunda forma normal (2FN)
Una relacin est en segunda forma normal si, y slo si, est en 1FN y, adems, cada atributo que
no est en la clave primaria es dependiente de la clave primaria completa.
La 2FN se aplica a las relaciones que tienen claves primarias compuestas por dos o ms
atributos. Si una relacin est en 1FN y su clave primaria es simple (tiene un solo atributo),
entonces tambin est en 2FN. Las relaciones que no estn en 2FN pueden sufrir anomalas
cuando se realizan actualizaciones.

Materia: Base de Datos I

Profesor: Calixto Maldonado

-1-

Para pasar una relacin en 1FN a 2FN hay que eliminar las dependencias parciales de la clave
primaria. Para ello, se eliminan los atributos que son funcionalmente dependientes y se ponen en
una nueva relacin con una copia de su determinante (los atributos de la clave primaria de los que
dependen).
Tercera forma normal (3FN)
Una relacin est en tercera forma normal si, y slo si, est en 2FN y, adems, cada atributo que
no est en la clave primaria no depende transitivamente de la clave primaria. La dependencia es
transitiva si existen las dependencias A
B, siendo A y B, atributos o conjuntos de atributos de
una misma relacin.
Aunque las relaciones en 2FN tienen menos redundancias que las relaciones en 1FN, todava
pueden sufrir anomalas frente a las actualizaciones. Para pasar una relacin de 2FN a 3FN hay
que eliminar las dependencias transitivas. Para ello, se eliminan los atributos que dependen
transitivamente y se ponen en una nueva relacin con una copia de su determinante (el atributo o
atributos no clave de los que dependen).
Forma normal de Boyce-Codd (BCFN)
Una relacin est en la forma normal de Boyce-Codd si, y slo si, todo determinante es una clave
candidata.
La 2FN y la 3FN eliminan las dependencias parciales y las dependencias transitivas de la clave
primaria. Pero este tipo de dependencias todava pueden existir sobre otras claves candidatas, si
stas existen. La BCFN es ms fuerte que la 3FN, por lo tanto, toda relacin en BCFN est en
3FN.
La violacin de la BCFN es poco frecuente ya que se da bajo ciertas condiciones que raramente
se presentan. Se debe comprobar si una relacin viola la BCFN si tiene dos o ms claves
candidatas compuestas que tienen al menos un atributo en comn
Ampliando con Ejemplos en cada una de las Formas Normales
Segn la definicin de Date de la 1FN, una tabla est en 1FN si y solo si es "isomorfa a alguna
relacin", lo que significa, especficamente, que satisface las siguientes cinco condiciones:
1. No hay orden de arriba-a-abajo en las filas.
2. No hay orden de izquierda-a-derecha en las columnas.
3. No hay filas duplicadas.
4. Cada interseccin de fila-y-columna contiene exactamente un valor del dominio aplicable
(y nada ms).
5. Todas las columnas son regulares (es decir, las filas no tienen componentes como IDs
de fila, IDs de objeto, o timestamps ocultos). (date,1998)
La violacin de cualquiera de estas condiciones significara que la tabla no es estrictamente
relacional, y por lo tanto no est en 1FN. Algunos ejemplos de tablas (o de vistas) que no satisface
esta definicin de 1FN son:

Materia: Base de Datos I

Profesor: Calixto Maldonado

-2-

Una tabla que carece de una clave primaria. Esta tabla podra acomodar filas
duplicadas, en violacin de la condicin 3.
Una vista cuya definicin exige que los resultados sean retornados en un orden
particular, de modo que el orden de la fila sea un aspecto intrnseco y
significativo de la vista. Esto viola la condicin Nro. 1. Las tuplas en relaciones
verdaderas no estn ordenadas una con respecto de la otra.
Una tabla con por lo menos un atributo que pueda ser nulo. Un atributo que
pueda ser nulo estara en violacin de la condicin 4, que requiere a cada
campo contener exactamente un valor de su dominio de columna. Sin embargo,
debe ser observado que este aspecto de la condicin 4 es controvertido. Muchos
autores consideran que una tabla est en 1FN si ninguna clave candidata puede
contener valores nulos, pero se aceptan stos para atributos (campos) que no
sean clave, segn el modelo original de Codd sobre el modelo relacional, el cual
hizo disposicin explcita para los nulos.

2. Grupos repetidos
La cuarta condicin de Date, que expresa "lo que la mayora de la gente piensa como la
caracterstica que define la 1FN", concierne a grupos repetidos. El siguiente ejemplo ilustra cmo
un diseo de base de datos puede incorporar la repeticin de grupos, en violacin de la 1NF.
2. 1. Ejemplo 1: Dominios y valores
Suponga que un diseador principiante desea guardar los nombres y los nmeros telefnicos de
los clientes. Procede a definir una tabla de cliente como la que sigue:
Cliente
ID Cliente Nombre Apellido

Telfono

123

Rachel Ingram

555-861-2025

456

James

Wright

555-403-1659
555-776-4100

789

Maria

Fernndez 555-808-9633

Figura 1 Tabla cliente

En este punto, el diseador se da cuenta de un requisito para guardar mltiples nmeros

telefnicos para algunos clientes. Razona que la manera ms simple de hacer esto es permitir que
el campo "Telfono" contenga ms de un valor en cualquier registro dado:
Asumiendo, sin embargo, que la columna "Telfono" est definida en algn tipo de dominio de
nmero telefnico (por ejemplo, el dominio de cadenas de 12 caracteres de longitud), la
representacin de arriba no est en 1FN. La 1FN (y, para esa materia, el RDBMS) prohbe a un
campo contener ms de un valor de su dominio de columna.

Materia: Base de Datos I

Profesor: Calixto Maldonado

-3-

2. 2. Ejemplo 2: Grupos repetidos a travs de columnas

El diseador puede evitar esta restriccin definiendo mltiples columnas del nmero telefnico:
Cliente
ID Cliente Nombre Apellido

Telfono 1

123

Osvaldo Ingram

555-861-2025

456

James

Wright

555-403-1659 555-776-4100

789

Mara

Fernndez 555-808-9633

Telfono 2

Telfono 3

Sin embargo, esta representacin hace uso de columnas que permiten valores nulos, y por lo
tanto no se conforman con la definicin de la 1NF de Date. Incluso si se contempla la posibilidad
de columnas con valores nulos, el diseo no est en armona con el espritu de 1NF. Telfono 1,
Telfono 2, y Telfono 3, comparten exactamente el mismo dominio y exactamente el mismo
significado; el dividir del nmero de telfono en tres encabezados es artificial y causa problemas
lgicos. Estos problemas incluyen:

Dificultad en hacer consultas a la tabla. Es difcil contestar preguntas tales como

"Qu clientes tienen el telfono X?" y "Qu pares de clientes comparten un
nmero de telfono?".
La imposibilidad de hacer cumplir la unicidad los enlaces Cliente-a-Telfono por
medio del RDBMS. Al cliente 789 se le puede dar equivocadamente un valor
para el Telfono 2 que es exactamente igual que el valor de su Telfono 1.
La restriccin de los nmeros de telfono por cliente a tres. Si viene un cliente
con cuatro nmeros de telfono, estamos obligados a guardar solamente tres y
dejar el cuarto sin guardar. Esto significa que el diseo de la base de datos est
imponiendo restricciones al proceso del negocio, en vez de (como idealmente
debe ser el caso) al revs.

2. 3. Ejemplo 3: Repeticin de grupos dentro de columnas

El diseador puede, alternativamente, conservar una sola columna de nmero de telfono, pero
alterando su dominio, haciendo una cadena de suficiente longitud para acomodar mltiples
nmeros telefnicos:
Cliente
ID Cliente Nombre Apellido Telfono
123
Rachel Ingram
555-861-2025
456
James Wright
555-403-1659, 555-776-4100
789
Maria Fernndez 555-808-9633
ste es el peor diseo de todos, y otra vez no mantiene el espritu de la 1NF. El encabezado
"Telfono" llega a ser semnticamente difuso, ya que ahora puede representar o un nmero de
telfono o una lista de nmeros de telfono o, de hecho, cualquier cosa. Una consulta como
"Qu pares de clientes comparten un nmero telefnico?" es virtualmente imposible de formular,
dada la necesidad de proveerse de listas de nmeros telefnicos as como nmeros telefnicos

Materia: Base de Datos I

Profesor: Calixto Maldonado

-4-

individuales. Con este diseo en la RDBMS, son tambin imposibles de definir significativas
restricciones en nmeros telefnicos.
2. 4. Un diseo conforme con 1FN
Un diseo que est inequvocamente en 1FN hace uso de dos tablas: una tabla de cliente y una
tabla de telfono del cliente.

Cliente
Cliente Nombre
Rachel
James
Maria

Cliente ID
123
456
789

Apellido
Ingram
Wright
Fernandez

Telfono del cliente

ID Cliente Telfono
123
555-861-2025
456
555-403-1659
456
555-776-4100
789
555-808-9633
En este diseo no ocurren grupos repetidos de nmeros telefnicos. En lugar de eso, cada enlace
Cliente-a-Telfono aparece en su propio registro.
3. Atomicidad
Algunas definiciones de 1NF, ms notablemente la de E.F. Codd [codd,1970], hacen referencia al
concepto de atomicidad. Codd indica que "se requiere que los valores sean atmicos con respecto
al DBMS en los dominios en los que cada relacin es definida". Codd define un valor atmico
como uno que "no puede ser descompuesto en pedazos ms pequeos por el DBMS (excepto
ciertas funciones especiales)".
Hugh Darwen y Chris Date [Date, 1998] han sugerido que el concepto de Codd de un "valor
atmico" es ambiguo, y que esta ambigedad ha conducido a una extensa confusin sobre cmo
debe ser entendida la 1NF. En particular, la nocin de un "valor que no puede ser descompuesto"
es problemtica, pues parecera implicar que pocos, si algn, tipos de datos son atmicos:

Una cadena de caracteres parecera no ser atmica, ya que el RDBMS tpicamente

proporciona operadores para descomponerla en subcadenas.
Una fecha parecera no ser atmica, ya que el RDBMS proporciona tpicamente operadores
para descomponerla los componentes de da, mes, y ao.
Un nmero de punto fijo parecera no ser atmico, ya que el RDBMS proporciona tpicamente
operadores para descomponerlo en componentes de nmeros enteros y fraccionarios.

4. Normalizacin ms all de la 1NF

Materia: Base de Datos I

Profesor: Calixto Maldonado

-5-

Cualquier tabla que est en la segunda forma normal (2NF) o ms arriba, tambin est, por
definicin, en 1NF (cada forma normal tiene criterios ms rigurosos que su precursor). Por una
parte, una tabla que est en 1NF puede o no puede estar en 2NF; si est en 2NF, puede o no
puede estar en 3NF, y as sucesivamente.
Las formas normales ms arriba que la 1NF son pensadas para ocuparse de las situaciones en
las que una tabla sufre de problemas de diseo que pueden comprometer la integridad de los
datos dentro de ella. Por ejemplo, la tabla siguiente est en 1NF, pero no est en 2NF y por lo
tanto es vulnerable a inconsistencias lgicas:

ID del subscriptor
108
252
252
360

Direccin de correo del subscriptor

Direccin de correo
nombre del
subscriptor
steve@aardvarkmail.net
Steve
carol@mongoosemail.org Carol
crobertson@hotmail.com Carol
hclark@antelopemail.com Harriet

nombre del
subscriptor
Wallace
Robertson
Hall
Clark

Figura 2. Direcciones de correo del subscriptor

La clave primaria de la tabla es {ID del subscriptor, Direccin de correo}.

Si Carol Robertson cambia su apellido (Robertson) por el de matrimonio (Hall), el cambio debe ser
aplicado a dos filas. Si el cambio es aplicado solamente a una fila, resulta en una contradiccin: la
pregunta "cul es nombre del cliente 252?" tiene dos respuestas que estn en conflicto. La 2NF
aborda este problema
La segunda forma normal (2NF) es una forma normal usada en normalizacin de bases de
datos. La 2NF definida originalmente por E.F. Codd en 1971. Una tabla que est en la primera
forma normal (1NF) debe satisfacer criterios adicionales para calificar para la segunda forma
normal. Especficamente: una tabla 1NF est en 2NF si y solo si, dada cualquier clave candidata y
cualquier atributo que no sea un constituyente de la clave candidata, el atributo no clave depende
de toda la clave candidata en vez de solo una parte de ella.
En trminos levemente ms formales: una tabla 1NF est en 2NF si y slo si ninguno de sus
atributos no-principales son funcionalmente dependientes en una parte (subconjunto apropiado)
de una clave candidata. (Un atributo no-principal es uno que no pertenece a ninguna clave
candidata).
Observe que cuando una tabla 1NF no tiene ninguna clave candidata compuesta (claves
candidatas consistiendo en ms de un atributo), la tabla est automticamente en 2NF.
1. Ejemplo
Considere una tabla describiendo las habilidades de los empleados:

Empleado (CP)

Habilidad (CP)

Lugar actual de
trabajo

Materia: Base de Datos I

Profesor: Calixto Maldonado

-6-

Jones
Jones
Jones
Bravo
Ellis
Ellis

Mecanografa
Taquigrafa
Tallado
Limpieza ligera
Alquimia
Malabarismo

114 Main Street

114 Main Street
114 Main Street
73 Industrial Way
73 Industrial Way
73 Industrial Way

Figura 3. Habilidades de los empleados

La clave primaria de la tabla es {Empleado, Habilidad}.

El atributo restante, Lugar actual de trabajo, es dependiente slo en parte de la clave candidata,
llamada Empleado. Por lo tanto la tabla no est en 2NF. Observe la redundancia de la manera en
que son representadas los Lugares actuales de trabajo: nos dicen tres veces que Jones trabaja en
la 114 Main Street, y dos veces que Ellis trabaja en 73 Industrial Way. Esta redundancia hace a la
tabla vulnerable a anomalas de actualizacin: por ejemplo, es posible actualizar el lugar del
trabajo de Jones en sus registros "Mecanografa" y "Taquigrafa" y no actualizar su registro
"Tallado". Los datos resultantes implicaran respuestas contradictorias a la pregunta "Cul es el
lugar actual de trabajo de Jones?".
Las anomalas de actualizacin no pueden ocurrir en estas tablas, las cuales estn en 2NF.
Sin embargo, no todas las tablas 2NF estn libres de anomalas de actualizacin. Un ejemplo de
una tabla 2NF que sufre de anomalas de actualizacin es:

Torneo

Ao

Ganadores del torneo

Ganador
Fecha de nacimiento del ganador

Des Moines Masters

Indiana Invitational
Cleveland Open
Des Moines Masters
Indiana Invitational

1998
1998
1999
1999
1999

Chip Masterson
Al Fredrickson
Bob Albertson
Al Fredrickson
Chip Masterson

14 de marzo de 1977
21 de julio de 1975
28 de octubre de 1968
21 de julio de 1975
14 de marzo de 1977

Figura 4. Tabla de Ganadores del Torneo

Aunque el Ganador y la Fecha de nacimiento del ganador estn determinadas por una clave
completa {Torneo, Ao} y no son partes de ella, particularmente las combinaciones Ganador /
Fecha de nacimiento del ganador son mostradas redundantemente en mltiples registros. Este
problema es tratado por la tercera forma normal (3NF).
Una tabla o relacin que tiene una clave primaria simple, est en 2FN, por no poder existir una
dependencia parcial con parte de la clave, por que sta tiene un solo atributo o columna.
Por lo que en tablas donde la clave primaria es compuesta es necesario realizar el anlisis de que
los atributos no clave dependan de toda la clave primaria compuesta.

Materia: Base de Datos I

Profesor: Calixto Maldonado

-7-

La tercera forma normal (3NF) es una forma normal usada en la normalizacin de bases de
datos. La 3NF fue definida originalmente por E.F. Codd en 1971. La definicin de Codd indica que
una tabla est en 3NF si y slo si las dos condiciones siguientes se mantienen:

La tabla est en la segunda forma normal (2NF)

Ningn atributo no-primario de la tabla es dependiente transitivamente de una clave
candidata

Un atributo no-primario es un atributo que no pertenece a ninguna clave candidata. Una

dependencia transitiva es una dependencia funcional X Z en la cual Z no es inmediatamente
dependiente de X, pero s de un tercer conjunto de atributos Y, que a su vez depende de X. Es
decir, X Z por virtud de X Y y Y Z.
"Nada excepto la clave"
Un memorable resumen de la definicin de Codd de la 3NF, siendo paralelo al compromiso
tradicional de dar evidencia verdadera en un tribunal de justicia, fue dado por Bill Kent: cada
atributo no-clave "debe proporcionar un hecho sobre la clave, la clave entera, y nada ms excepto
la clave".Una variacin comn complementa esta definicin con el juramento: "con la ayuda de
Codd".
Requerir que los atributos no-clave sean dependientes en la clave completa asegura que una
tabla est en 2NF; un requerimiento posterior que los atributos no-clave sean dependientes de
nada excepto la clave asegura que la tabla est en 3NF.
Chris Date refiere al resumen de Kent como "una intuitiva atractiva caracterizacin" de la 3NF, y
observa que con una ligera adaptacin puede servir como definicin ligeramente ms fuerte de la
forma normal de Boyce-Codd: "Cada atributo debe representar un hecho acerca de la clave, la
clave entera, y nada excepto la clave". [5] La versin 3NF de la definicin es ms dbil que la
variacin de BCNF de Date, pues el anterior se refiere solamente a asegurarse de que los
atributos no-clave son dependientes en las claves. [Date, 1998].
2. Ejemplo
Un ejemplo de una tabla 2NF que falla en satisfacer los requerimientos de la 3NF es:

Torneo

Ao

Ganadores del torneo

Ganador
Fecha de nacimiento del ganador

Indiana Invitational
Cleveland Open
Des
Moines
Masters
Indiana Invitational

1998
1999
1999

Al Fredrickson
Bob Albertson
Al Fredrickson

21 de julio de 1975
28 de octubre de 1968
21 de julio de 1975

1999

Chip Masterson

14 de marzo de 1977

Figura 4. Tabla de Ganadores del Torneo

Materia: Base de Datos I

Profesor: Calixto Maldonado

-8-

La clave primaria es {Torneo, Ao}.

La violacin de la 3NF ocurre porque el atributo no primario Fecha de nacimiento del ganador es
dependiente transitivamente de {Torneo, Ao} va el atributo no primario Ganador. El hecho de
que la Fecha de nacimiento del ganador es funcionalmente dependiente en el Ganador hace la
tabla vulnerable a inconsistencias lgicas, pues no hay nada que impida a la misma persona ser
mostrada con diferentes fechas de nacimiento en diversos registros.
Para expresar los mismos hechos sin violar la 3NF, es necesario dividir la tabla en dos:

Ganadores del torneo

Ao

Torneo
Indiana Invitational
Cleveland Open
Des Moines Masters
Indiana Invitational

Ganador

1998
1999
1999
1999

Al Fredrickson
Bob Albertson
Al Fredrickson
Chip Masterson

Informacin del jugador

Jugador

Fecha de nacimiento

Chip Masterson 14 de marzo de 1977

Al Fredrickson

21 julio de 1975

Bob Albertson

28 septiembre de 1968

Las anomalas de actualizacin no pueden ocurrir en estas tablas, las cuales estn en 3NF.
3. Normalizacin ms all de la 3NF
La mayora de las tablas 3NF estn libres anomalas de actualizacin, insercin, y borrado.
Ciertos tipos de tablas 3NF, que en la prctica raramente se encuentran, son afectadas por tales
anomalas; stas son tablas que no satisfacen la forma normal de Boyce-Codd (BCNF) o, si
satisfacen la BCNF, son insuficientes para satisfacer las formas normales ms altas 4NF o 5NF.

Ejemplo paso a paso

Digamos que queremos crear una tabla con la informacin de usuarios, y los datos a guardar son
el nombre, la empresa, la direccin de la empresa y algn e-mail, o bien URL si las tienen. En
principio se encuentra en una situacin como la siguiente definiendo la estructura de una tabla
como esta:

Materia: Base de Datos I

Profesor: Calixto Maldonado

-9-

Normalizacin CERO
Usuarios
nombre

empresa

direccin _ empresa

url1

url2

Joe

ABC

1 Work Lane

abc.com

xyz.com

Jill

XYZ

1 Job Street

abc.com

xyz.com

Tabla 1. Sin forma normal

Diramos que la anterior tabla esta en nivel de Normalizacin Cero porque ninguna de nuestras
reglas de normalizacin ha sido aplicada. Observa los campos url1 y url2 Qu haremos cuando
en nuestra aplicacin necesitemos una tercera url? Quieres tener que aadir otro
campo/columna a tu tabla y tener que reprogramar toda la entrada de datos de tu cdigo PHP? Se
quiere crear un sistema funcional que pueda crecer y adaptarse fcilmente a los nuevos
requisitos. Aplicaremos las reglas del Primer Nivel de Formalizacin-Normalizacin.
Primera Forma Normal (F/N)
1. Eliminar los grupos repetitivos de las tablas.
2. Crear una tabla separada por cada grupo de datos relacionados.
3. Identificar cada grupo de datos relacionados con una clave primaria.
Es notable que la tabla esta rompiendo la primera regla cuando repetimos los campos url1 y url2 ?
Y que pasa con la tercera regla, la clave primaria? Las columnas definidas no permiten
identificar cada fila, porque Qu pasara si tuviramos dos usuarios llamados Joe y queremos
diferenciarlos? Para este problema se puede definir una clave artificial que se puede implementar
en los motores de base de datos con un campo auto incrementable o con el uso de un objeto
secuencia. Veamos como qued la tabla:
Usuarios
direccin _ empresa

userId

Nombre

empresa

url

Joe

ABC

1 Work Lane

abc.com

Joe

ABC

1 Work Lane

xyz.com

Jill

XYZ

1 Job Street

abc.com

Jill

XYZ

1 Job Street

xyz.com

Tabla 2. Primera forma normal

Ahora diremos que nuestra tabla est en el primer nivel de F/N. Hemos solucionado el problema
de la limitacin del campo url. Pero sin embargo vemos otros problemas....Cada vez que
introducimos un nuevo registro en la tabla usuarios, tenemos que duplicar el nombre de la
empresa y del usuario. No slo nuestra BD crecer muchsimo, sino que ser muy fcil que la BD

Materia: Base de Datos I

Profesor: Calixto Maldonado

- 10 -

se corrompa si escribimos mal alguno de los datos redundantes. Aplicaremos pues la segunda
Forma Normal:
Segunda Forma Normal
1. Crear una tabla aparte con los datos repetitivos
2. Relacionar estas tablas mediante una clave externa.
Hemos separado el campo url en otra tabla, de forma que podemos aadir ms en el futuro si
tener que duplicar los dems datos. Tambin vamos a usar nuestra clave primaria para relacionar
estos campos:
Usuarios
userId

nombre

Empresa

direccin _ empresa

Joe

ABC

1 Work Lane

Jill

XYZ

1 Job Street

Urls
urlid

relUserId

url

abc.com

xyz.com

abc.com

xyz.com

Tabla 3. Segunda forma normal

Hemos creado tablas separadas y la clave primaria en la tabla usuarios, userId, esta
relacionada ahora con la clave fornea en la tabla urls, relUserId.
Se agrega una columna que numera las relaciones usuarios y url, llamada urlid que
tambin puede implementarse con una secuencia. Pero que ocurre cuando queremos
aadir otro empleado a la empresa ABC? O 200 empleados? Ahora tenemos el nombre
de la empresa y su direccin duplicndose, otra situacin que puede inducirnos a introducir
errores en nuestros datos. As que tendremos que aplicar el tercer nivel de F/N:
Tercer nivel de F/N.
1. Crear otra tabla y llevar a aquellos campos que no dependan de la clave.
Nuestro nombre de empresa y su direccin no tienen nada que ver con el campo userId,
as que tienen que tener su propio empresaId:

Materia: Base de Datos I

Profesor: Calixto Maldonado

- 11 -

Usuarios
userId

Nombre

relEmpresaId

Joe

Jill

2
Empresas

emprId

empresa

direccin _ empresa

ABC

1 Work Lane

XYZ

1 Job Street
Urls

Urlid

relUserId

url

abc.com

xyz.com

abc.com

xyz.com

Tabla 4. Tercera forma normal

Ahora tenemos la clave primaria emprId, en la tabla empresas, relacionada con la clave
externa recEmpresaId en la tabla usuarios, y podemos aadir 200 usuarios mientras que
slo tenemos que insertar el nombre 'ABC' una vez. Nuestras tablas de usuarios y urls
pueden crecer todo lo que quieran sin duplicacin ni corrupcin de datos. Es normalmente
aceptado que el tercer nivel de Forma Normal es suficiente. (Font, 2009)

RESUMEN
En la tabla siguiente se describe brevemente cada una de las reglas
Regla

Descripcin

Primera Forma Normal (1FN)

Incluye la eliminacin de todos los grupos repetidos.

Segunda Forma Normal (2FN)

Asegura que todas las columnas que no son clave

sean completamente dependientes de la clave
primaria (PK).

Tercera Forma Normal (3FN)

Elimina cualquier dependencia transitiva. Una

dependencia transitiva es aquella en la cual las
columnas que no son clave son dependientes de
otras columnas que tampoco son clave.

Materia: Base de Datos I

Profesor: Calixto Maldonado

- 12 -

Referencias Bibliogrficas
[codd,1970] [codd,1970] Comunications of ACM Vol. 13, Number 6 Pagina377 Junio 1970 Ver
tambin www.seas.upenn.edu/~zives/03f/cis550/codd.pdf
[Date, 1998] Date, Chris, Introduccin a los Sistemas de Base de Datos. - DATE - Quinta y
Septima - 1998 - addison-wesley - Mexico

[Font, 2009] Normalizacin de Bases de Datos y Tcnicas de diseo ( Por Barry Wise)Traducido
por. J.M.Font http://www.lawebdelprogramador.com/temas/tecdiseno.php - visitado en Septiembre
2009
[Grayson, 2002] Thomas H. Grayson - Diseo de bases de datos relacionales: principios bsicos
de diseo 23 de enero de 2002
[mysql,
2009]
Normalizacin
de
bases
de
hispano.org/page.php?id=16&pag=1 - Visitado Agosto 2009

datos

http://www.mysql-

[wap,2009] Wiki: Normalizacin de bases de datos - Enciclopedia para

http://wapedia.mobi/es/Normalizacion_de_bases_de_datos - Visitado Agosto 2009

Materia: Base de Datos I

Profesor: Calixto Maldonado

celulares

- 13 -