Diseño Estructurado de Datos · Diseño Estructurado de Datos 9 Aunque una relación se puede...

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA

Diseño Estructurado

de Datos

Esperanza Marcos

Diseño Estructurado de Datos

2

Contenido

GUÍA DE ESTUDIO......................................................................................................................................... 3

1. EL DISEÑO DE DATOS EN EL PROCESO DE DESARROLLO SOFTWARE................................................. 4

2. CONCEPTOS Y TÉRMINOS BÁSICOS DE BASES DE DATOS .................................................................. 5

2.1. CONCEPTO DE BASE DE DATOS ................................................................................................................. 52.2. ARQUITECTURA ANSI/X3/SPARC A TRES NIVELES ...................................................................................... 6

3. EL MODELO DE DATOS RELACIONAL................................................................................................... 7

3.1. INTRODUCCIÓN AL MODELO RELACIONAL ................................................................................................... 73.2. ESTÁTICA DEL MODELO RELACIONAL.......................................................................................................... 8

3.2.1. Dominio y Atributo .................................................................................................................... 93.2.2. Definición Formal de Relación ................................................................................................. 113.2.3. Claves ...................................................................................................................................... 12

3.3. EL MODELO RELACIONAL Y LA ARQUITECTURA ANSI .................................................................................. 16

4. DISEÑO DE BASES DE DATOS RELACIONALES ................................................................................... 17

4.1. TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL E/R AL ESQUEMA RELACIONAL .............................................. 204.2. TEORÍA DE LA NORMALIZACIÓN............................................................................................................... 28

4.2.1. Dependencias Funcionales ...................................................................................................... 314.2.2. Formas Normales .................................................................................................................... 364.2.3. Descomposición de Relaciones ................................................................................................ 404.2.4. Algunas Consideraciones sobre la Teoría de la Normalización ............................................... 43

5. EJERCICIOS DE AUTOCOMPROBACIÓN ............................................................................................. 44

5.1. ENUNCIADOS....................................................................................................................................... 44

6. BIBLIOGRAFÍA .................................................................................................................................... 47

6.1. BIBLIOGRAFÍA BÁSICA ........................................................................................................................... 476.2. BIBLIOGRAFÍA RECOMENDADA ................................................................................................................ 47


3

Guía de Estudio

En la unidad dedicada al Modelado Conceptual de Datos, nos ocupamos de estudiar elmodo de recoger los requisitos de usuario en cuanto a sus necesidades de datos. Estasnecesidades del usuario captadas en la etapa de análisis hay que llevarlas al mundoinformático implementándolas en un sistema concreto. Aunque existen diversos modosde 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 elalumno, al finalizar el estudio de la misma, sea capaz de diseñar, a partir de un esquemaconceptual de datos previamente concebido, el esquema relacional correspondiente.

Para ello, en primer lugar, situaremos las actividad del diseño de datos en el lugar queles corresponde dentro del proceso de desarrollo software, estableciendo las relacionesexistentes entre ésta y otras actividades. Posteriormente, revisaremos el concepto deBase de Datos (en adelante BD), así como las características más relevantes de éstas, a finde poder comprender mejor el proceso de diseño. A continuación pasaremos a exponer elmodelo relacional, que además de ser el más extendido en la actualidad, es el modelológico de datos ligado al desarrollo estructurado de software. Continuaremos estudiandouna metodología de diseño para BD relacionales.

La unidad incluye una serie de ejercicios de autocomprobación con las solucionespropuestas. 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, engeneral, el alumno debería conocer; y bibliografía recomendada, constituida por librosque también hemos consultado y que se recomienda a aquellos alumnos que deseenprofundizar o completar algún aspecto concreto de ésta unidad. Finalmente se incluye uncontrol que permitirá evaluar los conocimientos adquiridos por el alumno al final de launidad.

Para cualquier consulta o sugerencia, el alumno dispone de una dirección de correoelectrónico ([email protected]) a la que podrá enviar sus comentarios.


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 obtenerun esquema conceptual que representaba los requisitos de usuario de un modototalmente independiente de la implementación del mismo. Estábamos en la etapa deanálisis y nuestro objetivo era determinar el Qué pero sin ocuparnos aún del Cómo. Esahora, en la etapa de diseño, cuando debemos ocuparnos de cómo implementar elesquema conceptual obtenido en la etapa de análisis.

El primer paso en este proceso es determinar el modelo de persistencia que se va autilizar, es decir, el modo en que se almacenarán los datos. Como primera opcióndebemos decidir si almacenaremos los datos en sistemas de ficheros o en sistemas debases 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, seutilizarán BD para la persistencia de los mismos.

Dependiendo del modelo que soporte el Sistema de Gestión de la Bases de Datos (enadelante SGBD), existen diferentes tipos de BD: jerárquicas, Codasyl, relacionales, objeto-relacionales y orientadas a objetos. Sin embargo, en la actualidad, el modelo más utilizadosin duda alguna para aplicaciones de gestión es el modelo relacional. Por ello, utilizaremosel 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. Enla 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 comprendetanto el diseño de datos como el de funciones. La técnica más habitual para el diseño dedatos es el modelo relacional y para el diseño de procesos son los Diagramas deEstructuras de Cuadros (en adelante DEC). Como se puede apreciar, la etapa de análisistambién se compone del análisis de datos y del análisis de procesos, tal y como vimos enla unidad dedicada al modelado conceptual de datos.

Figura 1.1. Comparación entre el diseño de datos y de procesos

DATOS

ANALISISREQUISITOS DE INFORMACIÓN

FUNCIONES

DISEÑO REQUISITOS DE LOS PROCESOS

Modelado Conceptual de Datos: E/RModelado Conceptual de Procesos: DFD

Diseño de Datos: RelacionalDiseño de Procesos: DEC


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 unsoporte informático no volátil. Los datos están interrelacionados y estructurados deacuerdo con un modelo capaz de recoger el máximo contenido semántico. Dada larelevancia que tienen en el mundo real las interrelaciones entre los datos, esimprescindible que la base de datos sea capaz de almacenar estas interrelaciones. En elmundo 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. Labase 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 duplicidadesperjudiciales ni innecesarias, y que las redundancias físicas, convenientes muchas veces afin de responder a objetivos de eficiencia, sean tratadas por el mismo sistema, de modoque no puedan producirse inconsistencias. Esto podría resumirse diciendo que en lasbases de datos no debe existir redundancia lógica, aunque sí se admite cierta redundanciafísica por motivos de eficiencia.

Las bases de datos pretenden servir al conjunto de la organización, manejando losdatos como otro recurso que viene a añadirse a los ya tradicionales. Por tanto, las basesde datos han de atender a múltiples usuarios y a diferentes aplicaciones, en contraposicióna los sistemas de ficheros, en los que cada fichero está diseñado para responder a lasnecesidades de una determinada aplicación.

Otro aspecto importante de las bases de datos es la independencia, tanto física comológica, entre datos y tratamientos. Esta independencia, objetivo fundamental de las basesde datos, es una característica esencial que distingue las bases de datos de los ficheros yque ha tenido una enorme influencia en la arquitectura de los SGBD, como se verá másadelante.

La definición o descripción del conjunto de datos contenidos en la base (a lo que sedenomina estructura o esquema de la base de datos) deben ser únicas y estar integradascon los mismos datos. En los sistemas basados en ficheros, los datos se encuentranalmacenados en ficheros, mientras su descripción (muy somera) está separada de losmismos, formando parte de los programas, para lo cual se precisa que los lenguajesfaciliten medios para la descripción de los datos. En las bases de datos, la descripción, y enalgunos casos también una definición y documentación completas (metadatos), sealmacena junto con los datos, de modo que éstos están autodocumentados, y cualquiercambio que se produzca en dicha documentación se ha de reflejar y quedar recogido en elsistema, con todas las ventajas que de este hecho se derivan.


6

La actualización y recuperación de los datos debe realizarse mediante procesos biendeterminados, incluidos en el SGBD, el cual ha de proporcionar también instrumentos quefaciliten 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:

Podemos definir Sistema de Gestión de Bases de Datos (SGBD) como:

El SGBD, junto con la base de datos y con los usuarios, constituyen el Sistema de Basede Datos (SBD).

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 delusuario) y la física (forma en que se encuentran los datos almacenados). En las bases dedatos aparece un nuevo nivel de abstracción que se ha denominado de diversas maneras:nivel conceptual, lógico global, etc. Esta estructura intermedia pretende unarepresentación global de los datos que se interponga entre las estructuras lógica y físicade la arquitectura a dos niveles, siendo independiente, tanto del equipo como de cadausuario en particular (ver figura 2.1).

“Una colección o depósito de datos integrados, almacenados ensoporte secundario (no volátil) y con redundancia controlada. Losdatos, que han de ser compartidos por diferentes usuarios yaplicaciones, deben mantenerse independientes de ellos, y sudefinición (estructura de la base de datos) única y almacenada juntocon los datos, se ha de apoyar en un modelo de datos, el cual hade permitir captar las interrelaciones y restricciones existentes enel mundo real. Los procedimientos de actualización yrecuperación, comunes y bien determinados, facilitarán laseguridad del conjunto de los datos”, De Miguel y Piattini (1999).

“Conjunto de programas que permiten la implantación, acceso ymantenimiento de la base de datos”.

SBD = SGBD + DATOS + USUARIOS


7

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 dedatos cada usuario en particular; la estructura lógica global (también denominadaesquema conceptual) responde al enfoque del conjunto de la empresa y la estructurafísica (o esquema interno) es la forma cómo se organizan los datos en el almacenamientofísico. La estructuración de una base de datos en estos tres niveles de abstracción fuepropuesta por el grupo ANSI/X3/SPARC y tiene como principal objetivo conseguir laindependencia 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 lasrelaciones, en donde los datos se estructuran lógicamente en forma de relaciones -tablas-,siendo un objetivo fundamental del modelo mantener la independencia de esta estructuraló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 alos modelos de datos anteriores son:

Sencillez y uniformidad: los usuarios ven la base de datos relacional como unacolección de tablas, y al ser la tabla la estructura fundamental del modelo, éstegoza de una gran uniformidad, lo que unido a unos lenguajes no navegacionales ymuy orientados al usuario final, da como resultado la sencillez de los sistemasrelacionales.

USUARIO

ESTRUCTURA LOGICA

ESTRUCTURA FISICA

A B C D E F G

C D

E FG

A

B

ESTRUCTURALOGICAGLOBAL


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áticosbasados en abstracciones.

Independencia de la interfaz de usuario: los lenguajes relacionales, al manipularconjuntos de registros, proporcionan una gran independencia respecto a la formaen 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 productoscomerciales y a su falta de semántica. Probablemente, la teoría relacional nació cuando latecnología existente no podía todavía ofrecer el adecuado soporte para implementacionesque respondiesen eficientemente a las necesidades de los usuarios.

A pesar de ello, el modelo de datos relacional ha tenido un auge espectacular desdefinales de los años 70, y sobre todo en los 80, una vez que empezaron a vencerse lasdificultades que presentaba su implementación y gracias al desarrollo tecnológico que hapermitido una mayor eficiencia de los productos relacionales.

3.2. Estática del Modelo Relacional

Como hemos señalado anteriormente, la relación es el elemento básico del modelorelacional, y se puede representar como una tabla. En la figura 3.1 se representa la relaciónEMPLEADO en donde aparece la estructura del modelo relacional. En ella, podemos observarel nombre de la relación (EMPLEADO); los atributos (Nombre, DNI, y Estado_civil); losdominios (de donde los atributos toman sus valores); las tuplas (o filas); el grado (número deatributos); y la cardinalidad (número de tuplas).

Figura 3.1. Representación mediante una tabla de la relación EMPLEADO

Nombre DNI Estado_civil

Vela, B.

Parrilla, A. B.

Bermudez, S.

Jimenez, B.

9764320

7654394

9876544

8762098……….

Soltera

Soltera

Soltero

Casada

Grado 3

Atributos

TUPLAS

Cardinalidad4

EMPLEADO


9

Aunque una relación se puede representar en forma de tabla, tiene una serie deelementos 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 haberun valor (no se admiten atributos multivaluados).

3.2.1. Dominio y Atributo

Definimos dominio (D) como:

Decimos valores homogéneos porque son todos del mismo tipo, y atómicos porque sonindivisibles en lo que al modelo se refiere, es decir, si se descompusiesen, perderían lasemá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 sondivisibles 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 aisladamentehan 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 dedatos; así el tipo de datos del dominio de Estados_civiles es una tira de caracteres delongitud diez. También se le puede asociar ciertas restricciones.

Los dominios pueden definirse por intensión o por extensión. Por ejemplo, el dominio delas Notas de los alumnos se puede definir por intensión como un entero de longitud doscomprendido entre 0 y 10, mientras que la definición del dominio de Estadso_civiles porintensión sería muy pobre semánticamente, ya que permitiría toda combinación de 10 letrasaun cuando no constituyesen un nombre válido de estado civil; por ello, es preferible definireste 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:

Un conjunto finito de valores homogéneos y atómicos V1,V2, ..., Vn, caracterizado por un nombre.

El papel que juega un determinado dominio D en unarelación; se dice que D es el dominio de A y se denotacomo dom(A)


10

Así, el atributo Estado_civil de la tabla EMPLEADO, definido sobre el dominio deEstados_civiles nos indica que dicho atributo tiene el papel de estado civil del empleado endicha tabla, tal y como se muestra en la figura 3.2.

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, A1 A2, ....., An, estructurados enrelaciones; cada atributo toma sus valores de un único dominio (dominio subyacente) yvarios atributos pueden tener el mismo dominio subyacente.

Es muy usual dar el mismo nombre al atributo y al dominio subyacente. En el caso de quesean varios los atributos de una misma tabla definidos sobre el mismo dominio, habrá quedarles nombres distintos, ya que una tabla no puede tener dos atributos con el mismonombre.

Además de los dominios y atributos simples, que acabamos de definir, en la década de los90, los trabajos posteriores de algunos autores como Codd y Date, introducen el concepto dedominio compuesto. Un dominio compuesto se puede definir como una combinación dedominios 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, undominio compuesto por ellos denominado Fecha, al que podríamos aplicar las adecuadasrestricciones de integridad a fin de que no aparecieran valores no válidos para la fecha; algoanálogo ocurre con el nombre y los apellidos, que, según las aplicaciones, puede serconveniente tratarlos en conjunto o por separado.

xxxxxxxx

25

9764320765439498765448762098……….

Soltero SolteraCasadoc CasadaViudo ViudaDivorciado Divorciada

NOMBRE DNI ESTADO_CIVIL

DOMINIOS


Vela, B.

Parrilla, A. B.

Bermudez, S.

Jimenez, B.

9764320

7654394

9876544

8762098……….

Soltera

Soltera

Soltero

Casada

Grado 3

Atributos

TUPLAS

Cardinalidad4

EMPLEADO


11

Al igual que es posible definir dominios compuestos, existen también atributoscompuestos; así el atributo Fecha tomaría sus valores del dominio compuesto de igualnombre.

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.

3.2.2. Definición Formal de Relación

Matemáticamente, una relación, definida sobre los n dominios D1, D2, ...., Dn, nonecesariamente 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 trabajosde Codd, no se alude a los atributos, es decir, al papel que juegan los dominios en la relacióny, además, en ella el orden de los valores dentro de una tupla es significativo. A fin de evitarestos inconvenientes se puede dar otra definición de relación más adecuada desde el puntode vista de las bases de datos (ya que la relación matemática y la relación en BD no esexactamente lo mismo), para lo cual es preciso distinguir en la noción de relación lossiguientes elementos:

Nombre: las relaciones se identifican por un nombre; si bien ciertas relaciones queno necesitan identificarse (por ejemplo, resultados intermedios) pueden no tenernombre.

Cabecera de relación: conjunto de n pares atributo-dominio subyacente{(Ai:Di)}i=1

n donde n es el grado; se corresponde con la primera fila cuando larelación se percibe como una tabla. El conjunto A de atributos sobre los que sedefine la relación se llama contexto de la misma.

Cuerpo de la relación: conjunto de m tuplas {t1, t2, ..., tm}, donde cada tupla es unconjunto de n pares atributo-valor {(Ai:Vij)}, siendo Vij el valor j del dominio Di

asociado al atributo Ai; el número de tuplas m es la cardinalidad. Así como lacabecera de relación es invariante, su cuerpo varía en el transcurso del tiempo, aligual que la cardinalidad.

Esquema de relación: constituido por el nombre R -si existe- y la cabecera,denotandose: R ({Ai:Di}

ni=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 quehemos llamado entidad en el modelo E/R (ver la unidad dedicada al modeladoconceptual de datos).

El estado de relación r(R), al que denominaremos simplemente relación otambié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 instantedado, satisface el correspondiente esquema de relación. Corresponde a lo quehemos denominado extensión de entidad en el modelo E/R.


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).

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 unacolección de relaciones que varían en el tiempo.

3.2.3. Claves

Una clave candidata de una relación es un conjunto de atributos que identifican unívoca ymínimamente cada tupla de la relación. Por la propia definición de relación, siempre hay, almenos, una clave candidata, ya que al ser una relación un conjunto no existen dos tuplasiguales y, por tanto, el conjunto de todos los atributos siempre tiene que identificarunívocamente a cada tupla; si no se cumpliera la condición de minimalidad se eliminaríanaquellos atributos que lo impidiesen. Por ejemplo, la relación EMPLEADO de la figura 3.3tiene dos claves candidatas: el atributo Nombre, ya que suponemos que no existen dosautores con el mismo nombre y el atributo DNI. Una relación puede tener más de una clavecandidata, entre las cuales se debe distinguir entre la clave primaria y la(s) clave(s)alternativa(s).

EMPLEADO (Nombre: Nombres, DNI: DNIs, Estado_civil: Estados_civiles)

ESQUEMA DE RELACION (INTENSION):ESQUEMA DE RELACION (INTENSION):

RELACION (EXTENSION o ESTADO):RELACION (EXTENSION o ESTADO):

EMPLEADO


Vela, B.

Parrilla, A. B.

Bermudez, S.

Jimenez, B.

9764320

7654394

9876544

8762098……….

Soltera

Soltera

Soltero

Casada


13

Clave primaria: es aquella clave candidata que el usuario escogerá, por consideracionesajenas al modelo relacional, para identificar las tuplas de la relación. Cuando sólo existe unaclave candidata, ésta será la clave primaria. En el ejemplo de la relación EMPLEADO, elatributo DNI será la clave primaria, aunque también podría serlo el atributo Nombre. Elmodelo relacional obliga a la existencia de una clave primaria en cada relación. La claveprimaria de una relación suele representarse subrayando el atributo u atributos que lacomponen.

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 valornulo"; esto es, un valor desconocido o inexistente.

La necesidad de los valores nulos o marcas en las bases de datos es evidente por diversasrazones:

Crear tuplas (filas) con ciertos atributos desconocidos en ese momento, porejemplo, la fecha de nacimiento de un empleado.

Añadir un nuevo atributo a una relación existente; atributo que, en el momentode 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 depersonal para un empleado de la administración que no sea funcionario.

Claves alternativas: son aquellas claves candidatas que no han sido escogidas como claveprimaria. En el ejemplo de la relación EMPLEADO la clave alternativa sería el atributo Nombrea 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 cuyosvalores han de coincidir con los valores de la clave candidata de una relación R1 (R1 y R2 noson necesariamente distintas). Cabe destacar que la clave ajena y la correspondiente clavecandidata han de estar definidas sobre el mismo dominio.

La clave ajena lleva siempre asociada la regla de integridad referencial, que dice “Si unarelación R2 (relación que referencia) tiene un descriptor que es una clave candidata de larelación R1 (relación referenciada), todo valor de dicho descriptor debe, bien concordar conun 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. Laclave ajena sirve para asociar relaciones.

En la figura 3.5 se muestra cómo los valores del atributo Departamento de la relaciónEMPLEADO concuerdan con los de la clave primaria Cod_dep de la relación DEPARTAMENTO.


14

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 deintegridad referencial (los empleados deben pertenecer a un departamento existente o, sise desconoce el departamento, tendrán valor nulo para ese atributo). Tanto la relaciónEMPLEADO como la relación DEPARTAMENTO verifican también la regla de integridad deentidad ya que sus respectivas claves primarias, DNI y Cod_dep, no contienen ningún valornulo. En la figura 3.6 se muestra una forma de representar las claves ajenas, mediante lo quese denomina el grafo relacional.

Figura 3.6. Ejemplo de representación de clave ajena mediante un grafo relacional


Vela, B.

Parrilla, A. B.

Bermudez, S.

Jimenez, B.

9764320

7654394

9876544

8762098……….

Soltera

Soltera

Soltero

Casada

EMPLEADO

Departamento

Dep1

Dep1

Dep2

NULL

Cod_dep Nom_dep ...

Dep1

Dep2

Dep3

Dep4

Formación

Ventas

I+D

Personal

DEPARTAMENTO

EMPLEADO (DNI, Nombre, Estado_civil, Departamento)

DEPARTAMENTO (Cod_dep, Nom_dep…)


15

Además de definir las claves ajenas, hay que determinar las consecuencias que puedentener ciertas operaciones (borrado y modificación) realizadas sobre tuplas de la relaciónreferenciada; 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 quecontiene la clave referenciada (o la modificación de dicha clave) sólo se permite sino existen tuplas con este valor en la relación que contiene la clave ajena . Estonos llevaría, por ejemplo, a que para borrar un departamento de nuestra base dedatos no debería haber ningún empleado que estuviese asociado a dichodepartamento; en caso contrario el sistema impediría el borrado. Es la opciónvá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 larelación que contiene la clave candidata referenciada (o la modificación de dichaclave) lleva consigo el borrado (o modificación) en cascada de las tuplas de larelació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, dichocódigo se modificaría automáticamente en todos los empleados de la base dedatos asociados a dicho departamento (análogamente ocurriría en el caso deborrado de la clave referenciada).

Operación con puesta a nulos (SET NULL): el borrado de tuplas de la relación quecontiene la clave candidata referenciada (o la modificación de dicha clave) llevaconsigo poner a nulos los valores de las claves ajenas de la relación quereferencia. Esto nos llevaría a que cuando se borra un departamento, a losempleados que pertenecieran a dicho departamento y que se encuentran en larelación EMPLEADOS se les pone automáticamente a nulos el atributoDepartamento.

Operación con puesta a valor por defecto (SET DEFAULT): el borrado de tuplas dela relación que contiene la clave candidata referenciada (o la modificación dedicha clave) lleva consigo poner el valor por defecto a la clave ajena de la relaciónque referencia; valor por defecto que habría sido definido al crear la tablacorrespondiente. Por ejemplo, si se borra el departamento de ventas, a losempleados de dicho departamento se les asocia temporalmente a undepartamento genérico.

La opción seleccionada en caso de borrado es independiente de la de modificación, esdecir, las opciones de borrado y de modificación pueden ser distintas.

Resumiendo, el modelo relacional define los siguientes tipos de claves:


16

La clave primeria y la clave ajena llevan asociadas dos reglas que son restricciones

inherentes al modelo relacional:

3.3. El Modelo Relacional y la Arquitectura ANSI

El modelo relacional puede examinarse, en el marco de la arquitectura ANSI, según lostres niveles que explicamos en el apartado 2.2.

En el nivel conceptual de la arquitectura ANSI se encuentran, además de los dominios, lasrelaciones o tablas. En el nivel externo de la arquitectura ANSI están las vistas, tablasvirtuales de las que sólo se almacena su definición, y no tienen, por tanto, representacióndirecta en el almacenamiento.

Por lo que respecta al esquema interno, el modelo relacional no especificaabsolutamente nada, ya que se trata de un modelo lógico. En general, cada registro delesquema interno se corresponde con una tupla de las relaciones base, pero no tendríaporqué haber una correspondencia biunívoca, ya que un registro podría estar constituidopor varias tuplas de distintas relaciones o, viceversa, una tupla podría dividirse en variosregistros. Además, cada producto ofrecerá los elementos internos, v.g. índices,agrupamientos, particiones, etc., que el implementador considere más oportunos con el finde mejorar el rendimiento del sistema.

Clave candidata: conjunto de atributos que identifican unívoca y mínimamente cadatupla de una relación.

Clave primaria: clave candidata que el usuario escogerá, por consideraciones ajenasal modelo relacional, para identificar las tuplas de la relación.

Claves alternativas: claves candidatas que no han sido escogidas como claveprimaria.

Clave ajena: de una relación R2 es un conjunto no vacío de atributos cuyos valoreshan de coincidir con los valores de la clave candidata de una relación R1 (R1

y R2 no son necesariamente distintas).

Regla de integridad de entidad:

"Ningún atributo que forme parte de la clave primaria de una relación puedetomar 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 clavecandidata de la relación R1 (relación referenciada), todo valor de dicho descriptordebe, bien concordar con un valor de la clave candidata referenciada de R1, bienser nulo”.


17

En la figura 3.7 se muestra un visión global del modelo relacional dentro del marcodefinido por la arquitectura ANSI, mostrando, además, ciertas sentencias del lenguaje SQLque ayudan a definir los elementos correspondientes en los tres niveles. Las sentencias queatañen al nivel interno variarán de un producto a otro, ya que no están estandarizadas.

Figura 3.7. Arquitectura a tres niveles en un SGBDR

En la práctica, sin embargo, muchos productos no responden a la arquitectura a tresniveles, ya que las definiciones del esquema conceptual y del esquema interno no estánclaramente 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 alproducto concreto en el que se implementará la BD.

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

Nosotros nos ocuparemos aquí de la definición del esquema lógico, pero sin tener encuenta el producto en el que se implementará (Oracle, Informix, DB2, SQL Server, etc.).

SQL - Manipulación

VISTA 1 VISTA 2 VISTA m

TABLA BASETB 1

TABLA BASETB 2

TABLA BASETB p

RELACIONAL

DATOS ALMACENADOS (Registros de las tablas base, índices, agrupamientos, etc.)

EXTERNOCREATE VIEW +sentencia de manipulación(SELECT)

CONCEPTUAL(CREATE TABLE,CREATE DOMAIN,…)

INTERNO(CREATE INDEX,CREATE PARTITION,CREATE CLUSTER,…)

Independen-cia lógica

Independen-cia física

…...

NIVEL

LOGICO

NIVEL

FISICO


18

Para su representación utilizaremos el grafo relacional por tratarse de una notaciónestá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 unesquema conceptual tal y como vimos en la unidad dedicada al modeladoconceptual de datos, para posteriormente convertirlo, aplicando unas reglas detransformación, al correspondiente esquema relacional. Este enfoque da comoresultado un conjunto de relaciones que deberán ser sometidas al proceso denormalización ver apartado 4.2).

2. Definir directamente el esquema relacional a partir de los atributos consideradosaisladamente y de las dependencias, especialmente de las funcionales (verapartado 4.2). La denominada relación universal, que contiene el conjunto deatributos y las dependencias, constituye en este caso el punto de partida de lasiguiente 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 menossubjetivo, 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 ahechos del mundo real, surgen dificultades para expresar restricciones de integridadreferencial y es más difícil que los usuarios participen en el diseño; otro problema que sepresenta en este caso es el de recoger la presencia de más de una interrelación entre dosentidades determinadas. Además, los costes de aplicar la teoría de la normalizacióncrecen exponencialmente con el número de atributos por relación; por tanto, si se partede la relación universal se necesita disponer de herramientas de normalización potentes ysofisticados 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 larelación universal, R <A, D>, donde A es el conjunto de atributos y D el de dependencias.


19

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 unconjunto de entidades e interrelaciones (con sus correspondientes atributos) yrestricciones semánticas; aplicando unas determinadas reglas de derivación (que seestudiarán más adelante) obtendremos un conjunto de relaciones (denominado {Ri} en lafigura) cada una de las cuales presenta un conjunto de atributos y dependenciasfuncionales.

Finalmente, ambos enfoques culminan en el proceso de normalización; aunque, comoya hemos advertido, en el caso de la relación universal la normalización es mucho máscostosa, mientras que cuando se parte del ME/R las relaciones están prácticamentenormalizadas.

Las herramientas CASE suelen soportar el modelado conceptual así como latransformación, más o menos completa, al modelo relacional, por lo que este enfoque escompatible con la aplicación de este tipo de herramientas.

Nosotros, como ya hemos indicado, concedemos una gran importancia a laparticipación de los usuarios en el proceso de diseño y pensamos, por tanto, que el ME/Rofrece 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 einterrelaciones del universo del discurso. Un posible inconveniente de este método es queexige cierta práctica en el diseño, pero, en nuestra opinión, sus ventajas superan conmucho este posible inconveniente.

MUNDO REAL

UD

- Atributos- Dependencias

- Entidades- Interrelaciones

R<(A), (D)>

ESQUEMA RELACIONAL- relación universal

-

{R}

R1<(Ai), (Di)>

ESQUEMA RELACIONAL- conjunto derelaciones-

NORMALIZACION


20

Por tanto, pasamos a exponer, en el apartado 4.1, las reglas de transformación delmodelo E/R al modelo relacional, para continuar, en el apartado 4.2, exponiendo la teoríade la normalización que deberá aplicarse a este esquema relacional a fin de refinarlo, tal ycomo se muestra en la parte derecha de la figura 4.1.

4.1. 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 lassiguientes:

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 delejemplo propuesto en la unidad desidaca al modelado conceptual (figura 3.16 de dichaunidad). Puede observarse que las tres entidades DEPARTAMENTO, EMPLEADO yPROYECTO se han transformado en otras tantas relaciones. La interrelación N:M Participada lugar a una nueva relación cuya clave es la concatenación de las claves primarias de lasentidades 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 yPROYECTO, respectivamente; la interrelación 1:N Pertenece se ha transformado medianteel mecanismo de propagación de clave, por el que se ha incluido en la tabla EMPLEADO elatributo clave de la entidad DEPARTAMENTO (Codigo_dep), que constituye, por tanto, laclave ajena de la relación EMPLEADO referenciando a la tabla DEPARTAMENTO.


21

DEPARTAMENTO EMPLEADO PROYECTOPertenece Participa

Codigo_dep DNI Codigo_proy

1:N N:M

EMPLEADO (DNI, Nombre, ..., Codigo_dep, Fecha_alta)

DEPARTAMENTO (Codigo_dep, Nombre, ...)

PARTICIPA (Codigo_proy, DNI)

PROYECTO (Codigo_proy,...)

Clave ajena

Clave ajena

Clave ajena

Fecha_alta

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 loselementos del modelo E/R estudiados:

1. Transformación de dominios. En el modelo relacional estándar un dominio es unobjeto más, propio de la estructura del modelo que, como tal, tendrá su definiciónconcreta en el LDD (en nuestro caso el SQL92) que se elija. Como ejemplo podemos crearel dominio de los estados civiles, como un conjunto de valores de tipo carácter, delongitud 1, que puede tomar los valores 'S', 'C', 'V' o 'D'. Los dominios no tienenrepresentación en el grafo relacional; en SQL expresaríamos este dominio de la siguienteforma:

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 deeste apartado, "cada entidad se convierte en una relación". La tabla se llamará igual que laentidad de donde proviene. Para su definición disponemos en el SQL de la sentenciaCREATE TABLE. Por ejemplo, la entidad EMPLEADO se transforma en una tabla con esemismo nombre (ver figura 4.3). En este caso la transformación es directa, y no hay perdidade semántica.

3. Transformación de atributos de entidades. Cada atributo de una entidad setransforma en una columna de la relación a la que ha dado lugar la entidad. Distinguimosentre atributos identificador principal (AIP en adelante) del resto de atributos:


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 lafigura 4.3 tenemos la relación EMPLEADO, fruto de la transformación de la entidaddel 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 pormedio de la claúsula PRIMARY KEY en la descripción de la tabla, luego laransformación es directa y no hay pérdida de semántica.

Figura 4.3. Transformación de una entidad

4. Transformación de interrelaciones. Ya hemos señalado que, dependiendo del tipode 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 esodesglosamos esta regla en tres subreglas:

4.1. Interrelaciones N:M. Una interrelación N:M se transforma en una relación quetendrá 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 laasociació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 delDNI del empleado y el código del proyecto. Además, cada uno de los atributos queforman la clave primaria de esta relación son claves ajenas que referencian a las tablasen que se ha convertido las entidades interrelacionadas (claves primarias).

EMPLEADODNINombreFecha_nac

TeléfonoDirección

NombreDNI Dirección Teléfono

Ana Belén12223433 Rios Rosas, 23 670123123Santiago54656754 Alarcos, 8 567983456Belén53567523 Getafe, 4 6º9267854

Goyo97856757 Pez, 102 679345763

.. . .

.. . .

.. . .

.. . .

Roberto34534522 Fundación, 10 639456239

EMPLEADO

ME/R

MR

CLAVE PRIMARIA

EMPLEADO (DNI, Nombre, Fecha_nac, Dirección, Teléfono)

Fecha_nac

11-07-93

12-08-6624-03-94

01-01-65

.

.

..

04-02-76


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).

DEPARTAMENTO

EMPLEADO

Pertenece

Codigo_dep

DNI

Esquema E/R

(0,n)

(1,1)

1:N

PROFESOR (Cód_prof,, ..., Cod_dep)

DEPARTAMENTO (Cod_dep, ...)

Esquema Relacional

Figura 4.4. Transformación de una interrelación N:M

4.2. Interrelaciones 1:N. Existen dos soluciones para la transformación de unainterrelación 1:N:

a) Propagar los AIP de la entidad que tiene cardinalidad máxima 1 a la que tienecardinalidad N, es decir en el sentido de la flecha, desapareciendo el nombre dela interrelación. Podemos ver un ejemplo en la figura 4.5. Si la interrelacióntiene atributos propios, estos se propagan a la misma relación a la que se hahecho la propagación de clave. Debe tenerse en cuenta que la propagación declave causa la aparición de claves ajenas, con sus mecanismos de borrado yactualizació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; sinembargo en este caso, la clave primaria de la relación creada es sólo la claveprimaria de la tabla a la que le corresponde la cardinalidad n.


24

PROYECTO

EMPLEADO

Participa

Codigo_proy

DNI

(0,n)

(1,n)

N:M

EMPLEADO (DNI, ...)

PARTICIPA (DNI, Codigo_proy)

PROYECTO (Codigo_proy, ...)

Esquema E/R Esquema Relacional

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 laeficiencia, los casos en los que puede ser apropiado transformar la interrelación en unarelación son los siguientes:

a) Cuando el número de ejemplares interrelacionados de la entidad que propagasu clave es muy pequeño y, por tanto, existirían muchos valores nulos en laclave propagada.

b) Cuando se prevé que dicha interrelación en un futuro se convertirá en una detipo N:M.

c) Cuando la interrelación tiene atributos propios y no deseamos propagarlos.

4.3. Interrelaciones 1:1. Una interrelación de tipo 1:1 es un caso particular de una N:Mo, también, de una 1:N, por lo que no hay regla fija para la transformación de este tipode interrelación al modelo relacional, pudiéndose aplicar la regla 4.1 (con lo quecrearíamos una relación) o aplicar la regla 4.2. (esto es, propagar la clavecorrespondiente). 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 quela relación tenga atributos propios, en las cardinalidades mínimas, en recoger la mayorcantidad de semántica posible, evitar los valores nulos o en motivos de eficiencia. Acontinuación exponemos algunos ejemplos, que puedan servir de pauta:


25

a) Si las entidades que se asocian poseen cardinalidades (0,1), puede serconveniente 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 entidadcon 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 puedepropagar la clave de cualquiera de ellas a la tabla resultante de la otra, teniendoen cuenta en este caso los accesos más frecuentes y prioritarios a los datos delas tablas. Se puede plantear (también por motivos de eficiencia) la propagaciónde las dos claves, lo que introduce redundancias que deben ser controladas pormedio de restricciones.

d) Si la entidad posee atributos propios, puede ser conveniente transformar lainterrelació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 enuna relación, todos sus atributos pasan a ser columnas de la relación. En caso de que lainterrelación se transforme mediante propagación de clave, sus atributos migran junto ala clave a la relación que corresponda (ver figura 4.2), aunque ya hemos advertido que eneste caso puede ser preferible crear una nueva relación para representar lasinterrelaciones que tienen atributos.

7. Transformación de entidades débiles. La interrelación que une una entidad débilcon una entidad regular es siempre una interrelación de tipo 1:N. En este caso, las dosentidades se transforman en relaciones y la interrelación se transforma mediantemigración de clave de la relación que representa a la entidad regular hacia la relación querepresenta a la entidad débil, creando una clave ajena en la entidad dependiente, con lacaracterística de obligar a una modificación y un borrado en cascada. La figura 4.6 muestraun ejemplo de transformación cuando existe una entidad débil. En este caso, suponemosque la empresa tan sólo desea conocer la información relativa a los hijos de susempleados. Por ello, cada ejemplar de la entidad HIJO depende de un ejemplar concretode la entidad EMPLEADO, de tal modo que si se borra un empleado de la BD deberánborrarse también todos sus hijos.

Además, en algunos casos, y dependiendo de la semántica de cada problema, la claveprimaria de la relación en la que se ha transformado la entidad débil puede estar formadapor la concatenación de las claves de las dos entidades participantes en la interrelación.


26

HIJO

EMPLEADO

Tiene

DNI_hijo

DNI

(0,n)

(1,1)

1:N

EMPLEADO (DNI, ...)

HIJO (DNI_hijo, DNI_padre...)

Clave ajenaBorrado en CASCADA

Modificación en CASCADA

Esquema E/R Esquema Relacional

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, noson objetos que se puedan representar explícitamente en el modelo relacional. Ante unaentidad 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 solarelación. En general, adoptaremos esta solución cuando los subtipos sediferencien en muy pocos atributos y las interrelaciones que los asocian con elresto de las entidades del esquema sean las mismas para todos (o casi todos) lossubtipos. Por ejemplo, si consideramos que la diferencia existente entre unempleado que sea analista y otro que sea programador, es mínima debido a queambos tienen los mismos atributos y ambos pueden participar en proyectos, lasolución adecuada sería la creación de una sola tabla que contenga todos losatributos del supertipo y los de los subtipos, añadiendo el atributo discriminanteque indica el tipo de empleado (ver figura 4.7).

Hay que observar que el atributo discriminante de la jerarquía podrá admitirvalores nulos en el caso de que la jerarquía sea parcial y no deberá permitirlos si lajerarquía es total. Por otra parte, el atributo discriminante constituirá un gruporepetitivo, si los subtipos se solapan, debiendo, por tanto, separar este atributo enuna relación aparte que tendrá como clave la concatenación de la clave delsupertipo con el atributo discriminante; otra solución bastante más eficienteconsiste en crear un código para los valores del atributo discriminante quecontemple los posibles subtipos solapados.


27

Opción b: crear una relación para el supertipo y tantas relaciones como subtiposhaya, con sus atributos correspondientes. La clave primaria de todas las relacionescreadas es la misma y además, en las relaciones correspondientes a los subtipos laclave 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 encascada. Esta es la solución adecuada cuando existen muchos atributos distintosentre los subtipos y se quieren mantener de todas maneras los atributos comunesa 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óncuando se dieran las mismas condiciones que en el caso anterior –muchosatributos distintos- y los accesos realizados sobre los datos de los distintos subtipossiempre afectaran a atributos comunes.

Figura 4.7. Transformación de subtipos

Podemos, por tanto, elegir entre tres estrategias distintas para la transformación de untipo y sus subtipos al modelo relacional. Sin embargo, desde un punto de vistaexclusivamente semántica la opción b es la mejor. Por otra parte, desde el punto de vistade la eficiencia tenemos que tener en cuenta que:

ANALISTA PROGRAMADOR

(0,1)

(1,1)

(0,1)

TipoEs_un

EMPLEADO

Titulación

A) EMPLEADO (DNI, Nombre, …, Tipo, Titulación)

B) EMPLEADO (DNI, Nombre, …)

ANALISTA (DNI,Titulación, …)

PROGRAMADOR (DNI,…)

C) ANALISTA (DNI, Nombre, Titulación, …)

NO_DOCTOR (DNI, Nombre, …)


28

Opción a: el acceso a una fila que refleje toda la información de una determinadaentidad 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 desdeun 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ássemántica; además si existe solapamiento se introduce redundancia que debe sercontrolada si queremos evitar inconsistencias.

Elegiremos una estrategia u otra dependiendo de que sea la semántica o la eficiencia laque prime para el usuario en un momento determinado.

Por último, cabe destacar que en próximas versiones del lenguaje SQL (la denominadaSQL:1999) se están definiendo más elementos a fin de soportar directamente la herenciapor medio de las denominadas subtablas.

4.2. Teoría de la Normalización

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

Aunque, en general, la primera aproximación produce un esquema relacionalestructurado y con poca redundancia, por lo que no es imprescindible verificar la "bondad"del esquema obtenido, siempre es conveniente aplicar un conjunto de reglas, conocidascomo teoría de la normalización, que nos permiten asegurar que un esquema relacionalcumple unas ciertas propiedades. En el segundo enfoque, es decir cuando no se haaplicado la metodología de diseño anteriormente expuesta, la teoría de normalizaciónresulta imprescindible.

Entre los problemas que puede presentar un esquema relacional cuando el diseño esinadecuado 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).


29

Pérdida de ciertas restricciones de integridad que dan lugar a interdependenciasentre los datos (lo que, posteriormente, denominaremos dependencias funcionales).

Aparición en la base de datos, como consecuencia de las redundancias, de estadosque 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 losproblemas anteriormente citados, evitando así la pérdida de información y la aparición deinconsistencias.

Veamos un ejemplo de estos problemas derivados de un diseño inadecuado. En la figura4.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 losproblemas enumerados anteriormente.

Figura 4.8. Ejemplo de diseño inadecuado

Los principales problemas de esta relación se derivan de la gran cantidad de redundanciaque presenta. Por ejemplo, la dirección del empleado se repite por cada proyecto en el queparticipa; y algo análogo sucede con los proyectos. Esta redundancia produce a su vez:

Anomalías de inserción, ya que dar de alta un proyecto obliga a insertar en labase de datos tantas tuplas como participantes tenga el proyecto.

Anomalías de modificación, ya que cambiar la dirección de un empleado obliga amodificar todas las tuplas que corresponden a dicho empleado, y viceversa, sicambiamos el nombre de un proyecto habría que cambiarlo en tantas tuplascomo empleados participen en dicho proyecto.

Anomalías de borrado, ya que el borrado de un proyecto obliga a borrar variastuplas, tantas como participantes tenga ese proyecto y, viceversa, el borrado deun empleado nos lleva a borrar tantas tuplas como proyectos en los que participa.

DNI NOMBRE DIRECCIÓN CODIGO_PROY NOMBRE HORAS

B. Vela 23433 2000

23433 150023433 1600

97875 2000

97875 1500

97875 1600

86754 2000

86754 1500

23456 2000

PARTICIPA

1234567812345678

12345678

45678901

45678901

45678901

7890123478901234

89012345

B. Vela

B. VelaA.B. Parrilla

A.B. Parrilla

A.B. ParrillaS. Bermudez

S. Bermudez

A. Ortega

P1

P1

P1

P1

P2

P2

P2

P3

P3

Leonardo

Leonardo

Leonardo

Leonardo

Alejandría

Alejandría

Alejandría

Nikos

Nikos


30

Vemos, por tanto, que la actualización (alta, baja o modificación) de un solo empleado ode un solo proyecto nos puede obligar a actualizar más de una tupla, dejándose laintegridad de la base de datos en manos del usuario. Al riesgo de la posible pérdida deintegridad, 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 otrosproblemas adicionales, como la imposibilidad de almacenar ciertos hechos, o ladesaparición de información que desearíamos mantener en la base de datos. Por ejemplo sise quisiera incluir información sobre un empleado que no participe en ningún proyecto, noserí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 unproyecto desaparecen de nuestra base de datos los datos de los empleados que participenen 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 principiobásico en todo diseño:

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

Si se hubiera llevado a cabo un diseño riguroso no se habría presentado una relación deeste tipo. Si se siguiera la metodología de diseño propuesta, realizando un buen diseñoconceptual en el modelo E/R, seguido de una cuidadosa transformación al modelorelacional, se evitarían en gran parte estas anomalías, obteniéndose en general unesquema exento de errores. Sin embargo, ante las posibles dudas respecto a si undeterminado esquema relacional es o no correcto, será preferible aplicar siempre a dichoesquema un método formal de análisis que determine lo que pueda estar equivocado en elmismo y nos permita llegar a otro esquema en el que se asegure el cumplimiento de ciertosrequisitos; 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 quecomentábamos anteriormente. Así, en lugar de la relación del ejemplo que aparecía en lafigura 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)

"Hechos distintos se deben almacenar en objetos distintos"


31

donde se ha seguido el principio básico anteriormente enunciado, separando hechosdistintos en relaciones distintas, de forma que cada uno de estos esquemas de relaciónrecoge un hecho bien determinado y concreto del mundo real con sus correspondientesatributos. La teoría de la normalización, que puede definirse como una técnica formal paraorganizar datos, nos ayuda a determinar qué está equivocado en un diseño y nos enseña lamanera de corregirlo. Por tanto, la teoría de la normalización introduce una formalizaciónen el diseño lógico de bases de datos relacionales, lo que, además, permite mecanizar partedel 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íasmencionadas, evitando muchos de los problemas que se pueden plantear en lasactualizaciones. Sin embargo, al mismo tiempo penaliza las consultas al disminuir laeficiencia de las mismas, ya que cuando se aplica el proceso de normalización a una basede datos aumenta el número de relaciones, por lo que una determinada consulta puedellevar 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. Sedice que un esquema de relación está en una determinada forma normal si satisface unconjunto específico de restricciones. Codd, junto con la 1FN, definió también la segundaforma normal (2FN) y la tercera (3FN). Posteriormente, otros autores propusieron nuevasformas normales, como la Forma Normal de Boyce y Codd (FNBC), y la cuarta y quinta formanormal (4FN y 5FN) debidas a Fagin. La 2FN impone más restricciones que la 1FN, la 3FNmás que la 2FN, etc., siendo la 5FN la que impone restricciones más fuertes. A fin de evitarlas anomalías que describíamos anteriormente es preferible la 5FN, después la 4FN, FNBC, la3FN, la 2FN y, por último, la 1FN. Sin embargo en la práctica, y debido fundamentalmente amotivos 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 atributosde una relación, las cuales son conocidas con el nombre de dependencias. Existen variostipos de dependencias, encontrándose relacionadas la 2ª, 3ª y FNBC con las dependenciasfuncionales, la 4ª con las dependencias multivaluadas y la 5ª con las dependencias deproyección-combinación.

4.2.1. Dependencias Funcionales

Ya hemos señalado que la teoría de la normalización se basa en el concepto dedependencias. Las dependencias son propiedades inherentes al contenido semántico de losdatos que se han de cumplir para cualquier extensión del esquema de relación y formanparte de las restricciones de usuario del modelo relacional. La existencia de unadependencia no se puede demostrar, pero sí afirmar por observación del mundo real que se


32

trata de modelar; por tanto, del análisis de una extensión válida de un esquema de relaciónnunca 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, siconocemos que una dependencia es cierta para un esquema de relación, podremosasegurar que una extensión de dicho esquema no es válida si no la cumple.

Las dependencias nos muestran algunas importantes interrelaciones existentes entre losatributos 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 cualproceden.

Las dependencias funcionales son un tipo especial de dependencias, el más extendido enla práctica, en el cual se basan las primeras formas normales. A continuación vamos a definirdicho 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 Ysubconjuntos de A llamados descriptores. Se dice que Y depende funcionalmente de X, o loque es igual que X determina o implica a Y, si, y sólo si, cada valor de X tiene asociado entodo momento un único valor de Y. Representamos esta dependencia funcional de lasiguiente forma:

X Y

Llamamos determinante o implicante al descriptor que se encuentra a la izquierda delsí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 lacategorí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 anterioresdependencias y el Salario y la Categoría son los implicados. Estas dependencias también nosdicen que el salario, o la categoría, es información acerca del empleado, ya que unadependencia funcional se puede interpretar diciendo que el implicado es un hecho (enrealidad una información) acerca del implicante.

La afirmación de que Cod_emp determina Salario no significa que conocido el código deun empleado podamos deducir, a partir de él, cuál es su salario, a no ser que tengamos unaextensión r(R) del esquema de relación que contiene la correspondiente dependenciafuncional. Es decir, si para un esquema R, tenemos la dependencia funcional:

X Y


33

dado el valor de X no podemos, en general, conocer el valor de Y, solamente noslimitaremos a afirmar que para dos tuplas de cualquier extensión r(R) que tengan el mismovalor 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 grafoo diagrama de dependencias funcionales, mediante el cual se representa un conjunto deatributos y las dependencias funcionales existentes entre ellos. En el grafo aparecen losnombres de los atributos unidos por flechas, las cuales indican las dependencias funcionalesy parten del implicante hacia el implicado. Cuando el implicante de una dependencia no esun único atributo, es decir se trata de un implicante compuesto, los atributos que locomponen 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 delempleado tal como indica la correspondiente flecha; de forma análoga, Cod_proy determinael 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 laFecha_inicio y Fecha_fin de trabajo de un determinado empleado en un determinadoproyecto.

Figura 4.9. Ejemplo de diagrama de dependencias funcionales

Existen otros conceptos, como el de dependencia plena o completa y el de dependenciatransitiva, 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 dependefuncionalmente de X, pero no depende de ningún subconjunto del mismo, esto es:

X Y

X1 Y

X2 Y

Cod_emp

Cod_proy

Salario, Categoría

Fecha_inicio, Fecha_fin

Nombre, Duración


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, existeuna única fecha de inicio. Sin embargo, ni el código de empleado, ni tampoco el código deproyecto, implican, por sí solos, la fecha de inicio, ya que un empleado puede comenzar atrabajar en proyectos distintos en distintas fechas y en un detereminado proyectos puedenincorporarse diferentes empleados en distintas fechas. Por tanto, la dependencia funcionalanterior es completa, lo que se representa:

Cod_emp, Cod_proy Fecha_inicio

ya que:

Cod_emp Fecha_inicio

Cod_proy Fecha_inicio

lo que, intuitivamente, se puede interpretar como que Fecha_inicio constituye unainformación sobre el conjunto de empleado y proyecto, pero esta información no atañe aun 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 ladependencia (también llamado extraño).

B) Dependencia funcional transitiva.

Sea la relación

R (X, Y, Z)


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 quese 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, setendrá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 variosempleados), la dependencia funcional entre Cod_emp y Salario es una dependenciatransitiva 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 elempleado, 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 parael ejemplo propuesto, en el que la dependencia

Cod_emp Salario

es una dependencia transitiva.

Salario

Cod-emp Categoría

Figura 4.10. Ejemplo de dependencia funcional transitiva


36

4.2.2. Formas Normales

Expuesto ya el concepto de dependencia funcional, podemos pasar a definir las formasnormales. Como ya se ha indicado, nos limitaremos al estudio de las formas normalesbasadas 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 esobligatorio. 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. Enrealidad, 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 aquellosempleados 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ónen 1FN habrá que repetir el resto de atributos de la tupla para cada uno de los valores delgrupo repetitivo, tal como aparece en la parte b) de la figura 4.11. La clave primaria ya nopodrá ser el código del empleado, pues éste se repetirá tantas veces como proyectos en losque participe el empleado en cuestión; la clave primaria se formará por la concatenación dela clave primaria de la tabla sin normalizar con el atributo (o atributos) que tiene el gruporepetitivo (en el ejemplo, Proyecto).


37

NO ESTA EN 1F

Hay grupos repetitivos

EMPLEADO (Cod_emp, Nombre, Cod_proy)

ESTA EN 1F

b)EMPLEADO (Cod_emp, Nombre, Cod_proy)

a)

COD_EMP NOMBRE COD_PROY

Emp1 B. Vela P1P2

Emp2 A. B. Parrilla P1

Emp3 S. Bermudez P1P3

COD_EMP NOMBRE COD_PROY

Emp1 B. Vela P1

P2Emp2 A. B. Parrilla P1Emp3 S. Bermudez P1

P3

Emp1 B. Vela

Emp3 S. Bermudez

Figura 4.11. 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 decada una de las claves (es decir, no hay dependencias de atributos noprincipales 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 seencuentra en 2FN ya que el nombre del empleado está determinado sólo por el código deempleado y no por la clave completa; del mismo modo, el nombre del departamentodepende del código de departamento y no de la clave completa.


38

Para convertir una relación a 2FN es necesario descomponerla tantas relaciones comosea necesario a fin de eliminar las dependencia funcionales no completas. En el ejemplopropuesto, 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 queCod_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 algunade las claves de 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 dependetransitivamente 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 queforman la dependencia funcional transitiva y se eliminan los atributos con dependenciatransitiva de la relación original.


39

Así, por ejemplo, la relación EMPLEADO, la descompondremos en otras dos del siguientemodo:

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 propuestasoriginariamente Codd, pero, como ya hemos señalado, con el paso del tiempo semostraron insuficientes para afrontar ciertos problemas en relaciones que presentabanvarias claves candidatas compuestas que se solapaban. Por ello, en 1974, Boyce y Codddefinieron la llamada forma normal que lleva su nombre (FNBC). Se trata de unaredefinició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 unaclave candidata.

Sea la siguiente relación:

EMPLEADO (Cod-emp, Nomb_emp, Cod-proy, Función)

que presenta las siguientes dependencias funcionales:

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 larelación PROYECTO no está en FNBC.

Para convertir esta relación en otra que esté en FNBC la descomponemos en dosrelaciones del siguiente modo:

EMPLEADO1 (Cod-emp, Nomb_emp)

EMPLEADO (Cod-emp, Cod-proy, Función)

cod-empcod_proy

función

nomb_empcod_proy

función

nomb_empcod-emp


40

4.2.3. 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 deproyección del álgebra relacional.


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 unaforma 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únCod_proy) nos devuelve la relación original.

En el proceso de normalización las relaciones se descomponen en proyeccionesindependientes 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 sinpé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 lacombinació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 4.12.


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 4.12. La combinación de estas dosrelaciones (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 deLIBRO ha dado lugar a pérdida de información.

Figura 4.12. Descomposición con pérdida de información (aparición de tuplas espúrias)

COD_LIBRO EDITORIAL PAIS

654654 Rama España665465 Rama España876545 Paraninfo España

987456 Anaya España965842 Addison-w. EE.UU.

EDITORIAL PAIS

Rama España

Rama España

Paraninfo España

Anaya EspañaAddison-W.. EE.UU.

COD_LIBRO PAIS

654654 España665465 España876545 España

987456 España965842 EE.UU.

COD_LIBRO EDITORIAL PAIS

654654 Rama España654654 Paraninfo España654654 Anaya España665465 Rama España665465 Paraninfo España665465 Anaya España876545 Rama España

876545 Paraninfo España

876545 Anaya España

987456 Rama España987456 Paraninfo España987456 Anaya España965842 Addison-w.. EE.UU.

LIBRO

LIBRO1 EDITORIAL1

LIBRO1 * EDITORIAL1

TUPLASESPÚRIAS

a)

b)

c)


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érdidade información es que el atributo común de las dos relaciones sea clave, al menos, en una deellas; 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 esconveniente conservarlas en el proceso de descomposición.

Sea la misma relación LIBRO del ejemplo anterior que hemos descompuesto en LIBRO2 yEDITORIAL2, 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 queen 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 hadesaparecido 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 {Ri} se dice que se harealizado en proyecciones independientes si no ha habido ni pérdida de información ni dedependencias funcionales.


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 delas relaciones (la segunda), por lo que no hay pérdida de información; además, tampocohay 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 larelación original y, en ellas, se han eliminado las anomalías de inserción, borrado ymodificación (dado que sólo se ha llegado a 3FN no se puede asegurar que, en todos loscasos, se eliminen por completo las anomalías).

Como ya hemos dicho, se puede demostrar que es posible descomponer cualquierrelación, llevándola a 3FN, sin pérdida de información ni de dependencias funcionales (cosaque 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 ypor el conjunto de sus dependencias funcionales. Este método de descomposición, que esel que acabamos de analizar, recibe el nombre de análisis. Existe otro método paranormalizar una relación que es el denominado método de síntesis.

4.2.4. Algunas Consideraciones sobre la Teoría de la Normalización

La teoría de la normalización nos ayuda a estructurar mejor las relaciones, evitandoposibles redundancias y anomalías, y a representar mejor nuestro mundo real en unesquema relacional.

Sin embargo, no hay que olvidar que al descomponer una relación penalizamos lasconsultas, provocando una pérdida de eficiencia en las mismas. Aunque, en general, seaconseja 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 caboel proceso inverso, es decir, una desnormalización, combinando las relaciones hasta dejarlasen formas normales anteriores. También en relaciones muy estables, donde apenas seproducen actualizaciones (este es, por ejemplo, el caso de ciertas investigacionesestadísticas), puede no ser conveniente avanzar en la normalización.


44

Por otra parte, si seguimos la metodología de diseño expuesta en la primera parte deesta unidad, obteniendo primero un esquema en el modelo E/R y transformándolo despuésal modelo relacional, el esquema relacional resultante, siempre que todo el proceso se hayarealizado correctamente, estará al menos en 3FN (e incluso en formas normales másavanzadas). En este caso, la teoría de la normalización nos servirá para comprobar que eldiseño ha sido correcto y, si no lo fuese, podremos aplicar la descomposición para corregirlos 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?


45

Supuestos

Para cada uno de los siguientes esquemas conceptuales, tomados de los supuestos dela unidad dedicada al modelado conceptual de datos, se pide:

a) Definir el correspondiente esquema relacional utilizando para ello la metodologíapropuesta en esta unidad.

b) Comprobar en que forma normal se encuentra el esquema relacional obtenido yllevar, en caso de que no lo esté ya, hasta la FNBC.

S1.

(1,1)

1:N

DEPARTAMENTO

Pertenece

Codigo_dep

Fecha_alta

(0,n)

Codigo_proy

1:1 N:M

(1,n)

(0,n)

EMPLEADO

PROYECTO

Dirige

DNI

(1,1)

Es_un

(0,1) (0,1)

ANALISTA PROGRAMADOR

Participa

(1,1)

(1,1)


46

S2.

S3.

Avalado_por

Alquilado

(0,n)

EJEMPLAR

Tiene

I

(1,n)

(1,1)

DIRECTOR PELÍCULA ACTORParticipaDirige

(0,n)(1,n)(1,n)(1,1)

Tipo_part

Nombre Nacional

SexoNombre Nacional

ProductTítulo Nacional Fecha

Num_Ej

Conserv

Fecha_c

Fecha_f

(0,n)

SOCIO(0,n)

(1,1)

Nombre

DNI

Tlf

Direc

CURSO

EMPLEADOEDICIÓN

Impartido

Prerrequisito

Participa

Cod_c

Cod_e

Tipo_pFecha

Opcional

N:M

1:N

N:M(0,n)

(1,1)

(0,n)

(0,n)

(0,n) (1,n)


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 2006.

Es el libro en el que nos hemos basado para la elaboración de esta documentación, porlo que es un excelente complemento de la misma. Presenta, de un modo claro ypreciso, el modelo relacional así como las dos aproximaciones al diseño de bases dedatos relacionales, tanto el diseño basada en la teoría de las normalización, como eldiseño a partir del modelo E/R. Propone una metodología de diseño para BDrelacionales basada en esta última aproximación. Contiene además una colección deejercicios de diseño, algunos de ellos con soluciones, por lo que es tambiénrecomendable para aquellos alumnos que deseen practicar más.

6.2. Bibliografía Recomendada

Date, C.J. Introducción a los sistemas de bases de datos. Séptima edición.Addison-Wesley, 2001.

El Date es el libro de referencia obligada en para bases de datos relacionales y muyapropiado para quienes quieran profundizar en los siguientes temas: modelorelacional, teoría de la normalización y diseño de bases de datos relacionales basadoen la teoría de la normalización.

Melton, J. y Simon, A. SQL: 1999 - Understanding Relational Language Components.Morgan Kaufmann, 2001.

El SQL es el lenguaje estándar para bases de datos relacionales. En esta unidad se haestudiado el modelo relacional pero sin entrar en el lenguaje de definición ymanipulación, por lo que este libro, escrito por el editor del SQL, Jim Melton, puede serun buen complemento. Además, el conocimiento del SQL es un apoyo para una mejorcomprensión del modelo relacional.

Diseño Estructurado de Datos · Diseño Estructurado de Datos 9 Aunque una relación se puede...

Documents

Transcript of Diseño Estructurado de Datos · Diseño Estructurado de Datos 9 Aunque una relación se puede...