MATERIA: Modulo I, II

CATEDRATICO: Alberto Mendes

ALUMNA: Tahiri Velzquez Aguilar

TRABAJO: investigacin

TEMA: las 3 formas normales para aplicar en

un diseo de Base de Datos.

FECHA DE ENTREGA: 24-09-2015

INTRODUCCION
Al realizar este trabajo podrs encontrar cuales son las tres formas normales para
aplicar a un diseo de Base de Datos.
Existen varios niveles de normalizacin: Primera Forma Normal, Segunda Forma
Normal, Tercera Forma
Normal, Forma Normal Boyce-Codd, Cuarta Forma Normal, Quinta Forma Normal
o Forma Normal de
Proyeccin-Unin, Forma Normal de Proyeccin-Unin Fuerte, Forma Normal de
Proyeccin-Unin Extra.

DESARROLLO
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.
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.
Todo atributo en una tabla tiene un dominio, el cual representa el conjunto de
valores que el mismo puede tomar. Una instancia de una tabla puede verse
entonces como un subconjunto del producto cartesiano entre los dominios de los
atributos. Sin embargo, suele haber algunas diferencias con la analoga
matemtica, ya que algunos RDBMS permiten filas duplicadas, entre otras cosas.
Finalmente, una tupla puede razonarse matemticamente como un elemento del
producto cartesiano entre los dominios.
Las formas normales son aplicadas a las tablas de una base de datos. Decir que
una base de datos est en la forma normal N es decir que todas sus tablas estn
en la forma normal N.

Diagrama de inclusin de todas las formas normales.

En general, 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.1

GRADOS DE NORMALIZACIN

Existen bsicamente tres niveles de normalizacin: Primera Forma Normal (1NF),

Segunda Forma Normal (2NF) y Tercera Forma Normal (3NF). Cada una de estas formas
tiene sus propias reglas. Cuando una base de datos se conforma a un nivel, se considera
normalizada a esa forma de normalizacin. No siempre es una buena idea tener una base

de datos conformada en el nivel ms alto de normalizacin, puede llevar a un nivel de

complejidad que pudiera ser evitado si estuviera en un nivel ms bajo de normalizacin.

PRIMERA FORMA NORMAL

La regla de la Primera Forma Normal establece que las columnas repetidas deben
eliminarse y colocarse en tablas separadas.
Poner la base de datos en la Primera Forma Normal resuelve el problema de los
encabezados de columna mltiples. Muy a menudo, los diseadores de bases de
datos inexpertos harn algo similar a la tabla no normalizada. Una y otra vez,
crearn columnas que representen los mismos datos. La normalizacin ayuda a
clarificar la base de datos y a organizarla en partes ms pequeas y ms fciles
de entender. En lugar de tener que entender una tabla gigantesca y monoltica que
tiene muchos diferentes aspectos, slo tenemos que entender los objetos
pequeos y ms tangibles, as como las relaciones que guardan con otros objetos
tambin pequeos.
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

789

Cesar

Dure

555-808-9633

En este punto, el diseador se da cuenta que un requerimiento es

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:
Cliente

ID Cliente Nombre Apellido Telfono

123

Rachel

Ingram

555-861-2025

456

James

Wright

555-403-1659
555-776-4100

789

Cesar

Dure

555-808-9633

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

Telfono 2

123

Rachel

Ingram

555-861-2025

456

James

Wright

555-403-1659 555-776-4100

Telfono 3

789

Cesar

Dure

555-808-9633

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; dividir los
nmeros 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.
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

Cesar

Dure

555-808-9633

ste es defendiblemente 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 individuales. Con este diseo en la RDBMS, son tambin
imposibles de definir significativas restricciones en nmeros telefnicos.
UN DISEO 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.
Telfono del cliente
Cliente
ID Cliente Telfono
ID Cliente Nombre Apellido

123

456

789

Rachel

James

Cesar

123

555-861-2025

456

555-403-1659

456

555-776-4100

789

555-808-9633

Ingram

Wright

Dure

En este diseo no ocurren grupos repetidos de nmeros telefnicos. En lugar

de eso, cada enlace Cliente-a-Telfono aparece en su propio registro. Es
valioso notar que este diseo cumple los requerimientos adicionales para la
segunda (2NF) y la tercera forma normal (3FN).

SEGUNDA FORMA NORMAL

La regla de la Segunda Forma Normal establece que todas las dependencias
parciales se deben eliminar y separar dentro de sus propias tablas. Una
dependencia parcial es un trmino que describe a aquellos datos que no
dependen de la llave primaria de la tabla para identificarlos.
Una vez alcanzado el nivel de la Segunda Forma Normal, se controlan la mayora
de los problemas de lgica. Podemos insertar un registro sin un exceso de datos
en la mayora de las tablas.
Considere una tabla describiendo las habilidades de los empleados:
Habilidades de los empleados

Empleado Habilidad

Lugar actual de trabajo

Jones

Mecanografa

114 Main Street

Jones

Taquigrafa

114 Main Street

Jones

Tallado

114 Main Street

Bravo

Limpieza ligera 73 Industrial Way

Ellis

Alquimia

73 Industrial Way

Ellis

Malabarismo

73 Industrial Way

Harrison

Limpieza ligera 73 Industrial Way

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

El atributo restante, Lugar actual de trabajo, es dependiente solo 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?".
Un alternativa 2NF a este diseo representara la misma informacin en dos
tablas:
Empleados

Empleado Lugar actual de trabajo

Jones

114 Main Street

Bravo

73 Industrial Way

Ellis

73 Industrial Way

Harrison

73 Industrial Way

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:

Ganadores del torneo

Torneo

Des
Masters

Moines

Ao

Ganador

Fecha de
ganador

nacimiento

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 septiembre de 1968

Des
Masters

1999 Al Fredrickson

21 de julio de 1975

Moines

Indiana Invitational

1999

Chip
Masterson

del

14 de marzo de 1977

TERCERA FORMA NORMAL

Una tabla est normalizada en esta forma si todas las columnas que no son llave
son funcionalmente dependientes por completo de la llave primaria y no hay
dependencias transitivas. Comentamos anteriormente que una dependencia
transitiva es aquella en la cual existen columnas que no son llave que dependen
de otras columnas que tampoco son llave.
Cuando las tablas estn en la Tercera Forma Normal se previenen errores de
lgica cuando se insertan o borran registros. Cada columna en una tabla est
identificada de manera nica por la llave primaria, y no deben haber datos
repetidos. Esto provee un esquema limpio y elegante, que es fcil de trabajar y
expandir.

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

Torneo

Ao

Ganador

Indiana Invitational

1998 Al Fredrickson

21 de julio de 1975

Cleveland Open

1999 Bob Albertson

28 de septiembre de 1968

Des Moines Masters 1999 Al Fredrickson

Indiana Invitational

Fecha de nacimiento del ganador

21 de julio de 1975

1999 Chip Masterson 14 de marzo de 1977

La nica clave candidata 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
primarioGanador. 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

Torneo

Ao

Ganador

Indiana Invitational

1998 Al Fredrickson

Cleveland Open

1999 Bob Albertson

Des Moines Masters 1999 Al Fredrickson

Indiana Invitational

1999 Chip Masterson

Fecha de nacimiento del jugador

Ganador

Fecha de nacimiento

Chip Masterson 14 de marzo de 1977

Al Fredrickson

21 de julio de 1975

Bob Albertson

28 de septiembre de 1968

Las anomalas de actualizacin no pueden ocurrir en estas tablas, las cuales

estn en 3NF.

CONCLUSION

Como conclusin llegue a que gracias a estos tres tipos de formas normales
para agregar a una Base de Datos podemos saber ms como es que una base
de datos est formada, o como realizar para que quede muy bien nuestra
Base.

Fuentes
http://ucipedia.uci.cu/index.php/Normalizaci%C3%B3n_de_una_base_de_d
atos
https://es.wikipedia.org/wiki/Normalizaci%C3%B3n_de_bases_de_datos
http://es.slideshare.net/sesa78/normalizacion-de-base-de-datos-14102278
http://isc.itcj.s5.com/bdd1/unidad4.htm