Diseño Estructurado de Datos

Transcripción

1 ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA Diseño Estructurado de Datos Esperanza Marcos

2 Contenido GUÍA DE ESTUDIO EL DISEÑO DE DATOS EN EL PROCESO DE DESARROLLO SOFTWARE CONCEPTOS Y TÉRMINOS BÁSICOS DE BASES DE DATOS CONCEPTO DE BASE DE DATOS ARQUITECTURA ANSI/X3/SPARC A TRES NIVELES EL MODELO DE DATOS RELACIONAL INTRODUCCIÓN AL MODELO RELACIONAL ESTÁTICA DEL MODELO RELACIONAL Dominio y Atributo Definición Formal de Relación Claves EL MODELO RELACIONAL Y LA ARQUITECTURA ANSI DISEÑO DE BASES DE DATOS RELACIONALES TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL E/R AL ESQUEMA RELACIONAL TEORÍA DE LA NORMALIZACIÓN Dependencias Funcionales Formas Normales Descomposición de Relaciones Algunas Consideraciones sobre la Teoría de la Normalización EJERCICIOS DE AUTOCOMPROBACIÓN ENUNCIADOS BIBLIOGRAFÍA BIBLIOGRAFÍA BÁSICA BIBLIOGRAFÍA RECOMENDADA

3 Guía de Estudio En la unidad dedicada al Modelado Conceptual de Datos, nos ocupamos de estudiar el modo de recoger los requisitos de usuario en cuanto a sus necesidades de datos. Estas necesidades del usuario captadas en la etapa de análisis hay que llevarlas al mundo informático implementándolas en un sistema concreto. Aunque existen diversos modos de almacenar datos en un sistema informático, el sistema más extendido en la actualidad, es mediante el uso de Bases de Datos Relacionales. El objetivo de esta unidad es que el alumno, al finalizar el estudio de la misma, sea capaz de diseñar, a partir de un esquema conceptual de datos previamente concebido, el esquema relacional correspondiente. Para ello, en primer lugar, situaremos las actividad del diseño de datos en el lugar que les corresponde dentro del proceso de desarrollo software, estableciendo las relaciones existentes entre ésta y otras actividades. Posteriormente, revisaremos el concepto de Base de Datos (en adelante BD), así como las características más relevantes de éstas, a fin de poder comprender mejor el proceso de diseño. A continuación pasaremos a exponer el modelo relacional, que además de ser el más extendido en la actualidad, es el modelo lógico de datos ligado al desarrollo estructurado de software. Continuaremos estudiando una metodología de diseño para BD relacionales. La unidad incluye una serie de ejercicios de autocomprobación con las soluciones propuestas. Finalmente se detalla la bibliografía que se ha divido en dos apartados: bibliografía básica en la que nos hemos basado para desarrollar esta unidad y que, en general, el alumno debería conocer; y bibliografía recomendada, constituida por libros que también hemos consultado y que se recomienda a aquellos alumnos que deseen profundizar o completar algún aspecto concreto de ésta unidad. Finalmente se incluye un control que permitirá evaluar los conocimientos adquiridos por el alumno al final de la unidad. Para cualquier consulta o sugerencia, el alumno dispone de una dirección de correo electrónico (cuca@escet.urjc.es) a la que podrá enviar sus comentarios. 3

4 1. El Diseño de Datos en el Proceso de Desarrollo Software En la unidad dedicada al modelado conceptual de datos, estudiábamos como obtener un esquema conceptual que representaba los requisitos de usuario de un modo totalmente independiente de la implementación del mismo. Estábamos en la etapa de análisis y nuestro objetivo era determinar el Qué pero sin ocuparnos aún del Cómo. Es ahora, en la etapa de diseño, cuando debemos ocuparnos de cómo implementar el esquema conceptual obtenido en la etapa de análisis. El primer paso en este proceso es determinar el modelo de persistencia que se va a utilizar, es decir, el modo en que se almacenarán los datos. Como primera opción debemos decidir si almacenaremos los datos en sistemas de ficheros o en sistemas de bases de datos. En general, siempre que se trate de un sistema centrado en los datos, como es el caso de los Sistemas de Información (en adelante SI) para la gestión, se utilizarán BD para la persistencia de los mismos. Dependiendo del modelo que soporte el Sistema de Gestión de la Bases de Datos (en adelante SGBD), existen diferentes tipos de BD: jerárquicas, Codasyl, relacionales, objetorelacionales y orientadas a objetos. Sin embargo, en la actualidad, el modelo más utilizado sin duda alguna para aplicaciones de gestión es el modelo relacional. Por ello, utilizaremos el modelo relacional como técnica de diseño estructurado de datos. La actividad de diseño de datos se realiza paralelamente a la de diseño de procesos. En la figura 1.1 se muestra la situación del diseño de datos en el proceso de desarrollo, así como la relación existente entre esta y otras actividades. La etapa de diseño comprende tanto el diseño de datos como el de funciones. La técnica más habitual para el diseño de datos es el modelo relacional y para el diseño de procesos son los Diagramas de Estructuras de Cuadros (en adelante DEC). Como se puede apreciar, la etapa de análisis también se compone del análisis de datos y del análisis de procesos, tal y como vimos en la unidad dedicada al modelado conceptual de datos. DATOS FUNCIONES ANALISIS Modelado Conceptual de Datos: Modelado E/R Conceptual de Procesos: DFD REQUISITOS DE INFORMACIÓN DISEÑO Diseño de Datos: REQUISITOS RelacionalDiseño DE LOS PROCESOS de Procesos: DEC Figura 1.1. Comparación entre el diseño de datos y de procesos 4

5 2. Conceptos y Términos Básicos de Bases de Datos 2.1. Concepto de Base de Datos Una base de datos es un conjunto, colección o depósito de datos almacenados en un soporte informático no volátil. Los datos están interrelacionados y estructurados de acuerdo con un modelo capaz de recoger el máximo contenido semántico. Dada la relevancia que tienen en el mundo real las interrelaciones entre los datos, es imprescindible que la base de datos sea capaz de almacenar estas interrelaciones. En el mundo real existen, además, restricciones semánticas, y que, en los sistemas actuales, tienden a almacenarse junto con los datos, al igual que ocurre con las interrelaciones. La base de datos se describe y se manipula apoyándose en un modelo de datos. La redundancia de los datos debe ser controlada, de forma que no existan duplicidades perjudiciales ni innecesarias, y que las redundancias físicas, convenientes muchas veces a fin de responder a objetivos de eficiencia, sean tratadas por el mismo sistema, de modo que no puedan producirse inconsistencias. Esto podría resumirse diciendo que en las bases de datos no debe existir redundancia lógica, aunque sí se admite cierta redundancia física por motivos de eficiencia. Las bases de datos pretenden servir al conjunto de la organización, manejando los datos como otro recurso que viene a añadirse a los ya tradicionales. Por tanto, las bases de datos han de atender a múltiples usuarios y a diferentes aplicaciones, en contraposición a los sistemas de ficheros, en los que cada fichero está diseñado para responder a las necesidades de una determinada aplicación. Otro aspecto importante de las bases de datos es la independencia, tanto física como lógica, entre datos y tratamientos. Esta independencia, objetivo fundamental de las bases de datos, es una característica esencial que distingue las bases de datos de los ficheros y que ha tenido una enorme influencia en la arquitectura de los SGBD, como se verá más adelante. La definición o descripción del conjunto de datos contenidos en la base (a lo que se denomina estructura o esquema de la base de datos) deben ser únicas y estar integradas con los mismos datos. En los sistemas basados en ficheros, los datos se encuentran almacenados en ficheros, mientras su descripción (muy somera) está separada de los mismos, formando parte de los programas, para lo cual se precisa que los lenguajes faciliten medios para la descripción de los datos. En las bases de datos, la descripción, y en algunos casos también una definición y documentación completas (metadatos), se almacena junto con los datos, de modo que éstos están autodocumentados, y cualquier cambio que se produzca en dicha documentación se ha de reflejar y quedar recogido en el sistema, con todas las ventajas que de este hecho se derivan. 5

6 La actualización y recuperación de los datos debe realizarse mediante procesos bien determinados, incluidos en el SGBD, el cual ha de proporcionar también instrumentos que faciliten el mantenimiento de la seguridad (confidencialidad, disponibilidad e integridad) del conjunto de datos. El concepto de base de datos ha ido cambiando y configurándose a lo largo del tiempo; en la actualidad, y de acuerdo con estas características que acabamos de analizar, podemos definir la Base de Datos como: Una colección o depósito de datos integrados, almacenados en soporte secundario (no volátil) y con redundancia controlada. Los datos, que han de ser compartidos por diferentes usuarios y aplicaciones, deben mantenerse independientes de ellos, y su definición (estructura de la base de datos) única y almacenada junto con los datos, se ha de apoyar en un modelo de datos, el cual ha de permitir captar las interrelaciones y restricciones existentes en el mundo real. Los procedimientos de actualización y recuperación, comunes y bien determinados, facilitarán la seguridad del conjunto de los datos, De Miguel y Piattini (1999). Podemos definir Sistema de Gestión de Bases de Datos (SGBD) como: Conjunto de programas que permiten la implantación, acceso y mantenimiento de la base de datos. El SGBD, junto con la base de datos y con los usuarios, constituyen el Sistema de Base de Datos (SBD). SBD = SGBD + DATOS + USUARIOS 2.2. Arquitectura ANSI/X3/SPARC a Tres Niveles Se puede observar en los SI la existencia de dos estructuras distintas, la lógica (vista del usuario) y la física (forma en que se encuentran los datos almacenados). En las bases de datos aparece un nuevo nivel de abstracción que se ha denominado de diversas maneras: nivel conceptual, lógico global, etc. Esta estructura intermedia pretende una representación global de los datos que se interponga entre las estructuras lógica y física de la arquitectura a dos niveles, siendo independiente, tanto del equipo como de cada usuario en particular (ver figura 2.1). 6

7 USUARIO A B C D E F G ESTRUCTURA LOGICA ESTRUCTURA LOGICA GLOBAL B E A C D G F ESTRUCTURA FISICA Figura 2.1. Arquitectura de BD a tres niveles La estructura lógica de usuario o esquema externo es la visión que tiene de la base de datos cada usuario en particular; la estructura lógica global (también denominada esquema conceptual) responde al enfoque del conjunto de la empresa y la estructura física (o esquema interno) es la forma cómo se organizan los datos en el almacenamiento físico. La estructuración de una base de datos en estos tres niveles de abstracción fue propuesta por el grupo ANSI/X3/SPARC y tiene como principal objetivo conseguir la independencia entre datos y aplicaciones. 3. El Modelo de Datos Relacional 3.1. Introducción al Modelo Relacional A finales de los años 60, Codd propone un modelo de datos basado en la teoría de las relaciones, en donde los datos se estructuran lógicamente en forma de relaciones -tablas-, siendo un objetivo fundamental del modelo mantener la independencia de esta estructura lógica respecto al modo de almacenamiento y a otras características de tipo físico. Los avances más importantes que el modelo de datos relacional incorpora respecto a los modelos de datos anteriores son: Sencillez y uniformidad: los usuarios ven la base de datos relacional como una colección de tablas, y al ser la tabla la estructura fundamental del modelo, éste goza de una gran uniformidad, lo que unido a unos lenguajes no navegacionales y muy orientados al usuario final, da como resultado la sencillez de los sistemas relacionales. 7

8 Sólida fundamentación teórica: al estar el modelo definido con rigor matemático, el diseño y la evaluación del mismo puede realizarse por métodos sistemáticos basados en abstracciones. Independencia de la interfaz de usuario: los lenguajes relacionales, al manipular conjuntos de registros, proporcionan una gran independencia respecto a la forma en la que los datos están almacenados. Las indiscutibles ventajas del modelo relacional no le han librado de críticas, especialmente las relativas a la poca eficiencia de los primeros prototipos y productos comerciales y a su falta de semántica. Probablemente, la teoría relacional nació cuando la tecnología existente no podía todavía ofrecer el adecuado soporte para implementaciones que respondiesen eficientemente a las necesidades de los usuarios. A pesar de ello, el modelo de datos relacional ha tenido un auge espectacular desde finales de los años 70, y sobre todo en los 80, una vez que empezaron a vencerse las dificultades que presentaba su implementación y gracias al desarrollo tecnológico que ha permitido una mayor eficiencia de los productos relacionales Estática del Modelo Relacional Como hemos señalado anteriormente, la relación es el elemento básico del modelo relacional, y se puede representar como una tabla. En la figura 3.1 se representa la relación EMPLEADO en donde aparece la estructura del modelo relacional. En ella, podemos observar el nombre de la relación (EMPLEADO); los atributos (Nombre, DNI, y Estado_civil); los dominios (de donde los atributos toman sus valores); las tuplas (o filas); el grado (número de atributos); y la cardinalidad (número de tuplas). EMPLEADO Vela, B. Nombre DNI Estado_civil Parrilla, A. B. Bermudez, S. Jimenez, B Soltera Soltera Soltero Casada Atributos T U P L A S Cardinalidad 4 Grado 3 Figura 3.1. Representación mediante una tabla de la relación EMPLEADO 8

9 Aunque una relación se puede representar en forma de tabla, tiene una serie de elementos característicos que la distinguen de la tabla, ya que una relación: No admite filas duplicadas Las filas y las columnas no están ordenadas Es plana, es decir, que en el cruce de una fila y de una columna sólo puede haber un valor (no se admiten atributos multivaluados) Dominio y Atributo Definimos dominio (D) como: Un conjunto finito de valores homogéneos y atómicos V 1, V 2,..., V n, caracterizado por un nombre. Decimos valores homogéneos porque son todos del mismo tipo, y atómicos porque son indivisibles en lo que al modelo se refiere, es decir, si se descompusiesen, perderían la semántica a ellos asociada. Por ejemplo, el dominio de Estados_civiles tiene los valores: Soltero/a, Casado/a, Viudo/a y Divorciado/a, que son todos del mismo tipo y que no son divisibles sin perder su semántica; así, si descompusiéramos el valor "SOLTERO" en las letras "S", "O", "L", etc., se perdería la semántica, ya que estas letras consideradas aisladamente han dejado de tener el significado que tiene "SOLTERO" como un valor del estado civil. Todo dominio ha de tener un nombre, por el cual nos podemos referir a él y un tipo de datos; así el tipo de datos del dominio de Estados_civiles es una tira de caracteres de longitud diez. También se le puede asociar ciertas restricciones. Los dominios pueden definirse por intensión o por extensión. Por ejemplo, el dominio de las Notas de los alumnos se puede definir por intensión como un entero de longitud dos comprendido entre 0 y 10, mientras que la definición del dominio de Estadso_civiles por intensión sería muy pobre semánticamente, ya que permitiría toda combinación de 10 letras aun cuando no constituyesen un nombre válido de estado civil; por ello, es preferible definir este dominio por extensión con los nombres de los distintos estados civiles. Podemos definir un atributo (A) en función del concepto de dominio como: El papel que juega un determinado dominio D en una relación; se dice que D es el dominio de A y se denota como dom(a) 9

10 Así, el atributo Estado_civil de la tabla EMPLEADO, definido sobre el dominio de Estados_civiles nos indica que dicho atributo tiene el papel de estado civil del empleado en dicha tabla, tal y como se muestra en la figura 3.2. DOMINIOS NOMBRE DNI ESTADO_CIVIL xxxxxxxx Soltero Casadoc Viudo Divorciado Soltera Casada Viuda Divorciada EMPLEADO Vela, B. Nombre DNI Estado_civil Parrilla, A. B. Bermudez, S. Jimenez, B Soltera Soltera Soltero Casada Atributos T U P L A S Cardinalidad 4 Grado 3 Figura 3.2. Dominios y atributos de la relación EMPLEADO El universo del discurso de una base de datos relacional, representado por U, está compuesto por un conjunto finito y no vacío de atributos, A 1 A 2,..., A n, estructurados en relaciones; cada atributo toma sus valores de un único dominio (dominio subyacente) y varios atributos pueden tener el mismo dominio subyacente. Es muy usual dar el mismo nombre al atributo y al dominio subyacente. En el caso de que sean varios los atributos de una misma tabla definidos sobre el mismo dominio, habrá que darles nombres distintos, ya que una tabla no puede tener dos atributos con el mismo nombre. Además de los dominios y atributos simples, que acabamos de definir, en la década de los 90, los trabajos posteriores de algunos autores como Codd y Date, introducen el concepto de dominio compuesto. Un dominio compuesto se puede definir como una combinación de dominios simples a la que se puede aplicar ciertas restricciones de integridad. Por ejemplo, un usuario puede necesitar manejar, además de los tres dominios Día, Mes y Año, un dominio compuesto por ellos denominado Fecha, al que podríamos aplicar las adecuadas restricciones de integridad a fin de que no aparecieran valores no válidos para la fecha; algo análogo ocurre con el nombre y los apellidos, que, según las aplicaciones, puede ser conveniente tratarlos en conjunto o por separado. 10

11 Al igual que es posible definir dominios compuestos, existen también atributos compuestos; así el atributo Fecha tomaría sus valores del dominio compuesto de igual nombre. Tanto los atributos compuestos como los dominios compuestos pueden ser tratados, si así lo precisa el usuario, como piezas únicas de información, es decir, como valores atómicos Definición Formal de Relación Matemáticamente, una relación, definida sobre los n dominios D 1, D 2,..., D n, no necesariamente distintos, es un subconjunto del producto cartesiano de estos dominios, donde cada elemento de la relación (tupla) es una serie de n valores ordenados. En esta definición matemática de relación, que es la que aparece en los primeros trabajos de Codd, no se alude a los atributos, es decir, al papel que juegan los dominios en la relación y, además, en ella el orden de los valores dentro de una tupla es significativo. A fin de evitar estos inconvenientes se puede dar otra definición de relación más adecuada desde el punto de vista de las bases de datos (ya que la relación matemática y la relación en BD no es exactamente lo mismo), para lo cual es preciso distinguir en la noción de relación los siguientes elementos: Nombre: las relaciones se identifican por un nombre; si bien ciertas relaciones que no necesitan identificarse (por ejemplo, resultados intermedios) pueden no tener nombre. Cabecera de relación: conjunto de n pares atributo-dominio subyacente n {(A i :D i )} i=1 donde n es el grado; se corresponde con la primera fila cuando la relación se percibe como una tabla. El conjunto A de atributos sobre los que se define la relación se llama contexto de la misma. Cuerpo de la relación: conjunto de m tuplas {t 1, t 2,..., t m }, donde cada tupla es un conjunto de n pares atributo-valor {(A i :V ij )}, siendo V ij el valor j del dominio D i asociado al atributo A i ; el número de tuplas m es la cardinalidad. Así como la cabecera de relación es invariante, su cuerpo varía en el transcurso del tiempo, al igual que la cardinalidad. Esquema de relación: constituido por el nombre R -si existe- y la cabecera, denotandose: R ({A i :D i } n i=1). El esquema de relación representa la parte definitoria y estática de la relación y se denomina también intensión; corresponde a lo que hemos llamado entidad en el modelo E/R (ver la unidad dedicada al modelado conceptual de datos). El estado de relación r(r), al que denominaremos simplemente relación o también extensión, está constituido por el esquema y el cuerpo de relación: <esquema, cuerpo>; siendo el cuerpo el conjunto de tuplas que, es un instante dado, satisface el correspondiente esquema de relación. Corresponde a lo que hemos denominado extensión de entidad en el modelo E/R. 11

12 En la figura 3.2 se representa en forma de tabla, un ejemplo de esquema de relación (intensión) y de estado de una relación (extensión). ESQUEMA DE RELACION (INTENSION): EMPLEADO (Nombre: Nombres, DNI: DNIs, Estado_civil: Estados_civiles) RELACION (EXTENSION o ESTADO): EMPLEADO Nombre DNI Estado_civil Vela, B. Parrilla, A. B. Bermudez, S. Jimenez, B Soltera Soltera Soltero Casada Figura 3.3. Ejemplo de esquema (intensión) y de estado (extensión) de la relación EMPLEADO Una base de datos relacional es una base de datos percibida por los usuarios como una colección de relaciones que varían en el tiempo Claves Una clave candidata de una relación es un conjunto de atributos que identifican unívoca y mínimamente cada tupla de la relación. Por la propia definición de relación, siempre hay, al menos, una clave candidata, ya que al ser una relación un conjunto no existen dos tuplas iguales y, por tanto, el conjunto de todos los atributos siempre tiene que identificar unívocamente a cada tupla; si no se cumpliera la condición de minimalidad se eliminarían aquellos atributos que lo impidiesen. Por ejemplo, la relación EMPLEADO de la figura 3.3 tiene dos claves candidatas: el atributo Nombre, ya que suponemos que no existen dos autores con el mismo nombre y el atributo DNI. Una relación puede tener más de una clave candidata, entre las cuales se debe distinguir entre la clave primaria y la(s) clave(s) alternativa(s). 12

13 Clave primaria: es aquella clave candidata que el usuario escogerá, por consideraciones ajenas al modelo relacional, para identificar las tuplas de la relación. Cuando sólo existe una clave candidata, ésta será la clave primaria. En el ejemplo de la relación EMPLEADO, el atributo DNI será la clave primaria, aunque también podría serlo el atributo Nombre. El modelo relacional obliga a la existencia de una clave primaria en cada relación. La clave primaria de una relación suele representarse subrayando el atributo u atributos que la componen. La clave primaria lleva siempre asociada la regla de integridad de entidad por la que: "Ningún atributo que forme parte de la clave primaria de una relación puede tomar un valor nulo"; esto es, un valor desconocido o inexistente. La necesidad de los valores nulos o marcas en las bases de datos es evidente por diversas razones: Crear tuplas (filas) con ciertos atributos desconocidos en ese momento, por ejemplo, la fecha de nacimiento de un empleado. Añadir un nuevo atributo a una relación existente; atributo que, en el momento de añadirse, no tendría ningún valor para las tuplas de la relación. Atributos inaplicables a ciertas tuplas, por ejemplo, el número de registro de personal para un empleado de la administración que no sea funcionario. Claves alternativas: son aquellas claves candidatas que no han sido escogidas como clave primaria. En el ejemplo de la relación EMPLEADO la clave alternativa sería el atributo Nombre a que el atributo DNI ha sido seleccionado como clave primaria. Se denomina clave ajena de una relación R2 a un conjunto no vacío de atributos cuyos valores han de coincidir con los valores de la clave candidata de una relación R1 (R1 y R2 no son necesariamente distintas). Cabe destacar que la clave ajena y la correspondiente clave candidata han de estar definidas sobre el mismo dominio. La clave ajena lleva siempre asociada la regla de integridad referencial, que dice Si una relación R2 (relación que referencia) tiene un descriptor que es una clave candidata de la relación R1 (relación referenciada), todo valor de dicho descriptor debe, bien concordar con un valor de la clave candidata referenciada de R1, bien ser nulo. El descriptor es, por tanto, una clave ajena de la relación R2. Las relaciones R1 y R2 no son necesariamente distintas. La clave ajena sirve para asociar relaciones. En la figura 3.5 se muestra cómo los valores del atributo Departamento de la relación EMPLEADO concuerdan con los de la clave primaria Cod_dep de la relación DEPARTAMENTO. 13

14 DEPARTAMENTO Cod_dep Nom_dep... Dep1 Dep2 Dep3 Dep4 Formación Ventas I+D Personal EMPLEADO Nombre DNI Estado_civil Departamento Vela, B Soltera Dep1 Parrilla, A. B Soltera Dep1 Bermudez, S Soltero Dep2 Jimenez, B Casada NULL Figura 3.5. Clave ajena de la tabla EMPLEADO que referencia a DEPARTAMENTO Como se puede apreciar en la figura 3.5., todos los valores de la clave ajena, Departamento, de la relación EMPLEADO concuerdan con algún valor de la clave primaria, Cod_dep, de la relación DEPARTAMENTO, o bien son nulos, cumpliendose así la regla de integridad referencial (los empleados deben pertenecer a un departamento existente o, si se desconoce el departamento, tendrán valor nulo para ese atributo). Tanto la relación EMPLEADO como la relación DEPARTAMENTO verifican también la regla de integridad de entidad ya que sus respectivas claves primarias, DNI y Cod_dep, no contienen ningún valor nulo. En la figura 3.6 se muestra una forma de representar las claves ajenas, mediante lo que se denomina el grafo relacional. EMPLEADO (DNI, Nombre, Estado_civil, Departamento) DEPARTAMENTO (Cod_dep, Nom_dep ) Figura 3.6. Ejemplo de representación de clave ajena mediante un grafo relacional 14

15 Además de definir las claves ajenas, hay que determinar las consecuencias que pueden tener ciertas operaciones (borrado y modificación) realizadas sobre tuplas de la relación referenciada; pudiéndose distinguir, según el estándar SQL92, las siguientes opciones: Operación restringida (NO ACTION): el borrado de tuplas de la relación que contiene la clave referenciada (o la modificación de dicha clave) sólo se permite si no existen tuplas con este valor en la relación que contiene la clave ajena. Esto nos llevaría, por ejemplo, a que para borrar un departamento de nuestra base de datos no debería haber ningún empleado que estuviese asociado a dicho departamento; en caso contrario el sistema impediría el borrado. Es la opción válida por defecto, es decir, si no se indica ninguna opción, el sistema tomará ésta. Operación con transmisión en cascada (CASCADE): el borrado de tuplas de la relación que contiene la clave candidata referenciada (o la modificación de dicha clave) lleva consigo el borrado (o modificación) en cascada de las tuplas de la relación que contiene la clave ajena. En nuestro ejemplo, equivaldría a decir que, al modificar el código de un departamento en la relación DEPARTAMENTO, dicho código se modificaría automáticamente en todos los empleados de la base de datos asociados a dicho departamento (análogamente ocurriría en el caso de borrado de la clave referenciada). Operación con puesta a nulos (SET NULL): el borrado de tuplas de la relación que contiene la clave candidata referenciada (o la modificación de dicha clave) lleva consigo poner a nulos los valores de las claves ajenas de la relación que referencia. Esto nos llevaría a que cuando se borra un departamento, a los empleados que pertenecieran a dicho departamento y que se encuentran en la relación EMPLEADOS se les pone automáticamente a nulos el atributo Departamento. Operación con puesta a valor por defecto (SET DEFAULT): el borrado de tuplas de la relación que contiene la clave candidata referenciada (o la modificación de dicha clave) lleva consigo poner el valor por defecto a la clave ajena de la relación que referencia; valor por defecto que habría sido definido al crear la tabla correspondiente. Por ejemplo, si se borra el departamento de ventas, a los empleados de dicho departamento se les asocia temporalmente a un departamento genérico. La opción seleccionada en caso de borrado es independiente de la de modificación, es decir, las opciones de borrado y de modificación pueden ser distintas. Resumiendo, el modelo relacional define los siguientes tipos de claves: 15

16 Clave candidata: conjunto de atributos que identifican unívoca y mínimamente cada tupla de una relación. Clave primaria: clave candidata que el usuario escogerá, por consideraciones ajenas al modelo relacional, para identificar las tuplas de la relación. Claves alternativas: claves candidatas que no han sido escogidas como clave primaria. Clave ajena: de una relación R2 es un conjunto no vacío de atributos cuyos valores han de coincidir con los valores de la clave candidata de una relación R1 (R1 y R2 no son necesariamente distintas). La clave primeria y la clave ajena llevan asociadas dos reglas que son restricciones inherentes al modelo relacional: Regla de integridad de entidad: "Ningún atributo que forme parte de la clave primaria de una relación puede tomar un valor nulo"; esto es, un valor desconocido o inexistente. Regla de integridad referencial: Si una relación R2 (relación que referencia) tiene un descriptor que es una clave candidata de la relación R1 (relación referenciada), todo valor de dicho descriptor debe, bien concordar con un valor de la clave candidata referenciada de R1, bien ser nulo El Modelo Relacional y la Arquitectura ANSI El modelo relacional puede examinarse, en el marco de la arquitectura ANSI, según los tres niveles que explicamos en el apartado 2.2. En el nivel conceptual de la arquitectura ANSI se encuentran, además de los dominios, las relaciones o tablas. En el nivel externo de la arquitectura ANSI están las vistas, tablas virtuales de las que sólo se almacena su definición, y no tienen, por tanto, representación directa en el almacenamiento. Por lo que respecta al esquema interno, el modelo relacional no especifica absolutamente nada, ya que se trata de un modelo lógico. En general, cada registro del esquema interno se corresponde con una tupla de las relaciones base, pero no tendría porqué haber una correspondencia biunívoca, ya que un registro podría estar constituido por varias tuplas de distintas relaciones o, viceversa, una tupla podría dividirse en varios registros. Además, cada producto ofrecerá los elementos internos, v.g. índices, agrupamientos, particiones, etc., que el implementador considere más oportunos con el fin de mejorar el rendimiento del sistema. 16

17 En la figura 3.7 se muestra un visión global del modelo relacional dentro del marco definido por la arquitectura ANSI, mostrando, además, ciertas sentencias del lenguaje SQL que ayudan a definir los elementos correspondientes en los tres niveles. Las sentencias que atañen al nivel interno variarán de un producto a otro, ya que no están estandarizadas.... SQL - Manipulación Independencia lógica VISTA 1 VISTA 2 VISTA m TABLA BASE TB 1 TABLA BASE TB 2 RELACIONAL TABLA BASE TB p N I V E L L O G I C O EXTERNO CREATE VIEW + sentencia de manipulación (SELECT) CONCEPTUAL (CREATE TABLE, CREATE DOMAIN, ) Independencia física DATOS ALMACENADOS (Registros de las tablas base, índices, agrupamientos, etc.) N I V E L F I S I C O INTERNO (CREATE INDEX, CREATE PARTITION, CREATE CLUSTER, ) Figura 3.7. Arquitectura a tres niveles en un SGBDR En la práctica, sin embargo, muchos productos no responden a la arquitectura a tres niveles, ya que las definiciones del esquema conceptual y del esquema interno no están claramente diferenciadas. 4. Diseño de Bases de Datos Relacionales La tarea de diseño de una BD puede dividirse en dos etapas: Diseño lógico: cuyo objetivo es obtener un esquema relacional independiente al producto concreto en el que se implementará la BD. Diseño físico: cuyo objetivo es conseguir una implementación, lo más eficiente posible, del esquema lógico. Nosotros nos ocuparemos aquí de la definición del esquema lógico, pero sin tener en cuenta el producto en el que se implementará (Oracle, Informix, DB2, SQL Server, etc.). 17

18 Para su representación utilizaremos el grafo relacional por tratarse de una notación estándar e independiente de productos, aunque también podría utilizarse el lenguaje SQL- 92, como lenguaje estándar de BD relacionales. Para la definición del esquema lógico existen, básicamente, dos enfoques: 1. El enfoque basado en el modelo E/R, que consiste en realizar previamente un esquema conceptual tal y como vimos en la unidad dedicada al modelado conceptual de datos, para posteriormente convertirlo, aplicando unas reglas de transformación, al correspondiente esquema relacional. Este enfoque da como resultado un conjunto de relaciones que deberán ser sometidas al proceso de normalización ver apartado 4.2). 2. Definir directamente el esquema relacional a partir de los atributos considerados aisladamente y de las dependencias, especialmente de las funcionales (ver apartado 4.2). La denominada relación universal, que contiene el conjunto de atributos y las dependencias, constituye en este caso el punto de partida de la siguiente etapa de diseño que consiste en la normalización de esta relación. El método, basado en la relación universal presenta la ventaja de un diseño menos subjetivo, que permite en gran parte aplicar procedimientos algorítmicos. Sin embargo, en él se suele perder más semántica, las relaciones resultantes pueden no corresponder a hechos del mundo real, surgen dificultades para expresar restricciones de integridad referencial y es más difícil que los usuarios participen en el diseño; otro problema que se presenta en este caso es el de recoger la presencia de más de una interrelación entre dos entidades determinadas. Además, los costes de aplicar la teoría de la normalización crecen exponencialmente con el número de atributos por relación; por tanto, si se parte de la relación universal se necesita disponer de herramientas de normalización potentes y sofisticados que consumen gran cantidad de tiempo y de recursos de máquina. En la figura 4.1 se resumen los dos enfoques expuestos anteriormente. Por un lado (parte izquierda de la figura), partiendo de los atributos y de las dependencias se llega a la relación universal, R <A, D>, donde A es el conjunto de atributos y D el de dependencias. 18

19 MUNDO REAL UD - Atributos - Dependencias - Entidades - Interrelaciones R<(A), (D)> ESQUEMA RELACIONAL - relación universal - {R} R 1 <(A i ), (D i )> ESQUEMA RELACIONAL - conjunto derelaciones- NORMALIZACION Figura 4.1. Dos enfoques en el desarrollo de una BD Por otro lado (derecha de la figura), podemos basarnos en el modelo E/R y llegar a un conjunto de entidades e interrelaciones (con sus correspondientes atributos) y restricciones semánticas; aplicando unas determinadas reglas de derivación (que se estudiarán más adelante) obtendremos un conjunto de relaciones (denominado {R i } en la figura) cada una de las cuales presenta un conjunto de atributos y dependencias funcionales. Finalmente, ambos enfoques culminan en el proceso de normalización; aunque, como ya hemos advertido, en el caso de la relación universal la normalización es mucho más costosa, mientras que cuando se parte del ME/R las relaciones están prácticamente normalizadas. Las herramientas CASE suelen soportar el modelado conceptual así como la transformación, más o menos completa, al modelo relacional, por lo que este enfoque es compatible con la aplicación de este tipo de herramientas. Nosotros, como ya hemos indicado, concedemos una gran importancia a la participación de los usuarios en el proceso de diseño y pensamos, por tanto, que el ME/R ofrece un mejor punto de partida, ya que se obtienen relaciones más estructuradas, facilita la normalización, y las relaciones finales representan mejor las entidades e interrelaciones del universo del discurso. Un posible inconveniente de este método es que exige cierta práctica en el diseño, pero, en nuestra opinión, sus ventajas superan con mucho este posible inconveniente. 19

20 Por tanto, pasamos a exponer, en el apartado 4.1, las reglas de transformación del modelo E/R al modelo relacional, para continuar, en el apartado 4.2, exponiendo la teoría de la normalización que deberá aplicarse a este esquema relacional a fin de refinarlo, tal y como se muestra en la parte derecha de la figura Transformación del Esquema Conceptual E/R al Esquema Relacional Las tres reglas básicas para convertir un esquema en el modelo E/R al relacional son las siguientes: 1) Toda entidad se convierte en una relación. 2) Toda interrelación N:M se transforma en una relación. 3) Para toda interrelación 1:N se realiza lo que se denomina propagación de clave (regla general), o se crea una nueva relación. Debido a que el modelo relacional no distingue entre entidades e interrelaciones, ambos conceptos deben representarse mediante relaciones. En la figura 4.2 se presenta una posible transformación al modelo relacional del ejemplo propuesto en la unidad desidaca al modelado conceptual (figura 3.16 de dicha unidad). Puede observarse que las tres entidades DEPARTAMENTO, EMPLEADO y PROYECTO se han transformado en otras tantas relaciones. La interrelación N:M Participa da lugar a una nueva relación cuya clave es la concatenación de las claves primarias de las entidades que participan en ella (DNI de EMPLEADO y Codigo_proyecto de PROYECTO), siendo además éstas claves ajenas de Participa, que referencian a las tablas EMPLEADO y PROYECTO, respectivamente; la interrelación 1:N Pertenece se ha transformado mediante el mecanismo de propagación de clave, por el que se ha incluido en la tabla EMPLEADO el atributo clave de la entidad DEPARTAMENTO (Codigo_dep), que constituye, por tanto, la clave ajena de la relación EMPLEADO referenciando a la tabla DEPARTAMENTO. 20

21 Codigo_dep DNI Codigo_proy Fecha_alta DEPARTAMENTO Pertenece EMPLEADO Participa PROYECTO 1:N N:M EMPLEADO (DNI, Nombre,..., Codigo_dep, Fecha_alta) Clave ajena DEPARTAMENTO (Codigo_dep, Nombre,...) Clave ajena PARTICIPA (Codigo_proy, DNI) Clave ajena PROYECTO (Codigo_proy,...) Figura 4.2. Ejemplo de paso del ME/R al modelo relacional Resumimos, a continuación, las reglas de transformación para cada uno de los elementos del modelo E/R estudiados: 1. Transformación de dominios. En el modelo relacional estándar un dominio es un objeto más, propio de la estructura del modelo que, como tal, tendrá su definición concreta en el LDD (en nuestro caso el SQL92) que se elija. Como ejemplo podemos crear el dominio de los estados civiles, como un conjunto de valores de tipo carácter, de longitud 1, que puede tomar los valores 'S', 'C', 'V' o 'D'. Los dominios no tienen representación en el grafo relacional; en SQL expresaríamos este dominio de la siguiente forma: CREATE DOMAIN Estados_Civiles AS CHAR(1) CHECK (VALUE IN ('S', 'C', 'V', 'D')) 2. Transformación de entidades. Según lo que hemos indicado en la introducción de este apartado, "cada entidad se convierte en una relación". La tabla se llamará igual que la entidad de donde proviene. Para su definición disponemos en el SQL de la sentencia CREATE TABLE. Por ejemplo, la entidad EMPLEADO se transforma en una tabla con ese mismo nombre (ver figura 4.3). En este caso la transformación es directa, y no hay perdida de semántica. 3. Transformación de atributos de entidades. Cada atributo de una entidad se transforma en una columna de la relación a la que ha dado lugar la entidad. Distinguimos entre atributos identificador principal (AIP en adelante) del resto de atributos: 21

22 3.1. Atributos Identificadores: el (o los) atributo (s) que son identificador(es) principales (AIP) pasan a ser la clave primaria de la relación. Por ejemplo, en la figura 4.3 tenemos la relación EMPLEADO, fruto de la transformación de la entidad del mismo nombre, con su AIP (DNI) que pasa a ser la clave primaria. El lenguaje lógico estándar (LLS) recoge recoge directamente este concepto por medio de la claúsula PRIMARY KEY en la descripción de la tabla, luego la ransformación es directa y no hay pérdida de semántica. ME/R DNI Nombre Fecha_nac EMPLEADO Teléfono Dirección MR EMPLEADO DNI Nombre Fecha_nac Dirección Teléfono Ana Belén Rios Rosas, Santiago Alarcos, Belén Getafe, 4 6º Goyo Pez, Roberto Fundación, CLAVE PRIMARIA EMPLEADO (DNI, Nombre, Fecha_nac, Dirección, Teléfono) Figura 4.3. Transformación de una entidad 4. Transformación de interrelaciones. Ya hemos señalado que, dependiendo del tipo de correspondencia de la interrelación, y de otros aspectos semánticos de la misma, variará la manera de realizar la transformación al esquema relacional, por eso desglosamos esta regla en tres subreglas: 4.1. Interrelaciones N:M. Una interrelación N:M se transforma en una relación que tendrá como clave primaria la concatenación de los AIP de las entidades que asocia. Por ejemplo, la figura 4.4 muestra esta transformación, en la que se presenta la asociación que existe entre los empleados y los proyectos en los que participan, apareciendo una relación cuya clave primaria está compuesta por la concatenación del DNI del empleado y el código del proyecto. Además, cada uno de los atributos que forman la clave primaria de esta relación son claves ajenas que referencian a las tablas en que se ha convertido las entidades interrelacionadas (claves primarias). 22

23 Además habrán de definirse el tipo de borrado y actualización para cada clave ajena (restringido, cascada, puesta a nulos y valor por defecto). Esquema E/R Esquema Relacional EMPLEADO DNI (0,n) Pertenece (1,1) 1:N PROFESOR (Cód_prof,,..., Cod_dep) DEPARTAMENTO (Cod_dep,...) DEPARTAMENTO Codigo_dep Figura 4.4. Transformación de una interrelación N:M 4.2. Interrelaciones 1:N. Existen dos soluciones para la transformación de una interrelación 1:N: a) Propagar los AIP de la entidad que tiene cardinalidad máxima 1 a la que tiene cardinalidad N, es decir en el sentido de la flecha, desapareciendo el nombre de la interrelación. Podemos ver un ejemplo en la figura 4.5. Si la interrelación tiene atributos propios, estos se propagan a la misma relación a la que se ha hecho la propagación de clave. Debe tenerse en cuenta que la propagación de clave causa la aparición de claves ajenas, con sus mecanismos de borrado y actualización correspondientes, según la semántica del problema. b) Transformarla en una relación, como si se tratara de una interrelación N:M; sin embargo en este caso, la clave primaria de la relación creada es sólo la clave primaria de la tabla a la que le corresponde la cardinalidad n. 23

24 Esquema E/R Esquema Relacional EMPLEADO DNI (1,n) EMPLEADO (DNI,...) Participa N:M PARTICIPA (DNI, Codigo_proy) (0,n) PROYECTO (Codigo_proy,...) PROYECTO Codigo_proy Figura 4.5. Transformación de una interretación 1:N en propagación de clave Aunque depende del criterio del diseñador, e influye además de la semántica la eficiencia, los casos en los que puede ser apropiado transformar la interrelación en una relación son los siguientes: a) Cuando el número de ejemplares interrelacionados de la entidad que propaga su clave es muy pequeño y, por tanto, existirían muchos valores nulos en la clave propagada. b) Cuando se prevé que dicha interrelación en un futuro se convertirá en una de tipo N:M. c) Cuando la interrelación tiene atributos propios y no deseamos propagarlos Interrelaciones 1:1. Una interrelación de tipo 1:1 es un caso particular de una N:M o, también, de una 1:N, por lo que no hay regla fija para la transformación de este tipo de interrelación al modelo relacional, pudiéndose aplicar la regla 4.1 (con lo que crearíamos una relación) o aplicar la regla 4.2. (esto es, propagar la clave correspondiente). En este último caso hay que observar que en una interrelación 1:1, la propagación de la clave puede efectuarse en ambos sentidos. Los criterios para aplicar una u otra regla y para propagar la clave se basan en que la relación tenga atributos propios, en las cardinalidades mínimas, en recoger la mayor cantidad de semántica posible, evitar los valores nulos o en motivos de eficiencia. A continuación exponemos algunos ejemplos, que puedan servir de pauta: 24

25 a) Si las entidades que se asocian poseen cardinalidades (0,1), puede ser conveniente transformar la interrelación 1:1 en una relación. b) Si una de las entidades que participa en la interrelación posee cardinalidades (0,1), mientras que en la otra son (1,1), conviene propagar la clave de la entidad con cardinalidades (1,1) a la tabla resultante de la entidad de cardinalidades (0,1). c) En el caso de que ambas entidades presenten cardinalidades (1,1), se puede propagar la clave de cualquiera de ellas a la tabla resultante de la otra, teniendo en cuenta en este caso los accesos más frecuentes y prioritarios a los datos de las tablas. Se puede plantear (también por motivos de eficiencia) la propagación de las dos claves, lo que introduce redundancias que deben ser controladas por medio de restricciones. d) Si la entidad posee atributos propios, puede ser conveniente transformar la interrelación 1:1 en una relación a fin de mantener la semántica. 5. Transformación de atributos de interrelaciones. Si la interrelación se transforma en una relación, todos sus atributos pasan a ser columnas de la relación. En caso de que la interrelación se transforme mediante propagación de clave, sus atributos migran junto a la clave a la relación que corresponda (ver figura 4.2), aunque ya hemos advertido que en este caso puede ser preferible crear una nueva relación para representar las interrelaciones que tienen atributos. 7. Transformación de entidades débiles. La interrelación que une una entidad débil con una entidad regular es siempre una interrelación de tipo 1:N. En este caso, las dos entidades se transforman en relaciones y la interrelación se transforma mediante migración de clave de la relación que representa a la entidad regular hacia la relación que representa a la entidad débil, creando una clave ajena en la entidad dependiente, con la característica de obligar a una modificación y un borrado en cascada. La figura 4.6 muestra un ejemplo de transformación cuando existe una entidad débil. En este caso, suponemos que la empresa tan sólo desea conocer la información relativa a los hijos de sus empleados. Por ello, cada ejemplar de la entidad HIJO depende de un ejemplar concreto de la entidad EMPLEADO, de tal modo que si se borra un empleado de la BD deberán borrarse también todos sus hijos. Además, en algunos casos, y dependiendo de la semántica de cada problema, la clave primaria de la relación en la que se ha transformado la entidad débil puede estar formada por la concatenación de las claves de las dos entidades participantes en la interrelación. 25

26 Esquema E/R Esquema Relacional EMPLEADO DNI EMPLEADO (DNI,...) (1,1) Tiene 1:N HIJO (DNI_hijo, DNI_padre...) HIJO (0,n) DNI_hijo Clave ajena Borrado en CASCADA Modificación en CASCADA Figura 4.6. Transformación de una entidad débil 9. Transformación de tipos y subtipos. En lo que respecta a los tipos y subtipos, no son objetos que se puedan representar explícitamente en el modelo relacional. Ante una entidad y sus subtipos caben varias soluciones de transformación al modelo relacional, con la consiguiente pérdida de semántica dependiendo de la estrategia elegida. Destacamos tres posibilidades: Opción a: englobar todos los atributos de la entidad y sus subtipos en una sola relación. En general, adoptaremos esta solución cuando los subtipos se diferencien en muy pocos atributos y las interrelaciones que los asocian con el resto de las entidades del esquema sean las mismas para todos (o casi todos) los subtipos. Por ejemplo, si consideramos que la diferencia existente entre un empleado que sea analista y otro que sea programador, es mínima debido a que ambos tienen los mismos atributos y ambos pueden participar en proyectos, la solución adecuada sería la creación de una sola tabla que contenga todos los atributos del supertipo y los de los subtipos, añadiendo el atributo discriminante que indica el tipo de empleado (ver figura 4.7). Hay que observar que el atributo discriminante de la jerarquía podrá admitir valores nulos en el caso de que la jerarquía sea parcial y no deberá permitirlos si la jerarquía es total. Por otra parte, el atributo discriminante constituirá un grupo repetitivo, si los subtipos se solapan, debiendo, por tanto, separar este atributo en una relación aparte que tendrá como clave la concatenación de la clave del supertipo con el atributo discriminante; otra solución bastante más eficiente consiste en crear un código para los valores del atributo discriminante que contemple los posibles subtipos solapados. 26

27 Opción b: crear una relación para el supertipo y tantas relaciones como subtipos haya, con sus atributos correspondientes. La clave primaria de todas las relaciones creadas es la misma y además, en las relaciones correspondientes a los subtipos la clave primaria será también clave ajena de la relación correspondiente al supertipo (ver figura 4.7). Además, las opciones de borrado y actualización deberán ser en cascada. Esta es la solución adecuada cuando existen muchos atributos distintos entre los subtipos y se quieren mantener de todas maneras los atributos comunes a todos ellos en una relación. Opción c: considerar relaciones distintas para cada subtipo, que contengan, además de los atributos propios, los atributos comunes. Se elegiría esta opción cuando se dieran las mismas condiciones que en el caso anterior muchos atributos distintos- y los accesos realizados sobre los datos de los distintos subtipos siempre afectaran a atributos comunes. EMPLEADO (1,1) Es_un Tipo Titulación (0,1) ANALISTA (0,1) PROGRAMADOR A) EMPLEADO (DNI, Nombre,, Tipo, Titulación) B) EMPLEADO (DNI, Nombre, ) ANALISTA (DNI,Titulación, ) C) ANALISTA (DNI, Nombre, Titulación, ) NO_DOCTOR (DNI, Nombre, ) PROGRAMADOR (DNI, ) Figura 4.7. Transformación de subtipos Podemos, por tanto, elegir entre tres estrategias distintas para la transformación de un tipo y sus subtipos al modelo relacional. Sin embargo, desde un punto de vista exclusivamente semántica la opción b es la mejor. Por otra parte, desde el punto de vista de la eficiencia tenemos que tener en cuenta que: 27

28 Opción a: el acceso a una fila que refleje toda la información de una determinada entidad es mucho más rápido (no hace falta combinar varias relaciones). Opción b: la menos eficiente, aunque, como ya hemos señalado, es la mejor desde un punto de vista exclusivamente semántica. Opción c: con esta solución aumentamos la eficiencia ante determinadas consultas (las que afecten a todos los atributos, tanto comunes como propios, de un subtipo) pero la podemos disminuir ante otras. Esta solución es en la que se pierde más semántica; además si existe solapamiento se introduce redundancia que debe ser controlada si queremos evitar inconsistencias. Elegiremos una estrategia u otra dependiendo de que sea la semántica o la eficiencia la que prime para el usuario en un momento determinado. Por último, cabe destacar que en próximas versiones del lenguaje SQL (la denominada SQL:1999) se están definiendo más elementos a fin de soportar directamente la herencia por medio de las denominadas subtablas Teoría de la Normalización 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. Pérdida de información (aparición de tuplas espúrias). 28

29 Pérdida de ciertas restricciones de integridad que dan lugar a interdependencias entre los datos (lo que, posteriormente, denominaremos dependencias funcionales). Aparición en la base de datos, como consecuencia de las redundancias, de estados que no son válidos 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 pérdida de información y la aparición de inconsistencias. Veamos un ejemplo de estos problemas derivados de un diseño inadecuado. En la figura 4.8 se muestra la relación PARTICIPA que almacena datos sobre los proyectos (Codigo_proyecto, Nombre y Horas) y sobre los empleados que realizan dichos proyectos (DNI, nombre y dirección). Si observamos esta relación, vemos que presenta varios de los problemas enumerados anteriormente. PARTICIPA B. Vela P1 Leonardo 2000 B. Vela P2 Alejandría 1500 B. Vela P3 Nikos 1600 A.B. Parrilla P1 Leonardo 2000 A.B. Parrilla P2 Alejandría 1500 A.B. Parrilla P3 Nikos 1600 S. Bermudez P1 Leonardo 2000 S. Bermudez P2 Alejandría 1500 A. Ortega P1 Leonardo 2000 Figura 4.8. Ejemplo de diseño inadecuado Los principales problemas de esta relación se derivan de la gran cantidad de redundancia que presenta. Por ejemplo, la dirección del empleado se repite por cada proyecto en el que participa; y algo análogo sucede con los proyectos. Esta redundancia produce a su vez: DNI NOMBRE DIRECCIÓN CODIGO_PROY NOMBRE HORAS Anomalías de inserción, ya que dar de alta un proyecto obliga a insertar en la base de datos tantas tuplas como participantes tenga el proyecto. Anomalías de modificación, ya que cambiar la dirección de un empleado obliga a modificar todas las tuplas que corresponden a dicho empleado, y viceversa, si cambiamos el nombre de un proyecto habría que cambiarlo en tantas tuplas como empleados participen en dicho proyecto. Anomalías de borrado, ya que el borrado de un proyecto obliga a borrar varias tuplas, tantas como participantes tenga ese proyecto y, viceversa, el borrado de un empleado nos lleva a borrar tantas tuplas como proyectos en los que participa. 29

30 Vemos, por tanto, que la actualización (alta, baja o modificación) de un solo empleado o de un solo proyecto 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 empleado que no participe en ningún proyecto, no sería posible ya que el atributo Codigo_proy forma parte de la clave primaria de la relación. Por otro lado, al dar de baja un empleado, se pierden también los datos de sus proyectos (si éstos no tuviesen más que un empleado participando en él) y, viceversa, si borramos un proyecto desaparecen de nuestra base de datos los datos de los empleados que participen en dicho proyecto (a no ser que participen en más de un proyecto). 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. Si se siguiera 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 que comentábamos anteriormente. Así, en lugar de la relación del ejemplo que aparecía en la figura 4.8, se podría haber diseñado el siguiente esquema relacional: EMPLEADO (DNI, Nombre, Dirección) PROYECTO (Codigo_proy, Nombre, Horas) PARTICIPA (Codigo_proy, DNI) 30

31 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. La teoría de la normalización, que puede definirse como una técnica formal para organizar datos, nos ayuda a determinar qué 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. La aplicación de la teoría de la normalización consigue una disminución en las anomalías mencionadas, 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. 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 normal si satisface un conjunto específico de restricciones. 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), y la cuarta y quinta forma normal (4FN y 5FN) debidas a Fagin. La 2FN impone más restricciones que la 1FN, la 3FN más que la 2FN, etc., siendo la 5FN la que impone restricciones más fuertes. A fin de evitar las anomalías que describíamos anteriormente es preferible la 5FN, después la 4FN, FNBC, la 3FN, la 2FN y, por último, la 1FN. Sin embargo en la práctica, y debido fundamentalmente a motivos de eficiencia, no es habitual encontrar relaciones en cuarta o quinta formal normal; aquí estudiaremos hasta la FNBC. 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 Dependencias Funcionales Ya hemos señalado que la teoría de la normalización se basa en el concepto de 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 sí afirmar por observación del mundo real que se 31

32 trata de modelar; por tanto, del análisis de una extensión válida de un esquema de relación nunca podremos deducir la existencia de una dependencia, pero sí 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 proceden. 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 él 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 sólo 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: EMPLEADO (Cod_emp, Salario, Categoría ) podemos decir que el código de un empleado determina, tanto el salario, como la categoría del mismo, lo que representamos del siguiente modo: Cod_emp Salario Cod_emp Categoría El código del empleado (Cod_emp) es el implicante (o determinante) en las anteriores dependencias y el Salario y la Categoría son los implicados. Estas dependencias también nos dicen que el salario, o la categoría, es información acerca del empleado, ya que una dependencia funcional se puede interpretar diciendo que el implicado es un hecho (en realidad una información) acerca del implicante. La afirmación de que Cod_emp determina Salario no significa que conocido el código de un empleado podamos deducir, a partir de él, cuál es su salario, a no ser que tengamos una extensión r(r) del esquema de relación que contiene la correspondiente dependencia funcional. Es decir, si para un esquema R, tenemos la dependencia funcional: X Y 32

33 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(r) que tengan el mismo valor de X, el valor de Y será también igual en 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 y parten 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 éste, no de cada atributo. En la figura 4.9. se presenta un ejemplo de cómo se visualizan las dependencias; podemos observar que Cod_emp determina funcionalmente el Salario y la Categoría del empleado tal como indica la correspondiente flecha; de forma análoga, Cod_proy determina el Nombre, y la Duración del proyecto; ambos atributos en conjunto Cod_emp y Cod_proy (lo que se indica haciendo que la flecha parta del recuadro que los incluye) determinan la Fecha_inicio y Fecha_fin de trabajo de un determinado empleado en un determinado proyecto. Cod_emp Salario, Categoría Fecha_inicio, Fecha_fin Cod_proy Nombre, Duración Figura 4.9. Ejemplo de diagrama de dependencias funcionales Existen otros conceptos, como el de dependencia plena o completa y el de dependencia transitiva, fundamentales en la teoría de la normalización, que veremos a continuació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 33

34 lo que se representa por: X Y Supongamos la relación: PARTICIPA (Cod_emp, Salario, Categoría, Cod_proy, Nombre, Duración, Fecha_inicio, Fecha_fin) cuyas dependencias funcionales aparecen en la figura 4.9, la dependencia funcional: Cod_emp, Cod_proy Fecha_inicio indica que, dado un determinado código de empleado y un código de proyecto, existe una única fecha de inicio. Sin embargo, ni el código de empleado, ni tampoco el código de proyecto, implican, por sí solos, la fecha de inicio, ya que un empleado puede comenzar a trabajar en proyectos distintos en distintas fechas y en un detereminado proyectos pueden incorporarse diferentes empleados en distintas fechas. Por tanto, la dependencia funcional anterior es completa, lo que se representa: ya que: Cod_emp, Cod_proy Fecha_inicio Cod_emp Fecha_inicio Cod_proy Fecha_inicio lo que, intuitivamente, se puede interpretar como que Fecha_inicio constituye una información sobre el conjunto de empleado y proyecto, pero esta información no atañe a un empleado o a un proyecto por separado. Lo mismo ocurre con el atributo Fecha_fin. Por el contrario, la dependencia: Cod_empleado, Cod_proy Nombre no es plena, ya que: Cod_proy Nombre se dice que, en esa dependencia, Cod_emp 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) 34

35 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 consideramos la relación EMPLEADO (Cod_emp, Nombre_emp, Salario, Categoría) en donde tenemos, para cada empleado, su código, su nombre, salario y categoría, se tendrán las siguientes dependencias: Cod_emp Nombre_emp Cod_emp Categoría Categoría Salario además, Categoría Cod_emp (ya que a una categoría pueden pertenecer varios empleados), la dependencia funcional entre Cod_emp y Salario es una dependencia transitiva a través de Categoría, representándola por: Cod_emp Salario (lo que se puede interpretar intuitivamente como que Salario es una información sobre el empleado, pero indirectamente, ya que constituye una información sobre la categoría y ésta, a su vez, sobre el empleado). La figura 4.10 muestra el diagrama de dependencias para el ejemplo propuesto, en el que la dependencia Cod_emp Salario es una dependencia transitiva. Cod-emp Categoría Salario Figura Ejemplo de dependencia funcional transitiva 35

36 Formas Normales Expuesto ya el concepto de dependencia funcional, podemos pasar a definir las formas normales. Como ya se ha indicado, nos limitaremos al estudio de las formas normales basadas en dependencias funcionales, que son las tres primeras formas normales así como la forma normal de Boyce y Codd (FNBC). Primera forma normal (1FN) La 1FN 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 sólo con que se encuentre en 1FN. En el ejemplo de la figura 4.11 se observa en la parte a) grupos repetitivos en aquellos empleados que participan en mas de un proyecto. Para convertir una tabla (no es una relación puesto que no está en 1FN) en una relación en 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) de la figura La clave primaria ya no podrá ser el código del empleado, pues éste se repetirá tantas veces como proyectos en los que participe el empleado en cuestión; la clave primaria se formará por la concatenación de la clave primaria de la tabla sin normalizar con el atributo (o atributos) que tiene el grupo repetitivo (en el ejemplo, Proyecto). 36

37 a) EMPLEADO (Cod_emp, Nombre, Cod_proy) COD_EMP NOMBRE COD_PROY Emp1 B. Vela P1 P2 Emp2 A. B. Parrilla P1 Emp3 S. Bermudez P1 P3 NO ESTA EN 1F Hay grupos repetitivos b) EMPLEADO (Cod_emp, Nombre, Cod_proy) COD_EMP NOMBRE COD_PROY Emp1 B. Vela P1 Emp1 B. Vela P2 Emp2 A. B. Parrilla P1 Emp3 S. Bermudez P1 Emp3 S. Bermudez P3 ESTA EN 1F Figura Tabla con grupos repetitivos y relación en 1FN Segunda forma normal (2FN) Se dice que una relación está en 2FN si cumple que: Está en 1FN. Cada atributo no principal tiene dependencia funcional completa respecto de cada una de las claves (es decir, no hay dependencias de atributos no principales respecto de una parte de la clave). Sea, por ejemplo, la relación: EMPLEADO (Cod_emp, Nombre_emp, Cod_dep, Nom_dep), en la que existe las siguientes dependencias funcionales: Cod_emp Nombre_emp Cod_dep Nombre_dep y cuya clave está constituida por el descriptor Cod_emp, Cod_dep. Esta relación no se encuentra en 2FN ya que el nombre del empleado está determinado sólo por el código de empleado y no por la clave completa; del mismo modo, el nombre del departamento depende del código de departamento y no de la clave completa. 37

38 Para convertir una relación a 2FN es necesario descomponerla tantas relaciones como sea necesario a fin de eliminar las dependencia funcionales no completas. En el ejemplo propuesto, la relación EMPLEADO se descompondrá en las siguientes relaciones: EMPLEADO1 (Cod_emp, Nombre_emp, Cod_dep) DEPARTAMENTO (Cod_dep, Nombre_dep) La dependencia funcional Cod_emp Nombre_emp en la relación EMPLEADO es ahora una dependencias funcionales completa, puesto que Cod_dep ya no forma parte de la clave primaria. Igualmente, la dependencia Cod_dep Nombre_dep en la relación DEPARTAMENTO es también ahora una dependencia funcional completa. Tercera forma normal (3FN) Se dice que una relación está en 3FN si se cumple que: Está 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: EMPLEADO (Cod_emp, Cod_dep, Nom_dep) que presenta las siguientes dependencias funcionales: Cod_emp Cod_dep Cod_dep Nom_dep Cod_emp Cod_dep y además se cumple que, Cod_dep Cod_emp y cuya clave es Cod_emp. Dicha relación no se encuentra en 3FN, ya que Nom_dep depende transitivamente de la clave a través de Cod_dep. Para convertir una relación a 3FN, se crea una relación nueva con los atributos que forman la dependencia funcional transitiva y se eliminan los atributos con dependencia transitiva de la relación original. 38

39 Así, por ejemplo, la relación EMPLEADO, la descompondremos en otras dos del siguiente modo: EMPLEADO1 (Cod_emp, Cod_dep) DEPARTAMENTO (Cod_dep, Nom_dep) Forma Normal de Boyce y Cod (FNBC) Las tres formas normales que acabamos de exponer fueron las propuestas originariamente Codd, pero, como ya hemos señalado, con el paso del tiempo se mostraron insuficientes para afrontar ciertos problemas en relaciones que presentaban varias claves candidatas compuestas que se solapaban. Por ello, en 1974, Boyce y Codd definieron la llamada forma normal que lleva su nombre (FNBC). Se trata de una redefinición más estricta de la 3FN. Se dice que una relación se encuentra en FNBC si, y sólo si, todo determinante es una clave candidata. Sea la siguiente relación: EMPLEADO (Cod-emp, Nomb_emp, Cod-proy, Función) que presenta las siguientes dependencias funcionales: cod-emp cod_proy nomb_emp cod_proy cod-emp función función nomb_emp y cuyas claves candidatas son: (Cod_emp, Cod_proy) (Nom_emp, Cod_proy) Cod_emp y Nom_empleado son determinante y no son clave candidata por lo que la relación PROYECTO no está en FNBC. Para convertir esta relación en otra que esté en FNBC la descomponemos en dos relaciones del siguiente modo: EMPLEADO1 (Cod-emp, Nomb_emp) EMPLEADO (Cod-emp, Cod-proy, Función) 39

40 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 álgebra relacional. Sea, por ejemplo, la relación: PARTICIPA (Cod_emp, Cod_proy, Nom_proy) que, como hemos visto, se encuentra sólo en 1FN (ya que su único atributo no principal, Nom_proy, 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_emp, Cod_proy y sobre Cod_proy, Nom_proy, tendríamos: PARTICIPA1 (Cod_emp, Cod_proy) DEPARTAMENTO (Cod_proy, Nom_proy) Ambas relaciones están en 3FN y han desaparecido las redundancias y las inconsistencias. Además, la combinación natural de PRESTA1*DEPARTAMENTO (por el atributo común Cod_proy) nos devuelve la relación original. En el proceso de normalización las relaciones se descomponen en proyecciones independientes de modo que siempre se deben cumplir dos principios: a) Que no haya pérdida de información b) Que no haya pérdida de dependencias Se puede demostrar que es posible descomponer cualquier relación hasta 3FN sin pérdida de información y sin pérdida de dependencias funcionales. 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) de la figura

41 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 figura La combinación de estas dos relaciones (ver parte c) de la figura 4.12) da lugar a la aparición de tuplas espúrias, es decir, tuplas que no se encontraban en la extensión original. Se dice que la descomposición de LIBRO ha dado lugar a pérdida de información. a) LIBRO COD_LIBRO EDITORIAL PAIS Rama España Rama España Paraninfo España Anaya España Addison-w. EE.UU. b) LIBRO1 COD_LIBRO PAIS España España España España EE.UU. EDITORIAL1 EDITORIAL Rama Rama Paraninfo Anaya Addison-W.. PAIS España España España España EE.UU. c) LIBRO1 * EDITORIAL1 COD_LIBRO EDITORIAL PAIS Rama España Paraninfo España Anaya España Rama España Paraninfo España Anaya España Rama España Paraninfo España Anaya España Rama España Paraninfo España Anaya España Addison-w.. EE.UU. TUPLAS ESPÚRIAS Figura Descomposición con pérdida de información (aparición de tuplas espúrias) 41

42 Si en lugar de esta descomposición, hubiéramos realizado esta otra: LIBRO2 (Cod_libro, País) EDITORIAL2 (Cod_libro, Editorial) es fácil comprobar que la combinación natural LIBRO2 * EDITORIAL2 Cod_libro daría como resultado la relación original (sin tuplas espúrias). 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 sí 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 ni pérdida de información ni de dependencias funcionales. 42

43 Si la relación LIBRO de nuestro ejemplo, si la hubiésemos descompuesto en: LIBRO3 (Cod_libro, Editorial) EDITORIAL3 (Editorial, País) estas dos proyecciones serían 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 sólo se ha llegado a 3FN no se puede asegurar que, en todos los casos, se eliminen por completo las anomalías). Como ya hemos dicho, 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. Este método de descomposición, que es el que acabamos de analizar, recibe el nombre de análisis. Existe otro método para normalizar una relación que es el denominado método de síntesis Algunas Consideraciones sobre la Teoría de la Normalización 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 relacional. 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 pueden obligar 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. 43

44 Por otra parte, si seguimos la metodología de diseño expuesta en la primera parte de esta unidad, obteniendo primero un esquema en el modelo E/R y transformándolo después al modelo relacional, el esquema relacional resultante, siempre que todo el proceso se haya realizado correctamente, estará al menos 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. 5. Ejercicios de Autocomprobación 5.1. Enunciados 1. En qué etapa del proceso de desarrollo se encuentra el diseño de datos? 2. Explique brevemente cuáles son los objetivos del diseño de datos. 3. Cuál es el modelo lógico de datos más utilizado en el diseño estructurado? 4. Defina con sus palabras: BD, SGBD y SBD. 5. Defina el concepto de clave primaria. 6. Defina el concepto de clave ajena. 7. Explique en qué consiste el principio de integridad de entidad. 8. Explique en qué consiste el principio de integridad referencial. 9. Explique brevemente en qué consiste el proceso de normalización? 10. Qué principios deben verificarse en todo proceso de normalización? 44

45 Supuestos Para cada uno de los siguientes esquemas conceptuales, tomados de los supuestos de la unidad dedicada al modelado conceptual de datos, se pide: a) Definir el correspondiente esquema relacional utilizando para ello la metodología propuesta en esta unidad. b) Comprobar en que forma normal se encuentra el esquema relacional obtenido y llevar, en caso de que no lo esté ya, hasta la FNBC. S1. DEPARTAMENTO (1,1) Codigo_dep 1:N Pertenece (0,n) EMPLEADO (1,1) DNI Fecha_alta Es_un (0,1) (0,1) ANALISTA PROGRAMADOR (1,1) (1,n) 1:1 Dirige Participa N:M (1,1) PROYECTO (0,n) Codigo_proy 45

46 S2. Cod_c (0,n) N:M CURSO Prerrequisito Opcional (1,1) (0,n) Impartido 1:N Cod_e (0,n) EDICIÓN (0,n) N:M Participa (1,n) EMPLEADO Fecha Tipo_p S3. Título Nacional Product Fecha Tipo_part Nombre Nacional DIRECTOR (1,1) (1,n) (0,n) (1,n) Dirige PELÍCULA Participa ACTOR (1,1) Nombre Nacional I Sexo Tiene (1,n) Num_Ej EJEMPLAR (0,n) Alquilado Conserv Fecha_c Fecha_f DNI (0,n) Nombre Direc SOCIO (1,1) (0,n) Avalado_por Tlf 46

47 6. Bibliografía 6.1. Bibliografía Básica Piattini, M., Marcos, E., Calero, C., Vela. B. Tecnología y Diseño de Bases de Datos. Ed. Ra-ma, Madrid Es el libro en el que nos hemos basado para la elaboración de esta documentación, por lo que es un excelente complemento de la misma. Presenta, de un modo claro y preciso, el modelo relacional así como las dos aproximaciones al diseño de bases de datos relacionales, tanto el diseño basada en la teoría de las normalización, como el diseño a partir del modelo E/R. Propone una metodología de diseño para BD relacionales basada en esta última aproximación. Contiene además una colección de ejercicios de diseño, algunos de ellos con soluciones, por lo que es también recomendable para aquellos alumnos que deseen practicar más Bibliografía Recomendada Date, C.J. Introducción a los sistemas de bases de datos. Séptima edición. Addison-Wesley, El Date es el libro de referencia obligada en para bases de datos relacionales y muy apropiado para quienes quieran profundizar en los siguientes temas: modelo relacional, teoría de la normalización y diseño de bases de datos relacionales basado en la teoría de la normalización. Melton, J. y Simon, A. SQL: Understanding Relational Language Components. Morgan Kaufmann, El SQL es el lenguaje estándar para bases de datos relacionales. En esta unidad se ha estudiado el modelo relacional pero sin entrar en el lenguaje de definición y manipulación, por lo que este libro, escrito por el editor del SQL, Jim Melton, puede ser un buen complemento. Además, el conocimiento del SQL es un apoyo para una mejor comprensión del modelo relacional. 47