CodAlumno
CodUniversidad
NombreAlumno
ApellidoAlumno
AñosNombreUniversidad
10 100 Luis González 3 UJAP
15 120 Vanessa Muñoz 2 CARABOBO
25 130 María Blanco 5 CUAM
35 140 Rafael Rodríguez 3 UNITEC
45 150 Ruth Nieves 6 BUAP
55 100 Rafael Rodríguez 4 UJAP
65 200 Karla Polanco 3 UAM
SEGUNDA FORMA NORMAL
TERCERA FORMA NORMAL
DEPENDENCIA TRANSITIVA: Sean A, B, C, tres campos o colección de
campos de una relación R. sí C es funcionalmente dependiente de B, y B lo es
de A, entonces C es funcionalmente dependiente de A. Sí A no es
funcionalmente dependiente de B, o B no lo es de C, entonces, se dice que C
es transitivamente dependiente de A.
La Transitividad se da cuando un atributo NO CLAVE depende
funcionalmente de un atributo que a su vez depende de la clave primaria,
es decir, depende de un campo no clave.
Para eliminar la transitividad se crean tantas tablas como sean necesarias,
donde los campos que dependen transitivamente de un atributo, pasen a
depender directamente de una clave.
LA TERCERA FORMA NORMAL CONSISTE EN ELIMINAR LAS
DEPENDENCIAS TRANSITIVAS
Ejemplo:
CIUDADES (Ciudad, Población, Superficie, País, Continente)
• Los atributos como Población y Superficie tienen dependencia funcional de
Ciudad
• En esta relación podemos encontrar además las siguientes dependencias:
Ciudad ---> País, País ---> Continente, Además, País --->| Ciudad
TERCERA FORMA NORMAL
Es decir, cada ciudad pertenece a un país y cada país pertenece a un continente,
pero en cada país pueden haber muchas ciudades. En este caso continente tiene
una dependencia funcional transitiva con respecto a ciudad, a través de país. Es
decir, cada ciudad está en un país, pero también en un continente.
Para eliminar la transitividad se crean tantas tablas como sean necesarias, donde los campos que dependen transitivamente de un atributo, pasen a depender directamente de una clave.
TERCERA FORMA NORMAL
IdCiudad NombreC Población Superficie PaísContinente
1 Paris 6000000 15 Francia Europa
2 Lion 35000000 9 Francia Europa
3 Pekin 75000000 16 China Asia
4 Berlin 19000000 36 Alemania EuropaExiste una relación entre país y continente, y ninguna de esos atributos es clave candidata. Por lo tanto, si queremos que nuestra tabla este en 3FN debemos separar esa columna:
CIUDADES
IdCiudadNombreC
PoblaciónNombrePaís
1 Paris 6000000 Francia
2 Lion35000000
Francia
3 Pekin75000000
China
4 Berlin19000000
Alemania
PAISES
NombrePaísNombreContinente
Francia Europa
Francia Europa
China Asia
Alemania Europa
•Tercera Forma Normal (3FN): Una relación se halla en 3FN si se encuentra en 2FN y cada uno de sus atributos no primos, son dependientes no transitivos de cada clave de R
TERCERA FORMA NORMAL
•Tercera Forma Normal (3FN): Una relación se halla en 3FN si y sólo si se encuentra en 2FN y además, cada atributo no clave depende de la clave primaria de modo no transitivo. Dicho de otra forma, una relación esta en tercera forma normal si y sólo si sus atributos no clave son:
•Mutuamente Independientes: es decir, no existe un atributo NO clave que dependa funcionalmente de alguna combinación del resto de los atributos No clave; por lo tanto
•Son completamente dependientes de la clave primaria
Para ver de forma práctica, como hacer uso de la teoría de Normalización de una Base
de Datos, vamos a ir aplicando cada una de las formas normales sobre un ejemplo
práctico en que se nos pide diseñar una base de datos para la parte de una empresa
correspondiente a la facturación de los clientes.
FACTURAFACTURA
Cod_Factura
Cod_Cliente
Nombre_Cliente
Dirección_Cliente
Ciudad
Fecha_Factura
Forma_Pago
Cod_Articulo
Descripción
Cantidad
Monto
IVA
METODOLOGÍA DE NORMALIZACIÓN
Para identificar la factura, hemos elegido como
clave primaria el código de la Factura y además
hemos indicado que necesariamente una factura
debe tener esos campos.
A este diseño inicial de las Facturas, al cual
debemos aplicarle la metodología de las formas
normales para ver si se trata de un buen diseño
de base de datos.
PRIMERA FORMA NORMAL
Se considera que está en 1FN si cada atributo (campo) de una tabla contiene
un solo valor atómico (simple). Un atributo que contiene varios valores puede
ocasionar una perdida de datos (información).
Analizando el diseño inicial de la tabla FACTURA,
observamos la existencia de múltiples valores
para los atributos siguientes: cod_Articulo,
Descripción, Cantidad, Monto e IVA. Por lo
tanto vemos que no cumple con la condición de
1FN.
FACTURAFACTURA
Cod_Factura
Cod_Cliente
Nombre_Cliente
Dirección_Cliente
Ciudad
Fecha_Factura
Forma_Pago
Cod_Articulo
Descripción
Cantidad
Monto
IVA
La solución consiste en crear una nueva tabla a la
que llamaremos DETALLE_FACTURA, la cual
tendrá los campos referente a los articulos
( Cod_Articulo, Descripci{on, Cantidad, Importe e
IVA)
PRIMERA FORMA NORMAL
DETALLE_FACTURADETALLE_FACTURA
Cod_Factura
Cod_Articulo
Descripción
Cantidad
Monto
IVA
El diseño de la base de datos para las
facturas en 1FN seria el siguiente:
FACTURAFACTURA
Cod_Factura
Cod_Cliente
Nombre_Cliente
Dirección_Cliente
Ciudad
Fecha_Factura
Forma_Pago
Como regla, cuando se produce la separación de datos de la tabla
original en una nueva tabla, además de los atributos necesarios, se
agrega la clave primaria de la tabla original como parte de su
nueva clave primaria, pro lo tanto la nueva tabla estará formada
pro dos atributos.
SEGUNDA FORMA NORMAL
La 2FN se relaciona con el concepto de dependencia funcional. Se entiende por
dependencia funcional , a la relación que tienen los campos de una tabla con otros
atributos de la propia tabla. Un campo tiene dependencia funcional si necesita
información de otro campo para poder contener su valor.
Una tabla se dice que esta en 2FN si:
• Está en 1FN
• Cada atributo (campo) no clave depende totalmente de la clave primaria y no de
parte de ella
CodAlumn
o
CodUniversida
d
NombreAlumno
ApellidoAlumno
AñosNombre
Universidad
10 100 Luis González 3 UJAP
El objetivo principal de la 2FN es identificar todas las tablas con una clave
compuesta, puesto que todas aquellas tablas con clave simple están por defecto en
2FN.
SEGUNDA FORMA NORMAL
DETALLE_FACTURADETALLE_FACTURA
Cod_Factura
Cod_Articulo
Descripción
Cantidad
Monto
IVA
FACTURAFACTURA
Cod_Factura
Cod_Cliente
Nombre_Cliente
Dirección_Cliente
Ciudad
Fecha_Factura
Forma_Pago
Siguiendo con el ejemplo, la tabla FACTURA se encuentra en 2FN pues esta en
1FN y su claves primaria es única. Sin embargo la tabla DETALLE_FACTURA ha de
ser analizada pues su clave es compuesta, es decir, esta formada por dos campos.
SEGUNDA FORMA NORMAL
DETALLE_FACTURADETALLE_FACTURA
Cod_Factura
Cod_Articulo
Cantidad
Monto
IVA
Analizando la tabla Detalle_Factura, vemos que el atributo descripción depende
únicamente del campo Cod_Articulo, por lo tanto la descripción debe ser llevada
a una nueva tabla junto con el atributo clave Cod_Articulo.
El campo IVA se aplica en común para toda la factura y no depende en cada
factura de los artículos. Por lo tanto, en este caso, el atributo IVA solo
dependerá funcionalmente de Cod_Factura, por lo que deber ser agregado en
la tabla FACTURA como un único campo IVA que depende totalmente de la
clave primaria Cod_Factura.
ARTICULOARTICULO
Cod_Articulo
Descripción
DETALLE_FACTURADETALLE_FACTURA
Cod_Factura
Cod_Articulo
Descripción
Cantidad
Monto
IVA
SEGUNDA FORMA NORMAL
Con este análisis el diseño de la base de datos para las facturas de la empresa
expresado en 2FN sería el siguiente:
FACTURAFACTURA
Cod_Factura
Cod_Cliente
Nombre_Cliente
Dirección_Cliente
Ciudad
Fecha_Factura
Forma_Pago
IVA
DETALLE_FACTURADETALLE_FACTURA
Cod_Factura
Cod_Articulo
Cantidad
Monto ARTICULOARTICULO
Cod_Articulo
Descripción
TERCERA FORMA NORMAL
Se dice que una tabla esta en 3FN (Tercera Forma Normal) si:
• Esta en 2FN
• Todos los atributos (campos) que no son claves deben ser mutuamente
independientes, es decir, un campo no debe depender de otro atributo no
clave de su tabla.
• Si un campo que no es clave depende de otro campo que no es clave, la
tabla posiblemente contiene datos acerca de más de una entidad,
contradiciendo el principio de que cada tabla debe almacenar información de
una sola entidad.
FACTURAFACTURA
Cod_Factura
Cod_Cliente
Nombre_Cliente
Dirección_Cliente
Ciudad
Fecha_Factura
Forma_Pago
IVA
DETALLE_FACTURADETALLE_FACTURA
Cod_Factura
Cod_Articulo
Cantidad
Monto
ARTICULOARTICULO
Cod_Articulo
Descripción
TERCERA FORMA NORMAL
En nuestro ejemplo podemos observar que las tablas ARTICULO y
DETALLE_FACTURA se encuentran en 3FN.
Sin embargo, la tabla FACTURA no esta en Tercera Forma Normal (3FN), pues los
atributos Nombre_Cliente, Dirección_cliente, Ciudad dependen
funcionalmente del campo (atributo) Cod_cliente, campo que NO es clave.
DETALLE_FACTURADETALLE_FACTURA
Cod_Factura
Cod_Articulo
Cantidad
Monto
ARTICULOARTICULO
Cod_Articulo
Descripción
FACTURAFACTURA
Cod_Factura
Cod_Cliente
Nombre_Cliente
Dirección_Cliente
Ciudad
Fecha_Factura
Forma_Pago
IVA
Aplicando esto, nuestro diseño de la Base de Datos para las FACTURAS da lugar a
las tablas que pueden verse a continuación en la siguiente figura y que ya están en
3FN por lo que podemos considerar que es un buen diseño.
TERCERA FORMA NORMAL
FACTURAFACTURA
Cod_Factura
Cod_Cliente
Fecha_Factura
Forma_Pago
IVA
DETALLE_FACTURADETALLE_FACTURA
Cod_Factura
Cod_Articulo
Cantidad
Monto
ARTICULOARTICULO
Cod_Articulo
Descripción
CLIENTE
Cod_Cliente
Nombre_Cliente
Dirección_Cliente
Ciudad