MATERIA:

MODULO

ESPECIALIDAD:

OFIMATICA

ALUMNA:

GLADIS ALEJANDRA GOMEZ UTRILLA

DOCENTE:

LIC. CORNELIO ALBERTO PEREZ MENDEZ

TRABAJO:

LAS 3 FORMAS NORMALES PARA APLICAR EN UN DISEO DE BASE DE DATOS.

SEMESTRE:

5

GRUPO:

A

FECHA:

MIERCOLES, 23 DE SEPTIEMBRE DEL 2015.

INTRODUCCION

En esta investigacin que a continuacin presentare, esta relacionado con las 3

formas normales para aplicar en un diseo de base datos. Existen 3 niveles de

normalizacin que deben respetarse para poder decir que nuestra base de datos,

se encuentra normalizada, es decir, que cumple con los requisitos naturales para

funcionar ptimamente y no perjudicar. Estas 3 reglas de normalizacin se las

conoce como las 3 formas normales. En donde mostrare ejemplos de casa unos

de ellos.

LA PRIMERA FORMA NORMAL

Esta primera forma normal, nos lleva a no repetir datos en nuestras tablas deben

aplicarse a la estructura. Si nuestra tabla de ventas repite una y otra vez (por cada

venta), el nombre, el domicilio y otros datos del Cliente, es por que no hemos

aplicado esta normalizacin. Si tenemos una tabla clientes, en la tabla ventas, solo

debera figurar el cdigo del cliente, para que el resto de los datos se puedan

referenciar automticamente sin problemas y sin duplicar informacin.

En general, las primeras tres formas normales son suficientes para cubrir las

necesidades de la mayora de base de datos. El creador de las 3 primeras formas

normales (o reglas) fue Edgar F. Codd.

Segn la definicin de Datos de la 1FN, una tabla est en primera forma normal si

solo es "isomorfa a alguna relacin", lo que significa, especficamente, 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 interseccin de fila-y-columna contiene exactamente un valor del dominio

aplicable (y nada ms).

5. Todas las columnas son regulares [es decir, las filas no tienen componentes

como IDs de fila, IDs de objeto, o timestamps ocultos].

La violacin de cualquiera de estas condiciones significara que la tabla no es

estrictamente relacional, y por lo tanto no est en 1FN. Algunos ejemplos de tablas

(o de vistas) que no satisfacen esta definicin de 1FN son:

Una tabla que carece de una clave primaria podra acomodar filas duplicadas,

en violacin de la condicin 3.

Una vista cuya definicin exige que los resultados sean retornados en un orden

particular, de modo que el orden de la fila sea un aspecto intrnseco y

significativo de la vista. Esto viola la condicin 1.

Una tabla que contenga un atributo puede ser nula ya que estara en violacin

de la condicin 4, que requiere a cada campo contener exactamente un valor

de su dominio de columna. Sin embargo, debe observarse que este aspecto de

la condicin 4 es controvertido.

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:

ID

Cliente

Nombre Apellido Telfono

123 Rachel Ingram 555-861-2025

456 James Wright 555-403-1656

789 Cesar Dure 555-808-9566

CLIENTE

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.

LA SEGUNDA FORMA NORMAL

La Segunda Forma Normal nos habla de que cada columna de la tabla debe

depender de la clave. Esto significa que todo un registro debe depender

nicamente de la clave principal, si tuviramos alguna columna que se repite a lo

largo de todos los registros, dichos datos deberan atomizarse en una nueva tabla,

en esta segunda forma normal debe estar aplicada la primera.

En trminos levemente ms formales: una tabla 1FN est en 2FN solo si ninguno

de sus atributos no-principales son funcionalmente dependientes en una parte

(subconjunto propio) de una clave primaria (Un atributo no-principal es uno que no

pertenece a ninguna clave primaria).

Observe que cuando una tabla 1FN no tiene ninguna clave candidata compuesta

(claves candidatas consistiendo en ms de un atributo), la tabla est

automticamente en 2FN.

Ejemplo 1:

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:

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

en 2FN.

Empleados

Empleado Lugar actual de trabajo

Jones 114 Main Street

Bravo 73 Industrial Way

Ellis 73 Industrial Way

Harrison 73 Industrial Way

Habilidades de los empleados

Empleado Habilidad

Jones Mecanografa

Jones Taquigrafa

Jones Tallado

Bravo Limpieza ligera

Ellis Alquimia

Ellis Malabarismo

Harrison Limpieza ligera

LA TERCERA FORMA NORMAL

La tercera forma normal (3NF) es usada en la normalizacin de bases de datos.

La 3FN fue definida originalmente por E.F. Codd en 1971. La definicin de Codd

indica que una tabla est en 3FN solo si las tres condiciones siguientes se

cumplen:

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

Ningn atributo no-primario de la tabla es dependiente transitivamente de

una clave primaria

Es una relacin que no incluye ningn atributo clave

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 e Y Z.

Una formulacin alternativa de la definicin de Codd, dada por Carlo Zaniolo en

1982, es sta: Una tabla est en 3FN para cada una de sus dependencias

funcionales X A, por lo menos una de las condiciones siguientes se mantiene:

X contiene A,

X es una sper clave,

A es un atributo primario es decir, A est contenido dentro de una clave

candidata.

Ejemplo:

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

es:

Ganadores del torneo

Torneo Ao Ganador Fecha de nacimiento del 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 21 de julio de 1975

Indiana Invitational 1999 Chip Masterson 14 de marzo de 1977

La nica clave candidata es {Torneo, Ao}.

La violacin de la 3FN ocurre porque el atributo no primario Fecha de nacimiento

del ganador es dependiente transitivamente de {Torneo, Ao} va 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 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:

Las anomalas de actualizacin no

pueden ocurrir en estas tablas, las

cuales estn en 3NF.

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

CONCLUSION

He llegado a la conclusin de esta investigacin relacionada con las 3 formas

normales para poder aplicar un diseo de base datos que es muy importante ya

que nos redacta y nos especifica como debe de ir el diseo y nos explica el por

que se repite y por que se relacin una forma con otra por ejemplo la 1FN con la

2FN tienen algo en especifico y eso nos va enseando el por que hay datos

iguales.

REFERENCIAS

https://cvva.wordpress.com/2007/12/04/normalizacion-de-bases-de-datos-

las-3-formas-normales/

https://www.google.com.mx/?gfe_rd=cr&ei=fBQCVpCSDMun8we-

uqz4Dg#q=ejemplo+de+la+primera+forma+de+dise%C3%B1o+de+base+d

atos

https://es.wikipedia.org/wiki/Tercera_forma_normal