UNIVERSIDAD MAYOR DE SAN ANDRÉS

FAC. CIENCIAS PURAS Y NATURALES

CARRERA DE INFORMÁTICA

  Nombre Univ.: Ivan Sergio Philco Condori

Nombre Univ.: Ronnie Bryan Gutierrez Marca

Nombre Univ.:Gary Alejandro Gutierrez Llanco

Nombre Univ.: Gudnar Adalid Guarachi Cruz

Nombre Univ.: Cecilia Elizabeth Fernandez Tristan

Materia: Diseño y Administración de Base de Datos INF-161

Paralelo: B

Docente: Lic. Aldo Ramiro Valdez Alvarado

Fecha:

NORMALIZACIÓN

Introducción

Formas normales (FN) Conjunto de restricciones sobre tablas relacionales que evitan los problemas de redundancia de datos y de anomalías de modificación, inserción y borrado de datos.

                          1FN =⇒ 2FN =⇒ 3FN =⇒ FNBC =⇒ 4FN =⇒ 5FN  

Mediante el tema de normalización se puede ver los grados de normalización que se puede obtener en las bases de datos relacionales se normalizan para: - Evitar la redundancia de los datos.

- Disminuir problemas de actualización de los datos en las tablas.

- Proteger la integridad de datos.

Objetivo Específico

La normalización de bases de datos es un proceso que consiste en designar y aplicar una serie de reglas a las relaciones obtenidas tras el paso.

1.- Definición

La normalización o estandarización es la redacción y aprobación de normas que se establecen para garantizar el acoplamiento de elementos construidos independientemente, así como garantizar el repuesto en caso de ser necesario, garantizar la calidad de los elementos fabricados y la seguridad de funcionamiento y para trabajar con responsabilidad social. Se aplican a distintas actividades científicas, industriales o económicas con el fin de ordenarlas y mejorarlas.

Según la ISO (Organización Internacional de Normalización) la Normalización es la actividad que tiene por objeto establecer, ante problemas reales o potenciales, disposiciones destinadas a usos comunes y repetidos, con el fin de obtener un nivel de ordenamiento óptimo en un contexto dado, que puede ser tecnológico, político o económico.

Normalización :las reglas de Normalización están encaminadas a eliminar redundancias e inconsistencias de dependencia en el diseño de las tablas. Eliminando grupos de datos repetitivos, separando tablas por grupos relacionados, e identificando los datos relacionados con una clave primaria

2.- Dependencias

El proceso de normalización se basa en relaciones que se conocen que mantienen los datos, principalmente dependencias funcionales, multivaluadas y de join.

2.1.- Dependencia funcional

B es funcionalmente dependiente de A.

Una dependencia funcional es una relación entre uno o más atributos. Por ejemplo, si se conoce el valor de DNI (Documento Nacional de Identidad-España) tiene una conexión con Apellido o Nombre .

Las dependencias funcionales del sistema se escriben utilizando una flecha, de la siguiente manera:

Fecha De Nacimiento Edad

De la normalización (lógica) a la implementación (física o real) puede ser sugerible tener estas dependencias funcionales para lograr la eficiencia en las tablas.

las dependencias funcionales son restricciones del conjunto de relaciones legales, que permiten expresar hechos sobre el problema que se modela con la base de datos.

Consideremos en esquema de una relación R y sean α R y β R. La dependencia funcional α β se cumple para el esquema R si, en cualquier relación legal r(R), para todos los pares de tuplas t1 y t2 de r tales que t1[α] =t2[α], también ocurre que t1 [β] =t2[β]. Definición Formal de DF .

La Entidad Proveedor_Articulo describe los siguientes Atributos: Código del Proveedor, Nombre del Proveedor, Teléfono del Proveedor, Código del Articulo, Descripción del Articulo y Precio del Articulo.

Pero Codigo_a para el valor A20 tiene dos precios 30 y 32, por tanto esta dependencia funcional no se cumple dado el mismo precio a los registros del atributo precio.

Una DF (dependencia funcional) es una restricción sobre una entidad, y no sobre un ejemplar de la entidad. No es posible afirmar el cumplimiento de una DF observando sus ocurrencias en un instante, puesto que pueden cambiar.

Una DF está impuesta por los usuarios del sistema y todas sus ocurrencias deben cumplirlas en todo instante.

Descomposiciones Funcional:

La descomposición funcional se refiere ampliamente al proceso de resolución de una relación funcional en sus partes constituyentes, de tal manera que la función original se puede reconstruir (es decir, recompuestos) de las partes en función de la composición. En general, este proceso de descomposición se lleva a cabo ya sea con el fin de hacerse una idea de la identidad de los elementos constitutivos (que pueden reflejar los procesos individuales de física de interés, por ejemplo), o con el fin de obtener una representación comprimida de la función global, una tarea que sólo es posible cuando los procesos constitutivos poseen un cierto nivel de modularidad (es decir, la independencia o no de interacción).

2.2.- Propiedades de la dependencia funcional

Existen tres axiomas de Armstrong:

2.3.- Dependencia funcional reflexiva

Si "y" está incluido en "x" entonces x   y

A partir de cualquier atributo o conjunto de atributos siempre puede deducirse él mismo. Si la dirección o el nombre de una persona están incluidos en el DNI, entonces con el DNI podemos determinar la dirección o su nombre.

2.4.- Dependencia funcional argumentativa

entonces

DNI,  nombre

DNI,dirección  nombre,dirección

Si con el DNI se determina el nombre de una persona, entonces con el DNI más la dirección también se determina el nombre y su dirección.

2.5.- Dependencia funcional transitiva

Dependencia funcional transitiva.

Sean X, Y, Z tres atributos (o grupos de atributos) de la misma entidad. Si Y depende funcionalmente de X y Z de Y, pero X no depende funcionalmente de Y, se dice entonces que Z depende transitivamente de X. Simbólicamente sería:

X  Y   Z entonces X   Z

FechaDeNacimiento    Edad

Edad  Conducir

FechaDeNacimiento  Edad  Conducir

Entonces entendemos que FechaDeNacimiento determina a Edad y la Edad determina a Conducir, indirectamente podemos saber a través de FechaDeNacimiento a Conducir (En muchos países, una persona necesita ser mayor de cierta edad para poder conducir un automóvil, por eso se utiliza este ejemplo).

"C será un dato simple (dato no primario), B, será un otro dato simple (dato no primario), A, es la llave primaria (PK). Decimos que C dependerá de B y B dependerá funcionalmente de A."

2.6.- Propiedades deducidas

2.6.1.- Unión

X Y  y  X Z entonces  X  Y Z

2.6.2.- Pseudo-Transitiva

 XY y  WYZ entonces WXZ

2.6.3.- Descomposición

XY y Z está incluido en Y entonces  XZ

Dependencias Multivaluadas

En el cálculo relacional de bases de datos, la dependencia multivaluada es una restricción entre dos conjuntos de atributos de una relación, que requiere que ciertas tuplas estén presentes en la misma. Dicha restricción se concreta en la cuarta forma normal.

Sea R un esquema de relación. La dependencia multivaluada X->Y vale en R si los pares de tuplas t1 y t2 en R, tal que t1[X] = t2[X] existen las tuplas t3 y t4 en R tales que:

t1[X] = t2[X] = t3[X] = t4[X]

t3[Y] = t1[Y]

t3[R-X-Y] = t2[R-X-Y]

t4[Y] = t2[Y]

t4[R-X-Y] = t1[R-X-Y]

En otras palabras se puede decir que: X -> Y si dado un valor de X, hay un conjunto de valores de Y asociados y este conjunto de valores de Y NO está relacionado (ni funcional ni multifuncionalmente) con los valores de R - X -Y (donde R es el esquema), es decir Y es independiente de los atributos de R-X-Y. (Cátedra de Base de Datos 1, 2009) Una dependencia multivaluada de la forma X -> Y, es trivial cuando el conjunto de atributos {X,Y} conforma el total de los atributos del esquema.

FORMAS NORMALES

Primera forma normal (1FN)

La primera forma normal (1FN), requiere que los datos sean atómicos. En otras palabras, la 1FN prohíbe a un campo contener más de un dato de su dominio de columna. También exige que todas las tablas deben tener una clave primaria. Por último, indica que una tabla no debe tener atributos que acepten valores nulos.

Cuando no existe normalización, se presentan anomalías en la base de datos. Estos problemas que ocasionan problemas al momento de insertar, modificar o eliminar datos.

Ejemplos:

Ejemplo 1)

• Multiples Valores

                                                 Múltiples datos en número de teléfono

                                                           Número de teléfono normalizado

• Redundancia de datos

Datos redundantes en dos registros

 La forma correcta de representar la tabla sería:

Sin redundancia. Cabe mencionar que la llave primaria de la segunda tabla es compuesta

• Columna que permiten valores nulos

La forma correcta de representar esta tabla seria como en el ejemplo anterior

• Tabla sin llave principal

La forma correcta sería agregando una llave principal

Ejemplo 2)

Una relación se encuentra en Primera Forma Normal (1FN) cuando cada atributo solo toma un valor del dominio simple subyacente. En 1FN no existen grupos repetitivos (De

Miguel et al, 2001).  En el siguiente ejemplo la tabla no se encuentra en 1FN.

Para que la tabla anterior esté en 1FN y sea una verdadera relación debería encontrarse en esta forma:

Se dice entonces que una relación está en 1FN si los dominios de todos los atributos son atómicos (Silberschatz A., Korth H. y Sudarshan S., 2006) y monovalentes (Reynosa E., Maldonado C., Muñoz R., Damiano L., Abrutsky M, 2012). Se le llama atómico a los elementos de un dominio cuando son unidades indivisibles. En la primera tabla “Mochila” y “Computadora” son elementos divisibles por lo que esa tabla no está en 1FN. El término monovalente se refiere a que los valores no pueden repetirse y deben expresarse una sola vez por ocurrencia. Si una tupla tiene repetida varias veces la misma información deberá reducirse a una única instancia. A eso se refiere la expresión, eliminar grupos repetitivos.

Ejemplo 3)

Veamos el siguente ejemplo:

Tabla original

Observamos que no se encuentra en 1FN, pues Sucursal y número de factura no es un dato atómico.  Un primer cambio que podemos hacer es el siguiente:

Encontramos que todavía existen grupos repetitivos. Para eliminarlos y no eliminar los detalles de la factura no queda otra opción sino dividir la tabla.

En la primera de las dos tablas resultantes, podemos eliminar los datos repetitivos, quedando la tabla de esta forma

Elegimos los dos primeros atributos como clave primaria

Agregamos las columnas que componen la clave primaria de la primera tabla, a la segunda tabla para poder relacionar ambas tablas.

Establecemos los tres primeros atributos como clave primaria para esta tabla. Y por último establecemos los dos primeros atributos como clave foránea.

Ejemplo 4:

En esta primera forma normal, no hay grupos repetidos, ni columna que guarde múltiples valores. Por ejemplo, si de una persona queremos guardar varios teléfonos se debe crear una tabla de TELEFONOS y relacionar con la tabla de PERSONAS.

Aplicando la Primera Forma Normal

TABLA PERSONAS

TABLA TELEFONOS

Ejemplo 5

Tenemos una tabla No Normalizada que contiene Estudiantes, Tutor, Habitación y las Clases 1,2 y 3. Vamos a implementar la primera forma normal, luego la segunda y la tercera. Al aplicarle la primera forma normal eliminamos los grupos repetidos quedándonos con una sola columna de clases y repitiendo los datos del estudiante tutor y habitación y ahora no tenemos grupos repetidos porque aplicamos la primera forma normal (1FN).

Ejemplo 6:

No se permiten campos nulos

Esta regla es algo discutible, pero tiene su lógica. Para empezar, si un campo va a tener valores nulos, ¿qué proporción de registros tendrán ese campo con valor nulo? En mi opinión esta regla nos ayuda a separar unas relaciones de otras, porque si una cantidad de registros tienen unos atributos que otros no, ¿no será que pertenecen a otra clase? Por ejemplo, si en una tabla de TBPRODUCTOS definimos los campos TallaProd, KilatesProd y potenciaProd se ve que los productos tendrán clases diversas y entonces habrá que crear una relación para cada clase (ropas, joya y eléctricos, por ejemplo) construyendo lo que se llama una generalización.

Segunda Forma Normal (2FN)

La segunda formal (2FN) es una forma normal usada en la normalización de la base de datos. Una tabla que está en primera forma normal (1FN) debe satisfacer los criterios adicionales para calificar para la segunda forma normal.

Una tabla 1FN estará en 2FN si y sólo si, dada una clave primaria y cualquier atributo que no esté constituido de la clave primaria, el atributo no depende de toda clave primaria de solo una parte de ella.

Ejemplo 1:

Múltiples valores

Aplicando la segunda forma normal se tiene:

Separando en una nueva tabla el atributo N_TRABAJADOR se tiene otra tabla:

Ejemplo 2: En este caso se tiene cinco atributos en una tabla se pide separar en tres tablas.

En este caso tendremos dos tablas que involucren a la tabla curso

Otro a la tabla alumno que tiene como atributo a N_ALUMNO

Otra tabla que involucre a los dos atributos principales como se C_ALUMNO y C_CURSO

Ejemplo 3:

Esta tabla esta en FN2

La Segunda Forma Normal presenta anomalias, en donde si existe dependencia funcional completa entre los atributos. como en el ejemplo siguiente:

De este tipo de anomalias se encarga la tercera forma normal.

Ejemplo 4:

Las siguientes Tablas están en 1FN, pero no cumplen para estar en 2FN

Ahora con la 2FN, creamos otra nueva tabla para mejorar la manejabilidad, tenemos (MATRÍCULA, SIGLA MATERIA) y (MATERIA, SIGLA MATERIA).

Ahora ya tenemos nuestras tablas normalizadas en 2FN

      Ejemplo 5

      Considera una tabla describiendo las habilidades de los empleados

La única clave candidata de la tabla es {Empleado, Habilidad}.

El atributo restante, Lugar actual de trabajo, es dependiente sólo en parte de la clave candidata, llamada Empleado. Por lo tanto, la tabla no está en 2NF. Observe la redundancia de la manera en que son representadas los Lugares actuales de trabajo: nos dicen tres veces que Jones trabaja en la 114 Main Street, y dos veces que Ellis trabaja en 73 Industrial Way. Esta redundancia hace a la tabla vulnerable a anomalías de actualización: por ejemplo, es posible actualizar el lugar del trabajo de Jones en sus registros "Mecanografía" y "Taquigrafía" y no actualizar su registro "Tallado". Los datos resultantes implicaría respuestas contradictorias a la pregunta "¿Cuál es el lugar actual de trabajo de Jones?".

Una alternativa 2NF a este diseño representaría la misma información en dos tablas:

          Las anomalías de actualización no pueden ocurrir en estas tablas, las cuales están en 2NF.

          Sin embargo, no todas las tablas 2NF están libres de anomalías de actualización.

Ejemplo 6:

Como vemos en la tabla “TBLINEASPEDIDO” del ejemplo incorrecto, la única clave candidata es PK_TBLINEASPEDIDO + IDProducto, ya que en conjunto son únicas en la tabla (podríamos tener un IDLinea_pedido único también, pero aún así esos dos campos seguirían siendo una clave candidata). El campo CantidadPed es dependiente de la clave candidata, pues el cliente ha pedido de ese producto una cantidad determinada de artículos, pero el nombre en cambio es dependiente sólo del producto, no del cliente. Si dejaremos esa tabla como está, tendríamos por una parte una redundancia de datos innecesaria pues el nombre del producto lo podemos sacar uniendo la tabla de productos, y además podrían darse inconsistencias de datos si cambiamos el nombre del producto en un registro… ¿cuál sería el nombre real del producto 1 si en varios registros tiene un nombre distinto?

Por lo tanto los pasos para aplicar la segunda forma normal son muy sencillos: encontrar las claves candidatas (compuestas), que identifican de manera única el registro; comprobar que los campos que no forman parte de la clave candidata y no son parte de ella (en el ejemplo de antes ni IDCliente ni IDProducto deben ser analizados) dependen totalmente de la clave candidata. Para el segundo paso puede ayudar preguntarse lo siguiente:

¿puedo saber el valor del campo X sabiendo el valor del campo Y (siendo Y parte de la clave candidata y X no siendo parte de ella)? Pero como todo lo relacionado con el análisis esto requiere un mínimo de agudeza, pues puede que casualmente el valor de un campo se repita para una parte de la clave (por casualidad todos los que compran unas pelotas de tenis lo hacen en cantidades de 5) pero sabemos que no es dependiente de ella.

Por último, aclarar que hay ocasiones en las que el análisis no tiene que ser tan cerrado, ya que a veces las apariencias engañan. Un ejemplo de ello es una tabla de facturas que tiene el nombre, dirección, NIF, y demás datos del cliente: a simple vista esos datos están duplicados y dependen del cliente y no de la factura, pero resulta que esos datos deben permanecer ahí pues fisicalmente debemos saber a qué datos se emitió una factura; esos datos son realmente dependientes de la factura, no del cliente. Si no los incluyéramos en la tabla de facturas, al modificar el registro del cliente en la tabla de clientes no sabríamos a qué datos fiscales se emitió la factura. Así que hay que tomar como referencia el estudio de factibilidad, necesidades de cliente y el minimundo, y no  solo aplicar normas.

Tercera Forma Normal (3FN):

Cada columna de una tabla será relacionada directamente con las columnas de la clave primaria, no debe estar en forma transitiva a través de otro campo, en mismo caso debe cumplir la forma 2FN caso contrario no cumple la tercera forma normal.

TABLA PERSONA

Ahora normalizando hasta la Tercera Forma Normal

TABLA EMPRESA

TABLA PUESTO

Ejemplo 2

Tenemos la siguientes tablas normalizadas hasta 2FN, nos fijamos un detalle en el nombre, el atributo carrera depende del nombre; el atributo nombre no es una clave primaria.

entonces lo que hacemos es sacar a CARRERA a otra nueva tabla con NUM CARRERA PK, se evita redundancia y reducimos espacio de almacenamiento.

Nuestras tablas normalizadas nos quedaran de la siguiente forma:

Ejemplo 3

Una tabla está normalizada en esta forma si todas las columnas que no son llave son funcionalmente dependientes por completo de la llave primaria y no hay dependencias transitivas. Comentamos anteriormente que una dependencia transitiva es aquella en la cual existen columnas que no son llave que dependen de otras columnas que tampoco son llave.

Cuando las tablas están en la Tercera Forma Normal se previenen errores de lógica cuando se insertan o borran registros. Cada columna en una tabla está identificada de manera única por la llave primaria, y no debe haber datos repetidos. Esto provee un esquema limpio y elegante, que es fácil de trabajar y expandir.

Un dato sin normalizar no cumple con ninguna regla de normalización. Para explicar con un ejemplo en qué consiste cada una de las reglas, vamos a considerar los datos de la siguiente tabla.

Al examinar estos registros, podemos darnos cuenta que contienen un grupo repetido para NUM_ITEM, DESC_ITEM, CANT y PRECIO. La 1FN prohíbe los grupos repetidos, por lo tanto tenemos que convertir a la primera forma normal. Los pasos a seguir son:

- Tenemos que eliminar los grupos repetidos.

- Tenemos que crear una nueva tabla con la PK de la tabla base y el grupo repetido.

Los registros quedan ahora conformados en dos tablas que llamemos ÓRDENES y ARTÍCULOS ORDENES

Ahora procederemos a aplicar la segunda formal normal, es decir, tenemos que eliminar cualquier columna no llave que no dependa de la llave primaria de la tabla. Los pasos a seguir son:

- Determinar cuáles columnas que no son llave no dependen de la llave primaria de la tabla.

- Eliminar esas columnas de la tabla base.

- Crear una segunda tabla con esas columnas y la(s) columna(s) de la PK de la cual dependen. 

La tabla ORDENES está en 2FN. Cualquier valor único de ID_ORDEN determina un sólo valor para cada columna. Por lo tanto, todas las columnas son dependientes de la llave primaria ID_ORDEN.

Por su parte, la tabla ARTICULOS ÓRDENES no se encuentra en 2FN ya que las columnas PRECIO y DESC_ITEM son dependientes de NUM_ITEM, pero no son dependientes de ID_ORDEN. Lo que haremos a continuación es eliminar estas columnas de la tabla ARTICULOS ÓRDENES y crear una tabla ARTICULOS con dichas columnas y la llave primaria de la que dependen.

Ejemplo 4:

Imagina que una tabla se encarga de registrar el primer servicio que más carga los servidores cada día. Del ejemplo incorrecto deducimos que el IDServidor y la Fecha, PK_TBCARGADIARIA son la clave candidata, pues identifican de manera única los registros. Analizando vemos que el IDServicio, que no es un campo primario, depende únicamente de la clave candidata, y que la carga también. Pero resulta que el Nombre_servicio depende de esa clave candidata pero también depende del IDServicio, pues con el IDServicio podemos averiguar qué Nombre_servicio tiene el registro. Para solucionar esto sacamos el campo Nombre_servicio de la tabla, y nos llevamos el IDServicio para que sea la clave principal pues es el campo del que depende.

Y con este ejemplo vemos qué fácil es librarnos de las inconsistencias de no cumplir la tercera forma normal, y de la redundancia de datos. Si no hubiéramos normalizado tendríamos que en un registro el IDServicio 3 es Apache y nadie nos asegura que en otro el IDServicio 3 también lo sea pues puede haberse modificado el campo Nombre_servicio. Y si resulta que la tabla fuese un histórico de 500 servidores durante 1000 días, tendríamos 500 mil registros con un campo innecesario que estaría duplicado muchísimas veces

Forma Normal de Boyce-Codd:

La forma Boyce-Codd es una forma normal utilizada en la normalización de base de datos. Es una versión más fuerte de la Tercera Forma Normal (3FN). La forma normal Boyce-Codd requiere que no existan dependencias funcionales no triviales de los atributos que no sean conjunto de la clave candidata. En una tabla en 3FN, todos los atributos dependen de una clave, clave completa y de ninguna otra cosa excepto de la clave.

Ejemplo 1:

Como podemos apreciar, el atributo Ganador es presenta dependencia funcional con (Torneo, Año), sin embargo, Fecha de nacimiento del ganador, no. por esta razón tenemos que dividirlo en 2 tablas:

Ejemplo 2:

Empezando con la siguiente tabla se ve que GRADO ACADEMICO no representa dependencia funcional.

Normalizando con FNBC quedaria asi, en dos tablas:

Ejemplo 3: Tendríamos una tabla con las columnas:

IDTutor, Numero Seguro Social, IDEstudiante

La única clave candidata es IDTutor (que será por lo tanto la clave primaria).

Por lo tanto, hemos encontrado un determinante (IDTutor) que sin embargo no es clave candidata. Por ello, esta tabla no está en Forma Normal Boyce-Codd. En este caso la redundancia ocurre por mala selección de clave. La repetición del par [IdTutor, Numero Seguro Social] es innecesaria y evitable.

Referencia cruzada de Tutor/Estudiante

El propósito de la tabla es mostrar que tutores están asignados a que estudiantes. Las claves candidatas de la tabla es la siguiente:

TABLA TUTOR

TABLA ESTUDIANTE

Cuarta Forma Normal (4FN)

Una tabla se encuentra en 4FN si, y sólo si, para cada una de sus dependencias múltiples no funcionales X->->Y, siendo X una super-clave que, X es o una clave candidata o un conjunto de claves primarias.

La cuarta forma normal (4NF) es una forma normal usada en la normalización de base de datos. La 4NF se asegura de que las dependencias multivaluadas independientes estén correctas y eficientemente representadas en un diseño de base de datos. La 4NF es el siguiente nivel de normalización después de la forma normal de Boyce-Codd (BCNF). Una Tabla está en 4NF si y sólo si está en Tercera Forma Normal o en BCNF y no posee dependencias multivaluadas no triviales. La definición de 4NF confía en la noción de dependencia multivaluada. Una tabla con una dependencia multivaluada es una donde la existencia de dos o más relaciones independientes muchos a mucha causa redundancia; y es esta redundancia la que es suprimida por la cuarta forma normal.

Consideremos el siguiente ejemplo 1: Permutaciones de envíos de pizzasက

Cada fila indica que un restaurante dado puede entregar una variedad dada de pizza a un área dada. Note que debido a que la tabla tiene una clave única y ningún atributo no-clave, no viola ninguna forma normal hasta el BCNF. Pero debido a que las variedades de pizza que un restaurante ofrece son independientes de las áreas a las cuales el restaurante envía, hay redundancia en la tabla: por ejemplo, nos dicen tres veces que A1 Pizza ofrece la Corteza rellena, y si A1 Pizza comienza a producir pizzas de Corteza de queso entonces necesitaremos agregar múltiples registros, uno para cada una de las Áreas de envío de A1 Pizza. En términos formales, esto se describe como que Variedad de pizza está teniendo una dependencia multivalor en Restaurante.

Para satisfacer la 4NF, debemos poner los hechos sobre las variedades de pizza ofrecidas en una tabla diferente de los hechos sobre áreas de envío:

      Variedades por restaurante

Áreas de envío por restaurante 

En contraste, si las variedades de pizza ofrecidas por un restaurante a veces variarán de un área de envio a otra, la tabla original de  tres columnas satisfaría la 4NF.   Ronald Fagin demostró que es siempre posible alcanzar la 4NF (pero no siempre deseable). El teorema de Rissanen es también aplicable en dependencias multivalor.

        Ejemplo 2:

Podemos notar la redundancia de datos presenta:

     (N_Restaurante) ---> (T_Variedad, T_Área_Envío).

Existen 2 maneras de aplicar la 4FN la primera consiste en hacer una tabla más, aceptando la posibilidad, en este ejemplo que un Restaurante puede tener n áreas de envío y n Tipos de Variedad.

                                         (N_Restaurante) ---> (T_Variedad).

        (N_Restaurante) ---> (T_Área_Envío).

Ejemplo 3:

ID_ALUMNO → (ALUMNO, MATERIA)

La restricción del ejemplo es que el alumno pueda tomar como máximo 2 materias

ID_ALUMNO → ALUMNO

ID_ALUMNO →( MATERIA 1, MATERIA 2 )

Ejemplo 4:

En estos casos existen dos relaciones de Dependencias Mutlivaluadas que son C_OrdenPed y C_Insumo, con C_Producto, para ello debemos separarlos entablas distintas junto con sus atributos relacionados y de esta manera se encuentre en 4FN.

En estos casos existen dos relaciones de Dependencias Mutlivaluadas que son C_OrdenPed y C_Insumo, con C_Producto, para ello debemos separarlos entablas distintas junto con sus atributos relacionados y de esta manera se encuentre en 4FN.

Quinta Forma Normal (5FN) 

Una tabla se encuentra en 5FN si:La tabla esta en 4FN

No existen relaciones de dependencias no triviales que no siguen los criterios de las claves. Una tabla que se encuentra en la 4FN se dice que esta en la 5FN si, y sólo si, cada relación de dependencia se encuentra definida por las claves candidatas.

La quinta forma normal (5FN), también conocida como forma normal de proyección-unión (PJ/NF), es un nivel de normalización de bases de datos diseñado para reducir redundancia en las bases de datos relacionales que guardan hechos multi-valores aislando semánticamente relaciones múltiples relacionadas. Una tabla se dice que está en 5NF si y sólo si está en 4NF y cada dependencia de unión (join) en ella es implicada por las claves candidatas.

 Ejemplo 1:

El psiquiatra puede ofrecer tratamiento reembolsable a los pacientes que sufren de la condición dada y que son asegurados por un cierto asegurador. Si no hay reglas que restrinjan las combinaciones válidas posibles de psiquiatra, asegurador, y condición, la tabla de tres atributos Psiquiatra-para-Asegurador-para-Condición es necesaria para modelar la situación correctamente.Pero si una regla (como la siguiente) aparece:

Cuando un psiquiatra es autorizado a ofrecer el tratamiento reembolsable a los pacientes asegurados por el asegurador P, y el psiquiatra puede tratar la condición C, entonces - en caso que el asegurador P cubra la condición C - debe ser cierto que el psiquiatra puede ofrecer el tratamiento reembolsable a los pacientes que sufren de la condición C y están asegurados por el asegurador P.

Con estas restricciones es posible dividir la relación en tres partes.

De esta manera podemos ir quitando redundancia. Si Dr. James empieza a proveer para Friendly Care, con el método antiguo tendríamos que poner dos entradas en la tabla (Friendly Care trata ansiedad y depresión), pero solo necesitaremos ahora una sola entrada en la tabla Psiquiatra-para-Asegurador.

Ejemplo 2

Conocimientos por empleado y proyecto

El empleado Pérez aporta al proyecto Magento sus conocimientos en PHP y SQL y para la página web TYPO3 recurre a SQL y a JavaScript. García también se encarga de la programación PHP de la tienda online y trabaja con JavaScript en la página web. Por último, González solo participa en el proyecto TYPO3, encargándose en solitario de la programación PHP. De esto se concluye que para utilizar Magento se requiere experiencia en PHP y SQL, mientras que un proyecto de TYPO3 da por sentado tener conocimientos en PHP, SQL y JavaScript.

La tabla solo posee una clave compuesta por todos los atributos, cumpliendo así con la 3FN y la FNBC. Al no darse dependencias entre los tres atributos también sería una representante de la 4FN.

Se tratará ahora de comprobar si también está en la 5FN. Para ello fragmentaremos la tabla original Conocimientos por empleado y proyecto en tres tablas: Participación en proyecto, Conocimientos por empleado y Requerimientos por proyecto.

La tabla Participación en proyecto muestra los proyectos en los que participa cada trabajador:

La tabla Conocimientos por empleado reseña los conocimientos en lenguajes de programación o de bases de datos que tiene cada empleado:

Por último, la tabla Requerimientos por proyecto deja entrever qué cualificación técnica requiere trabajar en cada proyecto:

Requerimientos por proyecto

A primera vista, la escisión de la tabla original aporta claridad. Con todo, las tablas que como esta resultan de la normalización ¿igualan en cantidad de información a la tabla original? Para averiguarlo debemos llevar a cabo un Join, una consulta a la base de datos que implique a las tres tablas. El resultado es sorprendente:

Reconstrucción de Conocimientos por empleado y proyecto

Al reconstruir la tabla original debemos dar por supuesto que cada empleado implicado en el proyecto aporta sus cualificaciones si el proyecto las requiere. La información de que González se ha encargado él solo de programar el proyecto TYPO3 en PHP se ha perdido. Esto quiere decir que la tabla original no puede fragmentarse sin pérdidas, cumpliendo así con la quinta forma normal.

En la práctica, pocas veces se topa con esquemas que cumplan con la 4FN pero no con la 5FN. La quinta forma normal es interesante, no obstante, en aquellos casos en los cuales se obtienen nuevos datos a partir de los disponibles. Nuestro ejemplo deja ver que tanto Pérez como García tienen conocimientos en PHP que podrían aportar en el futuro a TYPO3, aunque actualmente colaboran con otras aptitudes. Esta información podría servir a la empresa para diseñar el desarrollo de software en este proyecto de forma más eficiente.

Ejemplo 3:

La tabla tiene muchos atributos, hace difícil su manejo, para este caso en 5FN dividiremos la tabla en subconjuntos más pequeños, teniendo en común la clave primaria en estos subtablas.

Aquí ya tenemos la tabla ya normalizada en este caso, esto debería hacerse cuando sea una tabla con muchos atributos o con muchas columnas para que permita facilitar su manejabilidad.

Sexta Forma Normal (6FN)

La sexta forma normal ( 6NF ) es un término en la teoría de bases de datos relacionales, utilizada de dos maneras diferentes.

6FN (C. Definición de la fecha)

Christopher J. Date y otros han definido la sexta forma normal como una forma normal , basada en una extensión del álgebra relacional.  

Los operadores relacionales, como join , se generalizan para admitir un tratamiento natural de los datos de intervalo, como secuencias de fechas o momentos en el tiempo, por ejemplo, en bases de datos temporales . la  sexta forma normal se basa en esta unión generalizada.

La sexta forma normal está destinada a descomponer las variables de relación en componentes irreducibles. Aunque esto puede ser relativamente poco importante para las variables de relación no temporal, puede ser importante cuando se trata de variables temporales u otros datos de intervalo. Por ejemplo, si una relación comprende el nombre, el estado y la ciudad de un proveedor, es posible que también deseemos agregar datos temporales, como el tiempo durante el cual estos valores son, o fueron, válidos (por ejemplo, para datos históricos) pero los tres valores puede variar independientemente uno del otro y a diferentes velocidades. Podemos, por ejemplo, desear rastrear el historial de cambios a Status; Una revisión de los costos de producción puede revelar que un cambio fue causado por un proveedor que cambió de ciudad y, por lo tanto, lo que cobraron por la entrega.

Uso

La sexta forma normal se está utilizando actualmente en algunos almacenes de datos donde los beneficios superan los inconvenientes, por ejemplo, utilizando el modelado de anclaje . Aunque el uso de 6NF conduce a una explosión de tablas, las bases de datos modernas pueden eliminar las tablas de consultas seleccionadas (usando un proceso llamado 'eliminación de tablas') donde no son necesarias y así acelerar consultas que solo acceden a varios atributos.

Ejemplo 1:

Para que una tabla esté en 6NF, primero debe cumplir con 5NF y luego requiere que cada tabla satisfaga solo dependencias de unión triviales. Tomemos un ejemplo simple [11] con una tabla ya en 5NF: Aquí, en la tabla de usuarios, cada atributo no es nulo y la clave principal es el nombre de usuario:

Users_table

Esta tabla está en 5NF porque cada dependencia de unión está implícita en la clave candidata única de la tabla (nombre de usuario). Más específicamente, las únicas dependencias de unión posibles son: {nombre de usuario, estado}, {nombre de usuario, departamento}.

La versión 6NF se vería así:

Los usuarios

Users_dept

Entonces, de una tabla en 5NF, 6NF produce dos tablas.

El siguiente es otro ejemplo:

Tabla 1

  Las dependencias de unión de la tabla son {nombre médico, ocupación}, {nombre médico, práctica en años} y {práctica en años, tipo}. Por lo tanto, podríamos ver que dicha tabla es 2NF (debido a la aparición de dependencia transitiva). Las siguientes tablas intentan llevarlo a 6NF:

CUADRO 2.1

CUADRO 2.2

CUADRO 2.3

Ejemplo 2:

La sexta forma de normalización es muy reciente. Fue presentada a finales de la década de los años 90 por Christopher J. Date. En esta normalización la variable de relación se descompone hasta componentes irreducibles. Una base de datos cumplirá con la sexta forma de normalización si satisface los siguientes criterios:

1.  Que cumpla con la 5NF

2.  Que cada dependencia de la relación sea trivial.

Para comprender lo anterior, imaginemos la siguiente tabla que está en 5NF:

Tabla MEC

En el caso anterior, las dependencias join serían {Matrícula, Estudiante} y {Matrícula, Calificación}. Para que la anterior tabla cumpla con la 6NF, debería escindirse de la siguiente forma:

Tabla ME

Tabla MC

Séptima Forma Normal : Forma normal de dominio/clave

La forma normal de dominio/clave (DKNF) es una forma normal usada en normalización de bases de datos que requiere que la base de datos contenga restricciones de dominios y de claves.Una restricción del dominio especifica los valores permitidos para un atributo dado, mientras que una restricción clave especifica los atributos que identifican únicamente una fila en una tabla dada.

Esta es el santo grial de la Base de datos y es alcanzado cuando cada restricción en la relación es una consecuencia lógica de la definición de claves y dominios, y, haciendo cumplir las restricciones y condiciones de la clave y del dominio, causa que sean satisfechas todas las restricciones. Así, esto evita todas las anomalías no-temporales.

Es mucho más fácil construir una base de datos en forma normal de dominio/clave que convertir pequeñas bases de datos que puedan contener numerosas anomalías. Sin embargo, construir con éxito una base de datos en forma normal de dominio/clave sigue siendo una tarea difícil, incluso para programadores experimentados de bases de datos. Así, mientras que la forma normal de dominio/clave elimina los problemas encontrados en la mayoría de las bases de datos, tiende para ser la forma normal más costosa de alcanzar. Sin embargo, el no poder alcanzar la forma normal de dominio/clave puede llevar costos ocultos a largo plazo, debido a anomalías que aparecen con el tiempo en las bases de datos que solamente se adhieren a formas normales más bajas.

Una violación de DKNF ocurre en la siguiente tabla:

Persona rica

Asuma que el dominio para la DNI Persona rica consiste en los DNI's de toda la gente rica en una muestra predefinida de gente rica; el dominio para el Tipo de persona rica consiste de los valores 'Millonario excéntrico', 'Multimillonario excéntrico', 'Millonario malvado', y 'Multimillonario malvado'; y el dominio para el Valor neto en dólares consiste de todos los números enteros mayor que o igual a 1.000.000.

Hay una restricción que liga el Tipo de persona rica al Valor neto en dólares, incluso aunque no podamos deducir uno del otro. La restricción dicta que un Millonario excéntrico o Millonario malvado tendrá un valor neto de 1.000.000 a 999.999.999 inclusive, mientras que un Multimillonario excéntrico o un Multimillonario malvado tendrá un valor neto de 1.000.000.000 o más. Esta restricción no es ni una restricción de dominio ni una restricción de clave; por lo tanto no podemos confiar en las restricciones de dominio y las de clave para garantizar que una combinación de anómala de Tipo de persona rica / Valor neto en dólares no tenga cabida en la base de datos.

La violación de la DKNF podría ser eliminada alterando dominio Tipo de persona rica para hacer que sea consistente con solo dos valores, 'Malvado' y 'Excéntrico' (el estatus de persona rica como un millonario o un multimillonario es implícito en su Valor neto en dólares, así que no se pierde ninguna información útil).

Persona rica

Estado de riqueza

DKNF es frecuentemente difícil de alcanzar en la práctica.

       Resultados y análisis 

            Al proceder a la normalización de base de datos hay que plantearse 4 metas:

   - Organizar los datos en grupos lógicos, de tal manera que cada grupo describa una pequeña parte del todo.

   - Minimizar la cantidad de datos duplicados almacenados en una base de datos.

   - Perfeccionar la organización de los datos de tal manera que, cuando se necesite introducir modificaciones, el cambio sólo deba aplicarse en un lugar.

   - Construir una base de datos a la que se pueda acceder de forma rápida y donde sea posible manipular los datos con la máxima eficiencia y sin comprometer su integridad.

      Conclusiones: 

    Se puede destacar que la técnica de normalización. Tiene un resultado que permite afirmar que tiene un grado de ajuste aceptable a las normas internacionales. Con base en ello, se amplía la posibilidad de incorporar en los índices nacionales e internacionales, con el fin de vincularse aún más al entorno mundial en cuanto a transferencia de conocimientos. Los resultados alcanzados permiten proponer un plan de mejoras con vistas a mejorar la calidad y así aumentar sus posibilidades de aceptación en las bases de datos. Se recomienda realizar las sugerencias en cada uno de los bloques normativos, para conseguir los estándares internacionales de normalización.

      Bibliografía 

     1.-http://basesdedatosjc.blogspot.com/2012/04/primera-forma-normal-en-bases-de-datos.html

     2.-http://www.marcossarmiento.com/2017/06/28/normalizacion-de-base-de-datos/

Cuestionario

1. ¿Cuáles son sus claves? ¿Cuáles son los atributos principales? ¿Y los atributos no principales?

1. todas.empezando por el nombre del colegio… P, H y A/Cu y E
2. La tabla contiene una clave primaria única
3. Todas las anteriores
4. Ninguna de las anteriores

2. ¿En qué forma normal se encuentra la relación?

1. se encuentra en la tercera forma normal.
2. se encuentra en la primera forma normal.
3. Todas las anteriores
4. Ninguna de las anteriores

3.Un requisito para aplicar 5NF es el no tener relaciones de dependencias no triviales que no siguen los criterios de las claves

                                                   V                                                       F

4. La cuarta forma normal se asegura que las dependencias multivaluadas independientes estén correctas.

                                                   V                                                        F

5. Dependencia funcional: Es una conexión entre uno o más atributos:            DNI→ Nombre y apellidos.

                                        V                                                F

6. Dependencia Funcional Transitiva: Si “X” → “Y” → «Z” entonces “X” → “Z”

                                        V                                                F

7.Un defecto de normalización en una base de datos relacional puede provocar anomalías:

1. al borrar la información de una tupla, ya que se pueden estar borrando tuplas de otras tablas involuntariamente
2. al insertar información en una tabla, porque los datos insertados no se corresponderán con la realidad
3. al modificar la información de una tabla, ya que un cambio simple de un dato podría afectar a varias tuplas. 

8. La normalización:

1. se utiliza actualmente más como un criterio de calidad en el diseño
2. no es necesaria aunque sí recomendable
3. es el mejor método para diseñar las bases de datos

9.- La tercera Forma Normal de una tabla está relacionada con todas las columnas de la clave primaria y no por una combinación de parte de la clave primaria

V                                                            F

10.- Las formas normales son un conjunto de criterios que utilizamos para mejorar las estructuras de la base de datos

V                                                             F