CURSO BASE DE DATOS I: abril 2011

domingo, 10 de abril de 2011

OTRAS FORMAS DE NORMALIZACION

Forma Normal Boyce-Codd

La Forma Normal de Boyce-Codd (o FNBC) es una forma normal utilizada en la normalización de bases de datos. Es una versión ligeramente más fuerte de la Tercera forma normal (3FN). La forma normal de Boyce-Codd requiere que no existan dependencias funcionales no triviales de los atributos que no sean un conjunto de la clave candidata. En una tabla en 3FN, todos los atributos dependen de una clave, de la clave completa y de ninguna otra cosa excepto de la clave (excluyendo dependencias triviales, como ). Se dice que una tabla está en FNBC si y solo si está en 3FN y cada dependencia funcional no trivial tiene una clave candidata como determinante. En terminos menos formales, una tabla está en FNBC si está en 3FN y los únicos determinantes son claves candidatas.

Cuarta Forma Normal

La cuarta forma normal (4NF) es una forma normal usada en la normalización de bases de datos. La 4NF se asegura de que las dependencias multivaluadas independientes estén correcta y eficientemente representadas en un diseño de base de datos. La 4NF es el siguiente nivel de normalización después de la forma normal de Boyce-Codd (BCNF).
Una tabla está en 4NF si y solo si esta en Tercera forma normal o en BCNF (Cualquiera de ambas) y no posee dependencias multivaluadas no triviales. La definición de la 4NF confía en la noción de una dependencia multivaluada. Una tabla con una dependencia multivaluada es una donde la existencia de dos o más relaciones independientes muchos a muchos causa redundancia; y es esta redundancia la que es suprimida por la cuarta forma normal.

Quinta Forma Normal o Forma Normal de Proyección-Unión

La quinta forma normal (5FN), también conocida como forma normal de proyección-unión (PJ/NF), es un nivel de normalización de bases de datos designado para reducir redundancia en las bases de datos relacionales que guardan hechos multi-valores aislando semánticamente relaciones múltiples relacionadas. Una tabla se dice que está en 5NF si y sólo si está en 4NF y cada dependencia de unión (join) en ella es implicada por las claves candidatas.

Forma Normal de Proyección-Unión Fuerte, Extra Fuerte Y Clave de Dominio

Forma Normal de Proyección-Unión, Forma Normal de Proyección-Unión Fuerte, Forma Normal de Proyección-Unión Extra Fuerte y Forma Normal de Clave de Dominio. Estas formas de normalización pueden llevar las cosas más allá de lo que necesita. Éstas existen para hacer una base de datos realmente relacional. Tienen que ver principalmente con dependencias múltiples y claves relacionales.

viernes, 8 de abril de 2011

TAREA DE NORMALIZACION FACTURACION

EJEMPLO DE NORMALIZACION CON FACTURACION:

Factura

Num_Factura	Fecha	Nom_Cliente	Dir_Cliente	Nit_Cliente
4545	11/07/11	Juan Perez	Zona 11	417823-8
8456	08/08/11	Ana Amado	Zona 12	454586-9
4585	06/02/11	Soila Sanchez	Zona 13	825968-2

Factura

Nom_Vendedor	Cant_Prod	Desc_Prod	Precio_Unitario	Precio_Total	Total de Factura
Jose Paz	2	Brochas	15	30	755
Mario Coj	5	Laminas	95	475	755
Ana Solis	5	Sacos de Cal	50	250	755

1FN

Factura

Num_Fact	Fecha	Nom_Cliente	Dir_Cliente	Nit_Cliente	Nom_Vend	Total_Fact
4545	11/07/11	Juan Perez	Zona 11	417823-8	Jose Paz	755
8456	08/08/11	Ana Amado	Zona 12	454586-9	Mario Coj	755
4585	06/02/11	Soila Sanchez	Zona 13	825968-2	Ana Solis	755

DetalleFactura

Num_Fact	Cod_Prod	Cant_Prod	Desc_Prod	Precio_Uni	Precio_Total
4545	GLX	15	Brochas	15	30
8456	HSM	95	Laminas	95	475
4585	ADR	50	Sacos de Cal	50	250

2FN

Factura

Num_Fact	Fecha	Nom_Cliente	Dir_Cliente	Nit_Cliente	Nom_Vend	Total de Factura
4545	11/07/11	Juan Perez	Zona 11	417823-8	Jose Paz	755
8456	08/08/11	Ana Amado	Zona 12	454586-9	Mario Coj	755
4585	06/02/11	Soila Sanchez	Zona 13	825968-2	Ana Solis	755

DetalleFactura

Num_Fact	Cod_Producto	Cant_Prod	Precio Total
4545	GLX	15	30
8456	HSM	95	475
4585	ADR	50	250

Producto

Cod_Producto	Descripcion_Producto	Precio Unitario
GLX	Brochas	15
HSM	Laminas	95
ADR	Sacos de Cal	50

3FN

Factura

Num_Fact	Fecha	Cod_Cliente	Cod_Vendedor	Total Factura
4545	11/07/11	M5	J8G	755
8456	08/08/11	G7	D5D	755
4585	06/02/11	B8	S6R	755

Vendedor

CodigoVendedor	NombreVendedor
J8G	Jose Paz
D5D	Mario Coj
S6R	Ana Solis

Cliente

Cod_Cliente	Nom_Cliente	Dir_Cliente	Nit_Cliente
M5	Juan Perez	Zona 11	417823-8
G7	Ana Amado	Zona 12	454586-9
B8	Soila Sanchez	Zona 13	825968-2

DetalleFactura

Num_Factura	Cod_Factura	CantidadProducto	PrecioTotal
4545	JMS	15	30
8456	ASE	95	475
4585	ESR	50	250

Producto

CodigoProducto	DescripcionProducto	PrecioTotal
GLX	Brochas	30
HSM	Laminas	475
ADR	Sacos de Cal	250

domingo, 3 de abril de 2011

2do Ejemplo

Supongamos que nos plantean desarrollar una B.D. para una empresa de transporte que quiere
gestionar los envíos de pedidos a los clientes. Podemos plantearnos un diseño inicial de una tabla
para esta base de datos que contenga la información del código del envío, el camión que lo
transporta, los datos del cliente al que va dirigido así como cada uno de los artículos que
componen el envío incluyendo sus características, tal y como se muestra en la figura siguiente:

ENVIO
Codigo_envio
Matricula_camion
Modelo_camion
Capacidad_camion
Cliente_1
Direccion_cliente_1
Pedido_cliente_1
Articulo_1_pedido_cliente_1
Volumen_articulo_1_pedido_cliente_1
…
Articulo_I_pedido_cliente_1
Volumen_articulo_I_pedido_cliente_1
…
Cliente_N
Direccion_cliente_N
Pedido_cliente_N
Articulo_1_pedido_cliente_N
Volumen_articulo_1_pedido_cliente_N
…
Articulo_J_pedido_cliente_N
Volumen articulo J pedido cliente N

Es evidente que este diseño inicial no es bueno, por lo que habrá
que aplicar las tres primeras formas normales y llevar el diseño a
3FN.

La 1FN debemos aplicarla a la tabla ENVIO, obteniendo una nueva tabla PEDIDO, sobre la cual
debemos volver a aplicar la 1FN, obteniendo una nueva tabla PEDIDO_ARTICULO, para poder
tener valores atómicos. Después de esto, el esquema queda como sigue:
ENVIO
Codigo_envio
Matricula_camion
Modelo_camion
Capacidad_camion

PEDIDO_CLIENTE
Pedido_cliente
Cliente
Direccion_cliente
Codigo_envio

PEDIDO_ARTICULO
Pedido_cliente
Codigo_articulo
Volumen

Apliquemos ahora la 2FN; observamos que en la tabla PEDIDO_ARTICULO el campo volumen
solo depende del codigo_articulo, no dependiendo para nada del pedido_cliente, por lo cual
obtenemos una nueva tabla, que llamaremos ARTICULO:

ENVIO
Codigo_envio
Matricula_camion
Modelo_camion
Capacidad_camion

PEDIDO_CLIENTE
Pedido_cliente
Cliente
Direccion_cliente
Codigo_envio

PEDIDO_ARTICULO
Pedido_cliente
Codigo_articulo

ARTICULO
Codigo articulo
Volumen

Aplicando la 3FN, vemos que en la tabla ENVIO los datos modelo_camion y capacidad_camion
dependen de matricula_camion, que no es clave primaria, por lo cual debemos sacarlos en una
nueva tabla. Esto mismo sucede con el dato direccion_cliente respecto a cliente en la tabla
PEDIDO_CLIENTE. Teniendo esto en cuenta, el diseño final queda como:

CLIENTE
Cliente
Direccion_cliente

ENVIO
Codigo_envio
Matricula_camion

PEDIDO_CLIENTE
Pedido_cliente
Cliente
Codigo_envio

PEDIDO_ARTICULO
Pedido_cliente
Codigo_articulo

CAMION
Matricula_camion
Modelo_camion
Capacidad_camion

ARTICULO
Codigo articulo
Volumen

Normalizacion de Base de Datos (las 3 formas normales)

Existen 3 niveles de Normalización que deben respetarse para poder decir que nuestra Base de Datos, se encuentra NORMALIZADA, es decir, que cumple con los requisitos naturales para funcionar optimamente y no perjudicar las Performance por mala arquitectura.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 deberia figurar el codigo del cliente, para que el resto de los datos se puedan referenciar automaticamente sin problemas y sin duplicar información.Lo mismo ocurriria en una tabla de detalle de ventas, si por cada item vendido colocamos el detalle del producto, con su descripción , medidas, etc…Tendriamos 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 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.

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 :

Ninguna Columna puede depender de una columna que no tenga una clave
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.

1er Ejemplo

Tenemos una empresa pública donde los puestos de trabajo están regulados por el Estado, de modo que las condiciones salariales están determinadas por el puesto. Se ha creado el siguiente esquema relacional

EMPLEADOS(nss, nombre, puesto, salario, emails) con nss como clave primaria.

Primera forma normal (1FN)

Una tabla está en 1FN si sus atributos contienen valores atómicos. En el ejemplo, podemos ver que el atributo emails puede contener más de un valor, por lo que viola 1FN.

En general, tenemos una relación R con clave primaria K. Si un atributo M viola la condición de 1FN, tenemos dos opciones.

Solución 1: duplicar los registros con valores repetidos

En general, esta solución pasa por sustituir R por una nueva relación modificada R', en la cual:

El atributo M que violaba 1FN se elimina.
Se incluye un nuevo atributo M' que solo puede contener valores simples, de modo que si R'[M'] es uno de los valores que teníamos en R[M], entonces R'[K] = R[K]. En otras palabras, para una tupla con nvalores duplicados en M, en la nueva relación habrá n tuplas, que sólo varían en que cada una de ellas guarda uno de los valores que había en M.
La clave primaria de R' es (K, M'), dado que podrá haber valores de K repetidos, para los valores multivaluados en M.

Siguiendo el ejemplo, tendríamos el siguiente esquema para la nueva tabla EMPLEADOS'(a) con clave primaria (nss, email):

TABLE 2
nss	nombre	puesto	salario	email
111	Juan Pérez	Jefe de Área	3000	juanp@ecn.es
111	Juan Pérez	Jefe de Área	3000	jefe2@ecn.es
222	José Sánchez	Administrativo	1500	jsanchez@ecn.es
333	Ana Díaz	Administrativo	1500	adiaz@ecn.es
333	Ana Díaz	Administrativo	1500	ana32@gmail.com
...	...	...	...	...

Solución 2: separar el atributo que viola 1FN en una tabla

En general, esta solución pasa por:

sustituir R por una nueva relación modificada R' que no contiene el atributo M.

Crear una nueva relación N(K, M'), es decir, una relación con una clave ajena K referenciando R', junto al atributo M', que es la variante mono-valuada del atributo M.

La nueva relación N tiene como clave (K, M').

Siguiendo el ejemplo, tendríamos el siguiente esquema para la nueva tabla EMPLEADOS'(b)

TABLE 3
nss	nombre	puesto	salario
111	Juan Pérez	Jefe de Área	3000
222	José Sánchez	Administrativo	1500
333	Ana Díaz	Administrativo	1500
...	...	...	...

Y además tendríamos una nueva tabla EMAILS con clave primaria (nss, email):

TABLE 4
nss	email
111	juanp@ecn.es
111	jefe2@ecn.es
222	jsanchez@ecn.es
333	adiaz@ecn.es
333	ana32@gmail.com
...	...

Segunda forma normal (2FN)

Un esquema está en 2FN si:

Está en 1FN.

Todos sus atributos que no son de la clave principal tienen dependencia funcional completa respecto de todas las claves existentes en el esquema. En otras palabras, para determinar cada atributo no clave se necesita la clave primaria completa, no vale con una subclave.

La 2FN se aplica a las relaciones que tienen claves primarias compuestas por dos o más atributos. Si una relación está en 1FN y su clave primaria es simple (tiene un solo atributo), entonces también está en 2FN. Por tanto, de las soluciones anteriores, la tabla EMPLEADOS'(b) está en 1FN (y la tabla EMAILS no tiene atributos no clave), por lo que el esquema está en 2FN. Sin embargo, tenemos que examinar las dependencias funcionales de los atributos no clave de EMPLEADOS'(a). Las dependencias funcionales que tenemos son las siguientes:

nss->nombre, salario, email

puesto->salario

Como la clave es (nss, email), las dependencias de nombre, salario y email son incompletas, por lo que la relación no está en 2FN.

En general, tendremos que observar los atributos no clave que dependan de parte de la clave.

Para solucionar este problema, tenemos que hacer lo siguiente para los gupos de atributos con dependencia incompleta M:

Eliminar de R el atributo M.

Crear una nueva relación N con el atributo M y la parte de la clave primaria K de la que depende, que llamaremos K'.

La clave primaria de la nueva relación será K'.

Siguiendo el ejemplo anterior, crearíamos una nueva relación con los atributos que tienen dependencia incompleta

TABLE 5
nss	nombre	puesto	salario
111	Juan Pérez	Jefe de Área	3000
222	José Sánchez	Administrativo	1500
333	Ana Díaz	Administrativo	1500
...	...	...	...

Y al eliminar de la tabla original estos atributos nos quedaría:

TABLE 6
nss	email
111	juanp@ecn.es
111	jefe2@ecn.es
222	jsanchez@ecn.es
333	adiaz@ecn.es
333	ana32@gmail.com
...	...

Como vemos, la solución a la que llegamos es la misma que en la otra opción de solución para el problema de 1FN.

Tercera forma normal (3FN)

Una relación está en tercera forma normal si, y sólo si:

está en 2FN

y, además, cada atributo que no está incluido en la clave primaria no depende transitivamente de la clave primaria.

Por lo tanto, a partir de un esquema en 2FN, tenemos que buscar dependencias funcionales entre atributos que no estén en la clave.

En general, tenemos que buscar dependencias transitivas de la clave, es decir, secuencias de dependencias como la siguiente: K->A y A->B, donde A y B no pertenecen a la clave. La solución a este tipo de dependencias está en separar en una tabla adicional N el/los atributos B, y poner como clave primaria de N el atributo que define la transitividad A.

Siguiendo el ejemplo anterior, podemos detectar la siguiente transitividad:

nss->puesto

puesto->salario

Por lo tanto la descomposición sería la siguiente:

TABLE 7
nss	nombre	puesto
111	Juan Pérez	Jefe de Área
222	José Sánchez	Administrativo
333	Ana Díaz	Administrativo
...	...	...

En la nueva tabla PUESTOS, la clave sería el puesto, que también queda como clave ajena referenciando la tabla EMPLEADOS. El resto de las tablas quedan como estaban.

nss nombre puesto salario emails

111 Juan Pérez Jefe de Área 3000 juanp@ecn.es; jefe2@ecn.es

222 José Sánchez Administrativo 1500 jsanchez@ecn.es

333 Ana Díaz Administrativo 1500 adiaz@ecn.es; ana32@gmail.com

... ... ... ... ...