NORMALIZACION Y RELACIONES EN LAS BASES DE DATOS

12/04/2013
                                                               PERIODO 2


LOGROS
- definir que es normalización y las formas normales
- diseño del modelo entidad relación
-crear bases de datos en axes 2007

                                                                               ACTIVIDAD

1) que es normalización o normalizar en la base de datos

2) que dice la primera forma normal (1fn) y de un ejemplo

3) que dice la segunda forma normal (2fn) y de un ejemplo

4) que dice la tercera forma normal (3fn) y de un ejemplo

5) que es el modelo entidad relación y para que se utilizan las bases de datos

6) que tipos de relaciones se dan entre las tablas que forman una base de datos, defina cada una de ellas y de ejemplos

7) en una hoja del cuaderno diseñe  dibuje el modelo entidad relación para la base de datos de la biblioteca que venimos trabajando

8) en excel diseñe el modelo entidad relación que diseño en la hoja ,tomarle una fotografía y subirla al blog ademas el archivo de excel debe quedar almacenada  en el dropbox en la carpeta informática  2013

NOTA: recordar que cada respuesta debe ir acompañada de la dirección o link de donde se consulte dicha información  ademas de una imagen y un viseo que expliquen dicho tema se debe de leer y entender cada una de las respuestas para poder realizar dicha actividad


                                                                        SOLUCIÓN
1)  El proceso de normalización de bases de datos consiste en aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo entidad-relación al modelo relacional 

Las bases de datos relacionales se normalizan para:

• Evitar la redundancia de los datos.
• Evitar problemas de actualización de los datos en las tablas.
• Proteger la integridad de los datos.

En el modelo relacional es frecuente llamar tabla a una relación, aunque para que una tabla sea considerada como una relación tiene que cumplir con algunas restricciones:

• Cada tabla debe tener su nombre único.
• No puede haber dos filas iguales. No se permiten los duplicados.
• Todos los datos en una columna deben ser del mismo tipo.

http://es.wikipedia.org/wiki/Normalizaci%C3%B3n_de_bases_de_datos

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

ejemplo sin la primera forma normal

CodLibro	Titulo	Autor	Editorial	NombreLector	FechaDev
1001	Variable compleja	Murray Spiegel	McGraw Hill	Pérez Gómez, Juan	15/04/2005
1004	Visual Basic 5	E. Petroustsos	Anaya	Ríos Terán, Ana	17/04/2005
1005	Estadística	Murray Spiegel	McGraw Hill	Roca, René	16/04/2005
1006	Oracle University	Nancy Greenberg y Priya Nathan	Oracle Corp.	García Roque, Luis	20/04/2005
1007	Clipper 5.01	Ramalho	McGraw Hill	Pérez Gómez, Juan	18/04/2005

ejemplo con la primera forma normal

1NF

CodLibro	Titulo	Autor	Editorial	Paterno	Materno	Nombres	FechaDev
1001	Variable compleja	Murray Spiegel	McGraw Hill	Pérez	Gómez	Juan	15/04/2005
1004	Visual Basic 5	E. Petroustsos	Anaya	Ríos	Terán	Ana	17/04/2005
1005	Estadística	Murray Spiegel	McGraw Hill	Roca		René	16/04/2005
1006	OracleUniversity	NancyGreenberg	Oracle Corp.	García	Roque	Luis	20/04/2005
1006	OracleUniversity	Priya Nathan	Oracle Corp.	García	Roque	Luis	20/04/2005
1007	Clipper 5.01	Ramalho	McGraw Hill	Pérez	Gómez	Juan	18/04/2005

http://www.angelfire.com/ult/lupa/bd/normalizacion1.htm

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

3) 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 tuvieramos alguna columna que se repite a lo largo de todos los registros, dichos datos deberian 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

Ahi tenemos un claro problema !!!Acaso no se busca NO 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 ClienteVenta yFechaVenta 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 unico para cada grupo de registros.

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

4) La Tercera Forma Normal En realidad si nos guiamos en el ejemplo de esta nota, ya no quedaria normalización por aplicar y podriamos 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 dependian de la clave principal (VentaID) y que podrian 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	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 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.

ConclusiónFinalmente si tomamos en cuenta que una tabla de detalle de venta (item x item) 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.

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

5) Un diagrama o modelo entidad-relación (a veces denominado por sus siglas en inglés, E-R "Entity relationship", o del español DER "Diagrama de Entidad Relación") es una herramienta para el modelado de datosque permite representar las entidades relevantes de unsistema de información así como sus interrelaciones y propiedades.

http://es.wikipedia.org/wiki/Modelo_entidad-relaci%C3%B3n

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.

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 primera 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, una 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 lineas de pedido relacionada con clientes y con artículos.

http://www.aulaclic.es/access2000/b_5_1_1.htm