cod alumno cod universidad nombre alumno apellido alumno años nombre universidad...

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


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.


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


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.



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.



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


Cod_Factura

Cod_Articulo

Descripción

Cantidad

Monto

IVA


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


Cod_Factura

Cod_Articulo

Cantidad

Monto ARTICULOARTICULO

Cod_Articulo

Descripción


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


Cod_Factura

Cod_Articulo

Cantidad

Monto

ARTICULOARTICULO

Cod_Articulo

Descripción


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.


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.


FACTURAFACTURA

Cod_Factura

Cod_Cliente

Fecha_Factura

Forma_Pago

IVA


Cod_Factura

Cod_Articulo

Cantidad

Monto

ARTICULOARTICULO

Cod_Articulo

Descripción

CLIENTE

Cod_Cliente

Nombre_Cliente

Dirección_Cliente

Ciudad

cod alumno cod universidad nombre alumno apellido alumno años nombre universidad...

Documents