TEMA 4. Diseño Lógico de bases de datos relacionales

Bases de Datos – Biblioteconomía – 2003-2004 Tema 4: Diseño lógico de B.D.R.

TEMA 4. Diseño Lógico de bases de datos relacionales.

1. El modelo relacional

La teoría formal que constituye los cimientos de los sistemas relacionales se conoce como modelo de datos relacional. Cuando describimos un sistema como relacional queremos decir que el sistema en cuestión está construido de acuerdo con los principios de ese modelo teórico.

En términos precisos, el modelo relacional se ocupa de tres aspectos de los datos: su estructura, su integridad y su manipulación.

1.1. La estructura relacional

El modelo relacional se basa en el concepto de relación como elemento básico, el cual se puede representar como se muestra en la figura:

NOMBRE

atributo 1 atributo 2 … atributo n

…

…

…

…

…… …

XXX

XXX

XXX

XXX

XXX XXX XXX

XXX

XXX tupla 1

tupla 2

…

tupla m

En dicha relación podemos distinguir su nombre, un conjunto de columnas, denominadas atributos, que representan propiedades de las tablas y que también están caracterizadas por su nombre, y un conjunto de filas llamadas tuplas, que contienen los valores que toma cada uno de los atributos para cada elemento de la relación.

Concretando, los términos importantes en la estructura de datos relacional son:

• Relación. Es lo que correspondería con la idea general de una tabla. • Tupla. Es lo que correspondería a una fila en dicha tabla. • Atributo. Sería una columna de la tabla. • Cardinalidad. Número de tuplas en la tabla. • Grado. Número de atributos en la tabla. • Clave primaria. Es un identificador único para la tabla, esto es, una columna o

conjunto de columnas de forma que nunca existen dos filas en la misma tabla con el mismo valor en esa columna o conjunto de columnas.

• Dominio. Una colección de valores de los cuales uno o más atributos obtienen sus valores reales.

Veamos un ejemplo de una relación típica:

DNI Nombre Apellidos Dirección Teléfono Fec_nac 14.167.654 Alberto Gómez Martínez Pedrones, 4 963787878 23/02/195864.237.935 Luisa Ripoll Albert Denia, 64 963573895 12/06/196345.126.579 José Luis Pérez Cerdán Escandinavia, 12 963873333 15/12/194367.677.887 Andrea Martínez Zanón Poeta Más Gil, 37 963772564 10/02/1965

1


En esta relación, un ejemplo de tupla sería la fila marcada en gris. Los atributos serían: DNI, Nombre, Apellidos, Dirección, Teléfono y Fec_nac. La cardinalidad de esta relación es 4, y el grado es 6. La clave primaria sería el DNI, puesto que es un valor que identifica unívocamente cada tupla de la relación. Los dominios para cada atributo serían variables; por ejemplo, Nombre, Apellidos y Dirección pertenecería al dominio ‘texto’, el DNI pertenecería al dominio ‘entero’, teléfono pertenecería al dominio ‘entero de 9 dígitos’, y Fec_nac al dominio ‘fecha’.

Si observamos el siguiente ejemplo, en él se representa la relación PROFESOR donde aparece la estructura del modelo relacional. En ella se puede observar el nombre de la relación (PROFESOR); los atributos (código, nombre, apellidos, categoría); los dominios (de donde los atributos toman sus valores; varios atributos pueden tomar valores del mismo dominio); las tuplas (cada una de las cuales contiene los valores que toma el código, nombre y apellidos); el grado (número de atributos) y la cardinalidad (número de tuplas).

Atributos

Cardinalidad 3

Grado 4

CATEGORIAS

Catedrático

Titular

Ayudante

APELLIDOSNOMBRESCODIGOS

HNNNN XXXXXX XXXXXX

15 50

PROFESOR

NOMBRECODIGO APELLIDOS

H0001H0002H0003

AntonioAmparoIsabel

García GarcíaPérez PérezFernández Fernández

CATEGORIA

CatedráticoAyudanteTitular

Tuplas

DOMINIOS

Hay que hacer notar que, a pesar de que una relación se represente en forma de tabla existe una serie de elementos que la distinguen de una tabla; en una relación no se admiten filas duplicadas, las filas y columnas no están ordenadas y es plana, es decir, en el cruce de una fila y de una columna sólo puede haber un valor.

La representación en forma de tabla ha conducido a que los usuarios utilicen el nombre de tabla para denominar las relaciones y, como consecuencia de ello, se llame filas a las tuplas y columnas a los atributos. Si hacemos una comparación de la terminología de relación, tabla y fichero obtendríamos lo siguiente:

RELACIÓN

CARDINALIDAD

GRADO

ATRIBUTO

TUPLA

TABLA

Nº DE FILAS

Nº DE COLUMNAS

COLUMNA

FILA

FICHERO

Nº DE REGISTROS

Nº DE CAMPOS

CAMPO

REGISTRO

Veamos todo esto de modo más formal:

2


Dominios

La menor unidad semántica de información es el valor de un dato individual (como el nombre de una ciudad, el código de un pedido, etc.). A estos valores los llamaremos escalares (no poseen estructura interna).

Definimos un dominio como un conjunto de valores escalares, todos ellos del mismo tipo. Desde un punto de vista intuitivo, un dominio es equivalente a un tipo de datos. De este modo, se define atributos (variables) que pertenezcan a un dominio (tipo de datos). Por lo tanto, los dominios son fondos de valores, de los cuales se extraen los valores reales que aparecen en los atributos. Cada atributo debe estar definido sobre un único dominio.

Ya vimos que los atributos podían ser simples o compuestos, en realidad son así porque dependen del dominio sobre el que están definidos, y los dominios pueden ser simples o compuestos. Por otra parte, las operaciones relacionales deberán ser capaces de hacer referencia a ese atributo en su totalidad y también a sus componentes de forma individual.

Un dominio simple es un dominio de valores escalares. Un domino compuesto se define como una combinación de dominios simples. Por ejemplo el caso de la fecha, está compuesto del día, el mes y el año y las tres partes (simples) nos dan la fecha (compuesto).

Los dominios son útiles porque sirven para restringir las comparaciones. Esto significa que cuando se realiza una consulta utilizando el lenguaje de consulta apropiado, las condiciones de la consulta suelen representarse a través de comparaciones entre atributos de las relaciones. Por tanto, una forma sencilla de identificar si la consulta es semánticamente correcta es analizar si los atributos que forman parte de una comparación son compatibles, es decir, si pertenecen al mismo dominio.

Relaciones

Una Relación sobre un conjunto de dominios se compone de dos partes, la cabecera y el cuerpo. La cabecera está formada por un conjunto fijo de pares atributo-dominio (viene a ser la fila de cabeceras de columnas). El cuerpo está formado por el conjunto de tuplas (sería el conjunto de filas de datos) que a su vez están formadas por los pares atributo-valor, uno para cada atributo de la cabecera. El número de tuplas que hay en el cuerpo puede variar con el tiempo y nos indica la cardinalidad de la relación y el número de atributos que tenemos en la cabecera, el cual no cambia, nos indica el grado.

Las propiedades de las relaciones que se derivan de su propia definición son:

• No existen tuplas repetidas. La existencia de una clave primaria impide que existan tuplas repetidas. (Recordemos que en una tabla sí que pueden haber filas repetidas).

• Las tuplas no están ordenadas. Una relación está definida como un conjunto, y en un conjunto no se establece una relación de orden (matemáticamente).

• Los atributos no están ordenados. Puesto que la cabecera de una relación también se define como un conjunto, no existe un orden preestablecido.

3


• Todos los valores de los atributos son atómicos. Otra forma de expresar esta propiedad es diciendo que todos los valores de los atributos simples son atómicos, sólo toman un valor en cada caso. (Esta es la definición de 1ª Forma Normal que veremos en el último tema).

Por último, podemos tener distintos tipos de relaciones, unos de los cuales son:

• Relaciones base (o relaciones reales). Son aquellas relaciones que tienen tanta importancia que el diseñador de la BD decidió darle un nombre y hacerlas parte directa de la BD.

• Vistas (o relaciones virtuales). Es una relación derivada, con nombre.

• Resultados de consultas. Es una relación final resultante de alguna consulta especificada. Puede o no tener nombre. No tienen persistencia en la BD.

• Resultados intermedios. Son relaciones resultantes de alguna expresión relacional anidada dentro de alguna otra expresión relacional mayor.

• Relaciones temporales. Es una relación con nombre, pero que se destruye de forma automática en el momento apropiado.

Concepto de valor nulo

Si bien los valores nulos no son un concepto exclusivo del modelo relacional, ha sido en el contexto de este modelo donde se ha abordado su estudio de manera más sistemática y donde se están realizando más investigaciones a fin de formalizar su tratamiento.

Se puede definir el valor nulo (también denominado valor ausente) como una señal utilizada para representar información desconocida, inaplicable, inexistente, no válida, no proporcionada, indefinida, etc. Su necesidad en las bases de datos es evidente por diversas razones:

• Crear tuplas (filas) con ciertos atributos desconocidos en ese momento, por ejemplo, el año de edición de un libro.

• 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, la editorial para un artículo o la profesión para un menor.

El tratamiento de valores nulos exige definir operaciones de comparación, operaciones aritméticas, operaciones algebraicas y, funciones de agregación, de forma específica para el caso de que alguno de los operandos tome valores nulos, y obliga también a introducir nuevos operadores especiales. En las operaciones de comparación se plantea el problema de saber si dos valores nulos son o no iguales. No podemos decir que es cierto que sean iguales puesto que estaríamos afirmando que no son “tan” desconocidos; pero tampoco podemos decir que es falso que sean iguales; la única solución que nos queda es decir que quizá sean iguales.

El estudio de los nulos es una parte importante en las bases de datos pero excede el objetivo de este curso por lo que no profundizaremos más en ello.

4


1.2. Reglas de integridad relacional

Los elementos no permitidos o restricciones son debidos a que no todos los valores, cambios de valor o estructuras están permitidos en el mundo real. Por ejemplo, un niño de dos años no puede estar viudo, etc. Además, cada modelo de datos también impone por sí mismo limitaciones a las estructuras que admite; así, el modelo relacional no permite que dos filas de la misma tabla sean iguales.

Estas limitaciones, que unas veces las impone el modelo de datos y otras vienen impuestas por la situación real que estamos modelando se denominan restricciones. Las restricciones impuestas por el modelo son restricciones inherentes, y las que responden a que el sistema de información es un reflejo del mundo real son restricciones de integridad o semánticas. Las restricciones inherentes son propias del modelo y, por tanto, varían de un modelo a otro. Por el contrario, las restricciones de integridad son facilidades que se ofrecen al diseñador a fin de que pueda representar en el esquema, lo más fielmente posible, la semántica de los datos.

En general, todas las reglas de integridad se aplican a las relaciones base.

La mayor parte de las reglas de integridad son específicas, en cuanto que se aplican a una base de datos específica. Sin embargo, el modelo relacional incluye dos reglas generales de integridad, puesto que se aplican a cualquier base de datos, y se refieren a las claves primarias y claves ajenas. Veamos cuales son:

Claves primarias

Recordemos los siguientes conceptos relacionados con las claves primarias:

- Una Superclave es un conjunto de atributos que identifican de modo único las tuplas de una relación.

- Una Clave Candidata es el menor subconjunto de atributos de una superclave que sigue siendo un identificador único.

- En una relación pueden existir diferentes claves candidatas que se compongan de un número diferente de atributos. De todas las claves candidatas se elige una, y sólo una, que será la Clave Primaria. El resto de claves candidatas se definen como Claves Alternativas.

Debido a lo anterior, existen dos propiedades básicas asociadas a una clave candidata:

− Unicidad: no existen dos tuplas que posean el mismo valor de la clave candidata.

− Minimalidad: no se puede eliminar ningún atributo de la clave candidata sin destruir la unicidad de la clave candidata.

La regla de integridad de las entidades

La regla de integridad de las relaciones dice que: Ningún componente de la clave primaria de una relación base puede aceptar nulos.

5


Recordemos que se entiende como nulos el que no exista información o dato asociado a los componentes es decir, la ausencia de valor.

La justificación de esta regla está en los siguientes puntos:

− Las entidades se identifican de modo único en la realidad, y también deben de poderse identificar en el modelo relacional.

− Dicha identificación es realizada por las claves primarias.

− Si una clave primaria contiene un nulo quiere decir que no se puede aplicar la definición de clave primaria sobre la entidad asociada.

− Por lo tanto, esta entidad no se puede identificar, lo que entra en contradicción con la definición de entidad.

Así pues, la regla también se puede formular como “en una base de datos relacional, no se puede almacenar información sobre algo que no se pueda identificar”.

Las claves primarias compuestas debe de ser no nulas en su totalidad, es decir, ninguno de sus atributos puede ser nulo.

Claves ajenas

Una Clave Ajena es un atributo (o conjunto de atributos) de una relación R2 cuyos valores o son completamente nulos o coinciden que los de la clave primaria de una relación R1 (donde R1 y R2 no tienen porqué ser distintos).

Un valor de clave ajena representa una referencia a la tupla donde se encuentra el valor correspondiente de la clave primaria. Por tanto, el problema de garantizar que la base de datos no incluya valores no válidos de una clave ajena se conoce como el problema de la integridad referencial. La restricción según la cual los valores de una clave ajena determinada deben concordar con los valores de la clave primaria correspondiente se conoce como restricción referencial. La relación que contiene a la clave ajena se conoce como relación referencial y la relación que contiene a la clave primaria correspondiente se denomina relación referida o relación objetivo.

Comentarios:

• Una clave ajena dada y la clave primaria correspondiente deben definirse sobre el mismo dominio.

• La clave ajena no necesita ser un componente de la clave primaria de la relación que la contiene.

• Una relación referida puede ser también una relación referencial respecto de otro conjunto de atributos. (Comentario: desde luego, esto no sucede para el mismo atributo siendo clave ajena y primaria consecutivamente en todas las relaciones, sino que cada relación tendrá una serie de claves ajenas sobre la relación referida, distintas a las claves ajenas de la siguiente referencia).

• Las relaciones R1 y R2 en la definición de clave ajena no son necesariamente distintas. En este caso, podemos hablar de Relación Autorreferencial, donde coinciden la relación referida y la relación referencial.

• Las claves ajenas pueden admitir nulos, a diferencia de las claves primarias.

6


La regla de integridad referencial

Es la segunda regla general de integridad del modelo relacional y dice que: La base de datos no debe contener valores de clave ajena sin concordancia.

Es decir, para cualquier valor no nulo de la clave ajena existe un valor asociado en la clave primaria de la relación objetivo. Básicamente, se trata de justificar que si B hace referencia a A, entonces A debe existir.

Manejo de las claves ajenas (o de la integridad referencial)

Hemos hablado de la integridad referencial como estados posibles de la base de datos, pero no hemos dicho nada sobre el comportamiento que debe tener el SGBD para garantizar la integridad referencial. Como esto no es objeto del modelo relacional en sí, veremos un poco por encima los comportamientos genéricos posibles que nos pueden ser útiles para las prácticas.

Existen dos posibilidades para manejar la integridad referencial: a) impedir que se introduzca información que no garantiza la integridad referencial, o b) permitir la introducción de dicha información y realizar acciones consecuentes para que se mantenga la integridad referencial. Desde luego, esta última opción es la ideal, e incluso es posible implementarla en algunos sistemas, pero en este caso se depende completamente del diseño que se realiza, y se debe tener muy en cuenta como se realiza dicho diseño para cumplir con el objetivo propuesto. Por ejemplo, al intentar borrar un valor que es clave primaria en una tabla y clave ajena en otra, el SGBD tiene dos posibles comportamientos: a) impedir que se pueda borrar dicho valor, o b) borrar todas las entradas en la relación referencial cuyo valor de la clave ajena sea dicho valor de la clave primaria. Esta segunda opción es lo que se conoce como operación en cascada, es decir, que si tratamos de modificar una clave primaria o bien eliminarla cuando está siendo referenciada, la operación se propaga modificando o eliminando las referencias existentes.

1.3. Manipulación

La última parte del modelo relacional hace referencia a la manipulación de la información. Codd propuso dos alternativas para establecer una base formal de lo que corresponde a la manipulación del modelo relacional; el álgebra relacional y el cálculo relacional. La diferencia entre dichas alternativas es que, mientras que el álgebra relacional ofrece un conjunto de operadores que permiten construir una relación que contiene la información buscada en la base de datos, el cálculo relacional solo define la notación que permite describir las propiedades que deben cumplir las tuplas de la relación resultante.

Además, la formulación del cálculo es descriptiva donde la algebraica es prescriptiva, es decir, el cálculo solo plantea el problema mientras que el álgebra proporciona un procedimiento para resolverlo. Si definimos los lenguajes procedimentales como aquellos en el que el usuario da instrucciones al sistema para que realice una secuencia de operaciones de manera que se obtenga el resultado deseado, y los no procedimentales como los que el usuario describe la información que desea obtener sin especificar cómo llegar a obtenerla, entonces, el álgebra relacional se puede decir que es procedimental mientras que el cálculo es no procedimental.

7


Fue Codd quien propuesto por primera vez el concepto de cálculo relacional. En realidad, el álgebra y el cálculo son dos formalismos equivalentes, es decir, para cada expresión del álgebra existe una expresión equivalente en el cálculo, y a la inversa. Esta equivalencia fue demostrada por Codd en su Algoritmo de Reducción.

Dado que ambos formulismos son equivalentes, y debido a la brevedad de este curso, veremos tan solo el álgebra relacional.

2. Transformación de los diagramas E/R en relaciones

El objetivo del diseño lógico es convertir un esquema conceptual en un esquema lógico que se ajuste al sistema de gestión de base de datos a utilizar, definiendo unas claves primarias y ajenas de todas las relaciones y cuyo esquema incluya las reglas de integridad necesarias.

La conversión del diseño conceptual, en forma de esquema E-R, al diseño lógico de modelo relacional se basaba principalmente en los tres principios siguientes:

• Todo tipo de entidad del modelo conceptual se convierte en una relación (tabla).

• Todo tipo de relaciones N:M (muchos a muchos) origina la creación de una nueva relación (tabla).

• Todo tipo de relación 1:N se traduce en una propagación de la clave (se crea una clave ajena) o bien se crea una nueva relación (tabla).

En primer lugar, se observa que de la aplicación de las reglas anteriores, en el paso del diseño conceptual al diseño lógico se pierde información semántica, pues tanto las entidades como las relaciones son convertidas en tablas, sin que exista una diferencia entre las provenientes de entidades o de relaciones. Pero esto no va a afectar para nada la integridad de la base de datos, ya que se deberán definir las restricciones de integridad necesarias para asegurar la conservación de la misma.

Veamos cómo aplicar estas reglas generales a cada caso particular:

Transformación de las entidades

Cada tipo de entidad se debe convertir a una relación base, es decir, será necesario crear una tabla para cada entidad que aparezca en el diagrama E/R.

Transformación de los atributos de las entidades

Cada atributo de una entidad se debe transformar en una columna en la relación a la que ha dado lugar la entidad. Puesto que hay diferentes tipos de atributos, hay que indicar cómo se deben definir cada uno de ellos:

• El o los atributos principales de una entidad (es decir, la clave primaria de la entidad) pasan a ser la clave primaria de la relación. Se debe especificar que no son nulos.

• El resto de atributos pasan a ser columnas de la tabla, pudiendo tomar valores nulos, a no ser que se indique lo contrario.

8


Por ejemplo, la entidad empleado sería: EMPLEADO (DNI, nombre, apellido, salario).

Transformación de las relaciones

Dependiendo del tipo de relación y de la cardinalidad de que se trate, existen diversas formas de transformarlas:

• Relaciones N:M: Se genera una nueva relación que incluye los atributos de la propia relación (si los hay) y las claves primarias de las dos entidades, que forman la clave primaria de la nueva relación.

• Relaciones 1:N: Estas interrelaciones se pueden transformar de dos modos diferentes:

a) Propagar la clave principal de la entidad que tiene cardinalidad máxima 1 a la que tiene N, y hacer desaparecer la relación como tal.

b) Transformarla en una nueva relación como si fuese una de tipo N:M, es decir, incluyendo los atributos de la relación y las claves primarias de las dos entidades. Esta acción sólo es recomendable en los casos en que: 1) cuando es posible que aparezcan muchos nulos porque existen pocos elementos relacionados, 2) cuando se prevé que dicha relación pasará en un futuro a ser de tipo N:M, y 3) cuando la relación tiene atributos propios.

Cuando la cardinalidad mínima de la entidad uno es igual a uno, se suele utilizar la primera opción. En cambio si la cardinalidad mínima fuera cero, se suele utilizar la segunda opción.

• Relaciones 1:1. Este es un caso particular de cualquiera de los dos casos anteriores, por lo que se podrían aplicar las reglas anteriores. De todas formas es recomendable seguir las siguientes reglas:

a) Si la relación es (0,1)(0,1), es mejor crear una relación para evitar el tener muchos nulos como propagación de alguna de las claves a la otra.

b) Si la relación es (0,1)(1,1), es mejor propagar la clave de la entidad (1,1) a la (0,1).

c) Si la relación es (1,1)(1,1) la propagación es indiferente, y se hará atendiendo a los criterios de frecuencia de acceso (consulta, modificación, inserción, etc.) a cada una de las tablas en cuestión.

Transformación de atributos de relaciones

Si la relación se transforma en una tabla, todos sus atributos pasan a ser columnas de la tabla. En el caso en que alguno de los atributos de la relación sea principal, deberá ser incluido como parte de la clave primaria en dicha tabla.

Transformación de relaciones exclusivas

Para soportar relaciones exclusivas debemos definir las restricciones pertinentes en cada caso. Por ejemplo, en el caso en que exista una exclusividad en la edición de un libro

9


por parte de una editorial o de una universidad, estas dos relaciones se resuelven mediante el mecanismo de propagación de la clave, llevando las claves primarias de editorial y universidad a libro. Ya veremos en el tema 5, que tendremos que utilizar entonces la cláusula CHECK de SQL para introducir las restricciones pertinentes.

Transformación de Atributos Compuestos

El modelo relacional no permite representar atributos compuestos, por lo que se busca una alternativa. Transformar los atributos compuestos, como:

• Considerar el atributo compuesto como un atributo simple.

• Eliminar el atributo compuesto y considerar cada uno de sus atributos como atributo simple de la entidad.

Transformación de Entidades/Relaciones Débiles

En general, una entidad débil iba asociada a relaciones 1:M con una participación total por lo que deberemos propagar la clave de la entidad fuerte y además, ésta deberá formar parte de la clave primaria de la entidad débil.

Transformación de tipos y subtipos (Generalización)

Los tipos y subtipos no son objetos que se puedan representar en el modelo relacional estándar. Existen pues, varias posibilidades para su transformación:

• Englobar todos los atributos de una entidad y sus subtipos en una sola relación, añadiendo el atributo que permite distinguir los subtipos. También habrá que especificar las restricciones semánticas adecuadas.

• Crear una relación para el supertipo, y tantas relaciones como subtipos existan. Esta es la mejor opción desde el punto de vista semántico, pero es menos eficiente que la opción anterior.

• Crear sólo relaciones para los subtipos, añadiendo en cada una de ellas los atributos pertenecientes al supertipo.(Usaremos esta opción).

Transformación de la agregación

Se trata de transformar primero el nivel más alto de la agregación (aplicando las reglas adecuadas) y trataremos la relación resultante como si fuera “una nueva entidad a relacionar” con el nivel más bajo (aplicando las normas anteriores).

3. Ejemplo

Retomemos el ejemplo de la biblioteca que usamos en el tema anterior y apliquemos a nuestro diseño conceptual las reglas que acabamos de enumerar.

Aplicando la regla referente a las entidades obtenemos que, como existen seis entidades (autor, libro, ejemplar, tema, idioma y socio) hemos de crear seis relaciones, una por cada entidad, obteniendo las siguientes seis “tablas” con sus correspondientes claves primarias:

10


AUTOR

Codigo_autor Nombre

LIBRO

Codigo_libro Titulo Año

EJEMPLAR

Codigo_ejemplar

IDIOMA

Codigo_idioma Descripción

TEMA

Codigo_tema Descripción

SOCIO

DNI Nombre Telefono

Si aplicamos las reglas referentes a las relaciones, observamos que tenemos solo una relación 1:N (tiene), lo cual nos origina, a priori, la propagación de las claves. La propagación se efectúa desde la tabla de tipo 1 a la tabla de tipo N (dado que en nuestro caso, la relación de tipo 1 no tiene como cardinalidad mínima un cero y por tanto no es necesario crear una nueva tabla). Además, la propagación es “de clave primaria” si la clave primaria de la tabla original a la que se propaga la clave no identifica unívocamente a la entidad (es decir, se trata de una entidad débil), en caso contrario se propaga en forma de clave ajena. Como en nuestro caso tenemos una entidad débil, pasará a ser parte de la clave primaria, o dicho de otro modo, la clave codigo_libro de la tabla LIBRO se propaga a la tabla EJEMPLAR como clave primaria.

AUTOR

Codigo_autor Nombre

LIBRO


EJEMPLAR

Codigo_libro Codigo_ejemplar

IDIOMA


TEMA


SOCIO

DNI Nombre Telefono

Por otra parte, tenemos cuatro relaciones N:M, cada una de las cuales dará lugar a una nueva relación que estará compuesta por las claves primarias de las tablas que relaciona así como por todos aquellos atributos que identifican la relación entre las entidades. De esta forma obtendremos la siguiente relación final:

AUTOR

Codigo_autor Nombre

LIBRO


EJEMPLAR

Codigo_libro Codigo_ejemplar

IDIOMA


TEMA


SOCIO

DNI Nombre Telefono

PRESTA

Codigo_libro Codigo_ejemplar DNI Fecha_prest Fecha_dev

ESCRIBE

Codigo_autor Codigo_libro

TRATA

Codigo_libro Codigo_tema

ESCRITO_EN

Codigo_libro Codigo_idioma

11


4. Álgebra relacional

Como ya se ha comentado, para manipular la información en el modelo relacional, podemos usar el álgebra relacional que consiste en un conjunto de operadores de alto nivel que operan sobre relaciones. Cada uno de esos operadores toma una o dos relaciones como entrada y produce una nueva relación como salida. Originalmente, cuando Codd propuso el modelo relacional definió ocho operadores para el álgebra relacional, divididos en dos grupos de cuatro:

• Los operadores tradicionales de conjuntos: unión, intersección, diferencia y producto cartesiano.

• Los operadores relacionales especiales: restricción (selección), proyección, combinación natural (producto natural) y división.

En la siguiente figura se muestra, de forma gráfica, como operan básicamente cada uno de los operadores del álgebra relacional propuestos por Codd.

Unión Intersección Diferencia

a bc

x y

aabbcc

Producto

xyxyxy

a1a2a3

b1b2b3

b1b2b3

c1c2c3

a1a2a3

b1b2b3

c1c2c3

Combinación

a a a b c

x y z x y

xy

DivisiónProyección Selección

a

Aparte de esta clasificación, los operadores también se pueden dividir en operadores primitivos y operadores derivados según sean esenciales o no.

• Los operadores primitivos son los operadores esenciales que no pueden obtenerse de otros (sin ellos, el álgebra relacional no sería un lenguaje completo).

• Los operadores derivados se pueden obtener aplicando varios de los operadores primitivos. Podríamos prescindir de ellos ya que no aportan nada nuevo, sin embargo, son muy útiles y simplifican muchas operaciones habituales.

Si atendemos al número de operandos de cada operador, los podríamos dividir en:

• Unarios, si el operador tiene una única relación como operando.

• Binarios, si el operador tiene dos relaciones como operandos.

12


Por otra parte, se puede decir que, además de los ocho operadores originales, es posible definir más operadores siempre que tengan una o dos relaciones como operandos y una relación como resultado, y de hecho, así se ha hecho con posterioridad.

Además hay que comentar que, como el resultado de cada una de las operaciones es una relación, es posible utilizar ese resultado de la operación como operando para la siguiente, es decir, es posible escribir expresiones relacionales anidadas.

Si observamos la figura anterior, podemos detectar que se ha descuidado el tratamiento de la distinción entre cabecera y cuerpo de una relación. Esto ha sido intencionado. Evidentemente, toda relación base tendrá una cabecera y un cuerpo, pero ¿qué ocurre con las relaciones no nombradas? A veces será necesario darles un nombre pero lo que es todavía más importante es que la relación resultante tenga un conjunto apropiado de nombre de atributo ya que podría ser el resultado de una expresión anidada en otra más grande, y necesitaremos alguna forma de referirnos a los atributos.

Por tanto, con el único objetivo de garantizar que todas las relaciones resultantes de nuestra álgebra relacional tengan cabeceras apropiadas, definimos la operación de renombrado, cuyo propósito es cambiar el nombre de los atributos dentro de una relación y el operador asignación., para darle nombre a nuestra nueva relación.

Veamos detalladamente los operadores del álgebra relacional con los que trabajaremos.

4.1. Operador asignación relacional y renombrado de atributos

Antes de empezar a definir los operadores propios del álgebra relacional, vamos a introducir una operación auxiliar: la asignación. La operación asignación se utiliza para almacenar el resultado de una consulta (o expresión algebraica) en una nueva relación o para denominar resultados intermedios cuando se desea dividir una única operación compleja en una secuencia de operaciones más simples. Por otra parte, también se emplea para asignar un nuevo nombre a una relación existente (cambiando, por ejemplo, los nombres de sus atributos). El símbolo con el que se suele representar la operación de asignación es una flecha que señala hacia la nueva relación a la que se asignará el resultado de la operación:

RELACION_NUEVA ← O(R)

donde O(R) es el resultado de una o más operaciones algebraicas; aunque también podría aplicarse este operador para almacenar una relación en otra nueva relación con nombre distinto, es decir:

R’ ← R

La operación de renombrado consiste en asignar nuevos nombres a los atributos de una relación (la cual puede ser el resultado de una operación algebraica); el renombrado es una operación necesaria, como veremos más adelante, en ciertos casos en los que intervienen operadores binarios y a veces es preciso cambiar previamente en todo, o en parte, los nombres de los atributos de alguna de las relaciones que actúan como operandos. La forma de llevar a cabo el renombrado de los atributos es realizando una operación de asignación en la cual se especifican los nombres de los atributos de la relación que se encuentra a la izquierda del símbolo de asignación, es decir:

RELACION_NUEVA(A1,A2,…,An) ← O(R)

También en este caso, en lugar de O(R) se puede escribir el nombre de una relación.

13


4.2. Operador (especial) primitivo unario restricción o selección ( σ )

El operador restricción, que al ser unario va a tener como operando una única relación, lo que hace es extraer las tuplas de una relación dada que cumplan una condición especificada (es decir, restringe la relación solo a las tuplas que satisfagan dicha condición o expresión lógica). Hoy en día a esta operación se la conoce más como SELECCIONAR debido a la similitud con otros lenguajes, de ahí que se le suela llamar también al operador, operador selección.

Como condiciones podemos usar cualquiera de los operadores de comparación: < , > , = , ≥ , ≤ , ≠

Además, dichas condiciones se pueden combinar usando los operadores booleanos: AND ( ^ ) y OR ( v ).

La aplicación consecutiva del operador de selección a una relación, ( )( )( )Rcncn 11... σσσ − , es igual a una única operación de restricción con todos las condiciones c1, c2,…, cn, unidas por el operador booleano AND: σc1 v c2 … v cn

Veamos un ejemplo donde aplicamos el operador restricción a la relación PROFESOR quedándonos solo con aquellas tuplas que cumplen la condición de que el profesor pertenece a la categoría de “ayudante”.

σ PROFESOR

NOMBRE CODIGO APELLIDOS

H0001 H0002 H0003 H0004 H0005

Antonio Amparo Isabel José Carlos

García García Pérez Pérez Fernández Fernández Hernández Hernández Martínez Martínez

CATEGORIA

Catedrático Ayudante Titular Ayudante Titular

CODIGO NOMBRE APELLIDOS CATEGORIA

H0002 H0004

Amparo José

Pérez Pérez Hernández Hernández

Ayudante Ayudante

σcategoria=ayudante(PROFESOR)

4.3. Operador (especial) primitivo unario proyección ( ∏ )

El operador proyección extrae los atributos especificados de una relación dada, es decir, la proyección de una relación sobre un subconjunto de sus atributos es una relación definida sobre ellos, eliminando las tuplas duplicadas que hubieran podido resultar; por tanto, se trata de un subconjunto vertical de la relación a la que se aplica el operador.

Por ejemplo, proyectemos solo el atributo categoría de la siguiente relación: σ PROFESOR


H0001 H0002 H0003 H0004 H0005



CATEGORIA

Catedrático Ayudante Titular Ayudante Titular

CATEGORIA

Catedrático Ayudante Titular

∏categoria(PROFESOR)

14


4.4. El operador (tradicional) primitivo binario unión ( U )

Antes de comentar este operador es necesario señalar que los operadores binarios se aplican a dos relaciones y algunos de ellos (unión, diferencia e intersección) exigen que las dos relaciones involucradas sean compatibles en sus esquemas.

Se dice que dos esquemas de relación R1 y R2 son compatibles a efectos de dichos operadores, cuando ambos tienen el mismo número de atributos con igual nombre y están definidos sobre el mismo conjunto de dominios.

Si los nombres de los atributos de las dos relaciones fueran distintos o estuvieran en distinto orden, es decir, no hay correspondencia uno a uno entre los nombres de los atributos de los esquemas de R1 y R2, sería precisa una operación de renombrado.

Por ejemplo, en la siguiente figura tenemos dos relaciones que parecerían compatibles en sus esquemas al estar sus atributos definidos sobre los mismos dominios; sin embargo, los nombres de los atributos no coinciden. Por tanto, se debe proceder a la operación de renombrado de PDI1 para cambiar el atributo trabajo por categoria:

σ PROFESOR


H0001 H0002 H0003

Antonio Amparo Isabel

García GarcíaPérez Pérez Fernández Fernández

CATEGORIA

CatedráticoAyudante Titular

PDI1


H0003 H0004 H0005

Isabel José Carlos

Fernández FernándezHernández Hernández Martínez Martínez

TRABAJO

TitularAyudante Titular

PDI(codigo, nombre, apellidos, categoria) ← PDI1

Pasemos ahora a definir lo que es la unión de dos relaciones R1 y R2 compatibles en su esquema: se trata de una relación definida sobre el mismo esquema de relación y formada por aquellas tuplas que aparecen en cualquiera de las dos relaciones especificadas. Notar que se eliminarán las tuplas duplicadas puesto que se trata de una operación propia de conjuntos.

Usando el ejemplo anterior, veamos como se aplicaría la operación unión. σ PROFESOR


H0001H0002H0003

AntonioAmparoIsabel

García GarcíaPérez PérezFernández Fernández

CATEGORIA

CatedráticoAyudanteTitular

PDI


H0003H0004H0005

IsabelJoséCarlos

Fernández FernándezHernández HernándezMartínez Martínez

CATEGORIA

TitularAyudanteTitular


H0001H0002H0003H0004H0005

AntonioAmparoIsabelJoséCarlos

García GarcíaPérez PérezFernández FernándezHernández HernándezMartínez Martínez

CATEGORIA

CatedráticoAyudanteTitularAyudanteTitular

PROFESOR ∪ PDI

15


4.5. El operador (tradicional) primitivo binario diferencia ( - )

La diferencia (R1 – R2) de dos relaciones R1 y R2 con esquemas compatibles es otra relación definida sobre el mismo esquema de relación y cuya extensión estará constituida por el conjunto de tuplas que pertenezcan a R1 pero no a R2, es decir, construye una relación formada por todas las tuplas de la primera relación que no aparezcan en la segunda de las relaciones especificadas.

Ejemplo de aplicación de la operación diferencia: σ PROFESOR


H0001 H0002 H0003


García García Pérez Pérez Fernández Fernández

CATEGORIA


PDI


H0003H0004 H0005

IsabelJosé Carlos

Fernández Fernández Hernández Hernández Martínez Martínez

CATEGORIA



H0001 H0002

AntonioAmparo

García GarcíaPérez Pérez

CATEGORIA

CatedráticoAyudante

PROFESOR - PDI

4.6. El operador (tradicional) primitivo binario producto cartesiano generalizado ( x )

El producto cartesiano generalizado de dos relaciones especificadas construye una relación que contiene todas las combinaciones posibles de las tuplas, una de cada una de las dos relaciones. Expresado de manera más formal, nos define una relación constituida por tantos atributos como la suma de los atributos de las relaciones iniciales y tantas tuplas como el producto de las tuplas de las relaciones especificadas que se forman concatenando cada tupla de la primera relación con cada una de las tuplas de la segunda. Obsérvese que aquí no se exige que las dos relaciones sean compatibles en sus esquemas, lo que sí exigiremos es que los nombres de los atributos sean diferentes para evitar confusión al combinar las relaciones.

Siguiendo con el ejemplo, y realizando el producto cartesiano generalizado, tenemos:

ASIGNATURA PROFESOR

NOMBRENUMERO

10000 10001 10002

Tratamiento de datosAnálisis estadístico Cálculo numérico


H0001 H0002

Antonio Amparo

García GarcíaPérez Pérez

CATEGORIA

CatedráticoAyudante


H0001 H0001 H0001 H0002 H0002 H0002

Antonio Antonio Antonio Amparo Amparo Amparo

García GarcíaGarcía García García García Pérez Pérez Pérez Pérez Pérez Pérez

CATEGORIA

CatedráticoCatedrático Catedrático Ayudante Ayudante Ayudante

NOMBRE NUMERO

1000010001 10002 10000 10001 10002

Tratamiento de datosAnálisis estadístico Cálculo numérico Tratamiento de datos Análisis estadístico Cálculo numérico

PROFESOR X ASIGNATURA

16


4.7. El operador (especial) derivado binario combinación natural o producto natural ( |X| )

La combinación natural es el caso más simple de combinación (o reunión) y es el único que vamos a tratar en este curso. Lo que pretende es simplificar el proceso cuando unimos varias relaciones y restringimos el resultado a aquellas tuplas donde determinados atributos son iguales.

Diremos que la combinación natural a partir de dos relaciones especificadas construye una relación que contiene todas las posibles combinaciones de tuplas, una de cada una de las dos relaciones, tales que las dos tuplas participantes en una combinación dada satisfagan la siguiente condición especifica: los atributos definidos igual en ambas relaciones tienen además valores iguales. (En la relación resultante, los atributos iguales solo se expresan una vez). Notar que el producto natural es asociativo.

Como ejemplo de aplicación del operador combinación natural tenemos: ASIGNATURAPROFESOR


H0001 H0002 H0003 H0004 H0005



CATEGORIA

CatedráticoAyudante Titular Ayudante Titular

DATOS NUMERO

1000010001 10002

Tratamiento de datos Análisis estadístico Cálculo numérico

PROFESOR

H0001H0001 H0002

CODIGO NOMBRE APELLIDOS CATEGORIA DATOS NUMERO

1000010001 10002

Tratamiento de datos Análisis estadístico Cálculo numérico

H0001 H0001 H0002

AntonioAntonio Amparo

García GarcíaGarcía García Pérez Pérez

CatedráticoCatedrático Ayudante

PROFESOR |X| ASIGNATURA (PROFESOR.CODIGO=ASIGNATURA.PROFESOR)

Como puede observarse, la combinación natural es un producto cartesiano seguido de una restricción (de igualdad) y de una proyección.

4.8. El operador (tradicional) derivado binario intersección ( ∩ )

La intersección de dos relaciones R1 y R2 compatibles en su esquema es otra relación definida sobre el mismo esquema de relación y formada por aquellas tuplas que aparezcan en las dos relaciones especificadas.

Veamos un ejemplo de aplicación del operador intersección. σ PROFESOR


H0001 H0002 H0003


García García Pérez Pérez Fernández Fernández

CATEGORIA


PDI


H0003H0004 H0005

IsabelJosé Carlos

Fernández Fernández Hernández Hernández Martínez Martínez

CATEGORIA



H0003 Isabel Fernández Fernández

CATEGORIA

Titular

PROFESOR n PDI

La intersección se puede definir en función de la diferencia como: R1 ∩ R2 = R1 – (R1 – R2) o también R2 – (R2 – R1)

17


4.9. El operador (especial) derivado binario división ( : )

La división de una relación R1 (dividendo) por otra R2 (divisor) es una relación R (cociente) tal que, al realizarse su combinación con el divisor, todas las tuplas resultantes se encuentran en el dividendo. Es decir, dadas dos relaciones, una binaria y una unaria, construye una relación formada por todos los valores de un atributo de la relación binaria que concuerdan (en el otro atributo) con todos los valores en la relación unaria.

Como ejemplo, veamos todos aquellos profesores que imparten las dos asignaturas con códigos 10000 y 10002.

ASIGNATURAPROFESOR_ASIGNATURA


H0001 H0001 H0002 H0002 H0002 H0003 H0004 H0004 H0005 H0005

Antonio Antonio Amparo Amparo Amparo Isabel José José Carlos Carlos

García GarcíaGarcía García Pérez Pérez Pérez Pérez Pérez Pérez Fernández Fernández Hernández Hernández Hernández Hernández Martínez Martínez Martínez Martínez

CATEGORIA

CatedráticoCatedrático Ayudante Ayudante Ayudante Titular Ayudante Ayudante Titular Titular

ASIGNATURA

10000 10002

ASIGNATURA

1000010001 10000 10001 10002 10003 10002 10003 10000 10002

PROFESOR_ASIGNATURA : ASIGNATURA CODIGO NOMBRE APELLIDOS CATEGORIA

H0002 H0005

AmparoCarlos

Pérez PérezMartínez Martínez

Ayudante Titular

La división se puede expresar en función de la proyección, del producto cartesiano y de la diferencia de la siguiente forma (siendo C el conjunto de atributos de R1 menos R2):

R1 : R2 = ∏C(R1) – ∏C (R2 X ∏C (R1) – R1)

4.10. Operaciones de modificación de la B.D. en álgebra relacional

En las modificaciones de los datos, la operación de asignación es la que va a jugar el papel principal. Si representamos por la letra R a una relación y por E al resultado de una consulta (que nos permitirá seleccionar unas determinadas tuplas), la forma de modificar la información es la siguiente:

Eliminar: R ← R - E

Se borran tuplas enteras, nunca atributos sueltos.

Insertar: R ← R U E R ← R U { (atrib1, atrib2,...)}

Se insertan tuplas enteras, nunca atributos por separado.

Actualizar: δAtributo ← Valor_Atributo_nuevo ( R ) (#)

Permite cambiar el valor de un atributo para un conjunto de tuplas (o una sóla) sin cambiar todos sus atributos. (#) El atributo Atributo de la relación R toma el nuevo valor Valor_Atributo_nuevo

18

TEMA 4. Diseño Lógico de bases de datos relacionales

Documents

Transcript of TEMA 4. Diseño Lógico de bases de datos relacionales