C.B.T.i.

s 243
Especialidad:
Ofimtica
Grupo: A
5to Semestre
Tema:
Las 3 formas normales para aplicar en un diseo
de BD
Docente:
Cornelio Alberto Prez Mndez
Nombre:
Jos Espnola Lpez Morales
23/de Septiembre/2015

INTRODUCCIN
Este trabajo est concebido para ser un seminario muy breve dirigido a los
principiantes que quieren conseguir un dominio conceptual del proceso de
normalizacin de bases de datos. Para demostrar los importantes principios
tratados, tomaremos el clsico ejemplo de una Factura y la llevaremos hasta la
Tercera Forma Normal. Tambin construiremos, por el camino, un Modelo
Entidad - Relacin de la Base de Datos (BD)
Para empezar: Primero, memorice las 3 formas normales de tal forma que pueda
recitarlas cuando duerma. El significado se ir aclarando por el camino. Solo
memoricemos por ahora:
1. No elementos repetidos o grupos de elementos 2. Sin dependencias
parciales de llaves concatenadas
3. Sin dependencias de atributos que no son llaves

Normalizacin de bases 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 entidadrelacin al modelo 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.

Figura 1.0: Trabajo (Cdigo, Nombre, Posicin, Salario), donde Cdigo es la

Clave Primaria.

Relacin = tabla o archivo

Registro = registro, fila , rengln o tupla
Atributo = columna o campo
Clave = llave o cdigo de identificacin
Clave Candidata = superclave mnima
Clave Primaria = clave candidata elegida
Clave Ajena (o fornea) = clave externa o clave fornea
Clave Alternativa = clave secundaria
Dependencia Multivaluada = dependencia multivalor
RDBMS = Del ingls Relational Data Base Manager System que
significa, Sistema Gestor de Bases de Datos Relacionales.
1FN = Significa, Primera Forma Normal o 1NF del ingls First Normal
Form.

Los trminos Relacin, Tupla y Atributo derivan del lgebra y clculo relacional,
que constituyen la fuente terica del modelo de base de datos relacional.

LAS 3 FORMAS NORMALES PARA APLICAR EN UN DISEO DE

BD
Primera forma normal (1FN)
Definicin: Para que una base de datos sea 1FN, es decir, que cumpla la primera
forma normal, cada columna debe ser atmica.
Atmica significa "indivisible", es decir, cada atributo debe contener un
nico valor del dominio. Los atributos, en cada tabla de una base de datos
1FN, no pueden tener listas o arrays de valores, ya sean del mismo
dominio o de dominios diferentes.
Adems, cada atributo debe tener un nombre nico. Esto es algo que en
general, al menos trabajando con MySQL, no nos preocupa; ya que la
creacin de las tablas implica definir cada columna de un tipo concreto y
con un nombre nico.
Tampoco pueden existir tuplas idnticas. Esto puede parecer obvio, pero
no siempre es as. Supongamos una base de datos para la gestin de la
biblioteca, y que el mismo da, y al mismo socio, se le presta dos veces el
mismo libro (evidentemente, el libro es devuelto entre cada prstamo,
claro). Esto producir, si no tenemos cuidado, dos registros iguales.
Debemos evitar este tipo de situaciones, por ejemplo, aadiendo un
atributo con un identificador nico de prstamo.
Como vemos, las restricciones de la primera forma normal coinciden con
las condiciones de las relaciones de una base de datos relacional, por lo
tanto, siempre es obligatorio aplicar esta forma normal.
Aplicar la primera forma normal es muy simple, bastar con dividir cada
columna no atmica en tantas columnas atmicas como sea necesario.
Por ejemplo, si tenemos una relacin que contiene la informacin de una
agenda de amigos con este esquema:

Agenda (Nombre, email)

El nombre, normalmente, estar compuesto por el tratamiento (seor, seora,

don, doa, excelencia, alteza, seora, etc.), un nombre de pila y los apellidos.
Podramos considerar el nombre como un dato atmico, pero puede interesarnos
separar algunas de las partes que lo componen.
Y qu pasa con la direccin de correo electrnico? Tambin podemos
considerar que es un valor no atmico, la parte a la izquierda del smbolo @ es
el usuario, y a la derecha el dominio.

De nuevo, dependiendo de las necesidades del cliente o del uso de los datos,
podemos estar interesados en dividir este campo en dos, o incluso en tres partes
(puede interesar separar la parte a la derecha del punto en el dominio).
Tanto en esta forma normal, como en las prximas que veremos, es
importante no llevar el proceso de normalizacin demasiado lejos. Se trata
de facilitar el trabajo y evitar problemas de redundancia e integridad, y no
de lo contrario. Debemos considerar las ventajas o necesidades de aplicar
cada norma en cada caso, y no excedernos por intentar aplicar las normas
demasiado al pi de la letra.
El esquema de la relacin puede quedar como sigue:

Agenda (Nombre Tratamiento, Nombre Pila, Nombre Apellidos, email)

Otro caso frecuente de relaciones que no cumplen 1FN es cuando existen
atributos multivariados, si todos los valores se agrupan en un nico
atributo:
Libros (Titulo, autores, fecha, editorial)
Hemos previsto, muy astutamente, que un libro puede tener varios
autores. No es que sea muy frecuente pero sucede, y ms con libros
tcnicos y libros de texto.
Sin embargo, esta relacin no es 1FN, ya que en la columna de autores
slo debe existir un valor del dominio, por lo tanto debemos convertir ese
atributo en uno multivariado:
Libros
Titulo
autor fecha
editorial
Qu bueno es MySQL fulano 12/10/2003 La buena
Qu bueno es MySQL mengano 12/10/2003 La buena
Catstrofes naturales tulano 18/03/1998 Pentriga

Segunda forma normal (2FN)

Definicin: Para que una base de datos sea 2FN primero debe ser 1FN, y
adems todas las columnas que formen parte de una clave candidata deben
aportar informacin sobre la clave completa.
Esta regla significa que en una relacin slo se debe almacenar
informacin sobre un tipo de entidad, y se traduce en que los atributos
que no aporten informacin directa sobre la clave principal deben
almacenarse en una relacin separada.
Lo primero que necesitamos para aplicar esta forma normal es identificar
las claves candidatas.
Adems, podemos elegir una clave principal, que abreviaremos como PK,
las iniciales de Primary Key. Pero esto es optativo, el modelo relacional
no obliga a elegir una clave principal para cada relacin, sino tan slo a la
existencia de al menos una clave candidata.
o La inexistencia de claves candidatas implica que la relacin no cumple
todas las normas para ser parte de una base de datos relacional, ya que
la no existencia de claves implica la repeticin de tuplas.

o En general, si no existe un candidato claro para la clave principal,

crearemos una columna especfica con ese propsito.

o Veamos cmo aplicar esta regla usando un ejemplo. En este caso

trataremos de guardar datos relacionados con la administracin de un
hotel.
o Planteemos, por ejemplo, este esquema de relacin:
Ocupacin (No_cliente, Nombre_cliente, No_habitacin,
precio_noche, tipo_habitacin, fecha_entrada)

1. Lo primero que tenemos que hacer es buscar las posibles claves

candidatas. En este caso slo existe una posibilidad:
2. (No_habitacin, fecha_entrada)

3. Recordemos que cualquier clave candidata debe identificar de forma

unvoca una clave completa. En este caso, la clave completa es la
ocupacin de una habitacin, que se define por dos parmetros: la
habitacin y la fecha de la ocupacin.
4. Es decir, dos ocupaciones son diferentes si cambian cualquiera de estos
parmetros. La misma persona puede ocupar varias habitaciones al
mismo tiempo o la misma habitacin durante varios das o en diferentes
periodos de tiempo. Lo que no es posible es que varias personas ocupen
la misma habitacin al mismo tiempo (salvo que se trate de un
acompaante, pero en ese caso, slo una de las personas es la titular de
la ocupacin).
5. El siguiente paso consiste en buscar columnas que no aporten
informacin directa sobre la clave completa: la ocupacin. En este caso el
precio por noche de la habitacin y el tipo de habitacin (es decir, si es
doble o sencilla), no aportan informacin sobre la clave principal. En
realidad, estos datos no son atributos de la ocupacin de la habitacin,
sino de la propia habitacin.
6. El nmero de cliente y su nombre aportan datos sobre la ocupacin,
aunque no formen parte de la clave completa.

Expresado en forma de dependencias se ve muy claro:

(No_habitacin, fecha_entrada) -> No_cliente
(No_habitacin, fecha_entrada) -> Nombre_cliente
No_habitacin -> precio_noche
No_habitacin -> tipo_habitacin

Tercera forma normal 3FN

La tercera forma normal consiste en eliminar las dependencias transitivas.
Definicin: Una base de datos est en 3FN si est en 2FN y adems
todas las columnas que no sean claves dependen de la clave completa
de forma no transitiva.
Pero esto es una definicin demasiado terica. En la prctica significa que
se debe eliminar cualquier relacin que permita llegar a un mismo dato de
dos o ms formas diferentes.
Tomemos el ejemplo que usamos para ilustrar las dependencias
funcionales transitivas. Tenemos una tabla donde se almacenen datos
relativos a ciudades, y una de las columnas sea el pas y otra el continente
al que pertenecen. Por ejemplo:
Ciudades (ID_ciudad (PK), Nombre, poblacin, superficie, renta, pas,
continente)
Un conjunto de datos podra ser el siguiente:

Ciudades
ID_ciudad Nombre poblacin superficie renta pas
continente
1
Paris
6000000 15
1800 Francia Europa
2
Lion
3500000 9
1600 Francia Europa
3
Berln 7500000 16
1900 Alemania Europa
4
Pekn 19000000 36
550 China Asia
5
Bonn
6000000 12
1900 Alemania Europa
Podemos ver que para cada aparicin de un determinado pas, el
continente siempre es el mismo. Es decir, existe una redundancia de
datos, y por lo tanto, un peligro de integridad.
Existe una relacin entre pas y continente, y ninguna de ellas es clave
candidata. Por lo tanto, si queremos que esta table sea 3FN debemos
separar esa columna:
Ciudades (ID_ciudad (PK), Nombre, poblacin, superficie, renta, nombre
pas)
Pases (nombre pas (PK), nombre continente)
Ciudades
ID_ciudad Nombre poblacin superficie renta pas
1
Paris
6000000 15
1800 Francia
2
Lion
3500000 9
1600 Francia
3
Berln 7500000 16
1900 Alemania
4
Pekn 19000000 36
550 China
5
Bonn
6000000 12
1900 Alemania

Esta separacin tendra ms sentido si la tabla de pases contuviese ms

informacin, tal como est no tiene mucho sentido separar estas tablas,
aunque efectivamente, se evita redundan

Conclusin
Finalmente si tomamos en cuenta que una tabla de detalle de venta puede
contener un volumen de millones de registros, al haberle aplicado las 3 formas
normales nos estaremos ahorrando varios Gigabytes de tamao en dicha tabla
y por supuesto mejorado notablemente la performance

REFERENCIAS

https://es.wikipedia.org/wiki/Normalizaci%C3%B3n_de_bases_de_datos

https://cvva.wordpress.com/2007/12/04/normalizacion-de-bases-de-datos-las-3formas-normales/vvv
https://cvva.wordpress.com/2007/12/04/normalizacion-de-bases-de-datos-las-3formas-normales/
http://informatica.uv.es/estguia/ATD/apuntes/teoria/documentos/DisenoBD.pdf
http://mysql.conclase.net/curso/?cap=004

10