SemaNormana 14

NORMALIZACION II

CUARTA FORMA NORMAL

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.

QUINTA FORMA NORMAL

Una tabla se encuentra en 5FN si:

• La tabla está 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 está en la 5FN si, y sólo si, cada relación de dependencia se encuentra definida por las claves candidatas

REGLA DE CODD

Codd se percató de que existían bases de datos en el mercado las cuales decían ser relacionales, pero lo único que hacían era guardar la información en las tablas, sin estar estas tablas literalmente normalizadas; entonces éste publicó 12 reglas que un verdadero sistema relacional debería tener, en la práctica algunas de ellas son difíciles de realizar. Un sistema podrá considerarse "más relacional" cuanto más siga estas reglas.

Regla No. 1 - La Regla de la información

Toda la información en un RDBMS está explícitamente representada de una sola manera por valores en una tabla.

Cualquier cosa que no exista en una tabla no existe del todo. Toda la información, incluyendo nombres de tablas, nombres de vistas, nombres de columnas, y los datos de las columnas deben estar almacenados en tablas dentro de las bases de datos. Las tablas que contienen tal información constituyen el Diccionario de Datos. Esto significa que todo tiene que estar almacenado en las tablas.

Toda la información en una base de datos relacional se representa explícitamente en el nivel lógico exactamente de una manera: con valores en tablas. Por tanto los metadatos (diccionario, catálogo) se representan exactamente igual que los datos de usuario. Y puede usarse el mismo lenguaje (ej. SQL) para acceder a los datos y a los metadatos (regla 4)

Regla No. 2 - La regla del acceso garantizado

Cada ítem de datos debe ser lógicamente accesible al ejecutar una búsqueda que combine el nombre de la tabla, su clave primaria, y el nombre de la columna.

Esto significa que dado un nombre de tabla, dado el valor de la clave primaria, y dado el nombre de la columna requerida, deberá encontrarse uno y solamente un valor. Por esta razón la definición de claves primarias para todas las tablas es prácticamente obligatoria.

Regla No. 3 - Tratamiento sistemático de los valores nulos

La información inaplicable o faltante puede ser representada a través de valores nulos

Un RDBMS (Sistema Gestor de Bases de Datos Relacionales) debe ser capaz de soportar el uso de valores nulos en el lugar de columnas cuyos valores sean desconocidos.

Regla No. 4 - La regla de la descripción de la base de datos

La descripción de la base de datos es almacenada de la misma manera que los datos ordinarios, esto es, en tablas y columnas, y debe ser accesible a los usuarios autorizados.

La información de tablas, vistas, permisos de acceso de usuarios autorizados, etc, debe ser almacenada exactamente de la misma manera: En tablas. Estas tablas deben ser accesibles igual que todas las tablas, a través de sentencias de SQL (o similar).

Regla No. 5 - La regla del sub-lenguaje Integral

Debe haber al menos un lenguaje que sea integral para soportar la definición de datos, manipulación de datos, definición de vistas, restricciones de integridad, y control de autorizaciones y transacciones.

Esto significa que debe haber por lo menos un lenguaje con una sintaxis bien definida que pueda ser usado para administrar completamente la base de datos.

Regla No. 6 - La regla de la actualización de vistas

Todas las vistas que son teóricamente actualizables, deben ser actualizables por el sistema mismo.

La mayoría de las RDBMS permiten actualizar vistas simples, pero deshabilitan los intentos de actualizar vistas complejas.

Regla No. 7 - La regla de insertar y actualizar

La capacidad de manejar una base de datos con operandos simples aplica no sólo para la recuperación o consulta de datos, sino también para la inserción, actualización y borrado de datos'.

Esto significa que las cláusulas para leer, escribir, eliminar y agregar registros (SELECT, UPDATE, DELETE e INSERT en SQL) deben estar disponibles y operables, independientemente del tipo de relaciones y restricciones que haya entre las tablas o no.

Regla No. 8 - La regla de independencia física

El acceso de usuarios a la base de datos a través de terminales o programas de aplicación, debe permanecer consistente lógicamente cuando quiera que haya cambios en los datos almacenados, o sean cambiados los métodos de acceso a los datos.

El comportamiento de los programas de aplicación y de la actividad de usuarios vía terminales debería ser predecible basados en la definición lógica de la base de datos, y éste comportamiento debería permanecer inalterado, independientemente de los cambios en la definición física de ésta.

Regla No. 9 - La regla de independencia lógica

Los programas de aplicación y las actividades de acceso por terminal deben permanecer lógicamente inalteradas cuando quiera que se hagan cambios (según los permisos asignados) en las tablas de la base de datos.

La independencia lógica de los datos especifica que los programas de aplicación y las actividades de terminal deben ser independientes de la estructura lógica, por lo tanto los cambios en la estructura lógica no deben alterar o modificar estos programas de aplicación.

Regla No. 10 - La regla de la independencia de la integridad

Todas las restricciones de integridad deben ser definibles en los datos, y almacenables en el catalogo, no en el programa de aplicación.

Las reglas de integridad

1. Ningún componente de una clave primaria puede tener valores en blanco o nulos (ésta es la norma básica de integridad).
2. Para cada valor de clave foránea deberá existir un valor de clave primaria concordante. La combinación de estas reglas aseguran que haya integridad referencial.

Regla No. 11 - La regla de la distribución

El sistema debe poseer un lenguaje de datos que pueda soportar que la base de datos esté distribuida físicamente en distintos lugares sin que esto afecte o altere a los programas de aplicación.

El soporte para bases de datos distribuidas significa que una colección arbitraria de relaciones, bases de datos corriendo en una mezcla de distintas máquinas y distintos sistemas operativos y que esté conectada por una variedad de redes, pueda funcionar como si estuviera disponible como en una única base de datos en una sola máquina.

Regla No. 12 - Regla de la no-subversión

Si el sistema tiene lenguajes de bajo nivel, estos lenguajes de ninguna manera pueden ser usados para violar la integridad de las reglas y restricciones expresadas en un lenguaje de alto nivel (como SQL).

Algunos productos solamente construyen una interfaz relacional para sus bases de datos No relacionales, lo que hace posible la subversión (violación) de las restricciones de integridad. Esto no debe ser permitido.

EJEMPLO APLICACION

PRIMERA FORMA NORMAL. Cualquier tabla de datos que cumpla con la definición de una afinidad, se dice que esta en la primera forma normal. Para que una tabla sea una afinidad, debe cumplirse lo siguiente: la celda de la tabla debe poseer valores simples y no se permiten grupos ni arreglos repetidos como valores. Todos los ingresos en cualquier columna (atributo), deben ser del mismo tipo. Cada columna debe tener un nombre único, el orden las columnas en la tabla no es importante Dos hileras en una tabla no deben ser idénticas.

La siguiente afinidad esta en primera forma normal

 

SEGUNDA FORMA NORMAL.-  Para entender la segunda forma normal, consideramos la figura anterior. Tal afinidad posee anomalías de modificación. Si se elimina la tupla para estudiante 175, se perderá el hecho de que SQUASH cuesta $50. Tampoco se puede ingresar una actividad hasta que se inscriba un estudiante. La afinidad esta expuesta a anomalías de eliminación y de inserción.

El problema con tal afinidad es que posee una dependencia que involucra solo parte de la clave. La clave es la combinación (Clave, actividad), la afinidad contiene una dependencia, Actividad è Cuota. El determinante de esta dependencia (Actividad) es la parte de la clave (SID, Actividad). Se dice que cuota es parcialmente dependiente de la clave de la tabla. No habría anomalías de modificación si cuota dependiera por completo de la clave. Para eliminar las anomalías se debe separar la afinidad  en dos afinidades.

Esta situación conduce a la definición de segunda forma normal: Una afinidad esta en segunda forma normal si todos sus atributos que no son claves dependen por completo de la clave.

De acuerdo con esta definición, cada afinidad que tiene un atributo único como clave, esta en segunda forma normal. La clave es solo un atributo, en forma predeterminada, cada atributo que no es clave depende por completo de la clave; no puede haber dependencias parciales. La segunda forma normal solo hace referencia a afinidades con claves compuestas.

La afinidad ACTIVIDADES una vez aplicada la segunda forma normal quedaría:

             

4.3 TERCERA Y FORMAL NORMAL DE BOYCE-CODD

TERCERA FORMA NORMAL.- Las afinidades en la segunda forma normal también tienen anomalías. Considerando la afinidad VIVIENDA de la siguiente figura. La clave es SID y  las dependencias funcionales son SID è Edificio y Edificio è Cuota. Estas dependencias surgen porque cada estudiante vive en un edificio y cada edificio tiene una cuota. Cada estudiante que vive en Randolph Hall paga $1200 por trimestre.

 

Debido a que SID determina Edificio y Edificio determina cuota. Indirectamente SID è Cuota. Un arreglo de dependencias funcionales como este se denomina una dependencia transitiva, ya que SID determina Cuota por medio del atributo Edificio.

Por esta dependencia transitiva, SID es la clave y la afinidad esta en segunda forma normal. A pesar de esto vivienda tiene anomalías.

Para eliminar las anomalías de una afinidad en segunda forma normal, debe quitarse la dependencia transitiva, lo que conduce a la definición de una tercera forma normal:  Una afinidad está en tercera forma normal si está en segunda forma normal y no tiene dependencias transitivas.

La afinidad vivienda puede dividirse en dos afinidades en tercera forma normal.

 

 FORMA NORMAL DE BOYCE-CODD

Incluso las afinidades en tercera forma normal pueden tener anomalías.  Considere la siguiente afinidad ASESOR. Suponga que los requerimientos que sustentan esta afinidad son que un estudiante (SID), pueda tener una ó más especialidades, una especialidad puede tener varios miembros de la facultad (nombreF) como consejeros, y un miembro de la facultad (nombreF), sólo imparte asesoría en una área de especialidad.

 

Puesto que los estudiantes pueden tener varias especialidades, SID, no determina la especialidad.  Como los estudiantes pueden tener varios asesores, SID tampoco determina nombre F.  SID por si mismo no puede ser una clave.

La combinación (SID, especialidad) determina nombre F y la combinación (SID, nombre F), determina especialidad.  Cualquiera de las combinaciones puede ser una clave.  Dos ó mas atributos o conjuntos de atributos que puedan ser una clave, se denominan claves candidatas.  Cualquiera de las candidatas que se seleccione para ser la clave se denomina clave primaria.

ASESOR está en primera forma normal.  También está en segunda forma normal, pues cualquier atributo que no es clave depende de toda la clave (sin importar cual clave candidata se seleccione).  También está en tercera forma normal porque no tiene dependencias transitivas.  A pesar de todo esto tiene anomalías por modificación.

Suponga que estudiante 300 deja la escuela, si quita la tupla de estudiante 300 se perderá el hecho de que Perls imparte asesoría en psicología.  Ésta es una anomalía de eliminación.  En forma similar ¿Cómo se almacena el hecho de que  Keynes asesor en economía? No es posible, hasta que un estudiante se inscribe en tal materia.  Esta es una anomalía de inserción.

Situaciones como la anterior conducen a la definición de la forma normal de Boyce-Codd (BCNF):  Una afinidad está en BCNF si cada determinante es una clave candidata.  ASESOR no está en BCNF puesto que tiene un determinante, nombre F, que no es una clave candidata.

ASESOR puede descomponerse en dos afinidades que no tengan anomalías.

 

4.4  CUARTA Y QUINTA FORMA NORMAL

CUARTA FORMA NORMAL

Considere usted la afinidad ESTUDIANTE que muestra la relación entre estudiantes, especialidades y actividades.  Suponga que los estudiantes pueden inscribirse en varias especialidades y participar en diversas actividades.  La única clave es la combinación de los atributos (SID, Especialidad, Actividad).  La estudiante 100 tiene su especialidad en Música y Contabilidad y también participa en Natación y Tenis.  El  estudiante 150 sólo tiene especialidad en Matemáticas y participa en Carrera.

¿Cuál es la relación entre SID y especialidad?  No es una dependencia funcional porque los estudiantes pueden tener distintas especialidades.  Un valor único de SID puede poseer muchos valores de Especialidad.  Esto también se aplica a la relación entre SID y Actividad.

Tal dependencia por atributos de denomina dependencia de valores múltiples.  Las dependencias de valores múltiples conducen a anomalías de modificación.  Observe la redundancia en datos de la figura.  La estudiante 100 tiene cuatros registros, cada uno de los cuales muestra una de sus especialidades junto con una de sus actividades.  Si los datos se almacenaran con menos hileras:  si hubiera sólo dos tuplas, uno para música y natación y uno para contaduría y tenis, las implicaciones serían engañosas. Parecería que la Estudiante 100 sólo nadó cuando tenía música como especialidad y jugó tenis sólo cuando tenía contaduría como especialidad.  Esa interpretación no es lógica.  Sus especialidades y sus actividades son independientes entre sí.  Para prevenir tales engañosas conclusiones se almacenan todas las combinaciones de especialidades y actividades.

Suponga que, debido a que la Estudiante 100 decide apuntarse en Esquí, se debe agregar la tupla (100, MÚSICA, ESQUÍ), como en la figura. La afinidad en este punto indica que la Estudiante 100 esquía cuando estudia música, pero no cuando tiene contaduría como especialidad.  A fin de mantener la consistencia en los datos, se debe agregar una hilera para cada uno de una de sus actividades ligadas con Esquí.  También se debe agregar la hilera) (100, CONTABILIDAD, ESQUÍ),  como en la figura.  Ésta es una anomalía de actualización:  hay que hacer demasiadas actualizaciones para realizar  un cambio en los datos.

Existe una dependencia de valores múltiples cuando una afinidad tiene al menos tres atributos, dos de los cuales poseen valores múltiples y sus valores dependen sólo del tercer atributo.  En otras palabras en la afinidad R (A, B, C) existe una dependencia de valores múltiples si A determina  valores múltiples de B, A  determina valores múltiples de especialidad, y SID determina valores múltiples de Actividad, pero  Especialidad y Actividad son independientes entre sí.

Observe otra vez la figura.  Vea cómo están escritas las dependencias de valores múltiples:  SID è èEspecialidad y SID èè Actividad.  Esto se lee "SID multidetermina Especialidad, y SID multidermina Actividad".  Esta afinidad está en BCNF (2NF porque todo es clave; 3NF porque no tiene dependencias transitivas; y BCNF porque no tiene determinantes que no son claves).  Hemos visto que posee anomalías: si un estudiante toma otra especialidad, se debe ingresar un tuple para la nueva especialidad, y juntarlo con cada una de las actividades del estudiante.  Sucede  lo mismo si un estudiante se inscribe  en una nueva actividad.  Si un estudiante deja  una especialidad se deben eliminar cada uno de los registros que contienen  tal materia.  Si participa en cuatro actividades, habrá cutro tuples que contengan la especilidad que ha dejado  y deberá borrarse cada uno.

Para evitar tales anomalías, se deben  las dependencias de valores múltiples.  Esto se hace construyendo dos afinidades, donde cada una almacena datos para solamente uno de los atributos de valores múltiples.  La afinidades resultantes no tienen  anomalías.  Ellas son ESTU-ESPECIALIDAD (SID, Especialidad) y ESTU-ACT (SID, Actividad).

A partir de estas observaciones, se define la cuarta forma normal: Una afinidad está en cuarta forma normal si está en BCNF y no tiene dependencias de valores múltiples.

Quedaria de la siguiente manera:

  

QUINTA FORMA NORMAL

La quinta forma normal se refiere a dependencias  que son extrañas.  Tiene que ver con afinidades que pueden dividirse en subafinidades (como se ha venido haciendo), pero que no pueden reconstruirse.  La condición bajo la cual surge esta situación, no tiene significado intuitivo preciso.  No se sabe cuáles son las consecuencias de tales dependencias, incluso si tienen consecuencias prácticas.  Para más  información acerca de la quinta  forma normal, consulte la investigación de Date citada antes en este capítulo.

Cada una de las formas normales que se han analizado, fueron identificadas por investigadores que encontraron anomalías de modificación con afinidades en la segunda forma normal condujeron a la definición de la tercera forma normal.  Aunque  cada forma normal resolvía algunos de los problemas identificados con la forma normal anterior, nadie podía saber cuáles problemas todavía no habías sido identificados.  Cada paso, se avanzaba a una definición  estructurada de las bases de datos, nadie podía garantizar que no se encontarían  más anomalías.  En la siguiente sección se estudia una forma normal que garantiza que no habrá anomalías de ningún tipo.  Cuando se ponen las afinidades en esa forma, se sabe que no pueden ocurrir ni siquiera las extrañas anomalías asociadas con la quinta forma normal.

4.5 OTROS ENFOQUES HACIA EL DISEÑO DE BASES DE DATOS

Considerando la base de datos de la siguiente figura, se muestra una relación info-préstamo descompuesta en FNRP. En dicha base de representa una situación en la cual aún no se ha determinado el importe del préstamo P-58. pero se quiere grabar el resto de los datos del préstamo. Si ejecutamos la reunión natural de estas relaciones, todas la tuplas que se refieren al préstamo P-58 desaparecen. En otras palabras. No hay una relación info-préstamo que se corresponda con las relaciones de la figura. Las tuplas que desaparecen cuando se ejecuta la reunión natural son tuplas colgantes. Formalmente, sean r₁ (R₁) , r₂ (R₂) ,..., r_n(R_n) un conjunto de relaciones. Una tupla t de la relación r_i es una tupla colgante si t  no está en la relación.

La forma normal de reunión por proyección (FNRP) se define de la forma similar a la FNBC y 4FN, salvo que se usan las dependencias de reunión.

Un esquema de relación R  esta en FNRP respecto a un conjunto D dependencias funcionales, multivaloradas y de reunión si para toda dependencia de reunión perteneciente a D   de la forma * (R₁, R₂,...,R_N), donde casa R₁  Í R y R = R₁ U R₂ ... U R_n, se cumple al menos una de las siguientes condiciones:

·        * (R₁, R₂,...,R_N) es una dependencia de reunión.

·        Cada R_i es una superclave de R.

Un diseño de base de datos está en FNRP si cada miembro del conjunto de esquemas de relación que constituye el diseño está en FNRP. Alguno autores denominan también quinta forma normal (5FN) a la FNRP.

Descomposición en FNRP.

NOMBRE-SUCURSAL	NUMERO-PRÉSTAMO
COLLADO MEDIANO	P-58
NUMERO-PRESTAMO	IMPORTE
NUMERO-PRESTAMO	NOMBRE-CLIENTE
P-58	GONZALEZ

Las tuplas colgantes se pueden  dar en aplicaciones prácticas de bases de datos. Representan información incompleta, como se vio en el ejemplo, donde se quiere almacenar datos sobre un préstamo que aún esta en proceso de negociación.

A la relación r₁ reunión natural con r₂ se le llama relación universal, ya que involucra todos los atributos del universo definido por R₁ U R₂ U...U R_n.

El único modo de que se puede escribir una relación universal para el ejemplo anterior, es incluir valores nulos en la relación universal. Debido a la dificultad para manejar valores nulos, puede ser mejor considerar las relaciones del diseño descompuesto como representantes de la base de datos, en vez de la relación universal cuyo esquema se descompone durante el proceso de normalización.

Nótese que se puede introducir toda la información incompleta en la base de datos. Sin recurrir al uso de valores nulos. Por ejemplo, no se puede introducir un número de préstamo a menos que no se sepa algo de lo siguiente:

·        El nombre del cliente.

·        El nombre de la sucursal.

·        El importe del préstamo.

Por tanto, una descomposición particular define una forma restringida de la información incompleta que es aceptable en la base de datos.

Las formas normales que se definieron generan buenos diseños de bases de datos desde el punto de vista de la representación de información incompleta.

Si se permiten tuplas colgantes en la base de datos, puede ser preferible tomar una vista alternativa del proceso de diseño de bases de datos. Un lugar de descomponer una relación universal, se puede sintetizar una serie de esquemas en forma normal a partir de un conjunto de atributos dados.

Otra consecuencia de este enfoque de diseño de bases de datos es que los nombres de los atributos deben ser únicos en la relación universal. No se puede usar nombre para referirse a nombre-cliente y nombre-sucursal.

Sin embargo, en un lenguaje como SQL no hay operaciones de reunión natural, por lo que en una consulta que incluya a préstamo-sucursal  y préstamo-cliente se debe eliminar la ambigüedad en las referencias a nombre  poniendo como prefijo  el nombre de la relación. En estos entornos, los diversos significados de nombre son menos problemáticos y se pueden usar fácilmente.

El uso del supuesto de papel único es generalmente preferible a reutilizar el mismo nombre para varios atributos. Cuando no se cumple el supuesto del papel único, el diseñador de la base de datos debe tener un cuidado especial al construir un diseño normalizado de la base de datos relacional.