CENTRO DE BACHILLERATO TECNOLOGICO INDUSTRIAL Y DE SERVICIOS No.243

MATERIA: MODULO

DOCENTE: CORNELIO ALBERTO PEREZ MENDEZ.

ALUMNA: CARDONA GONZALEZ KAORI IXCHEL.

ESPECIALIDAD: OFIMATICA 5 A.

TRABAJO: INVESTIGACION DE LAS 3 NORMAS PARA BASES DE DATOS.

FECHA: 23 DE SEPTIEMBRE DEL 2015.

MOTOZINTLA DE MENDOZA CHIAPAS.

INTRODUCCION

En la siguiente investigacin se dar a conocer las 3 formas normales para poder emplear en una base de datos, con la cual dicha base de datos podra funcionar correctamente y sin interrupciones.Tambin se explicara brevemente en que consiste cada una de estas formas o dichas de otra manera, normalizacin de bases de datos, como tambin algunos ejemplos de las mismas.

Normalizacin de Bases de Datos(Las 3 formas normales)

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 las Performance por mala arquitectura. Estas 3 reglas de Normalizacin se las conoce como las 3 FORMAS NORMALES.

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.

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. Veamos un ejemplo:VentaIDItemIDFechaVentaClienteVentaProductoIdCantidad

1101/12/20072233410

1201/12/2007233332

1301/12/200726664334

1401/12/20072213

2102/12/2007535666

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 ClienteVenta y FechaVenta se repetirn por cada venta realizada. Es por ello que proponemos el siguiente esquema:VentaIDItemIDProductoIdCantidad

11233410

1233332

136664334

14213

2135666

Y ahora nuestra nueva tabla maestra:VentaIdFechaVentaClienteVenta

101/12/20072

202/12/20075

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 unico para cada grupo de registros.

Tercera Forma Normal

La 3ra Forma Normal nos habla de que: Ninguna Columna puede depender de una columna que no tenga una clave No puede haber datos derivadosEn 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.VentaIDItemIDProductoIDCantidadDescripcionMedidaProveedor

11345512Impresora HP LJ8000122cm1

12245534Scanner HP A355533cm1

21544421Mouse HP Wireless1

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.

CONCLUSIN

Al finalizar esta pequea investigacin, me di cuenta que, para que una base de datos pueda funcionar de una manera eficaz, es necesario seguir las normas anteriores y as no tener conflictos con nuestra base, porque hay que recordar que estas son para facilitarnos el acceso a datos importantes para nosotros o para alguna empresa, mas no para complicarnos.

Adems aprend como es que pueden aplicarse cada una de estas sencillas formas normales a una base de datos.

REFERENCIAS

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

http://dafelipe.blogspot.mx/2009/09/formas-normales.html

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