Materia:

Submodulo

DOCENTE:

Cornelio Alberto Lpez Mndez

ESPECIALIDAD:

Ofimtica

GRADO:

5 Semestre

GRUPO:

A

Alumna:

Magdiela Prez Lpez

FECHA: lunes 28 de septiembre 2015

INTRODUCCIN

El propsito de esta investigacin es dar a conocer las tres formas normales para

aplicar en un diseo de base de datos es un tema muy importante porque nos

sirve para archivar documentos en una computadora, o realizar una base de datos

con otras cosas, la investigacin pretende dar a conocer la informacin de las tres

formas para aplicar en un diseo de base de datos.

A continuacin se muestra lo siguiente dentro de la investigacin:

Introduccin

Desarrollo

Conclusin

referencias

LA PRIMERA FORMA NORMAL

Esta primera Forma Normal, nos lleva a no repetir datos en nuestras tablas. Los

famosos maestro detalle, deben aplicarse a la estructura de la tabla. Si nuestra

tabla de ventas repite una y otra vez (por cada venta) , el nombre, el domicilio y

otros datos del Cliente, es 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.Lo mismo ocurrira en una tabla de detalle de

ventas, si por cada tem vendido colocamos el detalle del producto, con su

descripcin, medidas, etcTendramos un desaprovechamiento de espacio y

recursos muy grande. Para ello, tendremos nuestra tabla maestra de Productos y

con solo grabar el cdigo de dicho producto en nuestra tabla de ventas, ser

suficiente.

Una tabla est en Primera Forma Normal si:

Todos los atributos son atmicos. Un atributo es atmico si los elementos del

dominio son simples e indivisibles.

La tabla contiene una clave primaria nica.

La clave primaria no contiene atributos nulos.

No debe existir variacin en el nmero de columnas.

Los Campos no clave deben identificarse por la clave (Dependencia Funcional)

Debe Existir una independencia del orden tanto de las filas como de las

columnas, es decir, si los datos cambian de orden no deben cambiar sus

significados

Esta forma normal elimina los valores repetidos dentro de una Base de Datos.

LA SEGUNDA FORMA NORMAL

(Si o si debe estar previamente aplicada la Primera 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. Veamos un

ejemplo

Venta ID Item ID Fecha Venta Cliente Venta Producto Id Cantidad

1 1 01/12/2007 2 2334 10

1 2 01/12/2007 2 3333 2

1 3 01/12/2007 2 66643 34

1 4 01/12/2007 2 21 3

2 1 02/12/2007 5 3566 6

Ah tenemos un claro problema!!!Acaso no se busca NO REPETIR DATOS ?Si

toda una venta tendr el mismo nmero de Cliente y la misma FechaPor que no

crear una Tabla de MAESTRO DE VENTAS y que contenga esos 2 datos ?Es

evidente que

la columna Cliente Venta y Fecha Venta se repetirn por cada venta realizada. Es

por ello que proponemos el siguiente esquema

Venta ID Item ID Producto Id Cantidad

1 1 2334 10

1 2 3333 2

1 3 66643 34

1 4 21 3

2 1 3566 6

Y ahora nuestra nueva tabla maestra

Venta Id Fecha Venta Cliente Venta

1 01/12/2007 2

2 02/12/2007 5

Entonces, nuestra 2da Forma Normal nos habla de que cada columna de una

tabla debe depender de toda la clave y no constituir un dato nico para cada grupo

de registros.

Dependencia Funcional. Una relacin est en 2FN si est en 1FN y si los atributos

que no forman parte de ninguna clave dependen de forma completa de la clave

principal. Es decir que no existen dependencias parciales. (Todos los atributos que

no son clave principal deben depender nicamente de la clave principal).

En otras palabras podramos decir que la segunda forma normal est basada en el

concepto de dependencia completamente funcional. Una dependencia

funcional es completamente funcional si al eliminar los atributos A de X

significa que la dependencia no es mantenida, esto es

que . Una dependencia funcional es una

dependencia parcial si hay algunos atributos que pueden ser eliminados

de X y la dependencia todava se mantiene, esto es .

Por ejemplo {DNI, ID_PROYECTO} HORAS_TRABAJO (con el DNI de un

empleado y el ID de un proyecto sabemos cuntas horas de trabajo por semana

trabaja un empleado en dicho proyecto) es completamente funcional dado que ni

DNI HORAS_TRABAJO ni ID_PROYECTO HORAS_TRABAJO mantienen

la dependencia. Sin embargo {DNI, ID_PROYECTO} NOMBRE_EMPLEADO es

parcialmente dependiente dado que DNI NOMBRE_EMPLEADO mantiene la

dependencia.

LA TERCERA FORMA NORMAL

En realidad si nos guiamos en el ejemplo de esta nota, ya no quedara

normalizacin por aplicar y podramos decir que nuestro ejemplo cumple con las 3

formas normales, ya que la 3ra Forma Normal nos habla de que :

1. Ninguna Columna puede depender de una columna que no tenga una clave

2. No puede haber datos derivados

En el 2do ejemplo hemos descubierto campos que dependan de la clave principal

(VentaID) y que podran incluirse en una tabla maestra. Pero supongamos un

ejemplo donde ciertas columnas no dependen de la clave principal y si dependen

de una columna de nuestra tabla.

VentaID ItemID Producto ID Cantidad Descripcin Medida Proveedor

1 1 3455 12 Impresora HP LJ8000 122cm 1

1 2 2455 34 Scanner HP A3555 33cm 1

2 1 5444 21 Mouse HP Wireless 1

Esto es muy normal encontrar en bases mal normalizadas. Vemos que los campos

DESCRIPCION, MEDIDA y PROVEEDOR no dependen de VENTAID y es por ello

que no deberan estar dentro de la tabla de detalle de ventas, ya que dependen de

PRODUCTOID.

Aqui no se trata ya de eliminar grupos repetidos de datos (1ra Forma Normal) sino

que ante la inclusin de una clave perteneciente a otra tabla, cualquier campo que

sea subordinado de dicha clave debe estar en otra tabla y no en nuestra tabla

detalle.

La tabla se encuentra en 3FN si es 2FN y si no existe ninguna dependencia

funcional transitiva entre los atributos que no son clave.

Un ejemplo de este concepto sera que, una dependencia funcional X->Y en un

esquema de relacin R es una dependencia transitiva si hay un conjunto de

atributos Z que no es un subconjunto de alguna clave de R, donde se mantiene X-

>Z y Z->Y.

Por ejemplo, la dependencia SSN->DMGRSSN es una dependencia transitiva en

EMP_DEPT de la siguiente figura. Decimos que la dependencia de DMGRSSN el

atributo clave SSN es transitiva va DNUMBER porque las dependencias

SSNDNUMBER y DNUMBERDMGRSSN son mantenidas, y DNUMBER no es

un subconjunto de la clave de EMP_DEPT. Intuitivamente, podemos ver que la

dependencia de DMGRSSN sobre DNUMBER es indeseable en EMP_DEPT dado

que DNUMBER no es una clave de EMP_DEPT.

Formalmente, un esquema de relacin est en 3 Forma Normal Elmasri-

Navathe,2 si para toda dependencia funcional , se cumple al menos una

de las siguientes condiciones:

1. es superllave o clave.

2. es atributo primo de ; esto es, si es miembro de alguna clave en .

Adems el esquema debe cumplir necesariamente, con las condiciones de

segunda forma normal.

CONCLUSIN

Al trmino de esta investigacin, me di cuenta que es un tema muy importante

dentro de nuestra materia, porque la base de datos es un sistema para archivar

informacin en una computadora, este tema fue muy importante porque lo

podemos utilizar en un futuro para realizarlo en una computadora, y asi poder

tener una base de datos, y asi tambin poder realizar una base de datos de otras

cosas.

REFERENCIAS

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

formas-normales/

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