NOMBRE:

Diego Armando Ortiz Snchez

PROFESOR:
Lic. Cornelio Alberto Prez Mndez
TRABAJO:
Investigacin
ESPECIALIDAD:
Ofimtica
SEMESTRE:
5to semestre
GRUPO:
A
FECHA:
23/09/2015

MOTOZINTLA DE MENDOZA, CHIAPAS

INTRODUCCIN
En este trabajo de investigacin aprenderemos sobre el proceso de normalizacin
de una base de datos, tambin veremos sobre los 3 tipos de normalizacin para
una base de datos, estas definiciones nos lo explicara ms a fondo el profesor
pero los tenemos que aprender bien, porque despus de esta investigacin lo
pondremos en prctica. Esto es un tema muy interesante porque es una cosa
nueva que se aprender.

C.B.T.I.S 243

Pgina 2

DESARROLLO
El proceso de normalizacin de una base de datos consiste en aplicar una serie de
reglas a las relaciones obtenidas tras el paso del modelo E-R (entidad-relacin) al
modelo relacional.

Objetivo de la normalizacin
Las bases de datos relacionales se normalizan para:

Evitar la redundancia de los datos.

Evitar 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 bidimensional sea considerada como una relacin tiene cumplir con
algunas restricciones:

Cada columna 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.

C.B.T.I.S 243

Pgina 3

FORMA NORMAL
Las primeras tres formas normales son suficientes para cubrir las necesidades de
la mayora de las bases de datos. El creador de estas 3 primeras formas normales
(o reglas) fue Edgar F. Codd, ste introdujo la normalizacin en un artculo
llamado A Relational Model of Data for Large Shared Data Banks.

Primera forma normal

Elimine los grupos repetidos de las tablas individuales.

Cree una tabla independiente para cada conjunto de datos relacionados.

Identifique cada conjunto de datos relacionados con una clave principal.

No use varios campos en una sola tabla para almacenar datos similares. Por
ejemplo, para realizar el seguimiento de un elemento del inventario que proviene
de dos orgenes posibles, un registro del inventario puede contener campos para
el Cdigo de proveedor 1 y para el Cdigo de proveedor 2.

Qu ocurre cuando se agrega un tercer proveedor? Agregar un campo no es la

respuesta, requiere modificaciones en las tablas y el programa, y no admite
fcilmente un nmero variable de proveedores. En su lugar, coloque toda la
informacin de los proveedores en una tabla independiente denominada
Proveedores y despus vincule el inventario a los proveedores con el nmero de
elemento como clave.

C.B.T.I.S 243

Pgina 4

Ejemplo:
Primera forma normal: no hay grupos repetidos

Las tablas slo deben tener dos dimensiones. Puesto que un alumno tiene varias
clases, estas clases deben aparecer en una tabla independiente. Los campos Clase1,
Clase2 y Clase3 de los registros anteriores son indicativos de un problema de diseo.

Las hojas de clculo suelen usar la tercera dimensin, pero las tablas no deberan
hacerlo. Otra forma de considerar ese problema es con una relacin de uno a varios y
poner el lado de uno y el lado de varios en tablas distintas. En su lugar, cree otra tabla
en la primera forma normal eliminando el grupo repetido (N clase), segn se muestra

continuacin:

N alumno
1022
1022
1022
4123
4123
4123

C.B.T.I.S 243

Tutor
Garca
Garca
Garca
Daz
Daz
Daz

Despacho-Tut
412
412
412
216
216
216

N clase
101-07
143-01
159-02
201-01
211-02
214-01

Pgina 5

Segunda forma normal

Cree tablas independientes para conjuntos de valores que se apliquen a

varios registros.

Relacione estas tablas con una clave externa.

Los registros no deben depender de nada que no sea una clave principal de una
tabla, una clave compuesta si es necesario. Por ejemplo, considere la direccin de
un cliente en un sistema de contabilidad. La direccin se necesita en la tabla
Clientes, pero tambin en las tablas Pedidos, Envos, Facturas, Cuentas por
cobrar y Colecciones. En lugar de almacenar la direccin de un cliente como una
entrada independiente en cada una de estas tablas, almacnela en un lugar, ya
sea en la tabla Clientes o en una tabla Direcciones independiente.

Ejemplo:
Segunda forma normal: eliminar los datos redundantes

Observe los diversos valores de N clase para cada valor de N alumno en la tabla
anterior. N clase no depende funcionalmente de N alumno (la clave principal), de
modo que la relacin no cumple la segunda forma normal.

Las dos tablas siguientes demuestran la segunda forma normal:

Alumnos:
N alumno
1022
4123

C.B.T.I.S 243

Tutor
Garca
Daz

Despacho-Tut
412
216

Pgina 6

Registro:
N alumno
1022
1022
1022
4123
4123
4123

N clase
101-07
143-01
159-02
201-01
211-02
214-01

Tercera forma normal

Elimine los campos que no dependan de la clave.

Los valores de un registro que no sean parte de la clave de ese registro no

pertenecen a la tabla. En general, siempre que el contenido de un grupo de
campos pueda aplicarse a ms de un nico registro de la tabla, considere colocar
estos campos en una tabla independiente. Por ejemplo, en una tabla Contratacin
de empleados, puede incluirse el nombre de la universidad y la direccin de un
candidato. Pero necesita una lista completa de universidades para enviar
mensajes de correo electrnico en grupo. Si la informacin de las universidades se
almacena en la tabla Candidatos, no hay forma de enumerar las universidades
que no tengan candidatos en ese momento. Cree una tabla Universidades
independiente y vinclela a la tabla Candidatos con el cdigo de universidad como
clave.

EXCEPCIN: cumplir la tercera forma normal, aunque en teora es deseable, no

siempre es prctico. Si tiene una tabla Clientes y desea eliminar todas las
dependencias posibles entre los campos, debe crear tablas independientes para
las ciudades, cdigos postales, representantes de venta, clases de clientes y

C.B.T.I.S 243

Pgina 7

cualquier otro factor que pueda estar duplicado en varios registros. En teora, la
normalizacin merece el trabajo que supone. Sin embargo, muchas tablas
pequeas pueden degradar el rendimiento o superar la capacidad de memoria o
de archivos abiertos.
Puede ser ms factible aplicar la tercera forma normal slo a los datos que
cambian con frecuencia. Si quedan algunos campos dependientes, disee la
aplicacin para que pida al usuario que compruebe todos los campos relacionados
cuando cambie alguno.

Ejemplo:
Tercera forma normal: eliminar los datos no dependientes de la clave
En el ltimo ejemplo, Despacho-Tut (el nmero de despacho del tutor) es
funcionalmente dependiente del atributo Tutor. La solucin es pasar ese atributo
de la tabla Alumnos a la tabla Personal, segn se muestra a continuacin:

Alumnos:
N alumno
1022

Tutor
Garca

4123

Daz

Personal:
Nombre
Garca

Habitacin
412

Dept
42

Daz

216

42

C.B.T.I.S 243

Pgina 8

CONCLUSION
Esta investigacin me sirvi mucho porque aprend lo que es la normalizacin,
como se forma, los objetivos principales, lo ms importante que se vio son las 3
formas de normalizacin de una base de datos que es lo que se veremos. Esto
nos servir en un futuro para nuestros prximos trabajos, tambin fue bueno
aprender sobre esta informacin porque base a esto nosotros realizaremos
nuestro proyecto de la escuela y ya sabemos cmo quedara nuestro proyecto.

C.B.T.I.S 243

Pgina 9

REFERENCIAS BIBLIOGRAFICAS

https://cvva.wordpress.com/2007/12/04/normalizacion-de-bases-de-datos-las-3formas-normales/

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

C.B.T.I.S 243

Pgina 10