SEGUNDA FORMA NORMAL Cod Alumno Universidad Nombre Apellido Años 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 UNITEC 45 150 Ruth Nieves 6 BUAP 55 4 65 200 Karla Polanco UAM

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.

TERCERA FORMA NORMAL 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. LA TERCERA FORMA NORMAL CONSISTE EN ELIMINAR LAS DEPENDENCIAS TRANSITIVAS

TERCERA FORMA NORMAL 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ís Continente 1 Paris 6000000 15 Francia Europa 2 Lion 35000000 9 3 Pekin 75000000 16 China Asia 4 Berlin 19000000 36 Alemania Existe 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 IdCiudad NombreC Población NombrePaís 1 Paris 6000000 Francia 2 Lion 35000000 3 Pekin 75000000 China 4 Berlin 19000000 Alemania PAISES NombrePaís NombreContinente Francia Europa China Asia Alemania

TERCERA FORMA NORMAL 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

METODOLOGÍA DE NORMALIZACIÓN 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. FACTURA Cod_Factura Cod_Cliente Nombre_Cliente Dirección_Cliente Ciudad Fecha_Factura Forma_Pago Cod_Articulo Descripción Cantidad Monto IVA 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). FACTURA Cod_Factura Cod_Cliente Nombre_Cliente Dirección_Cliente Ciudad Fecha_Factura Forma_Pago Cod_Articulo Descripción Cantidad Monto IVA 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. 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_FACTURA FACTURA Cod_Factura El diseño de la base de datos para las facturas en 1FN seria el siguiente: DETALLE_FACTURA Cod_Factura Cod_Articulo Descripción Cantidad Monto IVA FACTURA 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 Cod Alumno Universidad Nombre Apellido Años 10 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 Cod Alumno Universidad Nombre Apellido Años 10 100 Luis González 3 UJAP

SEGUNDA FORMA NORMAL 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. 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. FACTURA Cod_Factura Cod_Cliente Nombre_Cliente Dirección_Cliente Ciudad Fecha_Factura Forma_Pago DETALLE_FACTURA Cod_Factura Cod_Articulo Descripción Cantidad Monto IVA

SEGUNDA FORMA NORMAL 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. DETALLE_FACTURA Cod_Factura Cod_Articulo Descripción Cantidad Monto IVA DETALLE_FACTURA Cod_Factura Cod_Articulo Cantidad Monto IVA ARTICULO Cod_Articulo Descripción 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.

SEGUNDA FORMA NORMAL FACTURA 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: FACTURA Cod_Factura Cod_Cliente Nombre_Cliente Dirección_Cliente Ciudad Fecha_Factura Forma_Pago IVA DETALLE_FACTURA Cod_Factura Cod_Articulo Cantidad Monto ARTICULO 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. FACTURA Cod_Factura Cod_Cliente Nombre_Cliente Dirección_Cliente Ciudad Fecha_Factura Forma_Pago IVA DETALLE_FACTURA Cod_Factura Cod_Articulo Cantidad Monto ARTICULO Cod_Articulo Descripción

TERCERA FORMA NORMAL DETALLE_FACTURA ARTICULO 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_FACTURA Cod_Factura Cod_Articulo Cantidad Monto ARTICULO Cod_Articulo Descripción FACTURA Cod_Factura Cod_Cliente Nombre_Cliente Dirección_Cliente Ciudad Fecha_Factura Forma_Pago IVA

TERCERA FORMA NORMAL CLIENTE 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. FACTURA Cod_Factura Cod_Cliente Fecha_Factura Forma_Pago IVA CLIENTE Cod_Cliente Nombre_Cliente Dirección_Cliente Ciudad DETALLE_FACTURA Cod_Factura Cod_Articulo Cantidad Monto ARTICULO Cod_Articulo Descripción