Adapting to what?

seguiremos teniendo almacenada la restricción de exclusividad de la condición 1.

La primera condición se aplica tanto a las claves como a las superclaves, mientras que la segunda sólo a las claves. Por ejemplo, considere la relación ESTUDIANTEde la Figura 5.1. El conjunto de atributo {Dni} es una clave de ESTUDIANTEporque dos tuplas de estudiantes distintas no pueden tener el mismo valor para el Dni.8

Cualquier conjunto de atributos que incluya el Dni(por ejemplo, {Dni, Nombre, Edad} es una superclave. Sin embargo, la superclave {Dni, Nombre, Edad} no es una clave de ESTUDIANTEporque la eliminación del

Nombre,la Edad, o ambas, del conjunto aun no deja una superclave. En general, cualquier superclave forma- da a partir de un único atributo es también una clave. Una clave con múltiples atributos debe exigir todos ellos para mantener la condición de exclusividad.

El valor de un atributo clave puede usarse para identificar de forma única cada tupla en la relación. Por ejem- plo, el Dni30561243 identifica de forma inequívoca la tupla correspondiente a Benjamín Bayer en la relación

ESTUDIANTE. Observe que un conjunto de atributos que constituyen una clave son una propiedad del esque- ma de relación; es una restricción que debe mantenerse en cada estado de relación válido del esquema. Una clave está determinada por el significado de los atributos, y la propiedad es fija en el tiempo: debe mantener- se cuando insertemos nuevas tuplas en la relación. Por ejemplo, no podemos, y no debemos, designar el atri- buto Nombrede la relación ESTUDIANTEde la Figura 5.1 como una clave porque es posible que dos estu- diantes con nombres idénticos existieran en algún punto en un estado válido.9

En general, un esquema de relación puede contar con más de una clave. En este caso, cada una de ellas reci- be el nombre de clave candidata. Por ejemplo, la relación COCHEde la Figura 5.4 tiene dos claves candida- tas: NumeroPermisoConduciry NumeroBastidor. Es común designar una de ellas como la clave principal de la relación, y será la que se utilice para identificar las tuplas en la relación. Usamos la convención de que los atributos que forman la clave principal de un esquema de relación están subrayados, tal y como puede verse en la Figura 5.4. Observe que cuando una relación cuenta con varias claves candidatas, la elección de una de ellas como clave principal es algo arbitrario; sin embargo, es preferible elegir una que tenga un solo atributo, o un pequeño número de ellos.

Otra restricción en los atributos especifica si se permiten o no los valores NULL. Por ejemplo, si cada tupla

ESTUDIANTEdebe contar con un valor válido y no nulo para el atributo Nombre, entonces el Nombrede

ESTUDIANTEesta obligado a ser NOT NULL.

5.2.3

Bases de datos relacionales y esquemas de

bases de datos relacionales

Las definiciones y restricciones que hemos visto hasta ahora se aplican a las relaciones individuales y a sus atributos. Una base de datos relacional suele contener muchas relaciones, con tuplas que están relacionadas de diversas formas. En esta sección vamos a definir una base de datos relacional y un esquema del mismo

8 _{Observe que el Dni es también una superclave.}

9 _{A veces se utilizan los nombres como claves, pero entonces se utilizan algunos subterfugios (como la incorporación de un número de}

orden) para distinguir entre dos nombres idénticos.

5.2 Restricciones del modelo relacional y esquemas de bases de datos relacionales 131

Figura 5.4. La relación COCHE, con dos claves candidatas: NumeroPermisoConducir y NumeroBastidor. COCHE

tipo. Un esquema de base de datos relacional S es un conjunto de esquemas de relación S = {R₁, R₂, . . . ,

R_m} y de restricciones de integridad RI. Un estado de base de datos relacional10_{DB de S es un conjunto}

de estado de relación DB = {r₁, r₂, . . . , r_m} en el que cada r_ies un estado de R_i y satisface las restricciones de integridad especificadas en RI. La Figura 5.5 muestra un esquema de base de datos relacional que llama- mos EMPRESA = {EMPLEADO, DEPARTAMENTO, LOCALIZACIONES_DPTO, PROYECTO, TRABAJA_ EN, SUBORDINADO}. Los atributos subrayados representan las claves primarias. La Figura 5.6 muestra un estado de la base de datos que se corresponde con el esquema EMPRESA. Usaremos este esquema y el esta- do de base de datos a lo largo de este capítulo y en los que van del 6 al 9 para el desarrollo de consultas en diferentes lenguajes relacionales. En el sitio web de este libro puede encontrar algunos ejemplos (en inglés) que le servirán para realizar los ejercicios del final de los capítulos.

Cuando nos referimos a una base de datos relacional, incluimos implícitamente tanto su esquema como su estado actual. Un estado de base de datos que no cumple todas sus restricciones de integridad se dice que está en un estado incorrecto, mientras que aquél que sí las cumple está en un estado correcto.

En la Figura 5.5, el atributo NumDpto de DEPARTAMENTOy LOCALIZACIONES_DPTOrepresenta el mismo concepto del mundo real: el número asignado a un departamento. Este mismo concepto recibe el nombre de

Dnoen EMPLEADOy NumDptoProyectoen PROYECTO. Los atributos que representan el mismo concepto del mundo real pueden tener o no los mismos nombres en relaciones diferentes. Por otro lado, los atributos que representan diferentes conceptos pueden tener el mismo nombre en relaciones distintas. Por ejemplo, podríamos haber usado el nombre de atributo Nombretanto para el NombreProyecto de PROYECTOcomo para el NombreDptode DEPARTAMENTO; en este caso, tendríamos dos atributos con el mismo nombre pero que representarían dos conceptos diferentes: nombres de proyecto y de departamento.

En algunas de las primeras versiones del modelo relacional, se presupuso que el mismo concepto del mundo real, cuando era representado por un atributo, debería tener idéntico nombre de atributo en todas las relacio- nes. Esto crea problemas cuando ese concepto se emplea en distintos papeles (significados) dentro de la misma relación. Por ejemplo, el concepto de Documento Nacional de Identidad aparece dos veces en la rela- ción EMPLEADOde la Figura 5.5: una como el DNI del empleado y otra como el del supervisor. Les dimos distintos nombres de atributo (Dniy SuperDni, respectivamente) para distinguirlos.

Cada DBMS relacional debe tener un DDL para la definición del esquema de la base de datos relacional. Los DBMS relacionales actuales utilizan casi en su totalidad SQL para ello. Veremos este lenguaje en las Secciones de la 8.1 a la 8.3.

10 _{Un estado de base de datos relacional suele recibir a veces el nombre de instancia de base de datos. Sin embargo, como ya se comen-}

tó anteriormente, no lo utilizaremos porque se aplica también a las tuplas individuales.

NumeroPermisoConducir NumeroBastidor Marca Modelo Año Texas ABC-739 A69352 Ford Mustang 02 Florida TVP-347 B43696 Oldsmobile Cutlass 05 New Cork MPO-22 X83554 Oldsmobile Delta 01 California 432-TFY C43742 Mercedes 190-D 99 California RSK-629 Y82935 Toyota Camry 04 Texas RSK-629 U028365 Jaguar XJS 04 Capítulo 5 El modelo de datos relacional y las restricciones de una base de datos relacional

132

Figura 5.5. Diagrama del esquema de la base de datos relacional EMPRESA. EMPLEADO DEPARTAMENTO LOCALIZACIONES_DPTO PROYECTO TRABAJA_EN SUBORDINADO

Las restricciones de integridad se especifican en un esquema de base de datos y deben cumplirse en cada esta- do válido de esa base de datos. Además del dominio, la clave y las restricciones NOT NULL, hay otros dos tipos de restricciones que forman parte del modelo relacional: la integridad de entidad y la referencial.

5.2.4

Integridad de entidad, integridad referencial y foreign keys

Las restricciones de integridad de entidad declaran que el valor de ninguna clave principal puede ser NULL. Esto se debe a que dicha clave se emplea para identificar tuplas individuales en una relación. Si se permitie- ra este valor, significaría que no se podrían identificar ciertas tuplas.

Por ejemplo, si dos o más tuplas tuvieran NULLen sus claves primarias, no seríamos capaces de diferenciar- las si intentásemos hacer referencia a ellas desde otras relaciones.

Las restricciones de clave y las de integridad de entidad se especifican en relaciones individuales. Las de inte-

gridad referencial están especificadas entre dos relaciones y se utilizan para mantener la consistencia entre

las tuplas de dos relaciones. Informalmente, las restricciones de integridad referencial dicen que una tupla de una relación que hace referencia a otra relación debe hacer referencia a una tupla existente de esa relación. Por ejemplo, en la Figura 5.6, el atributo Dnode EMPLEADOdevuelve el número de departamento en el que trabaja cada empleado; por tanto, su valor en cada tupla EMPLEADOdebe coincidir con el valor NumeroDpto de alguna tupla de la relación DEPARTAMENTO.

Para expresar de un modo más formal la integridad referencial, primero debemos definir el concepto de una

foreign key (clave externa). Las condiciones de una foreign key, dadas más abajo, especifican una restricción

de integridad referencial entre dos esquemas de relación R₁y R₂. Un conjunto de atributos FK en una relación

R₁es una foreign key de R₁que referencia a la relación R₂si satisface las siguientes reglas: