2.3.1. el modelorelacional

Licenciatura en Documentación: Bases de datos documentais Curso 2011 – 2012

Autor: Juan Ramón López Rodríguez 1

El modelo relacional

El modelo relacional constituye una alternativa para la organización y representación de

la información que se pretende almacenar en una base de datos. Se trata de un modelo

teórico matemático que, además de proporcionarnos los elementos básicos de modelado

(las relaciones), incluye un conjunto de operadores (definidos en forma de un álgebra

relacional) para su manipulación, sin ambigüedad posible.

El carácter formal del modelo relacional hace relativamente sencilla su representación y

gestión por medio de herramientas informáticas. No es casual, pues, que haya sido

elegido como referencia para la construcción de la gran mayoría de los Sistemas de

Gestión de Bases de Datos comerciales disponibles en el mercado; ni tampoco que sea

también habitualmente seleccionado como modelo de referencia para la elaboración del

esquema lógico de una base de datos, como tercer paso de la habitual metodología de

diseño de BDs (después del análisis de requerimientos y la elaboración del esquema

conceptual).

En el modelo relacional se basa en el concepto matemático de relación. En este modelo,

la información se representa en forma de “tablas” o relaciones, donde cada fila de la

tabla se interpreta como una relación ordenada de valores (un conjunto de valores

relacionados entre sí). El siguiente ejemplo presenta una relación que representa al

conjunto de los departamentos de una determinada empresa, y que recoge información

sobre los mismos.

Num Nombre Localidad

D-01 Ventas A Coruña

D-02 I+D Ferrol

Figura 1: relación “Departamentos”

Definiciones

Formalmente, una relación se define como un conjunto de n-tuplas; donde una n-tupla

se define a su vez como un conjunto ordenado de valores atómicos (esto es, no

divisibles ni descomponibles en valores mas “pequeños”.

En el ejemplo 1, la relación mostrada incluye dos 3-tuplas: (‘D-01’, ‘Ventas’, ‘A

Coruña’) y (‘D-02’, ‘I+D’, ‘Ferrol’). Cada tupla incluye información sobre los

departamentos de una determinada empresa con sede en Galicia: el identificador del

departamento dentro de la empresa, su nombre, y la localidad donde tiene su sede. En

cada tupla, los tres valores están relacionados por el hecho de describir todos ellos al

mismo departamento.

Cada relación, vista como una tabla, consta de un conjunto de columnas; cada una de

esas columnas recibe el nombre de atributo. A cada atributo de una relación le

corresponde un nombre, que debe ser único dentro de la relación, y un dominio: el

conjunto de valores válidos para un atributo; o, dicho de otra manera, el conjunto de

valores que cada tupla de la relación puede tomar para ese atributo.

En el caso de la relación de nuestro ejemplo, los atributos de la misma serían Num,

Nombre y Localidad. Cada uno de ellos tendrá un dominio asociado: el conjunto de los



identificadores válidos de departamento (una cadena alfanumérica con formato „D-xx‟),

el conjunto de todos los nombres de departamento válidos (cadenas de texto de

cualquier longitud), y el conjunto de todas los nombres de localidades gallegas (ídem),

respectivamente.

El esquema de una relación es una descripción de su estructura interna (es decir, los

atributos que la componen), en la forma siguiente:

R (A1, ... , An)

…siendo R el nombre de la relación, y A1, ... , An los nombres de sus n atributos. Así, el

esquema de la relación Departamentos sería:

Departamentos (Num, Nombre, Localidad)

Podemos afirmar que el esquema de una relación constituye su intensión, es decir, la

parte invariante de la relación. En nuestro ejemplo, el tipo de información que

reflejaremos sobre los departamentos será siempre la misma: el código, nombre y

localidad de cada uno.

Sin embargo, la información recogida en una relación está expuesta constantemente al

cambio: nuestra empresa puede sufrir reestructuraciones, apareciendo o desapareciendo

departamentos, o viendo estos modificada su sede. Se dice que el conjunto de las tuplas

que conforman una relación constituye su extensión: la parte variable de la relación. De

acuerdo con la notación expresada antes, podemos representar a cada tupla de una

relación R por medio del siguiente formato:

(v1, ... , vn)

siendo v1 el valor de la tupla para el atributo A1, y vn el valor de la tupla para el atributo

An. Por ejemplo (‘D-01’, ‘Ventas’, ‘A Coruña’) sería la tupla correspondiente al

departamento de Ventas en la relación Departamentos.

A partir del esquema de la relación es posible determinar su grado1: el número de

atributos de los que consta. Así, la relación de nuestro ejemplo sería de grado 3.

Finalmente, es preciso revisar en detalle la definición del concepto de relación. Dicha

definición especifica que una relación consiste en un conjunto de tuplas. Eso implica

que no se puede aplicar un orden de ningún tipo a las tuplas de una relación (no están

ordenadas). Eso implica que las dos relaciones que mostramos a continuación son en

realidad la misma relación, presentada de dos maneras diferentes:

Figura 2: La misma relación presentada

con sus tuplas en diferente orden

1 Llegados a este punto, es necesario destacar la importancia de distinguir los conceptos de relación,

atributo y grado del modelo relacional y los de tipo de relación, atributo y grado del modelo entidad-

relación. Pese a la desafortunada coincidencia de terminología, se trata de conceptos diferentes con

diferente significado.

Num Nombre Localidad Num Nombre Localidad

D-01 Ventas A Coruña D-02 I+D Ferrol

D-02 I+D Ferrol D-01 Ventas A Coruña



Nulos

Hasta este punto, hemos presentado el elemento fundamental sobre el que se basa el

modelo relacional: la relación. Hemos visto que las relaciones están constituidas por

tuplas, y que cada tupla contiene información sobre un determinado objeto del mundo

real, proporcionando valores a un conjunto de atributos establecidos en la definición de

la relación.

Desgraciadamente sucede que, en ocasiones, es complicado conocer los valores de esos

atributos para un determinado objeto (para una determinada tupla). Por ejemplo, en el

caso de la relación Departamentos que venimos utilizando como referencia, puede

suceder que un departamento de reciente creación no tenga todavía asociada una sede

definitiva (ver ejemplo 3).



D-02 I+D Ferrol

D-03 Contabilidad ?

Figura 3: relación “Departamentos”

En todos los casos en los que el valor de un atributo para una determinada tupla…

…no se conozca

…no exista el valor / el atributo no sea aplicable

…el modelo relacional permite el uso de un valor especial, no perteneciente a ningún

dominio particular: el valor nulo



D-02 I+D Ferrol

D-03 Contabilidad Nulo

Figura 4: relación “Departamentos”, con el uso de valores nulos

Es necesario indicar que el uso de los valores nulos debe ser evitado en lo posible, ya

que (por motivos cuya explicación va más allá del objetivo de estas notas) suele dar

lugar a problemas a la hora de manipular o acceder a la información.

Restricciones de integridad

Cada tupla de una relación debe proporcionar valores a sus atributos. ¿De cualquier

manera? No. Para garantizar la consistencia y la facilidad de manipulación de la

información representada, existen una serie de reglas que deben ser cumplidas y que son

un elemento constituyente del modelo relacional. A esas reglas de consistencia se las

conoce, en la terminología del modelo, como restricciones de integridad. Podemos

distinguir varios tipos de restricciones:

Restricción de DOMINIO: “Los dominios de los atributos de una relación

deben ser atómicos”

Esta restricción exige que los valores de cualquier tupla de una relación R

correspondientes a los atributos A1, ..., An de R deben ser valores atómicos.

Esto es, esos valores no pueden ser descomponibles en valores más pequeños

o simples. Esta condición pretende garantizar que todas las relaciones

presenten un formato regular, que pueda ser fácilmente manipulable por



medio de un sencillo procedimiento o algoritmo, implementado en la forma

de un programa informático.

En el caso de nuestro ejemplo, estos dos casos no serían válidos:



Ferrol

D-02 I+D Ferrol

Figura 5: relación no válida por uso de valor múltiple

En la figura 5 se muestra un ejemplo de una relación en la que una de sus

tuplas, la correspondiente al departamento de Ventas, presenta un doble valor

para el atributo Localidad. De esa forma se pretende representar el hecho de

que Ventas tiene dos sedes: A Coruña y Ferrol. Este formato viola la

restricción de dominio, ya que rompe la regularidad de la “tabla” (de la

relación). El único formato de representación posible de esa información

sería el siguiente:



D-02 I+D Ferrol

D-01 Ventas Ferrol

Figura 6: relación corregida para ser correcta

En la figura 6 se muestra otro ejemplo en el que ahora el atributo Localidad

se usa para almacenar conjuntamente la sede de cada departamento y el

correspondiente código postal, aun cuando se espera que posteriormente

estos dos elementos de información vayan a necesitar ser accedidos por

separado. Se trata por lo tanto de un atributo compuesto que viola la

restricción de dominio, ya que rompe el modo de acceso regular al valor de

un atributo: no se trata ya de recuperar simplemente al valor (la sede

correspondiente a cada departamento), sino que ahora, en algunos casos, es

necesario separar ese valor en sus elementos constituyentes (la localidad y el

código postal).



D-02 I+D 15528 Ferrol

Figura 7: relación no válida por uso de valor compuesto

Restricción de CLAVE: “En una relación no puede haber ninguna tupla

repetida”

Ningún conjunto admite, por definición, la existencia de elementos repetidos

en su contenido. Tratándose de un conjunto de tuplas, las relaciones

requieren la misma exigencia.

Que la extensión de una relación no incluya tuplas repetidas, implica que

todas las tuplas que contiene puedan ser diferenciadas entre sí por el valor de

al menos un atributo.

Eso nos lleva al concepto de superclave de una relación: cualquier

subconjunto (propio o no) de atributos de la relación, que nos permita



diferenciar a cualesquiera dos tuplas que formen parte de su extensión a

partir de los valores de las tuplas para esos atributos. Toda relación cuenta

con una o más superclaves. En el peor de los casos, tendremos una

superclave única: aquella formada por el conjunto de todos los atributos de la

relación. En el caso de nuestro ejemplo, serían superclaves los siguientes

conjuntos de atributos:

(Num, Nombre, Localidad)

(Num, Localidad)

(Nombre, Localidad)

No existen (ni pueden existir) dos tuplas en la relación Departamentos para

los que coincidan simultáneamente los valores de número, nombre y

localidad; ni siquiera los valores de número y localidad; o los de nombre y

localidad. Sin embargo, hemos visto que dos tuplas de la relación pueden

coincidir en sus valores de número y nombre (ver Figura 6). Por lo tanto, los

siguientes subconjuntos de atributos no constituyen una superclave de la

relación:

(Num, Nombre)

(Num)

(Nombre)

(Localidad)

Para poder distinguir a dos tuplas cualesquiera de una relación, sería

necesario, en principio, comparar, uno por uno, los valores de todos y cada

uno de sus atributos. Sin embargo, y por cuestiones prácticas, lo ideal sería

seleccionar un subconjunto mínimo de los atributos suficiente para

identificarlas. Llamamos claves candidatas de la relación todas las

superclaves mínimas o no descomponibles, es decir, aquellos conjuntos de

atributos de los que ninguno puede ser eliminado sin provocar que el

conjunto deje de ser una superclave de la relación.

En el caso de nuestro ejemplo, el conjunto (Num, Nombre, Localidad)

contiene a las superclaves (Num, Localidad) y (Nombre, Localidad), y no

sería, por lo tanto, superclave mínima de la relación (si eliminamos Nombre

o Localidad del conjunto, este seguirá siendo clave candidata). Sí lo serían

tanto (Num, Localidad) como (Nombre, Localidad): pueden existir tuplas

diferentes con el mismo número, nombre o localidad (ver Figura 6). Pero

nunca existirán dos tuplas en la relación con el mismo número y localidad

simultáneamente, ni con el mismo nombre y sede.

Todas las claves candidatas son superclaves mínimas, cuyos valores son

suficientes para distinguir a dos tuplas cualesquiera de una relación. A

efectos prácticos, el modelo relacional recomienda seleccionar una sola de

las posibles claves candidatas para ser utilizada cuando sea necesaria: la

escogida será la clave primaria de la relación.

En el ejemplo, podríamos seleccionar entre (Num, Localidad) y (Nombre,

Localidad). Cualquiera de las dos claves candidatas sería una correcta clave

primaria de la relación.

La clave primaria de una relación debe ser indicada en la representación del

esquema de la misma, subrayando los nombres de los atributos que forman

parte de la misma.




Restricción de INTEGRIDAD de ENTIDAD: “Ninguna tupla de una

relación puede tomar valores nulos en los atributos que forman parte de su

clave primaria”

La necesidad de esta restricción es clara: dado que es la clave primaria la que

nos permite distinguir a las tuplas entre sí, los valores correspondientes a la

clave deben ser conocidos en cada tupla para poder diferenciarla.

En la figura 6 presentábamos una posible extensión de la relación, en la que

veíamos que un mismo departamento podía tener sedes en dos o más

localidades. Suponiendo que dichas localidades fuesen desconocidas, la

relación de la Figura 6 presentaría la siguiente extensión:


D-01 Ventas

D-02 I+D Ferrol

D-01 Ventas

Figura 8: relación corregida para ser correcta

Siendo desconocidos los valores de Localidad en ambas tuplas, es imposible

distinguir a una de otra. Se trata por tanto de una relación incorrecta, no

válida, debido a que viola la restricción de integridad de entidad.

Restricciones de INTEGRIDAD REFERENCIAL: “Si una tupla de una

relación R1 hace referencia a una relación R2, debe referirse a una tupla que

exista realmente en R2”.

Este tipo de restricciones permite garantizar la consistencia en el caso de

relaciones que mantengan una cierta vinculación. Por ejemplo, volvamos a

nuestro ejemplo de la empresa. Supongamos que nuestra relación

Departamentos presenta, en un momento dado, la siguiente extensión:



D-02 I+D Ferrol

Figura 9: relación Departamentos

Y que además, contamos también con una relación Empleados que nos

permite mantener información sobre los empleados de nuestra empresa, y

cuya extensión es la que sigue:

NSS Nombre NumD Localidad

1253 Juan D-01 A Coruña

3356 Pedro D-02 Ferrol

9012 María D-03 Narón

Figura 10: relación Empleados

La relación pretende representar el número de seguridad social de cada

empleado (mediante el atributo NSS, que actúa como clave primaria), su

nombre, y todos los datos relativos al departamento en el que trabaja. Para

evitar problemas de redundancia, en lugar de representar todos los datos de

cada departamento, se incluye una referencia a la tupla que le corresponde en

la relación Departamentos. Esa referencia se realiza por medio de los valores

de la clave primaria de la tupla: el número de departamento (NumD) y la



localidad donde tiene su sede (Localidad). Evidentemente, para que la

referencia sea correcta y tengamos acceso a la información sobre el

departamento al que pertenece un empleado, la tupla referenciada debe

existir en la tabla Departamentos.

En el caso del ejemplo, los departamentos referenciados en el caso de los

empleados Juan y Pedro existen realmente. En cambio, no existe ningún

departamento D03, con sede en Narón (al menos, este hecho no está

reflejado en la tabla Departamentos) y, por lo tanto, no es posible averiguar

nada acerca del departamento al que pertenece María (ni siquiera su

nombre). La tupla correspondiente a María viola una restricción de

integridad referencial de Empleados con respecto a Departamentos.

Los atributos NumD y Localidad de Empleados constituyen un ejemplo de

clave foránea: son atributos de la relación Empleados, pero constituyen

también la clave primaria de Departamentos: ese es el motivo de que sean

precisamente ellos los que se usen para referenciar al departamento de cada

empleado.

Dadas dos relaciones R1 y R2, un conjunto de atributos A1...An de R1 se dice

clave foránea de R1 con respecto a R2 si A1...An es también la clave primaria

de R2. Dicho de otra manera, A1...An es una clave foránea de R1 con respecto

a R2 si ese conjunto de atributos figura tanto en el esquema de R1 como en el

de R2; usándose en R2 como clave primaria, y usándose en R1 para

referenciar a tuplas de R2.

Hecha ya la definición de clave foránea, podemos dar ya una definición un

poco más formal de las restricciones de integridad referencial: “Dadas dos

relaciones R1 y R2, los valores que tome cualquier clave foránea de R1 con

respecto a R2 sólo pueden ser valores que correspondan a la clave primaria

de alguna tupla de R2”.

Esquema de una BD relacional

Como decíamos al principio, el modelo relacional es el seleccionado habitualmente

como referencia para la elaboración del esquema lógico de una base de datos. Una base

de datos, desde el punto de vista relacional, está formada por un conjunto de relaciones.

El esquema lógico de una base de datos consistirá, pues, en la unión de los esquemas

de todas las relaciones que componen la base de datos, conjuntamente con todas las

restricciones de integridad que afectan a esas relaciones.

Además, para facilitar la identificación de las claves foráneas en las relaciones que las

incluyan, estas se representarán gráficamente junto con el esquema. Las claves foráneas

se destacan en la representación del esquema conceptual de una base de datos

uniéndolas mediante flechas dirigidas a las claves primarias que representan, tal y como

se muestra en la figura 11.


Empleados (NSS, Nombre, NumD, Localidad)

Figura 11: Esquema lógico de la BD, con representación explícita de las claves foráneas



Bibliografía

- R. Elmasri y S. Navathe. Fundamentos de los Sistemas de Bases de Datos (3ª

edición). Addison-Wesley, 2002.

- A. Silberschatz, H. F. Korth y S. Sudarshan. Fundamentos de Bases de Datos (4ª

edición). McGraw Hill, 2002

2.3.1. el modelorelacional

Documents

Transcript of 2.3.1. el modelorelacional