Paul Leger http://pleger.cl Formas Normales Paul Leger http://pleger.cl

Formas Normales Codd creo las Formas Normales (FNs) para certificar modelos relacionales/intermedios En un inicio, Codd definió tres formas normales (1 FN, 2 FN y 3 FN). Luego con Boyce, definieron 3FN de Boyce-Codd o simplemente Boyce-Codd FN Hay varias otras formas normales, por ejemplo 4 y 5 FN. Estás dos últimas no serán estudiadas en este curso

Formas Normales Una forma normal establece que un conjunto de restricciones que deben ser satisfechas por el esquema de base datos El objetivo de las formas normales intentan definir de una manera formal los lineamientos del buen diseño de una base de datos Si una relación no cumple con las restricciones, esta relación se descompone para cumplir con la forma normal que se desea alcanzar

Formas Normales 1, 2 y 3 Existen varias FNs, donde cada uno involucra un conjunto de restricciones que se deben cumplir. Generalmente estas restricciones están expresadas en términos de dependencias funcionales Hasta Boyce-Codd FN, si uno tiene su esquema en FN n, entonces su esquema también satisfacen la FN n-1, …, 1

Formas Normales Para cumplir con las restricciones de FNs, es necesario descomponer relaciones en otras relaciones Sin embargo, la descomposiciones implican nuevos “joins” con las nuevas tablas descompuesta Dependiendo del problema, no siempre es necesario llegar a la mejor forma normal, pues su descomposición afecta al rendimiento ¿Por qué?

Beneficios de FNs Aunque cada formal busca un beneficio en particular, sin embargo, en general: Evitar tuplas espurias Conservar las DFs de la descripción

Algunos Conceptos Amigo Superclave es un conjunto de atributos que definen una relación Clave es una superclave, donde ningún atributo puede ser eliminado para seguir siendo superclave Clave candidatas el conjunto de claves Clave primaria (Primary Key) es un clave elegida arbitariamente Atributo primo es un atributo miembro de una clave candidata FACEBOOK Amigo E-mail User Name LastName Identifique: Superclaves, Claves candidata Primary Key Atributos primos en AMIGO

Primera Formal Normal (1 FN) Todo atributo debe ser atómico e indivisibles. Es decir, no debe haber atributos multi-valuados y compuestos Dpto NombreID Jefe BodegaID Un Dpto puede estar en varias bodegas Soluciones: 1- Descomponer en dos tablas (Dpto y bodega) 2- Ampliar la primary key con BodegaID 3- Si son tres bodegas como máximo, definir tres atributos (BodegaID1,BodegaID2, BodegaID3)

Primera Formal Normal (1 FN) Dpto NombreID Jefe BodegaID Bodega BodegaID 1 Se ubica n SOLUCIÓN DESEADA Debemos repetir el proceso para otras violaciones de 1 FN, y volver a descomponer hasta que todo el esquema cumpla 1 FN

Segunda Formal Normal (2 FN) Dependencia Funcional Total es una DF (X->Y) si al restar un atributo a X, X deja de definir a Y, es decir, (X – A) ≠> Y 2 FN exige que la primary key debe ser una dependencia funcional total con respecto a todos los atributos de la relación Obviamente toda relación, donde la primary key tiene un solo atributo, está en 2 FN ---- ¿Por qué? Amigo E-mail User Name LastName Trabaja_en Rut DptoID horas ¿Está en 2FN? ¿Está en 2FN?

Segunda Formal Normal (2 FN) Dpto NombreID Jefe FechaCreación BodegaID Calle Numero Ciudad NombreID, BodegaID -> {Jefe, FechaCreación, Calle, Numero, Ciudad} BodegaID -> {Calle, Numero, Ciudad} Hay un solución mejor, cierto? Dpto NombreID Jefe FechaCreación BodegaID BODEGA1 BodegaID Calle BODEGA2 BodegaID Numero BODEGA3 BodegaID Ciudad

Si está 2 FN, significa que está 1 FN

Tercera Forma Normal (3 FN) La 3 FN está relacionado con las dependencias funcionales transitiva X -> Y, donde, Y -> Z => X -> Z Un esquema está 3 FN, si está en 2 FN y no tiene dependencia transitiva

Tercera Forma Normal (3 FN) Dpto NombreID Jefe FechaCreación BodegaID Calle Numero Ciudad NombreID-> {Jefe, FechaCreación, BodegaID} BodegaID -> {Calle, Numero, Ciudad} Aquí hay una DF transitiva a través de BodegaID, Por lo tanto no está en 3 FN, pero si está en 2 FN ¿Por qué? Dpto NombreID Jefe FechaCreación BodegaID BODEGA BodegaID Calle Numero Ciudad NOTA: Suponga que un Dpto ahora solo puede estar en una bodega

Si está 3 FN, significa que está 2 FN

Solución (normalización) Resumen (1/2) Forma Normal Condición Solución (normalización) 1 FN Una relación no debería tener ningún atributo no atómico Formar relaciones nuevas para cada conjunto de atributos no atómicos 2 FN Para las relaciones en las que la primary key contiene múltiples atributos, ningún atributo no primo debería depender funcionalmente de una parte de la primary key Descomponer y crear una nueva relación por cada atributo dependiente por una parte la primary key. Asegurarse que puede reunir (join) con la tabla original 3 FN Una relación no debería tener un atributo no primo determinado funcionalmente por otro atributo no primos. En otras palabras, no debería existir DF transitiva por parte de un atributo no primo Crear una nueva relación con el conjunto de atributos no primos que determina las otras dependencias

Resumen (2/2) Forma Normal Violaciones 1 FN X ≠> Y, donde X es clave Y son atributos compuestos y multi-valuados 2 FN X -> Y ^ (X - A) -> Y, donde X es una clave candidata, Y es un conjunto de atributos 3 FN X -> Y ^ Y -> Z, donde X es una clave candidata Y es un conjunto de atributos no primos

Ejercicio (1/2) Identifique claves candidatas ¿Está en 2 FN? ¿No? ¿cuál DF rompe está FN?

Ejercicio (2/2) ¿Está en 3 FN? ¿No? ¿cuál DF rompe está FN?

Forma FN BC Esta FN es 3 FN con la restricción que un atributo no primo defina un atributo primo. En imágenes, lo siguiente no esta permitido: ¿Cuál es la solución para este problema? ¿Qué pasaría si la relación solamente fuera R(B,C), con las mismas dependencias?