Ejemplo

Práctico

Base de Datos I

1
Normalización
La normalización es una técnica para diseñar la estructura lógica de los datos de un
sistema de información en el modelo relacional, desarrollada por E. F. Codd en
1972. Las ventajas de la normalización son las siguientes:

• Evita anomalías en inserciones, modificaciones y borrados.

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

En el proceso de normalización se debe ir comprobando que cada relación (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 normalización. Si una
regla no se cumple, la relación se debe descomponer en varias relaciones que sí la
cumplan.

La normalización 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
normalización, las relaciones tienen un formato más estricto (más fuerte) y, por lo
tanto, son menos vulnerables a las anomalías de actualización. El modelo relacional
sólo 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 relación está en primera forma normal si y sólo si, todos los dominios de la
misma contienen valores atómicos, es decir, no hay grupos repetitivos. Si se ve la
relación gráficamente como una tabla, estará en 1FN si tiene un solo valor en la
intersección de cada fila con cada columna.

Si una relación no está en 1FN, hay que eliminar de ella los grupos repetitivos. Un
grupo repetitivo será el atributo o grupo de atributos que tiene múltiples valores
para cada tupla de la relación. 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 eliminarán después mediante las restantes formas
normales. La segunda forma de eliminar los grupos repetitivos consiste en poner
cada uno de ellos en una relación aparte, heredando la clave primaria de la relación
en la que se encontraban.

Un conjunto de relaciones se encuentra en 1FN si ninguna de ellas tiene grupos

repetitivos.

2
Segunda forma normal (2FN)

Una relación está en segunda forma normal si, y sólo si, está en 1FN y, además,
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
más atributos. Si una relación está en 1FN y su clave primaria es simple (tiene un
solo atributo), entonces también está en 2FN. Las relaciones que no están en 2FN
pueden sufrir anomalías cuando se realizan actualizaciones.

Para pasar una relación 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 relación con una copia de su determinante
(los atributos de la clave primaria de los que dependen).

Tercera forma normal (3FN)

Una relación está en tercera forma normal si, y sólo si, está en 2FN y, además, 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 relación.

Aunque las relaciones en 2FN tienen menos redundancias que las relaciones en
1FN, todavía pueden sufrir anomalías frente a las actualizaciones. Para pasar una
relación 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
relación con una copia de su determinante (el atributo o atributos no clave de los
que dependen).

Forma normal de Boyce-Codd (BCFN)

Una relación está en la forma normal de Boyce-Codd si, y sólo 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 todavía pueden existir sobre
otras claves candidatas, si éstas existen. La BCFN es más fuerte que la 3FN, por lo
tanto, toda relación en BCFN está en 3FN.

La violación de la BCFN es poco frecuente ya que se da bajo ciertas condiciones que

raramente se presentan. Se debe comprobar si una relación viola la BCFN si tiene
dos o más claves candidatas compuestas que tienen al menos un atributo en común

3
Ampliando con Ejemplos en cada una de las Formas Normales

Según la definición de Date de la 1FN, una tabla está en 1FN “si y solo si” es
"isomorfa” a alguna relación", lo que significa, específicamente, 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 intersección de fila-y-columna contiene exactamente un valor del
dominio aplicable (y nada más).
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 violación de cualquiera de estas condiciones significaría 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 definición de 1FN son:

• Una tabla que carece de una clave primaria. Esta tabla podría
acomodar filas duplicadas, en violación de la condición 3.
• Una vista cuya definición exige que los resultados sean
retornados en un orden particular, de modo que el orden de la
fila sea un aspecto intrínseco y significativo de la vista. Esto viola
la condición Nro. 1. Las tuplas en relaciones verdaderas no están
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 estaría en violación de la condición
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 condición 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, según el modelo original
de Codd sobre el modelo relacional, el cual hizo disposición
explícita para los nulos.

Grupos repetidos

La cuarta condición de Date, que expresa "lo que la mayoría de la gente piensa
como la característica que define la 1FN", concierne a grupos repetidos. El siguiente
ejemplo ilustra cómo un diseño de base de datos puede incorporar la repetición de
grupos, en violación de la 1NF.

Ejemplo 1: Dominios y valores

4
Suponga que un diseñador principiante desea guardar los nombres y los números
telefónicos de los clientes. Procede a definir una tabla de cliente como la que sigue:

Cliente
ID Cliente Nombre Apellido Teléfono
123 Rachel Ingram 555-861-2025
456 James Wright 555-403-1659
555-776-4100
789 Maria Fernández 555-808-9633

Figura 1 Tabla cliente

En este punto, el diseñador se da cuenta de un requisito para guardar múltiples

números telefónicos para algunos clientes. Razona que la manera más simple de
hacer esto es permitir que el campo "Teléfono" contenga más de un valor en
cualquier registro dado:

Asumiendo, sin embargo, que la columna "Teléfono" está definida en algún tipo de
dominio de número telefónico (por ejemplo, el dominio de cadenas de 12
caracteres de longitud), la representación de arriba no está en 1FN. La 1FN (y, para
esa materia, el RDBMS) prohíbe a un campo contener más de un valor de su
dominio de columna.

Ejemplo 2: Grupos repetidos a través de columnas

El diseñador puede evitar esta restricción definiendo múltiples columnas del

número telefónico:

Cliente
ID Cliente Nombre Apellido Teléfono 1 Teléfono 2 Teléfono 3
123 Osvaldo Ingram 555-861-2025

456 James Wright 555-403-1659 555-776-4100

789 María Fernández 555-808-9633

Sin embargo, esta representación hace uso de columnas que permiten valores
nulos, y por lo tanto no se conforman con la definición de la 1NF de Date. Incluso si
se contempla la posibilidad de columnas con valores nulos, el diseño no está en

5
armonía con el espíritu de 1NF. Teléfono 1, Teléfono 2, y Teléfono 3, comparten
exactamente el mismo dominio y exactamente el mismo significado; el dividir del
número de teléfono en tres encabezados es artificial y causa problemas lógicos.
Estos problemas incluyen:

• Dificultad en hacer consultas a la tabla. Es difícil contestar

preguntas tales como "¿Qué clientes tienen el teléfono X?" y
"¿Qué pares de clientes comparten un número de teléfono?".
• La imposibilidad de hacer cumplir la unicidad los enlaces Cliente-
a-Teléfono por medio del RDBMS. Al cliente 789 se le puede dar
equivocadamente un valor para el Teléfono 2 que es
exactamente igual que el valor de su Teléfono 1.
• La restricción de los números de teléfono por cliente a tres. Si
viene un cliente con cuatro números de teléfono, estamos
obligados a guardar solamente tres y dejar el cuarto sin guardar.
Esto significa que el diseño de la base de datos está imponiendo
restricciones al proceso del negocio, en vez de (como idealmente
debe ser el caso) al revés.

Ejemplo 3: Repetición de grupos dentro de columnas

El diseñador puede, alternativamente, conservar una sola columna de número

de teléfono, pero alterando su dominio, haciendo una cadena de suficiente
longitud para acomodar múltiples números telefónicos:

Cliente
ID Cliente Nombre Apellido Teléfono
123 Rachel Ingram 555-861-2025
456 James Wright 555-403-1659, 555-776-4100
789 Maria Fernández 555-808-9633

Éste es el peor diseño de todos, y otra vez no mantiene el espíritu de la 1NF. El

encabezado "Teléfono" llega a ser semánticamente difuso, ya que ahora puede
representar o un número de teléfono o una lista de números de teléfono o, de
hecho, cualquier cosa. Una consulta como "¿Qué pares de clientes comparten un
número telefónico?" es virtualmente imposible de formular, dada la necesidad de
proveerse de listas de números telefónicos así como números telefónicos
individuales. Con este diseño en la RDBMS, son también imposibles de definir
significativas restricciones en números telefónicos.

Un diseño conforme con 1FN

Un diseño que está inequívocamente en 1FN hace uso de dos tablas: una tabla de
cliente y una tabla de teléfono del cliente.

6
 Cliente

Cliente ID Cliente Nombre Apellido

123 Rachel Ingram
456 James Wright
789 Maria Fernandez

Teléfono del cliente

ID Cliente Teléfono
123
456 555-403-1659
456
789 555-808-9633
En este diseño no ocurren grupos repetidos de números telefónicos. En lugar de
eso, cada enlace Cliente-a-Teléfono aparece en su propio registro.

Atomicidad

Algunas definiciones de 1NF, más notablemente la de E.F. Codd [codd,1970], hacen

referencia al concepto de atomicidad. Codd indica que "se requiere que los valores
sean atómicos con respecto al DBMS en los dominios en los que cada relación es
definida". Codd define un valor atómico como uno que "no puede ser
descompuesto en pedazos más pequeños por el DBMS (excepto ciertas funciones
especiales)".

Hugh Darwen y Chris Date [Date, 1998] han sugerido que el concepto de Codd de
un "valor atómico" es ambiguo, y que esta ambigüedad ha conducido a una extensa
confusión sobre cómo debe ser entendida la 1NF. En particular, la noción de un
"valor que no puede ser descompuesto" es problemática, pues parecería implicar
que pocos, si algún, tipos de datos son atómicos:

• Una cadena de caracteres parecería no ser atómica, ya que el RDBMS

típicamente proporciona operadores para descomponerla en subcadenas.
• Una fecha parecería no ser atómica, ya que el RDBMS proporciona típicamente
operadores para descomponerla los componentes de día, mes, y año.
• Un número de punto fijo parecería no ser atómico, ya que el RDBMS
proporciona típicamente operadores para descomponerlo en componentes de
números enteros y fraccionarios.

Normalización más allá de la 1NF

7
Cualquier tabla que esté en la segunda forma normal (2NF) o más arriba, también
está, por definición, en 1NF (cada forma normal tiene criterios más 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 más arriba que la 1NF son pensadas para ocuparse de las
situaciones en las que una tabla sufre de problemas de diseño 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 lógicas:
Dirección de correo del subscriptor

ID del subscriptor Dirección de correo nombre del nombre del

subscriptor subscriptor
108 [email protected] Steve Wallace
252 [email protected] Carol Robertson
252 [email protected] Carol Hall
360 [email protected] Harriet Clark

Figura 2. Direcciones de correo del subscriptor

La clave primaria de la tabla es {ID del subscriptor, Dirección 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 contradicción: la pregunta "cuál es nombre del cliente 252?" tiene
dos respuestas que están en conflicto. La 2NF aborda este problema

La segunda forma normal (2NF) es una forma normal usada en normalización 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. Específicamente: 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 términos levemente más formales: una tabla 1NF está en 2NF si y sólo 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 más de un atributo), la tabla está
automáticamente en 2NF.

8
Ejemplo

Considere una tabla describiendo las habilidades de los empleados:

Empleado (CP) Habilidad (CP) Lugar actual de

trabajo
Jones Mecanografía 114 Main Street
Jones Taquigrafía 114 Main Street
Jones Tallado 114 Main Street
Bravo Limpieza ligera 73 Industrial Way
Ellis Alquimia 73 Industrial Way
Ellis Malabarismo 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 sólo 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 anomalías de actualización: por ejemplo, es posible actualizar el lugar del trabajo
de Jones en sus registros "Mecanografía" y "Taquigrafía" y no actualizar su registro
"Tallado". Los datos resultantes implicarían respuestas contradictorias a la
pregunta "¿Cuál es el lugar actual de trabajo de Jones?".

Las anomalías de actualización no pueden ocurrir en estas tablas, las cuales están
en 2NF.

Sin embargo, no todas las tablas 2NF están libres de anomalías de actualización. Un
ejemplo de una tabla 2NF que sufre de anomalías de actualización es:
Ganadores del torneo

Torneo Año Ganador Fecha de nacimiento del ganador

Des Moines Masters 1998 Chip Masterson 14 de marzo de 1977

Indiana Invitational 1998 Al Fredrickson 21 de julio de 1975
Cleveland Open 1999 Bob Albertson 28 de octubre de 1968
Des Moines Masters 1999 Al Fredrickson 21 de julio de 1975
Indiana Invitational 1999 Chip Masterson 14 de marzo de 1977

9
Figura 4. Tabla de Ganadores del Torneo

Aunque el Ganador y la Fecha de nacimiento del ganador están determinadas por

una clave completa {Torneo, Año} y no son partes de ella, particularmente las
combinaciones Ganador / Fecha de nacimiento del ganador son mostradas
redundantemente en múltiples registros. Este problema es tratado por la tercera
forma normal (3NF).

Una tabla o relación 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

análisis de que los atributos no clave dependan de toda la clave primaria
compuesta.

La tercera forma normal (3NF) es una forma normal usada en la normalización de

bases de datos. La 3NF fue definida originalmente por E.F. Codd en 1971. La
definición de Codd indica que una tabla está en 3NF si y sólo si las dos condiciones
siguientes se mantienen:

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

• Ningún 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 definición 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 más excepto la clave".Una variación común
complementa esta definición 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 caracterización"
de la 3NF, y observa que con una ligera adaptación puede servir como definición

10
ligeramente más 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 versión 3NF de la definición es más débil que la variación 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].

Ejemplo

Un ejemplo de una tabla 2NF que falla en satisfacer los requerimientos de la 3NF
es:

Ganadores del torneo

Torneo Año Ganador Fecha de nacimiento del ganador

Indiana Invitational 1998 Al Fredrickson 21 de julio de 1975

Cleveland Open 1999 Bob Albertson 28 de octubre de 1968
Des Moines 1999 Al Fredrickson 21 de julio de 1975
Masters
Indiana Invitational 1999 Chip Masterson 14 de marzo de 1977

Figura 4. Tabla de Ganadores del Torneo

La clave primaria es {Torneo, Año}.

La violación de la 3NF ocurre porque el atributo no primario Fecha de nacimiento

del ganador es dependiente transitivamente de {Torneo, Año} vía 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 lógicas, 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

Torneo Año Ganador

Indiana Invitational 1998 Al Fredrickson

11
Cleveland Open 1999 Bob Albertson
Des Moines Masters 1999 Al Fredrickson
Indiana Invitational 1999 Chip Masterson

Información 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 anomalías de actualización no pueden ocurrir en estas tablas, las cuales están
en 3NF.

Normalización más allá de la 3NF

La mayoría de las tablas 3NF están libres anomalías de actualización, inserción, y

borrado. Ciertos tipos de tablas 3NF, que en la práctica raramente se encuentran,
son afectadas por tales anomalías; é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 más altas 4NF o 5NF.

Ejemplo paso a paso

Digamos que queremos crear una tabla con la información de usuarios, y los datos
a guardar son el nombre, la empresa, la dirección de la empresa y algún e-mail, o
bien URL si las tienen. En principio se encuentra en una situación como la siguiente
definiendo la estructura de una tabla como esta:

Normalización CERO

Usuarios

nombre empresa dirección _ empresa url1 url2

Joe ABC 1 Work Lane abc.com xyz.com

Jill XYZ 1 Job Street abc.com xyz.com

12
Tabla 1. Sin forma normal

Diríamos que la anterior tabla esta en nivel de Normalización Cero porque ninguna
de nuestras reglas de normalización ha sido aplicada. Observa los campos url1 y
url2 ¿Qué haremos cuando en nuestra aplicación necesitemos una tercera url?
¿Quieres tener que añadir otro campo/columna a tu tabla y tener que reprogramar
toda la entrada de datos de tu código PHP? Se quiere crear un sistema funcional
que pueda crecer y adaptarse fácilmente a los nuevos requisitos. Aplicaremos las
reglas del Primer Nivel de Formalización-Normalización.

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é pasaría si
tuviéramos 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

dirección _ empresa
userId Nombre empresa url

1 Joe ABC 1 Work Lane abc.com

1 Joe ABC 1 Work Lane xyz.com

2 Jill XYZ 1 Job Street abc.com

2 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 limitación 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 sólo nuestra BD
crecerá muchísimo, sino que será muy fácil que la BD se corrompa si escribimos
mal alguno de los datos redundantes. Aplicaremos pues la segunda Forma Normal:

13
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 añadir más en
el futuro si tener que duplicar los demás datos. También vamos a usar nuestra clave
primaria para relacionar estos campos:
Usuarios

userId nombre Empresa dirección _ empresa

1 Joe ABC 1 Work Lane

2 Jill XYZ 1 Job Street

Urls

urlid url

relUserId

1 1 abc.com

2 2 xyz.com

3 1 abc.com

4 2 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 foránea en la tabla urls,
relUserId.

Se agrega una columna que numera las relaciones usuarios y url, llamada
urlid que también puede implementarse con una secuencia. ¿Pero que
ocurre cuando queremos añadir otro empleado a la empresa ABC? ¿O 200
empleados? Ahora tenemos el nombre de la empresa y su dirección
duplicándose, otra situación 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.

14
 Nuestro nombre de empresa y su dirección no tienen nada que ver con el
campo userId, así que tienen que tener su propio empresaId:

Usuarios

userId Nombre relEmpresaId

1 Joe 1

2 Jill 2

Empresas

emprId empresa dirección _ empresa

1 ABC 1 Work Lane

2 XYZ 1 Job Street

Urls

Urlid url

relUserId
1 1 abc.com

2 1 xyz.com

3 2 abc.com

4 2 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 añadir
200 usuarios mientras que sólo tenemos que insertar el nombre 'ABC' una
vez. Nuestras tablas de usuarios y urls pueden crecer todo lo que quieran
sin duplicación ni corrupción 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 Descripción

15
Primera Forma Normal (1FN) Incluye la eliminación de todos los grupos repetidos.

Asegura que todas las columnas que no son clave sean

Segunda Forma Normal (2FN) completamente dependientes de la clave primaria
(PK).
Elimina cualquier dependencia transitiva. Una
dependencia transitiva es aquella en la cual las
Tercera Forma Normal (3FN)
columnas que no son clave son dependientes de otras
columnas que tampoco son clave.

16
Referencias Bibliográficas
[Date, 1998] Date, Chris, Introducción a los Sistemas de Base de Datos. - DATE -
Quinta y Septima - 1998 - addison-wesley - Mexico

[Font, 2009] Normalización de Bases de Datos y Técnicas de diseño ( Por Barry

Wise)Traducido por. J.M.Font
http://www.lawebdelprogramador.com/temas/tecdiseno.php - visitado en
Septiembre 2009

17