SEGUNDA FORMA NORMAL Cod Nombre Alumno Universidad Alumno

SEGUNDA FORMA NORMAL Cod Nombre Alumno Universidad Alumno Apellido Alumno Años Nombre Universidad 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

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. Id. Ciudad Nombre. C Población Superficie País Continente 1 Paris 6000000 15 Francia Europa 2 Lion 35000000 9 Francia Europa 3 Pekin 75000000 16 China Asia 4 Berlin 19000000 36 Alemania Europa 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 3 FN debemos separar esa columna: CIUDADES PAISES Id. Ciudad Nombre. C Población Nombre. País Nombre. Continente 1 Paris 6000000 Francia Europa 2 Lion 35000000 Francia Europa 3 Pekin 75000000 China Asia 4 Berlin 19000000 Alemania Europa

TERCERA FORMA NORMAL • Tercera Forma Normal (3 FN): Una relación se halla en 3 FN si se encuentra en 2 FN y cada uno de sus atributos no primos, son dependientes no transitivos de cada clave de R • Tercera Forma Normal (3 FN): Una relación se halla en 3 FN si y sólo si se encuentra en 2 FN 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 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. Dirección_Cliente Ciudad Fecha_Factura A este diseño inicial de las Facturas, al cual debemos aplicarle Forma_Pago la metodología de las formas normales para ver si se trata de Cod_Articulo un buen diseño de base de datos. Descripción Cantidad Monto IVA

PRIMERA FORMA NORMAL Se considera que está en 1 FN 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 Analizando el diseño inicial de la tabla FACTURA, Cod_Cliente observamos la existencia de Nombre_Cliente atributos siguientes: cod_Articulo, Descripción, Cantidad, Dirección_Cliente Monto e IVA. Por lo tanto vemos que no cumple con la Ciudad condición de 1 FN. múltiples valores para los Fecha_Factura Forma_Pago Cod_Articulo Descripción La solución consiste en crear una nueva tabla a la que llamaremos DETALLE_FACTURA, la cual tendrá los campos Cantidad referente a los articulos ( Cod_Articulo, Descripci{on, Monto Cantidad, Importe e IVA) IVA

PRIMERA FORMA NORMAL El diseño de la base de datos para las facturas en 1 FN seria el siguiente: DETALLE_FACTURA Cod_Factura Cod_Articulo Cod_Cliente Descripción Nombre_Cliente Cantidad Dirección_Cliente Monto Ciudad IVA 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 2 FN 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 2 FN si: • Está en 1 FN • Cada atributo (campo) no clave depende totalmente de la clave primaria y no de parte de ella Cod Alumno Universidad 10 100 Nombre Alumno Apellido Alumno Años Nombre Universidad Luis González 3 UJAP

SEGUNDA FORMA NORMAL El objetivo principal de la 2 FN es identificar todas las tablas con una clave compuesta, puesto que todas aquellas tablas con clave simple están por defecto en 2 FN. Siguiendo con el ejemplo, la tabla FACTURA se encuentra en 2 FN pues esta en 1 FN 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 ARTICULO Cod_Factura Cod_Articulo Descripción Cantidad Monto IVA 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 Con este análisis el diseño de la base de datos para las facturas de la empresa expresado en 2 FN sería el siguiente: FACTURA Cod_Factura Cod_Cliente Nombre_Cliente Dirección_Cliente Ciudad DETALLE_FACTURA Fecha_Factura Cod_Factura Forma_Pago Cod_Articulo IVA Cantidad Monto ARTICULO Cod_Articulo Descripción

TERCERA FORMA NORMAL Se dice que una tabla esta en 3 FN (Tercera Forma Normal) si: • Esta en 2 FN • 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 FACTURA contiene datos acerca de más de una entidad, contradiciendo el principio de que cada tabla debe Cod_Factura almacenar información de una sola entidad. Cod_Cliente Nombre_Cliente Dirección_Cliente DETALLE_FACTURA Ciudad Cod_Factura Fecha_Factura Cod_Articulo Forma_Pago Cantidad IVA Monto ARTICULO Cod_Articulo Descripción

TERCERA FORMA NORMAL En nuestro ejemplo podemos observar que las tablas ARTICULO y DETALLE_FACTURA se encuentran en 3 FN. DETALLE_FACTURA Sin embargo, la tabla FACTURA no esta en Tercera Forma Normal (3 FN), pues los atributos ARTICULO Cod_Factura Dirección_cliente, Ciudad dependen funcionalmente del campo (atributo) Nombre_Cliente, Cod_Articulo Descripción Cod_cliente, campo que NO es clave. Cantidad Monto FACTURA Cod_Factura Cod_Cliente Nombre_Cliente Dirección_Cliente Ciudad Fecha_Factura Forma_Pago IVA

TERCERA FORMA NORMAL 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 3 FN por lo que podemos considerar que es un buen diseño. FACTURA CLIENTE Cod_Factura Cod_Cliente Nombre_Cliente Fecha_Factura Forma_Pago IVA DETALLE_FACTURA Cod_Factura Cod_Articulo Cantidad Monto Dirección_Cliente Ciudad ARTICULO Cod_Articulo Descripción