Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Formas normales1
Una vez obtenido el esquema relacional resultante del esquema entidad/relacin que
representa la base de datos, normalmente tendremos una buena base de datos. Pero
otras veces, debido a fallos en el diseo o a problemas indetectables, tendremos un
esquema que puede producir una base de datos que incorpore estos problemas:
- Redundancia. Se llama as a los datos que se repiten continua e innecesariamente
por las tablas de las bases de datos. Cuando es excesiva es evidente que el diseo
hay que revisarlo, es el primer sntoma de problemas y se detecta fcilmente.
- Ambigedades. Datos que no clarifican suficientemente el elemento al que
representan. Los datos de cada fila podran referirse a ms de un ejemplar de esa
tabla o incluso puede ser imposible saber a qu ejemplar exactamente se estn
refiriendo. Es un problema muy grave y difcil de detectar.
- Prdida de restricciones de integridad. Normalmente debido a dependencias
funcionales. Ms adelante se explica este problema. Se arreglan fcilmente
siguiendo una serie de pasos concretos.
- Anomalas en operaciones de modificacin de datos. El hecho de que al insertar un
solo elemento haya que repetir tuplas en una tabla para variar unos pocos datos. O
que eliminar un elemento suponga eliminar varias tuplas necesariamente (por
ejemplo que eliminar un cliente suponga borrar seis o siete filas de la tabla de
clientes, sera un error muy grave y por lo tanto un diseo terrible).
El principio fundamental reside en que las tablas deben referirse a objetos o situaciones
muy concretas, relacionados exactamente con elementos reconocibles por el sistema de
informacin de forma inequvoca. Cada fila de una tabla representa inequvocamente un
elemento reconocible en el sistema. Lo que ocurre es que conceptualmente es difcil
agrupar esos elementos correctamente.
En cualquier caso la mayor parte de problemas se agravan si no se sigue un modelo
conceptual y se decide crear directamente el esquema relacional. En ese caso, el diseo
tiene una garanta casi asegurada de funcionar mal.
Cuando aparecen los problemas enumerados, entonces se les puede resolver usando
reglas de normalizacin. Estas reglas suelen forzar la divisin de una tabla en dos o ms
tablas para arreglar ese problema
Las formas normales se corresponden a una teora de normalizacin iniciada por el
propio Codd y continuada por otros autores (entre los que destacan Boyce y Fagin).
Codd defini en 1970 la primera forma normal, desde ese momento aparecieron la
segunda, tercera, la Boyce-Codd, la cuarta y la quinta forma normal.
1
http://www.jorgesanchez.net/bd/gbd2012.pdf
2 curso de administracin de sistemas informticos en red autor: Jorge Snchez www.jorgesanchez.net
Normalizacion-GD-2016 Pgina 1
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL MENDOZA
CATEDRA: GESTION DE DATOS - INGENIERIA EN SISTEMAS DE INFORMACION
PROFESOR: Mara E. STEFANONI JTP: Higinio A. FACCHINI Ayte: Matilde I. CESARI
Una tabla puede encontrarse en primera forma normal y no en segunda forma normal,
pero no al contrario. Es decir los nmeros altos de formas normales son ms restrictivos
(la quinta forma normal cumple todas las anteriores).
La teora de formas normales es una teora absolutamente matemtica, pero en el
presente manual se describen de forma ms intuitiva.
Hay que tener en cuenta que muchos diseadores opinan que basta con llegar a la
forma Boyce-Codd, ya que la cuarta, y sobre todo la quinta, forma normal es polmica.
Hay quien opina que hay bases de datos peores en quinta forma normal que en tercera.
En cualquier caso debera ser obligatorio para cualquier diseador llegar hasta la forma
normal de Boyce-Codd.
No cumple la primera forma normal. Esa tabla s esta en primera forma normal.
DEPENDENCIAS FUNCIONALES
Por ejemplo el nombre de una PERSONA depende funcionalmente del DNI; es decir para un
DNI concreto slo hay un nombre posible. En la tabla del ejemplo anterior, el
DEPARTAMENTO no tiene dependencia funcional, ya que para un mismo DNI puede haber
ms de un departamento posible. Pero el nombre s que depende del DNI.
Normalizacion-GD-2016 Pgina 2
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL MENDOZA
CATEDRA: GESTION DE DATOS - INGENIERIA EN SISTEMAS DE INFORMACION
PROFESOR: Mara E. STEFANONI JTP: Higinio A. FACCHINI Ayte: Matilde I. CESARI
Por ejemplo en una tabla de CLIENTES, el conjunto de atributos formado por el nombre y el
DNI producen una dependencia funcional sobre el atributo apellidos. Pero no es plena ya
que el DNI individualmente, tambin produce una dependencia funcional sobre apellidos.
El DNI s produce una dependencia funcional completa sobre el campo apellidos.
Normalizacion-GD-2016 Pgina 3
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL MENDOZA
CATEDRA: GESTION DE DATOS - INGENIERIA EN SISTEMAS DE INFORMACION
PROFESOR: Mara E. STEFANONI JTP: Higinio A. FACCHINI Ayte: Matilde I. CESARI
Normalizacion-GD-2016 Pgina 4
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL MENDOZA
CATEDRA: GESTION DE DATOS - INGENIERIA EN SISTEMAS DE INFORMACION
PROFESOR: Mara E. STEFANONI JTP: Higinio A. FACCHINI Ayte: Matilde I. CESARI
DEPENDENCIAS MULTIVALUADAS
Para el resto de formas normales (las diseadas por Fagin, mucho ms complejas), es
importante definir este tipo de dependencia, que es distinta de las funcionales. Si las
funcionales eran la base de la segunda y tercera forma normal (y de la de Boyce-Codd),
stas son la base de la cuarta forma normal.
Normalizacion-GD-2016 Pgina 5
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL MENDOZA
CATEDRA: GESTION DE DATOS - INGENIERIA EN SISTEMAS DE INFORMACION
PROFESOR: Mara E. STEFANONI JTP: Higinio A. FACCHINI Ayte: Matilde I. CESARI
Se refiere a posibles valores (en plural) y se trata de que los valores de ese atributo
siempre sean los mismos segn el valor de un atributo y no del otro.
La tabla cursos, profesores y materiales del curso.
La tabla est en FNBC ya que no hay dependencias transitivas y todos los atributos son
clave sin dependencia funcional hacia ellos.
Sin embargo hay redundancia. Los materiales se van a repetir para cualquier profesor
dando cualquier curso, ya que los profesores van a utilizar todos los materiales del
curso (de no ser as no habra ninguna redundancia). Los materiales del curso dependen
de forma multivaluada del curso y no del profesor en una dependencia multivaluada (no
hay dependencia funcional ya que los posibles valores son varios). Para el par N de
curso y Profesor podemos saber los materiales; pero lo sabemos por el curso y no por
el profesor.
Normalizacion-GD-2016 Pgina 6
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL MENDOZA
CATEDRA: GESTION DE DATOS - INGENIERIA EN SISTEMAS DE INFORMACION
PROFESOR: Mara E. STEFANONI JTP: Higinio A. FACCHINI Ayte: Matilde I. CESARI
DEPENDENCIAS DE JOIN
Una proyeccin de una tabla es la tabla resultante de tomar un subconjunto de los
atributos de una tabla (se trata de la operacin proyeccin, , del lgebra relacional). Es
decir una tabla formada por unas cuantas columnas de la tabla original. La operacin
JOIN procedente tambin del lgebra relacional, consiste en formar una tabla con la
unin de dos tablas. La tabla resultante estar formada por la combinacin de todas
las columnas y filas de ambas, excepto las columnas y filas repetidas.
Normalizacion-GD-2016 Pgina 7
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL MENDOZA
CATEDRA: GESTION DE DATOS - INGENIERIA EN SISTEMAS DE INFORMACION
PROFESOR: Mara E. STEFANONI JTP: Higinio A. FACCHINI Ayte: Matilde I. CESARI
Esa descomposicin no pierde valores en este caso, sabiendo que si el proveedor nos
suministra un material podremos relacionarle con todos los proyectos que utilizan ese
material.
Resumiendo, una tabla no est en quinta forma normal si hay una descomposicin de
esa tabla que muestre la misma informacin que la original y esa descomposicin no
tenga como clave la clave original de la tabla.
Normalizacion-GD-2016 Pgina 8
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL MENDOZA
CATEDRA: GESTION DE DATOS - INGENIERIA EN SISTEMAS DE INFORMACION
PROFESOR: Mara E. STEFANONI JTP: Higinio A. FACCHINI Ayte: Matilde I. CESARI
Normalizacion-GD-2016 Pgina 9
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL MENDOZA
CATEDRA: GESTION DE DATOS - INGENIERIA EN SISTEMAS DE INFORMACION
PROFESOR: Mara E. STEFANONI JTP: Higinio A. FACCHINI Ayte: Matilde I. CESARI
Gua de Ejercicios
Aplicar las reglas de normalizacin los siguientes ejercicios.
1. Un dato sin normalizar no cumple con ninguna regla de normalizacin. Para explicar
con un ejemplo en qu consiste cada una de las reglas, vamos a considerar los datos
de la siguiente tabla.
ordenes (id_orden, fecha, id_cliente, nom_cliente, estado, num_art, nom_art, cant, precio)
Ordenes
Id_orden Fecha Id_cliente Nom_cliente Estado Num_art nom_art cant Precio
2301 23/02/11 101 Martin Caracas 3786 Red 3 35,00
2301 23/02/11 101 Martin Caracas 4011 Raqueta 6 65,00
2301 23/02/11 101 Martin Caracas 9132 Paq-3 8 4,75
2302 25/02/11 107 Herman Coro 5794 Paq-6 4 5,00
2303 27/02/11 110 Pedro Maracay 4011 Raqueta 2 65,00
2303 27/02/11 110 Pedro Maracay 3141 Funda 2 10,00
Ordenes
Id_orden Fecha Id_cliente Nom_cliente Estado
2301 23/02/11 101 Martin Caracas
2302 25/02/11 107 Herman Coro
2303 27/02/11 110 Pedro Maracay
Articulos_ordenes
Id_orden Num_art nom_art cant Precio
2301 3786 Red 3 35,00
2301 4011 Raqueta 6 65,00
2301 9132 Paq-3 8 4,75
2302 5794 Paq-6 4 5,00
2303 4011 Raqueta 2 65,00
2303 3141 Funda 2 10,00
Normalizacion-GD-2016 Pgina 10
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL MENDOZA
CATEDRA: GESTION DE DATOS - INGENIERIA EN SISTEMAS DE INFORMACION
PROFESOR: Mara E. STEFANONI JTP: Higinio A. FACCHINI Ayte: Matilde I. CESARI
Articulos_ordenes
Id_orden Num_art cant
2301 3786 3
2301 4011 6
2301 9132 8
2302 5794 4
2303 4011 2
2303 3141 2
Articulos
Num_art nom_art Precio
3786 Red 35,00
4011 Raqueta 65,00
9132 Paq-3 4,75
5794 Paq-6 5,00
3141 Funda 10,00
Normalizacion-GD-2016 Pgina 11
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL MENDOZA
CATEDRA: GESTION DE DATOS - INGENIERIA EN SISTEMAS DE INFORMACION
PROFESOR: Mara E. STEFANONI JTP: Higinio A. FACCHINI Ayte: Matilde I. CESARI
Para normalizar esta tabla, moveremos las columnas no llave y la columna llave de la
cual dependen dentro de una nueva tabla CLIENTES. Las nuevas tablas CLIENTES y
ORDENES se muestran a continuacin.
Ordenes
Id_orden Fecha Id_cliente
2301 23/02/11 101
2302 25/02/11 107
2303 27/02/11 110
Ordenes
Id_cliente Nom_cliente Estado
101 Martin Caracas
107 Herman Coro
110 Pedro Maracay
Por lo tanto la base de datos queda de la siguiente manera:
ordenes (id_orden, fecha, id_cliente)
Clientes (id_cliente, nom_cliente, estado)
Articulos ( num_art, nom_art, precio)
Articulos_ordenes (id_orden, num_art, cant)
Normalizacion-GD-2016 Pgina 12
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL MENDOZA
CATEDRA: GESTION DE DATOS - INGENIERIA EN SISTEMAS DE INFORMACION
PROFESOR: Mara E. STEFANONI JTP: Higinio A. FACCHINI Ayte: Matilde I. CESARI
5. Se presenta una base de datos de una biblioteca, aplicar las reglas de normalizacin
simplificando hasta la tercera forma normal.
Prestamos_libro (codLibro, Titulo, Autor, Editorial, NombreLector, Fechadev)
codLibro Titulo Autor Editorial nombreLector Fechadev
1001 Variable compleja Murray Spiegel McGraw Hill Prez Gmez, Juan 15/04/2005
1004 Visual Basic 5 E. Petroustsos Anaya Ros Tern, Ana 17/04/2005
1005 Estadstica Murray Spiegel McGraw Hill Roca, Ren 16/04/2005
1006 Oracle University Nancy Greenberg y Priya Nathan Oracle Corp. Garca Roque, Luis 20/04/2005
1007 Clipper 5.01 Ramalho McGraw Hill Prez Gmez, Juan 18/04/2005
Normalizacion-GD-2016 Pgina 13