NORMALIZACIÓN DE BASES DE DATOS.pdf

DOCENTE: Ing. Cornelio Alberto Pérez Méndez

MATERIA: Modulo

TRABAJO: Investigación:  las tres formas normales para aplicar en un diseño de BD.

ALUMNO: Yesenia Marisol Reynoso López

ESPECIALIDAD: Ofimática

SEMESTRE: 5°semestre

FECHA 23 de septiembre del 2015

En este tema conoceremos las tres formas normales para aplicar en un diseño de bd (base de datos).

Primera Forma Normal si: Todos los atributos son atómicos. Un atributo es atómico si los elementos del dominio son simples e indivisibles.

Segunda forma normal:  Una relación 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.

Tercer forma normal. La tabla se encuentra en 3FN si es 2FN y si no existe ninguna dependencia funcional transitiva entre los atributos que no son clave.

NORMALIZACIÓN DE BASES DE DATOS (LAS 3 FORMAS NORMALES) La normalización es el proceso de organizar los datos de una base de datos. Se incluye la creación de tablas y el establecimiento de relaciones entre ellas según reglas diseñadas tanto para proteger los datos como para hacer que la base de datos sea más flexible al eliminar la redundancia y las dependencias incoherentes. Estas 3 reglas de Normalización se las conoce como las 3 FORMAS NORMALES.

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 Normalización. Si tenemos una tabla clientes, en la tabla ventas, solo debería figurar el código del cliente, para que el resto de los datos se puedan referenciar automáticamente sin problemas y sin duplicar información. Lo mismo ocurriría en una tabla de detalle de ventas, si por cada ítem vendido colocamos el detalle del producto, con su descripción, medidas, etc…Tendríamos un desaprovechamiento

de espacio y recursos muy grande. Para ello, tendremos nuestra tabla maestra de Productos y con solo grabar el código de dicho producto en nuestra tabla de ventas, será suficiente.

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 tuviéramos alguna columna que se repite a lo largo de todos los registros, dichos datos deberían atomizarse en una nueva tabla. Veamos un ejemplo:

Venta ID

Item ID

Fecha Venta

Cliente Venta

Producto ID

Cantidad

1 1 1 1 2

1 2 3 4 1

01/12/2007 01/12/2007 01/12/2007 01/12/2007 02/12/2007

2 2 2 2 5

2334 3333 66643 21 3566

10 2 34 3 6

 Ahí tenemos un claro problema. Acaso no se busca NO REPETIR REPETIR DATOS ?Si toda una venta tendrá el mismo numero de Cliente y la misma Fecha…Por 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 repetirán por cada venta realizada. Es por ello que proponemos el siguiente esquema

Venta ID

Item ID

Producto ID

Cantidad

1 1 1 1 2

1 2 3 4 1

3334 3333 66643 21 3566

10 2 34 3 6

Y ahora nuestra nueva tabla maestra

Venta ID

Fecha Venta

Cliente Venta

1 2

01/12/2007 02/12/2007

2 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. La Tercera Forma Normal En realidad si nos guiamos en el ejemplo de esta nota, ya no quedaría normalización por aplicar y podríamos 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 dependían de la clave principal (Venta ID) y que podrían 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.

Venta ID

Item ID

Producto Cantidad ID

1

1

3455

12

1

2

2455

34

2

1

5444

21

Descripción Impresora HP LJ8000 Scanner HP  A3555 Mouse HP Wireless

Medida

Proveedor

122 Cm

1

33 Cm

1

-

1

Esto es muy normal encontrar en bases mal normalizadas. Vemos que los campos DESCRIPCION, MEDIDA y PROVEEDOR no dependen de VENTA ID y es por ello que no deberían estar dentro de la tabla de detalle de ventas, ya que dependen de PRODUCTO ID. Aquí no se trata ya de eliminar grupos repedidos de datos (1ra Forma Normal) sino que ante la inclusión 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.

Conclusión. Finalmente si tomamos en cuenta que una tabla de detalle de venta (ítem x ítem) puede contener un volumen de millones de registros, al haberle aplicado las 3 formas normales nos estaremos ahorrando varios Gigabytes de tamaño en dicha tabla y por supuesto mejorado notablemente la performance.

Llegue ala conclusión que es muy importante enfocarme en esta investigación por en ella aprendí sobre las tres formas normales para aplicar en un diseño de bd como por ejemplo:

Primera Forma Normal (1FN) Una tabla está en Primera Forma Normal si: 

Todos los atributos son atómicos. atómicos. Un atributo es atómico 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 variación en el número 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.