7/23/2019 3 formas de BD

1/8

MOTOZINTLA DE MENDOZA CHIAPAS

7/23/2019 3 formas de BD

2/8

INTRODUCCION

Este trabajo est concebido para ser una investigacin muy breve dirigido a los

principiantes que quieren conseguir un dominio conceptual del proceso denormalizacin de bases de datos. Yo encuentro muy difcil visualizar estos

conceptos usando solamente las palabras, por lo que me auxiliar, tanto como sea

posible, de imgenes y grficos. Esto no es una descripcin de cmo disear e

implementar una BD. Las muestras de BD en forma de imgenes de pantalla no

fueron pensadas para ser tomadas literalmente, sino simplemente como ayuda

visual para mostrar como los datos son redistribuidos a medida que la estructura

de la tabla se va transformando, cada vez ms, en normalizada. Yo no tratar

asuntos tales como las ventajas y desventajas de la normalizacin. Para aquellos

que quieren profundizar en esta materia, al final se da una lista de referencias.

Para la mayora, las primeras tres formas normales son las ms comnmente

aceptadas. Cuando la gente se sienta a disear una BD, ya ellos, con frecuencia,

tienen en mente una estructura parcialmente normalizada ya que la normalizacin

es una va natural de percibir las relaciones entre los datos y para ello no se

requieren habilidades matemticas o tericas. La normalizacin es una tarea

bastante comn que por la cual ser tratada en esta investigacin.

7/23/2019 3 formas de BD

3/8

LAS 3 FORMAS NORMALES PARA APLICAR EN UN DISEO DE BD

Existen 3 niveles de Normalizacin que deben respetarse para poder decir que

nuestra Base de Datos, se encuentra NORMALIZADA, es decir, que cumple conlos 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.

La Primera Forma Normal

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.

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

famosos maestrodetalle, 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

7/23/2019 3 formas de BD

4/8

La Segunda Forma Normal

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

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

VentaID ItemID FechaVenta ClienteVenta ProductoId 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 lacolumna Cliente Venta y Fecha Venta se repetirn por cada venta realizada. Es

por ello que proponemos el siguiente esquema

VentaID ItemID ProductoId 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

7/23/2019 3 formas de BD

5/8

VentaId FechaVenta ClienteVenta

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.

7/23/2019 3 formas de BD

6/8

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

En realidad si nos guiamos en el ejemplo de esta investigacin, 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

(Venta ID) 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 ProductoID 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

descripcin, medida y proveedor no dependen de venta id y es por ello que no

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

producto id. Aqu 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.

7/23/2019 3 formas de BD

7/8

CONCLUSIN

Finalmente si tomamos en cuenta que una tabla de detalle de venta puede

contener un volumen de millones de registros, al haberle aplicado las 3 formasnormales nos estaremos ahorrando varios Gigabytes de tamao en dicha tabla y

por supuesto mejorado notablemente la performance. En conclusin solo nos

queda memorizar las 3 formas de normalizacin de una Base de Datos:

1. No elementos repetidos o grupos de elementos.

2. Sin dependencias parciales de llaves concatenadas.

3. Sin dependencias de atributos que no son llaves.

7/23/2019 3 formas de BD

8/8

REFERENCIAS BIBLIOGRAFICAS

www.acm.org/classics/nov95 El artculo sobre normalizacin de Wikipedia

Wikipedia article on normalization

en.wikipedia.org/wiki/Database_normalization.

www.acm.org/classics/nov95

http://phlonx.com/resources/nf3/