Está en la página 1de 6

C.B.T.i.

s 243
Catedrtico:
Cornelio Alberto Prez Mndez
Alumna:
Gisela Edith Prez Prez
Especialidad:
Ofimtica
Semestre y grupo:
5to. A
Trabajo:
3 Formas normales para aplicar en un diseo de BD
Fecha de entrega:
23 Septiembre 2015

INTRODUCCIN
En este tema se hablara sobre la conveniencia que tiene crear una base de datos,
as como tambin un ejemplo y su breve explicacin.
Una base de datos ayuda principalmente a que no se baya repitiendo una misma
informacin (que no tenga redundancia). Puede haber base de datos local y en
red, puede ser utilizada por varios usuarios.
Una base de datos tiene tambin muchas caractersticas como son:

Independencia lgica
Redundancia mnima
Acceso concurrente
Consultas complejas
Seguridad de acceso y auditoria

Al disear una base de datos tenemos que considerar dos cosas muy importantes
como son los productos y almacn.
Para crear una base de datos primero hay que investigar, seleccionar un diseo,
ver como funciona ese diseo.

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

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

FechaVenta

ClienteVenta

Producto ID

Cantidad

01/12/2007

2334

10

01/12/2007

3333

01/12/2007

66643

34

01/12/2007

21

02/12/2007

3566

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


toda una venta tendr el mismo numero 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

Venta ID Item ID

Producto Id

Cantidad

2334

10

3333

66643

34

21

3566

Y ahora nuestra nueva tabla maestra


Venta ID

FechaVenta

ClienteVenta

01/12/2007

02/12/2007

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 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 muestra. 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
ID

Cantidad

Descripcin

Medida

Proveedor

3455

12

Impresora
LJ8000

HP 122cm

2455

34

Scanner
A3555

HP 33cm

5444

21

Mouse
Wireless

HP

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

CONCLUSIN
Al realizar esta investigacin pude llegar a la conclusin de que estas tres formas
para disear una base de datos son muy esenciales y muy eficientes con respecto
a la informacin, una base de datos nos facilita demasiado la obtencin de
informacin y hace que por su forma de aplicar nos ahorremos memoria y espacio
en nuestro procesador.
Una base de datos muestra que la redundancia es muy poca puesto que esta
descarta la repeticin de datos, esta siempre tiene un identificar nico para cada
dato. Las tres formas normales nos ayudan demasiado al querer realizar una base
de datos provocando con esto que las tres formas dependan siempre una de otra.
Con esta investigacin nos lleva a la conclusin de que la primer forma su
principal objetivo es eliminar columnas repetidas y colocar la informacin en tablas
separadas, la segunda se refiere que toda columna que no es llave ser
dependiente de la llave primaria y la tercer forma se refiere a que elimina la
dependiente transitiva o fornea.