Bases de datos relacionales

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:
D-01 Ventas
A Coruña
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

Bases de datos relacionales

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Bases de datos relacionales

Similar a Bases de datos relacionales (20)

Más de Ashley Stronghold Witwicky

Más de Ashley Stronghold Witwicky (20)

Último

Último (20)

Bases de datos relacionales