DISEÑO LÓGICO DE LAS BASES DE DATOS EN EL MODELO RELACIONAL

1- ETAPAS DE UNA METODOLOGÍA DE DISEÑO

En los últimos años venimos asistiendo, gracias al avance tecnológico, a una gran difusión de los SGBDR, cuyos productos se soportan en cualquier plataforma, desde los superordenadores a los ordenadores personales. Sin embargo, y a pesar del esfuerzo realizado por numerosos investigadores y estudiosos del tema, la concepción de una BD sigue siendo una tarea larga y costosa.

Estas dificultades inherentes al diseño de una base de datos han de afrontarse con procedimientos ordenados y metódicos en el marco de una metodología de diseño de bases de datos.

En el proceso de diseño de una base de datos hemos de distinguir tres grandes fases:

-          Diseño conceptual: cuyo objetivo es obtener una buena representación de los recursos de información de la empresa, con independencia de usuarios o aplicaciones en particular, y fuera de consideraciones sobre eficiencia del ordenador.

-          Diseño lógico: cuyo objetivo es transformar el esquema conceptual obtenido en la etapa anterior, adaptándolo al modelo de datos en el que se apoya el SGBD que se va a utilizar. Nosotros nos vamos a referir al modelo relacional, pero de forma análoga se podría adaptar esta etapa de diseño lógico a otros modelos de datos, como el Jerárquico o el Codasyl.

-          Diseño físico: cuyo objetivo es conseguir una instrumentación, lo más eficiente posible, del esquema lógico.

Cuando estudiamos el papel de los modelos de datos en el diseño de las bases de datos, ya señalamos las ventajas de obtener, en una primera fase del diseño, un esquema conceptual independiente de las características de los modelos convencionales, como el modelo relacional, y que recogiese la semántica del mundo real.

Un problema que se suele presentar en el diseño de bases de datos es la comunicación entre el diseñador y el usuario; este último conoce bien el dominio de aplicación, lo que en general no ocurre con el diseñador, pero muchas veces no sabe expresarlo de forma correcta y, menos aun, precisa. La utilización del modelo E/R, en una primera fase del diseño, facilita el dialogo entre el informático, conocedor de las técnicas de estructuración de los datos pero ajeno al dominio de la aplicación, y el usuario, que suele conocer bien su mundo real pero que no es capaz de describirlo bajo las premisas que impone un modelo convencional.

El modelo E/R sencillo, pero a la vez suficientemente potente, permite entablar un diálogo entre el usuario y el diseñador que facilitara que se despejen dudas y aclaren aspectos del universo del discurso a modelar. Se facilita así la colaboración de los especialistas con los usuarios, de manera que estos últimos pueden participar activamente, e incluso ser protagonistas, en el diseño.

Podemos representar esquemáticamente las dos primeras fases (diseño conceptual y diseño lógico) de la metodología, en este ejemplo, en el cual aparece el proceso de diseño de una biblioteca; el diseñador observa el mundo real bajo unos ciertos objetivos (universo del discurso) y, apoyándose en una primera etapa en el modelo E/R, llega a un esquema conceptual, al cual se le aplicara un conjunto de reglas a fin de transformarlo en una estructura relacional (conjunto de tablas).

2- TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL AL RELACIONAL

El paso de un esquema en el modelo E/R al relacional está basado en los tres principios siguientes:

-          Todo tipo de entidad se convierte en una relación.

-          Todo tipo de interrelación N:M se transforma en una relación.

-          Todo tipo de interrelación 1:N se traduce en el fenómeno de propagación de clave o bien se crea una nueva relación.

A primera vista se puede observar que en el paso del modelo E/R al relacional pierde semántica, puesto que tanto las entidades como las interrelaciones se transforman en relaciones, de forma que ya no es posible distinguir entre unas y otras (en el modelo relacional) solo existe la relación para presentar ambos tipos de objetos).

También se constata que la perdida de semántica es aún mayor en el caso de la propagación de clave, donde desaparece incluso el nombre de la interrelación. Es preciso destacar que la perdida de semántica no implica, necesariamente, un peligro para la integridad de la base de datos, ya que, si la transformación se ha realizado correctamente, se habrán definido las necesarias restricciones (muy en especial las claves ajenas con sus opciones) que aseguraran la consistencia de los datos.

En el ejemplo, puede observarse que las tres entidades EDITORIAL, LIBRO y AUTOR se transforman en otras tantas relaciones. La interrelación N:M Escribe da lugar a una nueva relación ESCRIBE cuya clave primaria es la concatenación de los atributos identificadores de las entidades que participan en ella (nombre de AUTOR y código de LIBRO), siendo además estos claves ajenas de ESCRIBE que referencian a las relaciones AUTOR y LIBRO, respectivamente. La interrelación 1:N edita se transforma en la relación LIBRO la clave de la relación EDITORIAL (  a la que llamamos Editorial); atributo que será clave ajena de la relación LIBRO referenciando a EDITORIAL.

Las opciones de clave ajena en la transformación del ME/R al relacional

Si bien, insistimos, el paso del ME/R al relacional implica una cierta pérdida de semántica, se debe procurar que está perdida sea lo menor posible, además de asegurar al máximo la consistencia de los datos, es decir, la integridad de la base de datos en las operaciones de actualización. Las opciones de clave ajena, cuando se borran o modifican ocurrencias de la relación referenciada (“NO ACTION”,”SET NULL”,”CASCADE, y “SET DEFAULT”), nos pueden ayudar a cumplir este objetivo de mantener la integridad. Seguidamente analizaremos las posibles opciones de borrado y modificación asociada a las claves ajenas en los casos de propagación de clave y de creación de una nueva relación.

A) Transformación por propagación de clave (interrelación 1:N)

Sea la interrelación Edita del ejemplo, donde suponemos que todo libro de nuestra base de datos esta siempre editado por una única editorial, es decir, las cardinalidades EDITORIAL en la interrelación Edita serian las que aparecen en el ejemplo; a la derecha de la figura se puede ver el esquema relación resultante de la transformación.

Las posibles opciones de borrado que se podrían aplicar en este caso serian:

-          Restringido (“NO ACTION”): impide el borrado (o actualización) de una ocurrencia de EDITORIAL en tanto existan en la base de datos libros editados por dicha editorial ( es la opción que el sistema toma por defecto en el caso de no explicitar ninguna, como ocurre en el ejemplo de la figura anterior).

-          Cascada (“CASCADE”): se utilizaría esta opción si se desea que, al borrar una ocurrencia de EDITORIAL, se borren ene la relación LIBRO todos los libros editados por ella.

-          Valor por defecto (“SET DEFAULT”): pondría el valor definido por defecto, para el atributo Editorial en la tabla LIBRO en todas aquellas ocurrencias asociadas a una editorial borrada en la relación EDITORIAL.

No podría utilizarse la opción de puesta al valor nulo, dado que la cardinalidad mínima de una en editorial, significa que todo libro ha de ser editado por una editorial,  por lo que el atributo Editorial en LIBRO no admite el valor nulo.

En el caso de modificación, lo más común es poner la opción de cascada, ya que, por regla general, se desea que el atributo Editorial en la relación LIBRO se modifique de la misma forma en que se modifica el nombre de la editorial (Nombre_E) en la relación EDITORIAL.

Como podemos observar, las opciones de borrado y modificación de la clave ajena ayudan a mantener la integridad de los datos.

La cardinalidad mínima de uno en LIBRO (es decir, si toda Editorial tuviese que editar un libro como mínimo) no podría recogerse mediante las opciones de clave ajena.

Cuando la interrelación es una dependencia en existencia, la transformación se realiza tal como aparece en el siguiente ejemplo.

Como en este caso las ocurrencias de la entidad débil (FAMILIAR) tienen que ser eliminadas cuando se borra la ocurrencia de la entidad regular (EMPLEADO) de la cual dependen, la opción de borrado será cascada.

Si la dependencia fuese en identificación, como en el ejemplo siguiente, la única diferencia con el caso anterior es que la clave primaria de EJEMPLAR seria la concatenación del atributo identificador principal de la entidad regular LIBRO (Código) con el Numero_e de la entidad EJEMPLAR, ya que Numero_e, por sí solo, no identifica a los ejemplares.

B) Transformación creando una nueva relación (interrelación N:M)

Sea la interrelación Escribe del siguiente ejemplo donde suponemos las cardinalidades que aparecen en la figura, es decir, existen libros anónimos (un libro puede no ser escrito por ningún autor) y, en cambio, todo autor tiene que haber escrito al menos un libro. El esquema relacional resultante de la transformación, con las claves ajenas y sus opciones, aparece en la parte derecha de la figura.

Las opciones de borrado y de modificación, en el caso de interrelaciones N:M, suelen ser cascada, pero hay casos, en los que está justificado elegir otra opción; así, como en el ejemplo, para clave ajena Cod_autor que referencia a AUT>OR> no se ha puesto opción de borrado (toma, por tanto, NO ACTION), ya que se supone que no se desea que se borre un autor en tanto exista una ocurrencia de ESCRIBE que asocie a ese autor con algún libro. Las cardinalidades mínimas de uno no pueden recogerse mediante las opciones de clave ajena.

Cuando la interrelación tiene un atributo, este pasa a ser un atributo de la tabla en la que se ha transformado la interrelación.

3- GRAFO RELACIONAL

Una forma sencilla de representar el esquema relacional es el denominado “grafo relacional”. Es un grado compuesto de un conjunto de nodos multiparticionados, donde cada nodo representa un esquema de relación, es decir, una tabla de la BD. Para cada esquema de la relación ha de aparecer, como mínimo, su nombre y sus atributos, indicando su clave primaria (subrayamos los atributos que la componen con trazo continuo) y las claves alternativas (se subrayan con trazo discontinuo) y las claves ajenas (de las cuales parten arcos que señalan la tabla referenciada por la correspondiente clave ajena), tal como aparece en el siguiente ejemplo. Las opciones de borrado y modificación de la clave ajena se pueden poner en el arco que une la clave ajena con la tabla referenciada.

4- TEORÍA DE LA NORMALIZACION

El diseño de una base de datos relacional se puede realizar mediante la metodología que acabamos de exponer, aplicando al mundo real, en una primera fase, un modelo semántico como el ME/R, a fin de obtener un esquema conceptual; en una segunda fase, se transforma dicho esquema al modelo relacional mediante las correspondientes reglas de transformación. Si bien nosotros insistimos en las ventajas de este enfoque, existe otra posibilidad que es plasmar directamente en el modelo relacional nuestra percepción del mundo real, obteniendo el esquema relacional sin realizar ese paso intermedio que es el esquema conceptual.

Aunque, en general, la primera aproximación produce un esquema relacional estructurado y con poca redundancia, por lo que no es imprescindible verificar la “bondad” del esquema obtenido, siempre es conveniente aplicar un conjunto de reglas, conocidas como teoría de la normalización que nos permiten asegurar que un esquema relacional cumple unas ciertas propiedades. En el segundo enfoque, es decir, cuando no se ha aplicado la metodología de diseño anteriormente expuesta, la teoría de normalización resulta imprescindible.

Entre los problemas que puede presentar un esquema relacional cuando el diseño es inadecuado cabe destacar:

-          Incapacidad para almacenar ciertos hechos.

-          Redundancias y, por tanto, posibilidad de inconsistencias.

-          Ambigüedades.

-          Perdida de información (aparición de tuplas espurias)

-          Perdidas de ciertas restricciones de integridad que dan lugar a interdependencias entre los datos (dependencias funcionales).

-          Aparición en la base de datos, como consecuencia de las redundancias, de estados que no son validos en el mundo real; es lo que se llama anomalías de inserción, borrado y modificación.

El esquema relacional debe ser, por tanto, analizado para comprobar que no presenta los problemas anteriormente citados, evitando así la perdida de información y la aparición de inconsistencias.

Veamos un ejemplo de estos problemas derivados de un diseño inadecuado. En el ejemplo se muestra la relación ESCRIBE que almacena datos sobre los libros (Cod_libro, Titulo, Editorial, Año) y sobre los autores que los han escrito (Autor y Nacionalidad). Si observamos esta relación, vemos que presenta varios de los problemas enumerados anteriormente.

Los principales problemas de esta relación se derivan de la gran cantidad de redundancia que presenta. Por ejemplo, la nacionalidad del autor se repite por cada libro que ha escrito; y algo análogo sucede, cuando un libro tiene más de un autor, con la editorial y el año de publicación. Esta redundancia produce a su vez:

-          Anomalías de inserción, ya que dar de alta un libro, obliga a insertar en la base de datos todas las tuplas como autores tenga el libro.

-          Anomalías de modificación, ya que cambiar la editorial de un libro obliga a modificar todas las tuplas que corresponden a ese libro.

-          Anomalías de borrado, ya que el borrado de un libro obliga a borrar varias tuplas, tantas como autores tenga ese libro y, viceversa, el borrado de un autor nos lleva a borrar tantas tuplas como libros ha escrito ese autor.

Vemos, por tanto, que la actualización (alta, baja o modificación) de un solo libro o de un solo autor nos puede obligar a actualizar más de una tupla, dejándose la integridad de la base de datos en manos del usuario. Al riesgo de la posible pérdida de integridad hay que añadir la falta de eficiencia asociada a estas múltiples actualizaciones.

Además de estas anomalías de inserción, borrado y modificación, existen otros problemas adicionales, como la imposibilidad de almacenar ciertos hechos o la desaparición de información que desearíamos mantener en la base de datos. Por ejemplo si se quisiera incluir información sobre un autor del que no existiera ningún libro en la base de datos, no sería posible, ya que el atributo Cod_libro forma parte de la clave primaria de la relación; ni tampoco podríamos introducir obras anónimas (recuerde el lector la regla de integridad de entidad que no permite los nulos en ningún atributo que forme parte de una clave primaria). Por otro lado, al dar de baja un libro, se pierden también los datos de sus autores (si estos solo tuviesen ese libro en la base de datos) y, viceversa, si borramos un autor desaparecen de nuestra base de datos los libros escritos por el ( a no ser que el libro tuviera más de un autor).

Esta relación presenta todos estos problemas debido a que atenta contra un principio básico en todo diseño:

“Hechos distintos se deben almacenar en objetos distintos”

En este caso, en relaciones distintas, con lo que se habrían evitado redundancias y, por tanto, los problemas que acabamos de describir.

Si se hubiera llevado a cabo un diseño riguroso no se habría presentado una relación de este tipo. El problema es que a menudo no se llega a comprender completamente o a representar de forma precisa el Universo del Discurso, debido a una excesiva premura al realizar el análisis o a carecer el analista de conocimientos sobre metodologías de diseño de bases de datos o de experiencia para aplicarlas adecuadamente; también el problema deriva muchas veces de una falta de comunicación entre el analista y el usuario.

Si se asegura la metodología de diseño propuesta, realizando un buen diseño conceptual en el modelo E/R, seguido de una cuidadosa transformación al modelo relacional, se evitarían en gran parte estas anomalías, obteniéndose en general un esquema exento de errores. Sin embargo, ante las posibles dudas respecto a si un determinado esquema relacional es o no correcto, será preferible aplicar siempre a dicho esquema un método formal de análisis que determine lo que pueda estar equivocado en el mismo y nos permita llegar a otro esquema en el que se asegure el cumplimiento de ciertos requisitos; este método formal, como ya hemos indicado es, la teoría de la normalización.

La teoría de la normalización evita las redundancias y las anomalías de actualización, obteniendo relaciones más estructuradas que no presenten los problemas de actualización, obteniendo relaciones más estructuradas que no presenten los problemas que comentábamos anteriormente. Así, en lugar de la relación del ejemplo anterior se podría haber diseñado el siguiente esquema relacional:

LIBRO (Cod_libro, Titulo, Editorial, Año)

AUTOR (Nombre, Nacionalidad)

ESCRIBE (Cod_libro, Nombre)

Donde se ha seguido el principio básico anteriormente enunciado, separando hechos distintos en relaciones distintas, de forma que cada uno de estos esquemas de relación recoge un hecho bien determinado y concreto del mundo real con sus correspondientes atributos; esto es, evidentemente, lo que habría hecho cualquier diseñador medianamente experimentado. Pero ¿Cuáles son las razones para haberlo hecho de esta manera?, ¿en que nos podemos apoyar para afirmar que este diseño es mejor que el anterior?, existen métodos matemáticos y los correspondientes algoritmos que permitan llega a este diseño?, ¿Cómo podríamos conseguir, sin basarnos en la experiencia, que un diseñador advirtiera los errores del primer diseño y,  en lugar de la primera relación ESCRIBE, obtuviese el segundo esquema relacional con las tres relaciones LIBRO, AUTOR y ESCRIBE?.

La respuesta a estas y a otras preguntas análogas se encuentra en la teoría de la normalización, la cual puede definirse como una técnica formal para organizar datos, la cual nos ayuda a determinar qué es lo que está equivocado en un diseño y nos enseña la manera de corregirlo. Por tanto, la teoría de la normalización introduce una formalización en el diseño lógico de bases de datos relacionales, lo que, además, permite mecanizar parte del proceso al poder disponer de instrumentos algorítmicos de ayuda al diseño.

Hemos de advertir que las anomalías a las que da lugar el diseño inadecuado de una base de datos se producen solo en procesos de actualización y nunca en los de consulta. La aplicación de la teoría de la normalización consigue una disminución de dichas anomalías, evitando muchos de los problemas que se pueden plantear en las actualizaciones. Sin embargo, al mismo tiempo penaliza las consultas al disminuir la eficiencia de las mismas, ya que cuando se aplica el proceso de normalización a una base de datos aumenta el número de relaciones, por lo que una determinada consulta puede llevar consigo el acceso a varias tablas realizando combinaciones entre ellas, lo que, indudablemente, eleva el coste de la consulta (recuerde que la operación de combinación consume muchos recursos).

4.1 NOCIÓN INTUITIVA DE LAS FORMAS NORMALES

La teoría de la normalización se centra en lo que se conoce como formas normales. Se dice que un esquema de relación está en una determinada forma si satisface un conjunto específico de restricciones.

La primera forma normal (1FN) fue introducida por Codd en su primer trabajo y es una restricción inherente al modelo relacional, por lo que su cumplimiento es obligatorio. Consiste en la prohibición de que en una relación existan grupos repetitivos, esto es, de que un atributo pueda tomar más de un valor del dominio subyacente. En realidad, se debe decir que una tabla está normalizada solo con que se encuentre en 1FN, aunque, a menudo, esta expresión no se aplica con la debida precisión y se afirma que una tabla no está normalizada porque no está en formas normales superiores a la primera.

Codd, junto con la 1FN, definió también la segunda forma normal (2FN) y la tercera (3FN). Posteriormente, otros autores propusieron nuevas formas normales, como la Forma Normal de BOYCE y CODD (FNBC), CODD (1974), y la cuarta y quinta formal normal (4FN y 5FN) debidas a FAGIN (1977 y 1979).

Tal como se ilustra a continuación, de todo el universo de relaciones en 1FN, solo algunas se encuentran en 2FN, y de estas únicamente una parte está en 3FN, y así sucesivamente; es decir, la 2FN impone más restricciones que la 1FN, la 3FN mas que la 2FN,etc., siendo la 5FN la que impone restricciones más fuertes. A fin de evitar anomalías que describíamos anteriormente es preferible la 5FN, después la 4FN, la 3FN, la 2FN y, por último la 1FN.

La teoría de la normalización se basa en ciertas restricciones definidas sobre los atributos de una relación, las cuales son conocidas con el nombre de dependencias. Existen varios tipos de dependencias, encontrándose relacionadas la 2ª, 3ª y FNBC con las dependencias funcionales, la 4ª con las dependencias multivaluadas y la 5ª con las dependencias de proyección-combinación.

Dado que la exposición de la teoría formal de la normalización exige una cierta base matemática, creemos que mostrar intuitivamente las ideas que subyacen en dicha teoría puede ayudar a nuestros lectores a comprender unos principios de diseño aplicable, no solo del modelo relacional, sino también a otros modelos, o incluso, a sistemas de ficheros. Estas ideas intuitivas no tendrán la precisión ni la formalización de la teoría matemática de la normalización, pero son muchas veces suficientes en la práctica.

Dentro de este enfoque intuitivo podemos decir que un esquema de relación se encuentra en 2FN si, además de estar en 1FN, todos los atributos que no forman parte de ninguna clave candidata suministran información acerca de la clave completa, no de una parte de la clave.

Esta es la causa por la cual la relación ESCRIBE del ejemplo anterior presenta tantas anomalías, y es también el origen de los mismo problemas en la relación PRESTAMO del ejemplo que pongo a continuación. Sea el esquema de relación:

PRÉSTAMO (Num_socio, Dni_socio, Cod_libro, Fecha_préstamo, Editorial, País)

Donde las claves candidatas son:

(Num_socio, Cod_libro)

(Dni_socio, Cod_libro)

Se puede observar que ciertos atributos que no forman parte de ninguna clave candidata, como Editorial, nos dan información acerca del libro pero no tienen nada que ver con el socio, por lo que no constituyen una información acerca de la clave completa sino únicamente de una parte de la clave, luego la relación PRESTAMO no se encuentra en 2FN.

La solución a los problemas ya expuestos que presenta esta relación es descomponerla en dos:

PRESTAMO1 (Num_socio, Dni_socio, Cod_libro, Fecha_prestamo)

LIBROS (Cod_libro, Editorial, País)

Con el primer esquema existen dos claves (Num_socio, Cod_libro y Dni_socio, Cod_libro), y el único atributo (Fecha_prestamo) que no forma parte de ninguna clave, suministra información acerca de la totalidad de ambas claves candidatas; por otra parte, en LIBROS la clave es Cod_libro, y los dos atributos que no son clave también suministran información acerca de la clave completa, ya que en este caso es simple. Por tanto, ambas relaciones se encuentran en 2FN.

De lo que acabamos de exponer se deduce que toda relación cuya clave está formada por un único atributo está, al menos, en 2FN.

Una relación se encuentra en 3FN si, además de las dos restricciones anteriores (1FN y 2FN), se cumple que los atributos que no forman parte de ninguna clave candidata facilitan información solo acerca de la(s) clave(s) y no acerca de otros atributos.

Así, por ejemplo, en PRESTAMO1 el atributo Fecha_prestamo solo facilita información acerca de las claves, ya que no existe ningún otro atributo no clave, por lo que dicha relación esta en 3FN. Sin embargo, en la relación LIBROS el atributo País facilita información acerca de la Editorial, no encontrándose por tanto esta relación en 3FN.

Para resolver los problemas (redundancias, inconsistencias, etc.) que presenta esta relación, conviene descomponerla en:

LIBROS1 (Cod_libro, Editorial)

EDITORIALES (Editorial, País)

Estas están en 3FN, ya que todo atributo no clave facilita información acerca de la clave.

En resumen, podemos decir, que para que una relación se encuentre en 3FN, ha de estar en 1FN, y además, todos sus atributos que no forman parte de ninguna clave candidata “deben ser información referida a la clave, la clave completa y nada más que la clave”, KENT (1983).

Al descomponer la relación de partida (que no estaba en 2FN) en tres relaciones que están en 3FN, hemos evitado muchas de las anomalías anteriormente expuestas. Sin embargo, todavía pueden existir relaciones (como PRESTAMO) que, a pesar de encontrarse en 3FN, continúan presentando problemas; para evitarlos, se definieron el resto de las formas normales.

4.2 DEPENDENCIAS FUNCIONALES

Ya hemos señalado que la teoría de la normalización se basa en el concepto de dependencias, hasta el punto de que se la conoce también como teoría de las dependencias.

Las dependencias son propiedades inherentes al contenido semántico de los datos que se han de cumplir para cualquier extensión del esquema de relación y forman parte de las restricciones de usuario del modelo relacional. La existencia de una dependencia no se puede demostrar, pero si afirmar por observación del mundo real que se trata de modelar; por tanto, del análisis de una extensión valida de un esquema de relación nunca podremos deducir la existencia de una dependencia, pero si podremos, en cambio, llegar a la conclusión de que no existe una determinada dependencia. Por otra parte, si conocemos que una dependencia es cierta para un esquema de relación, podremos asegurar que una extensión de dicho esquema no es válida si no la cumple.

Las dependencias nos muestran algunas importantes interrelaciones existentes entre los atributos del mundo real, cuya semántica tratamos de incorporar a nuestra base de datos; son, por tanto, invariantes en el tiempo, siempre que no cambie el mundo real del cual procede.

Las dependencias funcionales son un tipo especial de dependencias, el más extendido en la práctica, en el cual se basan las primeras formas normales. A continuación vamos a definir dicho concepto, procurando simplificar al máximo el formalismo matemático a el asociado.

Sea el esquema de relación R definido sobre el conjunto de atributos A y sean X e Y subconjuntos de A llamados descriptores. Se dice que Y depende funcionalmente de X, o lo que es igual, que X determina o implica a Y, si y solo si, cada valor de X tiene asociado en todo momento un único valor de Y. Representamos esta dependencia funcional de la siguiente forma:

X ——–> Y

Llamamos determinante o implicante al descriptor que se encuentra a la izquierda del símbolo de implicación, e implicado al descriptor que se encuentra a la derecha.

Sea, por ejemplo, la relación:

LIBRO (Cod_libro, Titulo, Idioma…)

Podemos decir que el código de un libro determina el titulo del mismo

Cod_libro ——-> Titulo

El código del libro (Cod_libro) es el implicante (o determinante) en la anterior dependencia y Titulo es el implicado. Esta dependencia también nos dice que el titulo es una información acerca del libro, ya que una dependencia funcional se puede interpretar diciendo que el implicado es un hecho (en realidad una información) acerca del implicante.

Queremos advertir que la afirmación de que Cod_libro determina Titulo no significa que conocido el código de un libro podamos deducir, a partir de él, cual es su titulo, a no ser que tengamos una extensión r(R9) del esquema de relación que contiene la correspondiente dependencia funcional. Es decir, si para un esquema R tenemos la dependencia funcional:

X ——–> Y

Dado el valor de X no podemos, en general, conocer el valor de Y; solamente nos limitaremos a afirmar que para dos tuplas de cualquier extensión r® que tengan el mismo valor de X, el valor de Y será también igual a ambas.

Una herramienta muy útil a la hora de explicitar las dependencias funcionales es el grafo o diagrama de dependencias funcionales, mediante el cual se representa un conjunto de atributos y las dependencias funcionales existentes entre ellos. En el grafo aparecen los nombres de los atributos unidos por flechas, las cuales indican las dependencias funcionales del implicante hacia el implicado. Cuando el implicante de una dependencia no es un único atributo, es decir, se trata de un implicante compuesto, los atributos que lo componen se encierran en un recuadro y la flecha parte de este, no de cada atributo.

En el ejemplo siguiente se presenta como se visualizan las dependencias. Existen otros conceptos, como el de dependencia plena o completa y el de dependencia transitiva, fundamentales en la teoría de la normalización.

A) Dependencia funcional plena o completa

Sea un descriptor compuesto X:

X(X1, X2)

Se dice que Y tiene dependencia funcional completa o plena de X si depende funcionalmente de X pero no depende de ningún subconjunto del mismo, esto es:

X ——> Y

X1 –/–> Y

X2 –/–> Y

Lo que se representa por:

X => Y

Supongamos la relación:

PRESTA (Cod_libro, Titulo, Editorial, Num_socio, Nombre, Domicilio, Teléfono, Fecha_prestamo, Fecha_dev)

Cuyas dependencias funcionales aparecen en la imagen anterior, la dependencia funcional:

Cod_libro, Num_socio ——> Fecha_prestamo

Indica que, dado un determinado código de libro y un numero de socio, existe una única fecha de préstamo (para simplificar se ha supuesto que un mismo libro no se presta a un mismo socio en varias ocasiones). Ni código de libro, ni tampoco numero de socio, implican, por si solos, la fecha de préstamo, ya que tanto un libro se puede prestar en varias fechas como un socio puede recibir libros prestados en varias fechas. Por tanto, la dependencia funcional anterior es completa, lo que se representa:

Cod_libro, Num_socio => Fecha_prestamo

Ya que:

Cod_libro     —/—> Fecha_prestamo

Num_socio —/—> Fecha_prestamo

Lo que, intuitivamente, se puede interpretar como que Fecha_prestamo constituye una información sobre el conjunto de libro y socio, pero esta información no atañe a un libro o a un socio por separado.

Por el contrario, la dependencia:

Cod_libro, Num_socio —–> Editorial

No es plena, ya que:

Cod_libro —–> Editorial

Se dice que, en esa dependencia. Num_socio es un atributo redundante o ajeno a la dependencia (también llamado extraño).

B) Dependencia funcional transitiva

Sea la relación

R(X, Y, Z)

En la que existen las siguientes dependencias funcionales:

X —–> Y

Y —–> Z

Y –/–> X

Se dice entonces que Z tiene una dependencia transitiva respecto de X a través de Y, lo que se representa por:

X —  —> Z

Si además, Z –/–> Y, se dice que la dependencia transitiva es estricta.

En la siguiente imagen se presenta un diagrama de dependencias funcionales en el que la dependencia

X —   —> Z

Es transitiva.

4.3 DEFINICION FORMAL DE LAS TRES PRIMERAS FORMAS NORMALES

Expuesto ya el concepto de dependencia funcional, podemos formalizar la definición de segunda y tercera forma normal apoyándonos en la dependencia funcional plena y transitiva.

Primera forma normal (1FN). Recordemos que para que una tabla pueda ser considerada una relación no debe admitir grupos repetitivos, esto es, debe estar en primera forma normal. En el siguiente ejemplo se observa, en la parte “a”, grupos repetitivos en aquellos libros que tienen más de un autor; para pasar esta tabla (no es una relación puesto que no está en 1FN) a 1FN, habrá que repetir el resto de atributos de la tupla para cada uno de los valores del grupo repetitivo, tal como aparece en la parte “b” del ejemplo. Se dice que una relación esta en 1FN si cada atributo toma un único valor del dominio subyacente.

Segunda forma normal (2FN) Se dice que una relación esta en 2FN si:

Esta en 1FN

Cada atributo no principal tiene dependencia funcional completa respecto de cada una de las claves.

Por ejemplo, si tenemos la relación: PRESTA (Cod_libro, Num_socio, editorial), en la que existe la siguiente dependencia funcional:

Cod_libro —–> Editorial

Y cuya clave esta constituida por el descriptor Cod_libro, Num_socio, esta relación no se encuentra en 2FN al venir la editorial determinada solo por el código de libro y no por la clave completa

Tercera formal normal (3FN) Se dice que una relación esta en 3FN si:

Esta en 2FN

No existe ningún atributo no principal que dependa transitivamente de alguna de las claves de relación.

Sea, por ejemplo, la relación:

SOCIO (Num_socio, Ciudad, País)

Que presenta las siguientes dependencias funcionales:

Num_socio —–> Ciudad

Ciudad         —–> País

Y cuya clave es, evidentemente, Num_socio. Dicha relación no se encuentra en 3FN, al depender País transitivamente de la clave a través de Ciudad.

Tanto la relación PRESTA como la relación SOCIO presentan los problemas citados anteriormente. Si estas relaciones se llevasen a formas normales más avanzadas se eliminarían, o al menos se atenuarían, estos problemas.

4.4 DESCOMPOSICIÓN DE RELACIONES

La transformación de una relación que se encuentra en una determinada forma normal, en otra relación cuya forma normal es superior se realiza por medio del operador de proyección del algebra relacional.

Sea, por ejemplo, la relación:

PRESTA (Cod_libro, Num_socio, Editorial)

Que, como hemos visto, se encuentra solo en 1FN (ya que su único atributo no principal, Editorial, no depende totalmente de la clave). Si quisiéramos llevar esta relación a una forma normal más avanzada, sería preciso descomponerla, mediante proyecciones, obteniendo varias relaciones. Así, proyectando sobre Cod_libro, Num_socio y sobre Cod_libro, Editorial, tendríamos:

PRESTA1 (Cod_libro, Num_socio)

PRESTA2 (Cod_libro, Editorial)

Ambas relaciones están en 3FN y han desaparecido las redundancias y las inconsistencias a las que antes aludíamos.

Además, la combinación natural de PRESTA1*PRESTA2 (por el atributo común Cod_libro) nos devuelve la relación original.

De manera análoga, la relación:

SOCIO (Num_socio, Ciudad, País)

Que se encuentra en 2FN, pero no es tercera, podría descomponerse en dos proyecciones:

SOCIO1 (Num_socio, Ciudad)

CIUDAD (Ciudad, País)

También, al igual que en el caso anterior:

SOCIO1 * CIUDAD = SOCIO

En el proceso de descomposición de relaciones, para llevarlas a formas normales mas avanzadas es preciso cumplir unas determinadas reglas:

A) Descomposición sin pérdida de información

Se dice que una descomposición se ha realizado sin pérdida de información cuando la combinación natural de las proyecciones resultantes nos devuelve la relación original.

Sea la relación:

LIBRO (Cod_libro, Editorial, País)

En la cual tienen lugar las siguientes dependencias funcionales:

Cod_libro —–> Editorial

Editorial   ——> País

Una extensión de esta relación aparece en la parte “a” del siguiente ejemplo

Supongamos que descomponemos esta relación en:

LIBRO1 (Cod_libro, País)

EDITORIAL1 (Editorial, País)

Cuyas extensiones aparecen en la parte “b” de la imagen anterior. La combinación de estas dos relaciones (ver parte c) da lugar a la aparición de tuplas espurias que no se encontraban en la extensión original. Se dice que la descomposición de LIBRO ha dado lugar a perdida de información.

Si en lugar de esta descomposición hubiéramos obtenido:

LIBRO2 (Cod_libro, País)

EDITORIAL2 (Cod_libro, Editorial)

Es fácil comprobar que la combinación natural

LIBRO2 * EDITORIAL2

Daría la relación original (sin tuplas espurias).

La condición necesaria y suficiente para que una descomposición se produzca sin pérdida de información es que el atributo común de las dos relaciones sea clave, al menos, en una de ellas; condición que no se cumple en la primera descomposición, pero si en la segunda.

B) Descomposición sin pérdida de dependencia funcionales

Las dependencias funcionales recogen la semántica del mundo real, por lo que es conveniente conservarlas en el proceso de descomposición.

Sea la misma relación LIBRO del ejemplo anterior que hemos descompuesto en LIBRO2 y EDITORIAL2, donde no ha habido pérdida de información, dado que el atributo común (Cod_libro) es clave en ambas relaciones.

Sin embargo, en esta descomposición se ha perdido una dependencia funcional, ya que en la relación LIBRO2 la única dependencia funcional es:

Cod_libro —-> País

Y en la EDITORIAL2, la única dependencia es:

Cod_libro —–> Editorial

Luego la dependencia Editorial —–> País se ha perdido, y con ella también ha desaparecido en nuestro esquema parte de la semántica del mundo real, que nos dice que, dada una editorial, ésta se encuentra en un único país.

C) Descomposición en proyecciones independientes

La descomposición de una relación R en un conjunto de relaciones {R_i} se dice que se ha realizado en proyecciones independientes si no ha habido perdida de información ni dependencias funcionales.

Si la relación LIBRO de nuestro ejemplo la hubiésemos descompuesto en:

LIBRO3 (Cod_libro, Editorial)

EDITORIAL3 (Editorial, País)

Estas dos proyecciones serian independientes, ya que el atributo común es clave de una de las relaciones (la segunda), por lo que no hay pérdida de información; además, tampoco hay pérdida de dependencias funcionales, dado que en LIBRO3 tenemos la dependencia:

Cod_libro —–> Editorial

Y en EDITORIAL3, tendríamos:

Editorial —–> País

Se trata de la mejor descomposición; las relaciones resultantes son equivalentes a la relación original y, en ellas, se han eliminado las anomalías de inserción, borrado y modificación (dado que solo se ha llegado a 3FN no se puede asegurar que, en todos los casos, se eliminen por completo las anomalías).

Se puede demostrar que es posible descomponer cualquier relación, llevándola a 3FN, sin pérdida de información ni de dependencias funcionales (cosa que no siempre ocurre si se quisiese llevarla a formas normales más avanzadas).

A veces, el proceso de normalización se aplica a la denominada relación universal, constituida por el conjunto de atributos de universo del discurso que se desea modelar y por el conjunto de sus dependencias funcionales. Además del método de descomposición, también llamado análisis, cuyos fundamentos acabamos de exponer, existe otro método para normalizar una relación que es el método de síntesis.

Existen procedimientos algorítmicos que realizan la descomposición de relaciones en proyecciones independientes.

4.5 CONSIDERACIONES FINALES SOBRE LA TEORIA DE LA NORMALIZACION

La teoría de la normalización nos ayuda a estructurar mejor las relaciones, evitando posibles redundancias y anomalías, y a representar mejor nuestro mundo real en un esquema relaciona.

Sin embargo, no hay que olvidar que al descomponer una relación penalizamos las consultas, provocando una pérdida de eficiencia en las mismas. Aunque, en general, se aconseja llevar los esquemas relacionales al menos a 3FN, existen ciertos casos en los que, una vez realizada la descomposición, exigencias de eficiencia muy estrictas obligan a llevar a cabo el proceso inverso, es decir, una desnormalización, combinando las relaciones hasta dejarlas en formas normales anteriores. También en relaciones muy estables, donde apenas se producen actualizaciones /este es, por ejemplo, el caso de ciertas investigaciones estadísticas), puede no ser conveniente avanzar en la normalización.

Por otra parte, si seguimos la metodología de diseño expuesta en la primera parte de este capítulo, obteniendo primero un esquema en el modelo entidad/ interrelación y transformándolo después al modelo relaciona, el esquema relacional resultante, siempre que todo el proceso se haya realizado correctamente, estará en 3FN (e incluso en formas normales más avanzadas). En este caso, la teoría de la normalización nos servirá para comprobar que el diseño ha sido correcto y, si no lo fuese, podremos aplicar la descomposición para corregir los errores que hubieran podido producirse.