cbtis243CATEDRATICO:

Cornelio Alberto Pérez mendaz

ALUMNA:

Bartolon Perez victoria

INVESTIGACIO:

3 formas normales para aplicar en un diseño de BD.

ESPECIALIDAD:

Ofimatica

MATERIA:

Modulo

GRADO Y GRUPO:

5to. (A)

FECHA:

23/09/2015INTRODUCCION

En este tema conoceremos las 3 formas normale para la aplicaciones de un

diseño de base de datos. Conociendo cada uno de su significado sus aplicaciones,

con sus devidas imagenes y ejemplos tratando de tener una mejor comprension.

Como también recordaremos las entidades vistas de uno a uno, de uno a

muchos, de muchos a muchos de los siguientes temas que a continuación se

muestran:

normalización

primera forma normal

segunda forma normal

tercera forma normal

modelo entidad relación

relación uno a uno

relación uno a vario

relación varios a varios

Yaqué son temas de gran importancia para la elaboración de una base de

datos (bd) conociendo cada una de sus partes y formas.

DESARROLLO

1.- NORMALIZACION: La normalización es el proceso mediante el cual se

transforman datos estructuras de datos más pequeñas, que además de ser más

simples y más estables, son más fáciles de mantener. 

Sirve para: ayudar a los diseñadores de bases de datos a desarrollar un esquema

que minimice los problemas de lógica. Cada regla está basada en la que le

antecede.

2.- Primera Forma Normal (1FN): La regla de la Primera Forma Normal establece

que las columnas repetidas deben eliminarse y colocarse  en tablas separadas.

3: Segunda Forma Normal (2fn): La regla de la Segunda Forma Normal

establece que todas las dependencias parciales se deben eliminar y separar

dentro de sus propias tablas. Una dependencia parcial es un término que describe

a aquellos datos que no dependen de la llave primaria de la tabla para

identificarlos.

Una vez alcanzado el nivel de la Segunda Forma Normal, se controlan la mayoría

de los problemas de lógica. Podemos insertar un registro sin un exceso de datos

en la mayoría de las tablas.

4.- Tercera Forma Normal (3fn). Una tabla está normalizada en esta forma si

todas las columnas que no son llave son funcional mente dependientes por

completo de la llave primaria y no hay dependencias transitivas. Comentamos

anteriormente que una dependencia transitiva es aquella en la cual existen

columnas que no son llave que dependen de otras columnas que tampoco son

llave. Cuando las tablas están en la Tercera Forma Normal se previenen errores

de lógica cuando se insertan o borran registros. Cada columna en una tabla está

identificada de manera única por la llave primaria, y no debe haber datos

repetidos. Esto provee un esquema limpio y elegante, que es fácil de trabajar y

expandir.

5.- modelo entidad relación:   El modelo entidad-relación (E-R) es uno de los

varios modelos conceptuales existentes para el diseño de bases de datos. Los

elementos esenciales del modelo son las entidades, los atributos y

las relaciones entre las entidades.

6).-  Relación Uno a Uno: Cuando un registro de una tabla sólo puede estar

relacionado con un único registro de la otra tabla y viceversa.

7).- ejemplos

Por ejemplo: tenemos dos tablas una con los datos de diferentes poblaciones y

otra con una lista de Alcaldes, una población sólo puede tener un alcalde, y un

alcalde lo será únicamente de una población.

Relación Uno a Varios: Cuando un registro de una tabla (tabla secundaria) sólo

puede estar relacionado con un único registro de la otra tabla (tabla principal) y un

registro de la otra tabla (tabla principal) puede tener más de un registro

relacionado en la prijcmera tabla (tabla secundaria).

Por ejemplo: tenemos dos tablas una con los datos de diferentes poblaciones y

otra con los habitantes, una población puede tener más de un habitante, pero un

habitante pertenecerá (estará empadronado) en una única población.

Relación Varios a Varios: Cuando un registro de una tabla puede estar

relacionado con más de un registro de la otra tabla y viceversa.

Por ejemplo: tenemos dos tablas una con los datos de clientes y otra con los

artículos que se venden en la empresa, un cliente podrá realizar un pedido con

varios artículos, y un artículo podrá ser vendido a más de un cliente.

Las relaciones varios a varios se suelen representar definiendo una tabla

intermedia entre las dos tablas. Siguiendo el ejemplo anterior sería definir una

tabla líneas de pedido relacionado con clientes y con artículos.

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

 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 número 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 

 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

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.

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.

 VentaID ItemID ProductoID Cantidad Descripcion Medida Proveedor

 1 1 3455 12Impresora HP

LJ8000122cm 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 deberian estar dentro de la tabla de detalle de ventas, ya que dependen de

PRODUCTOID.Aqui no se trata ya de eliminar grupos repedidos de datos (1ra

Forma Normal) sino que ante la inclusion 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.

CONCLUSION

En conclusión llegue analizar que para ser una base de datos e s importante

conocer cada una de sus formas normales para su elaboración por ejemplo en la

primera forma normal nos habla de que 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 y

pueda repetirse muchas veces. 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 puede contener un volumen de

millones de registros, y la tercera forma pues básicamente lo importante que nos

da a entender es que Ninguna Columna puede depender de una columna que no

tenga una clave no puede haber datos derivados. 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. Yaqué todos estas

indicaciones que nos asigna cada formas es para tener una base de datos, se

podría decir de calidad.

BIBLIOGRAFIA

http://www.eet2mdp.edu.ar/alumnos/MATERIAL/MATERIAL/info/infonorma.pdf

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

s.wikipedia.org/wiki/Forma_normal_(base_de_datos).