12.185 cursos gratis
8.406.331 alumnos
Facebook Twitter YouTube
Busca cursos gratis:

Capítulo 4:

 El modelo relacional

 

En este capítulo se presenta el modelo relacional, que es el modelo lógico en el que se basan la mayoría de los SGBD comerciales en uso hoy en día. En primer lugar, se trata la descripción de los principios básicos del modelo relacional: la estructura de datos relacional y las reglas de integridad. A continuación, se presenta un tratamiento detallado del álgebra relacional, que es un conjunto de operaciones para manipular la estructura de datos relacional y especificar consultas de datos. El álgebra relacional es un lenguaje procedural, mientras que el cálculo relacional, que también se estudia en este capítulo, es un lenguaje equivalente no procedural.

 

Introducción

Es una buena justificación para estudiar la teoría que hay tras el modelo relacional, la que da Hernández (1997):

"Muchas disciplinas (y sus metodologías de diseño asociadas) tienen algún tipo de base teórica. Los ingenieros industriales diseñan estructuras utilizando teorías de la física. Los compositores crean sinfonías utilizando conceptos de teoría de la música. La industria del automóvil utiliza teorías de la aerodinámica para diseñar automóviles con menor consumo. La industria aeronáutica utiliza las mismas teorías para diseñar alas de aviones que reduzcan la resistencia al viento.

Estos ejemplos demuestran que la teoría es muy importante. La ventaja principal de la teoría es que hace que las cosas sean predecibles: nos permite predecir qué ocurrirá si realizamos una determinada acción. Por ejemplo, sabemos que si soltamos una piedra, caerá al suelo. Si somos rápidos, podemos apartar nuestros pies del camino de la teoría de la gravedad de Newton. Lo importante es que siempre funciona. Si ponemos una piedra plana encima de otra piedra plana, podemos predecir que se quedarán tal y como las hemos puesto. Esta teoría permite diseñar pirámides, catedrales y casas de ladrillos. Consideremos ahora el ejemplo de una base de datos relacional. Sabemos que si un par de tablas están relacionadas, podemos extraer datos de las dos a la vez, simplemente por el modo en que funciona la teoría de las bases de datos relacionales. Los datos que se saquen de las dos tablas se basarán en los valores coincidentes del campo que ambas tienen en común. Una vez más, nuestras acciones tienen un resultado predecible.

El modelo relacional se basa en dos ramas de las matemáticas: la teoría de conjuntos y la lógica de predicados de primer orden. El hecho de que el modelo relacional esté basado en la teoría de las matemáticas es lo que lo hace tan seguro y robusto. Al mismo tiempo, estas ramas de las matemáticas proporcionan los elementos básicos necesarios para crear una base de datos relacional con una buena estructura, y proporcionan las líneas que se utilizan para formular buenas metodologías de diseño.

Hay quien ofrece una cierta resistencia a estudiar complicados conceptos matemáticos para tan sólo llevar a cabo una tarea bastante concreta. Es habitual escuchar quejas sobre que las teorías matemáticas en las que se basa el modelo relacional y sus metodologías de diseño, no tienen relevancia en el mundo real o que no son prácticas. No es cierto: las matemáticas son básicas en el modelo relacional. Pero, por fortuna, no hay que aprender teoría de conjuntos o lógica de predicados de primer orden para utilizar el modelo relacional. Sería como decir que hay que saber todos los detalles de la aerodinámica para poder conducir un automóvil. Las teorías de la aerodinámica ayudan a entender cómo un automóvil puede ahorrar combustible, pero desde luego no son necesarias para manejarlo.

La teoría matemática proporciona la base para el modelo relacional y, por lo tanto, hace que el modelo sea predecible, fiable y seguro. La teoría describe los elementos básicos que se utilizan para crear una base de datos relacional y proporciona las líneas a seguir para construirla. El organizar estos elementos para conseguir el resultado deseado es lo que se denomina diseño."

El modelo relacional

En 1970, el modo en que se veían las bases de datos cambió por completo cuando E. F. Codd introdujo el modelo relacional. En aquellos momentos, el enfoque existente para la estructura de las bases de datos utilizaba punteros físicos (direcciones de disco) para relacionar registros de distintos ficheros. Si, por ejemplo, se quería relacionar un registro con un registro , se debía añadir al registro un campo conteniendo la dirección en disco del registro . Este campo añadido, un puntero físico, siempre señalaría desde el registro al registro . Codd demostró que estas bases de datos limitaban en gran medida los tipos de operaciones que los usuarios podían realizar sobre los datos. Además, estas bases de datos eran muy vulnerables a cambios en el entorno físico. Si se añadían los controladores de un nuevo disco al sistema y los datos se movían de una localización física a otra, se requería una conversión de los ficheros de datos. Estos sistemas se basaban en el modelo de red y el modelo jerárquico, los dos modelos lógicos que constituyeron la primera generación de los SGBD.

El modelo relacional representa la segunda generación de los SGBD. En él, todos los datos están estructurados a nivel lógico como tablas formadas por filas y columnas, aunque a nivel físico pueden tener una estructura completamente distinta. Un punto fuerte del modelo relacional es la sencillez de su estructura lógica. Pero detrás de esa simple estructura hay un fundamento teórico importante del que carecen los SGBD de la primera generación, lo que constituye otro punto a su favor.

Dada la popularidad del modelo relacional, muchos sistemas de la primera generación se han modificado para proporcionar una interfaz de usuario relacional, con independencia del modelo lógico que soportan (de red o jerárquico). Por ejemplo, el sistema de red IDMS ha evolucionado a IDMS/R e IDMS/SQL, ofreciendo una visión relacional de los datos.

En los últimos años, se han propuesto algunas extensiones al modelo relacional para capturar mejor el significado de los datos, para disponer de los conceptos de la orientación a objetos y para disponer de capacidad deductiva.

El modelo relacional, como todo modelo de datos, tiene que ver con tres aspectos de los datos:

·        Estructura de datos.

·        Integridad de datos.

·        Manejo de datos.

Estructura de datos relacional

En este apartado se presenta la estructura de datos del modelo relacional: la relación

Relaciones

 

Definiciones informales

El modelo relacional se basa en el concepto matemático de relación, que gráficamente se representa mediante una tabla. Codd, que era un experto matemático, utilizó una terminología perteneciente a las matemáticas, en concreto de la teoría de conjuntos y de la lógica de predicados.

Una relación es una tabla con columnas y filas. Un SGBD sólo necesita que el usuario pueda percibir la base de datos como un conjunto de tablas. Esta percepción sólo se aplica a la estructura lógica de la base de datos (en el nivel externo y conceptual de la arquitectura de tres niveles ANSI-SPARC). No se aplica a la estructura física de la base de datos, que se puede implementar con distintas estructuras de almacenamiento.

Un atributo es el nombre de una columna de una relación. En el modelo relacional, las relaciones se utilizan para almacenar información sobre los objetos que se representan en la base de datos. Una relación se representa gráficamente como una tabla bidimensional en la que las filas corresponden a registros individuales y las columnas corresponden a los campos o atributos de esos registros. Los atributos pueden aparecer en la relación en cualquier orden.

Por ejemplo, la información de las oficinas de la empresa inmobiliaria se representa mediante la relación OFICINA, que tiene columnas para los atributos Onum (número de oficina), Calle, Area, Población, Teléfono y Fax. La información sobre la plantilla se representa mediante la relación PLANTILLA, que tiene columnas para los atributos Enum (número de empleado), Nombre, Apellido, Dirección, Teléfono, Puesto, Fecha_nac, Salario, DNI, Onum (número de la oficina a la que pertenece el empleado). A continuación se muestra una instancia de la relación OFICINA y una instancia de la relación PLANTILLA. Como se puede observar, cada columna contiene valores de un solo atributo. Por ejemplo, la columna Onum sólo contiene números de oficinas que existen.

OFICINA

OnumCalleAreaPoblaciónTeléfonoFax   
O5Enmedio, 8CentroCastellón964 201 240964 201 340   
O7Moyano, s/nCentroCastellón964 215 760964 215 670   
O3San Miguel, 1 Villarreal964 520 250964 520 255   
O4Trafalgar, 23GraoCastellón964 284 440964 284 420   
O2Cedre, 26 Villarreal964 525 810964 252 811   

PLANTILLA

EnumNombreApellidoDirecciónTeléfonoPuestoFecha_nacSalarioDNIOnum
EL21AmeliaPastorMagallanes, 15964 284 560Director12/10/623000039432212EO5
   Castellón      
EG37PedroCubedoBayarri, 11964 535 690Supervisor24/3/571800038766623XO3
   Villarreal      
EG14LuisColladoBorriol, 35964 522 230Administ.9/5/701200024391223LO3
   Villarreal      
EA9RitaRenauCasalduch, 32964 257 550Supervisor19/5/601800039233190FO7
   Castellón      
EG5JulioPratsMelilla, 23964 524 590Director19/12/502400025644309XO3
   Villarreal      
EL41CarlosBaezaHerrero, 51964 247 250Supervisor29/2/671800039552133TO5
   Castellón      

Un dominio es el conjunto de valores legales de uno o varios atributos. Los dominios constituyen una poderosa característica del modelo relacional. Cada atributo de una base de datos relacional se define sobre un dominio, pudiendo haber varios atributos definidos sobre el mismo dominio. La siguiente tabla muestra los dominios de los atributos de la relación OFICINA. Nótese que en esta relación hay dos atributos que están definidos sobre el mismo dominio, Teléfono y Fax.

AtributoNombre del DominioDescripciónDefinición
OnumNUM_OFICINAPosibles valores de número de oficina3 caracteres;
   rango O1-O99
CalleNOM_CALLENombres de calles de España25 caracteres
AreaNOM_AREANombres de áreas de las poblaciones de España20 caracteres
PoblaciónNOM_POBLACIONNombres de las poblaciones de España15 caracteres
TeléfonoNUM_TEL_FAXNúmeros de teléfono de España9 caracteres
FaxNUM_TEL_FAXNúmeros de teléfono de España9 caracteres

El concepto de dominio es importante porque permite que el usuario defina, en un lugar común, el significado y la fuente de los valores que los atributos pueden tomar. Esto hace que haya más información disponible para el sistema cuando éste va a ejecutar una operación relacional, de modo que las operaciones que son semánticamente incorrectas, se pueden evitar. Por ejemplo, no tiene sentido comparar el nombre de una calle con un número de teléfono, aunque los dos atributos sean cadenas de caracteres. Sin embargo, el importe mensual del alquiler de un inmueble no estará definido sobre el mismo dominio que el número de meses que dura el alquiler, pero sí tiene sentido multiplicar los valores de ambos dominios para averiguar el importe total al que asciende el alquiler. Los SGBD relacionales no ofrecen un soporte completo de los dominios ya que su implementación es extremadamente compleja.

Una tupla es una fila de una relación. Los elementos de una relación son las tuplas o filas de la tabla. En la relación OFICINA, cada tupla tiene seis valores, uno para cada atributo. Las tuplas de una relación no siguen ningún orden.

El grado de una relación es el número de atributos que contiene. La relación OFICINA es de grado seis porque tiene seis atributos. Esto quiere decir que cada fila de la tabla es una tupla con seis valores. El grado de una relación no cambia con frecuencia.

La cardinalidad de una relación es el número de tuplas que contiene. Ya que en las relaciones se van insertando y borrando tuplas a menudo, la cardinalidad de las mismas varía constantemente.

Una base de datos relacional es un conjunto de relaciones normalizadas.

Definiciones formales

Una relacióndefinida sobre un conjunto de dominios consta de:

·        Cabecera: conjunto fijo de pares atributo:dominio

 


donde cada atributo corresponde a un único dominio y todos los son distintos, es decir, no hay dos atributos que se llamen igual. El grado de la relación es .

·        Cuerpo: conjunto variable de tuplas. Cada tupla es un conjunto de pares atributo:valor:

 


con , donde es la cardinalidad de la relación . En cada par se tiene que .

La relación OFICINA tiene la siguiente cabecera:

{(Onum:NUM_OFICINA), (Calle:NOM_CALLE), (Area:NOM_AREA),
(Población:NOM_POBLACION), (Teléfono:NUM_TEL_FAX), (Fax:NUM_TEL_FAX)}.

Siendo la siguiente una de sus tuplas:

{(Onum:O5), (Calle:Enmedio,8), (Area:Centro),
(Población:Castellón), (Teléfono:964 201 240), (Fax:964 201 340)}.

Este conjunto de pares no está ordenado, por lo que esta tupla y la siguiente, son la misma:

{(Calle:Enmedio,8), (Fax:964 201 340), (Población:Castellón),
(Onum:O5), (Teléfono:964 201 240), (Area:Centro)}

Gráficamente se suelen representar las relaciones mediante tablas. Los nombres de las columnas corresponden a los nombres de los atributos y las filas son cada una de las tuplas de la relación. Los valores que aparecen en cada una de las columnas pertenecen al conjunto de valores del dominio sobre el que está definido el atributo correspondiente.

Propiedades de las relaciones

Las relaciones tienen las siguientes características:

·        Cada relación tiene un nombre y éste es distinto del nombre de todas las demás.

·        Los valores de los atributos son atómicos: en cada tupla, cada atributo toma un solo valor. Se dice que las relaciones están normalizadas.

·        No hay dos atributos que se llamen igual.

·        El orden de los atributos no importa: los atributos no están ordenados.

·        Cada tupla es distinta de las demás: no hay tuplas duplicadas.

·        El orden de las tuplas no importa: las tuplas no están ordenadas.

Tipos de relaciones

En un SGBD relacional pueden existir varios tipos de relaciones, aunque no todos manejan todos los tipos.

·        Relaciones base. Son relaciones reales que tienen nombre y forman parte directa de la base de datos almacenada (son autónomas).

·        Vistas. También denominadas relaciones virtuales, son relaciones con nombre y derivadas: se representan mediante su definición en términos de otras relaciones con nombre, no poseen datos almacenados propios.

·        Instantáneas. Son relaciones con nombre y derivadas. Pero a diferencia de las vistas, son reales, no virtuales: están representadas no sólo por su definición en términos de otras relaciones con nombre, sino también por sus propios datos almacenados. Son relaciones de sólo de lectura y se refrescan periódicamente.

·        Resultados de consultas. Son las relaciones resultantes de alguna consulta especificada. Pueden o no tener nombre y no persisten en la base de datos.

·        Resultados intermedios. Son las relaciones que contienen los resultados de las subconsultas. Normalmente no tienen nombre y tampoco persisten en la base de datos.

·        Resultados temporales. Son relaciones con nombre, similares a las relaciones base o a las instantáneas, pero la diferencia es que se destruyen automáticamente en algún momento apropiado.

Claves

Ya que en una relación no hay tuplas repetidas, éstas se pueden distinguir unas de otras, es decir, se pueden identificar de modo único. La forma de identificarlas es mediante los valores de sus atributos.

Una superclave es un atributo o un conjunto de atributos que identifican de modo único las tuplas de una relación.

Una clave candidata es una superclave en la que ninguno de sus subconjuntos es una superclave de la relación. El atributo o conjunto de atributos de la relación es una clave candidata para si y sólo si satisface las siguientes propiedades:

·        Unicidad: nunca hay dos tuplas en la relación con el mismo valor de .

·        Irreducibilidad (minimalidad): ningún subconjunto de tiene la propiedad de unicidad, es decir, no se pueden eliminar componentes de sin destruir la unicidad.

Cuando una clave candidata está formada por más de un atributo, se dice que es una clave compuesta. Una relación puede tener varias claves candidatas. Por ejemplo, en la relación OFICINA, el atributo Población no es una clave candidata ya que puede haber varias oficinas en una misma población. Sin embargo, ya que la empresa asigna un código único a cada oficina, el atributo Onum sí es una clave candidata de la relación OFICINA. También son claves candidatas de esta relación los atributos Teléfono y Fax.

En la base de datos de la inmobiliaria hay una relación denominada VISITA que contiene información sobre las visitas que los clientes han realizado a los inmuebles. Esta relación contiene el número del cliente Qnum, el número del inmueble Inum, la fecha de la visita Fecha y un comentario opcional. Para un determinado número de cliente Qnum, se pueden encontrar varias visitas a varios inmuebles. Del mismo modo, dado un número de inmueble Inum, puede que haya varios clientes que lo hayan visitado. Por lo tanto, el atributo Qnum no es una clave candidata para la relación VISITA, como tampoco lo es el atributo Inum. Sin embargo, la combinación de los dos atributos sí identifica a una sola tupla, por lo que los dos juntos son una clave candidata de VISITA. Si se desea considerar la posibilidad de que un mismo cliente pueda visitar un mismo inmueble en varias ocasiones, habría que incluir el atributo Fecha para identificar las tuplas de modo único (aunque éste no es el caso de la empresa que nos ocupa).

Para identificar las claves candidatas de una relación no hay que fijarse en un estado o instancia de la base de datos. El hecho de que en un momento dado no haya duplicados para un atributo o conjunto de atributos, no garantiza que los duplicados no sean posibles. Sin embargo, la presencia de duplicados en un estado de la base de datos sí es útil para demostrar que cierta combinación de atributos no es una clave candidata. El único modo de identificar las claves candidatas es conociendo el significado real de los atributos, ya que esto permite saber si es posible que aparezcan duplicados. Sólo usando esta información semántica se puede saber con certeza si un conjunto de atributos forman una clave candidata. Por ejemplo, viendo la instancia anterior de la relación PLANTILLA se podría pensar que el atributo Apellido es una clave candidata. Pero ya que este atributo es el apellido de un empleado y es posible que haya dos empleados con el mismo apellido, el atributo no es una clave candidata.

La clave primaria de un relación es aquella clave candidata que se escoge para identificar sus tuplas de modo único. Ya que una relación no tiene tuplas duplicadas, siempre hay una clave candidata y, por lo tanto, la relación siempre tiene clave primaria. En el peor caso, la clave primaria estará formada por todos los atributos de la relación, pero normalmente habrá un pequeño subconjunto de los atributos que haga esta función.

Las claves candidatas que no son escogidas como clave primaria son denominadas claves alternativas. Por ejemplo, la clave primaria de la relación OFICINA es el atributo Onum, siendo Teléfono y Fax dos claves alternativas. En la relación VISITA sólo hay una clave candidata formada por los atributos Qnum e Inum, por lo que esta clave candidata es la clave primaria.

Una clave ajena es un atributo o un conjunto de atributos de una relación cuyos valores coinciden con los valores de la clave primaria de alguna otra relación (puede ser la misma). Las claves ajenas representan relaciones entre datos. El atributo Onum de PLANTILLA relaciona a cada empleado con la oficina a la que pertenece. Este atributo es una clave ajena cuyos valores hacen referencia al atributo Onum, clave primaria de OFICINA. Se dice que un valor de clave ajena representa una referencia a la tupla que contiene el mismo valor en su clave primaria ( tupla referenciada).

Esquema de una base de datos relacional

Una base de datos relacional es un conjunto de relaciones normalizadas. Para representar el esquema de una base de datos relacional se debe dar el nombre de sus relaciones, los atributos de éstas, los dominios sobre los que se definen estos atributos, las claves primarias y las claves ajenas.

El esquema de la base de datos de la empresa inmobiliaria es el siguiente:

OFICINA(Onum, Calle, Area, Población, Teléfono, Fax)
PLANTILLA(Enum, Nombre, Apellido, Dirección, Teléfono, Puesto, Fecha_nac,
 Salario, DNI, Onum)
INMUEBLE(Inum, Calle, Area, Población, Tipo, Hab, Alquiler, Pnum, Enum,
 Onum)
INQUILINO(Qnum, Nombre, Apellido, Dirección, Teléfono, Tipo_pref,
 Alquiler_max)
PROPIETARIO(Pnum, Nombre, Apellido, Dirección, Teléfono)
VISITA(Qnum, Inum, Fecha, Comentario)

En el esquema, los nombres de las relaciones aparecen seguidos de los nombres de los atributos encerrados entre paréntesis. Las claves primarias son los atributos subrayados. Las claves ajenas se representan mediante los siguientes diagramas referenciales.

PLANTILLA OFICINA:Oficina a la que pertenece el empleado.
INMUEBLE PROPIETARIO:Propietario del inmueble.
INMUEBLE PLANTILLA:Empleado encargado del inmueble.
INMUEBLE OFICINA:Oficina a la que pertenece el inmueble.
VISITA INQUILINO:Inquilino que ha visitado el inmueble.
VISITA INMUEBLE:Inmueble que ha sido visitado.

A continuación se muestra un estado (instancia) de la base de datos cuyo esquema se acaba de definir.

OFICINA

OnumCalleAreaPoblaciónTeléfonoFax   
O5Enmedio, 8CentroCastellón964 201 240964 201 340   
O7Moyano, s/nCentroCastellón964 215 760964 215 670   
O3San Miguel, 1 Villarreal964 520 250964 520 255   
O4Trafalgar, 23GraoCastellón964 284 440964 284 420   
O2Cedre, 26 Villarreal964 525 810964 252 811   

PLANTILLA

EnumNombreApellidoDirecciónTeléfonoPuestoFecha_nacSalarioDNIOnum
EL21AmeliaPastorMagallanes, 15964 284 560Director12/10/623000039432212EO5
   Castellón      
EG37PedroCubedoBayarri, 11964 535 690Supervisor24/3/571800038766623XO3
   Villarreal      
EG14LuisColladoBorriol, 35964 522 230Administ.9/5/701200024391223LO3
   Villarreal      
EA9RitaRenauCasalduch, 32964 257 550Supervisor19/5/601800039233190FO7
   Castellón      
EG5JulioPratsMelilla, 23964 524 590Director19/12/502400025644309XO3
   Villarreal      
EL41CarlosBaezaHerrero, 51964 247 250Supervisor29/2/671800039552133TO5
   Castellón      

INMUEBLE

InumCalleAreaPoblaciónTipoHabAlquilerPnum
IA14Enmedio, 128CentroCastellónCasa6600P46
IL94Riu Ebre, 24Ronda SurCastellónPiso4350P87
IG4Sorell, 5GraoCastellónPiso3300P40
IG36Alicante,1 SegorbeCasa3325P93
IG21San Francisco, 10 VinarozPiso5550P87
IG16Capuchinos, 19RafalafenaCastellónPiso4400P93

PROPIETARIO

PnumNombreApellidoDirecciónTeléfono
P46AmparoFelipAsensi 24, Castellón964 230 680
P87ManuelObiolAv. Libertad 15, Vinaroz964 450 760
P40AlbertoEstradaAv. del Puerto 52, Castellón964 200 740
P93YolandaRoblesPurísima 4, Segorbe964 710 430

INQUILINO

QnumNombreApellidoDirecciónTeléfonoTipoAlquiler
Q76JuanFelipBarceló 47, Castellón964 282 540Piso375
Q56AnaGrangelSan Rafael 45, Almazora964 551 110Piso300
Q74ElenaAbasoNavarra 76, Castellón964 205 560Casa700
Q62AliciaMoriAlloza 45, Castellón964 229 580Piso550

VISITA

QnumInumFechaComentario
Q56IA1424/11/99muy pequeño
Q76IG420/10/99muy lejos
Q56IG426/11/99 
Q62IA1414/11/99no tiene salón
Q56IG3628/10/99 

 

Reglas de integridad

Una vez definida la estructura de datos del modelo relacional, pasamos a estudiar las reglas de integridad que los datos almacenados en dicha estructura deben cumplir para garantizar que son correctos.

Al definir cada atributo sobre un dominio se impone una restricción sobre el conjunto de valores permitidos para cada atributo. A este tipo de restricciones se les denomina restricciones de dominios. Hay además dos reglas de integridad muy importantes que son restricciones que se deben cumplir en todas las bases de datos relacionales y en todos sus estados o instancias (las reglas se deben cumplir todo el tiempo). Estas reglas son la regla de integridad de entidades y la regla de integridad referencial. Antes de definirlas, es preciso conocer el concepto de nulo.

Nulos

Cuando en una tupla un atributo es desconocido, se dice que es nulo. Un nulo no representa el valor cero ni la cadena vacía, éstos son valores que tienen significado. El nulo implica ausencia de información, bien porque al insertar la tupla se desconocía el valor del atributo, o bien porque para dicha tupla el atributo no tiene sentido.

Ya que los nulos no son valores, deben tratarse de modo diferente, lo que causa problemas de implementación. De hecho, no todos los SGBD relacionales soportan los nulos.

Regla de integridad de entidades

La primera regla de integridad se aplica a las claves primarias de las relaciones base: ninguno de los atributos que componen la clave primaria puede ser nulo.

Por definición, una clave primaria es un identificador irreducible que se utiliza para identificar de modo único las tuplas. Que es irreducible significa que ningún subconjunto de la clave primaria sirve para identificar las tuplas de modo único. Si se permite que parte de la clave primaria sea nula, se está diciendo que no todos sus atributos son necesarios para distinguir las tuplas, con lo que se contradice la irreducibilidad.

Nótese que esta regla sólo se aplica a las relaciones base y a las claves primarias, no a las claves alternativas.

Regla de integridad referencial

La segunda regla de integridad se aplica a las claves ajenas: si en una relación hay alguna clave ajena, sus valores deben coincidir con valores de la clave primaria a la que hace referencia, o bien, deben ser completamente nulos.

La regla de integridad referencial se enmarca en términos de estados de la base de datos: indica lo que es un estado ilegal, pero no dice cómo puede evitarse. La cuestión es ¿qué hacer si estando en un estado legal, llega una petición para realizar una operación que conduce a un estado ilegal? Existen dos opciones: rechazar la operación, o bien aceptar la operación y realizar operaciones adicionales compensatorias que conduzcan a un estado legal.

Por lo tanto, para cada clave ajena de la base de datos habrá que contestar a tres preguntas:

·        Regla de los nulos: ¿Tiene sentido que la clave ajena acepte nulos?

·        Regla de borrado: ¿Qué ocurre si se intenta borrar la tupla referenciada por la clave ajena?

o        Restringir: no se permite borrar la tupla referenciada.

o        Propagar: se borra la tupla referenciada y se propaga el borrado a las tuplas que la referencian mediante la clave ajena.

o        Anular: se borra la tupla referenciada y las tuplas que la referenciaban ponen a nulo la clave ajena (sólo si acepta nulos).

·        Regla de modificación: ¿Qué ocurre si se intenta modificar el valor de la clave primaria de la tupla referenciada por la clave ajena?

o        Restringir: no se permite modificar el valor de la clave primaria de la tupla referenciada.

o        Propagar: se modifica el valor de la clave primaria de la tupla referenciada y se propaga la modificación a las tuplas que la referencian mediante la clave ajena.

o        Anular: se modifica la tupla referenciada y las tuplas que la referenciaban ponen a nulo la clave ajena (sólo si acepta nulos).

Reglas de negocio

Además de las dos reglas de integridad anteriores, los usuarios o los administradores de la base de datos pueden imponer ciertas restricciones específicas sobre los datos, denominadas reglas de negocio.

Por ejemplo, si en una oficina de la empresa inmobiliaria sólo puede haber hasta veinte empleados, el SGBD debe dar la posibilidad al usuario de definir una regla al respecto y debe hacerla respetar. En este caso, no debería permitir dar de alta un empleado en una oficina que ya tiene los veinte permitidos.

Hoy en día aún existen SGBD relacionales que no permiten definir este tipo de restricciones ni las hacen respetar.

Lenguajes relacionales

La tercera parte de un modelo de datos es la de la manipulación. Son varios los lenguajes utilizados por los SGBD relacionales para manejar las relaciones. Algunos de ellos son procedurales, lo que quiere decir que el usuario dice al sistema exactamente cómo debe manipular los datos. Otros son no procedurales, que significa que el usuario dice qué datos necesita, en lugar de decir cómo deben obtenerse.

En este apartado se presentan el álgebra relacional y el cálculo relacional, definidos por Codd como la base de los lenguajes relacionales. Se puede decir que el álgebra es un lenguaje procedural (de alto nivel), mientras que el cálculo relacional es un lenguaje no procedural. Sin embargo, ambos lenguajes son equivalentes: para cada expresión del álgebra, se puede encontrar una expresión equivalente en el cálculo, y viceversa.

El álgebra relacional (o el cálculo relacional) se utilizan para medir la potencia de los lenguajes relacionales. Si un lenguaje permite obtener cualquier relación que se pueda derivar mediante el álgebra relacional, se dice que es relacionalmente completo. La mayoría de los lenguajes relacionales son relacionalmente completos, pero tienen más potencia que el álgebra o el cálculo porque se les han añadido operadores especiales.

Tanto el álgebra como el cálculo son lenguajes formales no muy "amigables". Pero se deben estudiar porque sirven para ilustrar las operaciones básicas que todo lenguaje de manejo datos debe ofrecer. Además, han sido la base para otros lenguajes relacionales de manejo de datos de más alto nivel.

Álgebra relacional

El álgebra relacional es un lenguaje formal con una serie de operadores que trabajan sobre una o varias relaciones para obtener otra relación resultado, sin que cambien las relaciones originales. Tanto los operandos como los resultados son relaciones, por lo que la salida de una operación puede ser la entrada de otra operación. Esto permite anidar expresiones del álgebra, del mismo modo que se pueden anidar las expresiones aritméticas. A esta propiedad se le denomina clausura: las relaciones son cerradas bajo el álgebra, del mismo modo que los números son cerrados bajo las operaciones aritméticas.

En este apartado se presentan los operadores del álgebra relacional de un modo informal. Las definiciones formales pueden encontrarse en la bibliografía que se comenta al final del capítulo. Primero se describen los ocho operadores originalmente propuestos por Codd y después se estudian algunos operadores adicionales que añaden potencia al lenguaje.

De los ocho operadores, sólo hay cinco que son fundamentales: restricción, proyección, producto cartesiano, unión y diferencia, que permiten realizar la mayoría de las operaciones de obtención de datos. Los operadores no fundamentales son la concatenación (join), la intersección y la división, que se pueden expresar a partir de los cinco operadores fundamentales.

La restricción y la proyección son operaciones unarias porque operan sobre una sola relación. El resto de las operaciones son binarias porque trabajan sobre pares de relaciones. En las definiciones que se presentan a continuación, se supone que R y S son dos relaciones cuyos atributos son A=(a , a , ..., a ) y B=(b , b , ..., b ) respectivamente.

Restricción

: R WHERE condición
La restricción, también denominada selección, opera sobre una sola relación R y da como resultado otra relación cuyas tuplas son las tuplas de R que satisfacen la condición especificada. Esta condición es una comparación en la que aparece al menos un atributo de R, o una combinación booleana de varias de estas comparaciones.

Ejemplo 4.1  Obtener todos los empleados con un salario anual superior a 15.000 euros.

PLANTILLA WHERE salario>15000

EnumNombreApellidoDirecciónTeléfonoPuestoFecha_nacSalarioDNIOnum
EL21AmeliaPastorMagallanes, 15964 284 560Director12/10/623000039432212EO5
   Castellón      
EG37PedroCubedoBayarri, 11964 535 690Supervisor24/3/571800038766623XO3
   Villarreal      
EA9RitaRenauCasalduch, 32964 257 550Supervisor19/5/601800039233190FO7
   Castellón      
EG5JulioPratsMelilla, 23964 524 590Director19/12/502400025644309XO3
   Villarreal      
EL41CarlosBaezaHerrero, 51964 247 250Supervisor29/2/671800039552133TO5
   Castellón      

Ejemplo 4.2   Obtener todos los inmuebles de Castellón con un alquiler mensual de hasta 350 euros.

INMUEBLE WHERE población=`Castellón´ AND alquiler<=350

InumCalleAreaPoblaciónTipoHabAlquilerPnum
IL94Riu Ebre, 24Ronda SurCastellónPiso4350P87
IG4Sorell, 5GraoCastellónPiso3300P40
IG36Alicante,1 SegorbePiso3325P93

Proyección

: R[a , ..., a ]
La proyección opera sobre una sola relación R y da como resultado otra relación que contiene un subconjunto vertical de R, extrayendo los valores de los atributos especificados y eliminando duplicados.

Ejemplo 4.3  Obtener un listado de empleados mostrando su número, nombre, apellido y salario.

PLANTILLA [enum,nombre,apellido,salario]

EnumNombreApellidoSalario
EL21AmeliaPastor30000
EG37PedroCubedo18000
EG14LuisCollado12000
EA9RitaRenau18000
EG5JulioPrats24000
EL41CarlosBaeza18000

Ejemplo 4.4   Obtener los distintos puestos que pueden ocupar los empleados.

PLANTILLA [puesto]

Puesto
Director
Supervisor
Administ.

Producto cartesiano

: R TIMES S
El producto cartesiano obtiene una relación cuyas tuplas están formadas por la concatenación de todas las tuplas de R con todas las tuplas de S.

La restricción y la proyección son operaciones que permiten extraer información de una sola relación. Habrá casos en que sea necesario combinar la información de varias relaciones. El producto cartesiano "multiplica" dos relaciones, definiendo una nueva relación que tiene todos los pares posibles de tuplas de las dos relaciones. Si la relación R tiene tuplas y atributos y la relación S tiene tuplas y atributos, la relación resultado tendrá tuplas y atributos. Ya que es posible que haya atributos con el mismo nombre en las dos relaciones, el nombre de la relación se antepondrá al del atributo en este caso para que los nombres de los atributos sigan siendo únicos en la relación resultado.

Ejemplo 4.5  Obtener los nombres de los inquilinos y los comentarios que éstos han realizado cuando han visto algún inmueble.

INQUILINO[qnum,nombre,apellido] TIMES VISITA[qnum,inum,comentario]

INQUILINO.QnumNombreApellidoVISITA.QnumInumComentario
Q76JuanFelipQ56IA14muy pequeño
Q76JuanFelipQ76IG4muy lejos
Q76JuanFelipQ56IG4 
Q76JuanFelipQ62IA14no tiene salón
Q76JuanFelipQ56IG36 
Q56AnaGrangelQ56IA14muy pequeño
Q56AnaGrangelQ76IG4muy lejos
Q56AnaGrangelQ56IG4 
Q56AnaGrangelQ62IA14no tiene salón
Q56AnaGrangelQ56IG36 
Q74ElenaAbasoQ56IA14muy pequeño
Q74ElenaAbasoQ76IG4muy lejos
Q74ElenaAbasoQ56IG4 
Q74ElenaAbasoQ62IA14no tiene salón
Q74ElenaAbasoQ56IG36 
Q62AliciaMoriQ56IA14muy pequeño
Q62AliciaMoriQ76IG4muy lejos
Q62AliciaMoriQ56IG4 
Q62AliciaMoriQ62IA14no tiene salón
Q62AliciaMoriQ56IG36 

Como se puede observar, la relación resultado contiene más información de la que se necesita. Por ejemplo, la primera tupla tiene distintos números de inquilino: el comentario realizado en la visita no corresponde al inquilino cuyo nombre y apellido se muestra. Para obtener el listado que se pide en el ejemplo, es necesario realizar una restricción para quedarse solamente con las tuplas en donde INQUILINO.Qnum = VISITA.Qnum.

(INQUILINO[qnum,nombre,apellido] TIMES VISITA[qnum,inum,comentario])
WHERE inquilino.qnum=visita.qnum

El resultado de esta operación se muestra a continuación.

INQUILINO.QnumNombreApellidoVISITA.QnumInumComentario
Q76JuanFelipQ76IG4muy lejos
Q56AnaGrangelQ56IA14muy pequeño
Q56AnaGrangelQ56IG4 
Q56AnaGrangelQ56IG36 
Q62AliciaMoriQ62IA14no tiene salón

La combinación del producto cartesiano y la restricción del modo en que se acaba de realizar, se puede reducir a la operación de concatenación ( join) que se presenta más adelante.

Unión

: R UNION S
La unión de dos relaciones R y S, con y tuplas respectivamente, es otra relación que tiene como mucho tuplas siendo éstas las tuplas que se encuentran en R o en S o en ambas relaciones a la vez. Para poder realizar esta operación, R y S deben ser compatibles para la unión.

Se dice que dos relaciones son compatibles para la unión si ambas tienen la misma cabecera, es decir, si tienen el mismo número de atributos y éstos se encuentran definidos sobre los mismos dominios. En muchas ocasiones será necesario realizar proyecciones para hacer que dos relaciones sean compatibles para la unión.

Ejemplo 4.6  Obtener un listado de las áreas en las que hay oficinas o inmuebles para alquilar.

OFICINA[área] UNION INMUEBLE[área]

Area
Centro
Grao
Ronda Sur
Rafalafena

Diferencia

: R MINUS S
La diferencia obtiene una relación que tiene las tuplas que se encuentran en R y no se encuentran en S. Para realizar esta operación, R y S deben ser compatibles para la unión.

Ejemplo 4.7  Obtener un listado de todas las poblaciones en donde hay una oficina y no hay inmuebles para alquilar.

OFICINA[población] MINUS INMUEBLE[población]

Población
Villarreal

Concatenación (Join)

: R JOIN S
La concatenación de dos relaciones R y S obtiene como resultado una relación cuyas tuplas son todas las tuplas de R concatenadas con todas las tuplas de S que en los atributos comunes (que se llaman igual) tienen los mismos valores. Estos atributos comunes aparecen una sola vez en el resultado.

Ejemplo 4.8  Obtener los nombres y los comentarios que los inquilinos han realizado cuando han visto algún inmueble.

INQUILINO JOIN VISITA

Esta expresión obtiene el mismo resultado que la expresión final del ejemplo 4.5, ya que la concatenación es, en realidad, un producto cartesiano y una restricción de igualdad sobre los atributos comunes.

Concatenación externa (Outer-join)

: R JOIN S (+)
La concatenación externa es una concatenación en la que las tuplas de R que no tienen valores en común con ninguna tupla de S, también aparecen en el resultado.

Ejemplo 4.9  Obtener un listado de todos los inmuebles y las visitas que han tenido.

INMUEBLE JOIN VISITA (+)

InumCallePoblaciónQnumFechaComentario
IA14Enmedio, 128CastellónQ5624/11/99muy pequeño
IA14Enmedio, 128CastellónQ6214/11/99no tiene salón
IL94Riu Ebre, 24Castellón   
IG4Sorell, 5CastellónQ7620/10/99muy lejos
IG4Sorell, 5CastellónQ5626/11/99 
IG36Alicante,1SegorbeQ5628/10/99 
IG21San Francisco, 10Vinaroz   
IG16Capuchinos, 19Castellón   

La expresión S (+) JOIN R es equivalente a R JOIN S (+). Cuando en ambas relaciones hay tuplas que no se pueden concate