Identifícate o Regístrate

Autor: Carlos Alberto García Chávez
Curso: 4,58/5 (6 opiniones) |11445 alumnos|Fecha publicación: 13/04/2005

V 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

Onum	Calle	Area	Población	Teléfono	Fax
O5	Enmedio, 8	Centro	Castellón	964 201 240	964 201 340
O7	Moyano, s/n	Centro	Castellón	964 215 760	964 215 670
O3	San Miguel, 1		Villarreal	964 520 250	964 520 255
O4	Trafalgar, 23	Grao	Castellón	964 284 440	964 284 420
O2	Cedre, 26		Villarreal	964 525 810	964 252 811

PLANTILLA

Enum	Nombre	Apellido	Dirección	Teléfono	Puesto	Fecha_nac	Salario	DNI	Onum
EL21	Amelia	Pastor	Magallanes, 15	964 284 560	Director	12/10/62	30000	39432212E	O5
			Castellón
EG37	Pedro	Cubedo	Bayarri, 11	964 535 690	Supervisor	24/3/57	18000	38766623X	O3
			Villarreal
EG14	Luis	Collado	Borriol, 35	964 522 230	Administ.	9/5/70	12000	24391223L	O3
			Villarreal
EA9	Rita	Renau	Casalduch, 32	964 257 550	Supervisor	19/5/60	18000	39233190F	O7
			Castellón
EG5	Julio	Prats	Melilla, 23	964 524 590	Director	19/12/50	24000	25644309X	O3
			Villarreal
EL41	Carlos	Baeza	Herrero, 51	964 247 250	Supervisor	29/2/67	18000	39552133T	O5
			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.

Atributo	Nombre del Dominio	Descripción	Definición
Onum	NUM_OFICINA	Posibles valores de número de oficina	3 caracteres;
			rango O1-O99
Calle	NOM_CALLE	Nombres de calles de España	25 caracteres
Area	NOM_AREA	Nombres de áreas de las poblaciones de España	20 caracteres
Población	NOM_POBLACION	Nombres de las poblaciones de España	15 caracteres
Teléfono	NUM_TEL_FAX	Números de teléfono de España	9 caracteres
Fax	NUM_TEL_FAX	Números de teléfono de España	9 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ón definida 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

Onum	Calle	Area	Población	Teléfono	Fax
O5	Enmedio, 8	Centro	Castellón	964 201 240	964 201 340
O7	Moyano, s/n	Centro	Castellón	964 215 760	964 215 670
O3	San Miguel, 1		Villarreal	964 520 250	964 520 255
O4	Trafalgar, 23	Grao	Castellón	964 284 440	964 284 420
O2	Cedre, 26		Villarreal	964 525 810	964 252 811

PLANTILLA

Enum	Nombre	Apellido	Dirección	Teléfono	Puesto	Fecha_nac	Salario	DNI	Onum
EL21	Amelia	Pastor	Magallanes, 15	964 284 560	Director	12/10/62	30000	39432212E	O5
			Castellón
EG37	Pedro	Cubedo	Bayarri, 11	964 535 690	Supervisor	24/3/57	18000	38766623X	O3
			Villarreal
EG14	Luis	Collado	Borriol, 35	964 522 230	Administ.	9/5/70	12000	24391223L	O3
			Villarreal
EA9	Rita	Renau	Casalduch, 32	964 257 550	Supervisor	19/5/60	18000	39233190F	O7
			Castellón
EG5	Julio	Prats	Melilla, 23	964 524 590	Director	19/12/50	24000	25644309X	O3
			Villarreal
EL41	Carlos	Baeza	Herrero, 51	964 247 250	Supervisor	29/2/67	18000	39552133T	O5
			Castellón

INMUEBLE

Inum	Calle	Area	Población	Tipo	Hab	Alquiler	Pnum
IA14	Enmedio, 128	Centro	Castellón	Casa	6	600	P46
IL94	Riu Ebre, 24	Ronda Sur	Castellón	Piso	4	350	P87
IG4	Sorell, 5	Grao	Castellón	Piso	3	300	P40
IG36	Alicante,1		Segorbe	Casa	3	325	P93
IG21	San Francisco, 10		Vinaroz	Piso	5	550	P87
IG16	Capuchinos, 19	Rafalafena	Castellón	Piso	4	400	P93

PROPIETARIO

Pnum	Nombre	Apellido	Dirección	Teléfono
P46	Amparo	Felip	Asensi 24, Castellón	964 230 680
P87	Manuel	Obiol	Av. Libertad 15, Vinaroz	964 450 760
P40	Alberto	Estrada	Av. del Puerto 52, Castellón	964 200 740
P93	Yolanda	Robles	Purísima 4, Segorbe	964 710 430

INQUILINO

Qnum	Nombre	Apellido	Dirección	Teléfono	Tipo	Alquiler
Q76	Juan	Felip	Barceló 47, Castellón	964 282 540	Piso	375
Q56	Ana	Grangel	San Rafael 45, Almazora	964 551 110	Piso	300
Q74	Elena	Abaso	Navarra 76, Castellón	964 205 560	Casa	700
Q62	Alicia	Mori	Alloza 45, Castellón	964 229 580	Piso	550

VISITA

Qnum	Inum	Fecha	Comentario
Q56	IA14	24/11/99	muy pequeño
Q76	IG4	20/10/99	muy lejos
Q56	IG4	26/11/99
Q62	IA14	14/11/99	no tiene salón
Q56	IG36	28/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

Enum	Nombre	Apellido	Dirección	Teléfono	Puesto	Fecha_nac	Salario	DNI	Onum
EL21	Amelia	Pastor	Magallanes, 15	964 284 560	Director	12/10/62	30000	39432212E	O5
			Castellón
EG37	Pedro	Cubedo	Bayarri, 11	964 535 690	Supervisor	24/3/57	18000	38766623X	O3
			Villarreal
EA9	Rita	Renau	Casalduch, 32	964 257 550	Supervisor	19/5/60	18000	39233190F	O7
			Castellón
EG5	Julio	Prats	Melilla, 23	964 524 590	Director	19/12/50	24000	25644309X	O3
			Villarreal
EL41	Carlos	Baeza	Herrero, 51	964 247 250	Supervisor	29/2/67	18000	39552133T	O5
			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

Inum	Calle	Area	Población	Tipo	Hab	Alquiler	Pnum
IL94	Riu Ebre, 24	Ronda Sur	Castellón	Piso	4	350	P87
IG4	Sorell, 5	Grao	Castellón	Piso	3	300	P40
IG36	Alicante,1		Segorbe	Piso	3	325	P93

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 eli

Recibe nuestras novedades

Recibir

Al presionar "Recibir" estás dándote de alta y aceptas las condiciones legales de mailxmail