La teoría del Modelo
Relacional se desarrolló hacia el 1970
de la mano de E. Codd, que
propuso también tres lenguajes
de definición y
manipulación de datos basados en el
Álgebra de conjuntos y el
Cálculo de Predicados de Primer
Orden. Desde entonces, el
Modelo Relacional se ha
impuesto claramente sobre
sus inmediatos predecesores, el
Jerárquico y el Red, por
su sencillez y por la aparición de un
lenguaje de
especificación, el SQL (Standard Query
Language), de
fuerte aceptación como lenguaje de
explotación.
Veremos a continuación las
estructuras que definen el
modelo, los operadores
asociados y los mecanismos para
representar restricciones
de integridad.
III1. introducción intuitiva
Se puede decir que
empezamos a hablar de tecnologías de bases de
datos propiamente dichas
con la aparición del modelo relacional. De
hecho, el modelo
jerárquico y el modelo en red, los otros clasificados
dentro del grupo de los
modelos clásicos, no eran considerados como
tales sino que la
aparición del relacional forzó la formalización de esos
dos sistemas de gestión de
ficheros.
Sin duda es el modelo de
datos de más éxito entre los SGBD
comerciales. Su difusión
se basa en la sencillez en la representación de
los datos y en la
aparición de un lenguaje de manipulación de datos
que es considerado como
estándar y cada vez más utilizado.
Los modelos clásicos, el
relacional entre ellos, se considera que están
orientados a registro
(mientras que los semánticos se dice que están
orientados al objeto). No
obstante, de cara al usuario, el modelo
relacional no presenta la
información en registros sino como tablas. La
tabla presenta la
información referente a un concepto en forma de filas,
y las columnas representan
una cierta característica o propiedad del
concepto; los nombres
descriptivos de dichas propiedades están en la
cabecera de la tabla.
No existe otra forma de
representar la información: la única estructura
que ofrece el modelo para
captar cualquier realidad es la tabla. La
información siempre se
almacena en forma de valores explícitos, es
decir, no existen punteros
o mecanismos similares que relacionen la
información sino que
valores iguales en dos columnas de diferentes
tablas indican una posible
relación.
Además, los lenguajes de
manipulación de datos no son
navegacionales, no
implican procesos de recuperación secuencial de
registros, sino que,
simplemente, el usuario le dice al sistema que
condiciones ha de cumplir
la información resultante. Ese resultado
también se presenta en
forma de tabla, o lo que es lo mismo, el
lenguaje es cerrado ya que
operandos y resultado son del mismo tipo
conjunto.
El estándar actual, el
SQL, sufre pocas variaciones de una marca a otra
de SGBD y ha contribuido
también a la alta aceptación del modelo.
III2. concepto de relación
La teoría del Modelo
Relacional se basa en el concepto matemático de
relación,
formalismo en el que se apoya la tabla6. Definiremos los
conceptos necesarios hasta
llegar al de Relación Matemática: dominio
y producto cartesiano. La
relación nos permitirá representar objetos y
restricciones semánticas,
y los operadores utilizarán relaciones como
operandos y darán como
resultado nuevas relaciones.
dominio
Un dominio es un conjunto
de valores escalares, en el sentido de que
son las unidades
semánticas de datos más pequeñas, son valores
simples que no tienen una
estructura interna.
En realidad, hablar de
dominios es hablar de tipos de datos sobre los
que toman valores los
objetos del sistema de información, y es un
concepto clave a la hora
de poder establecer criterios de ordenación o,
simplemente, comparar dos
objetos.
Por otro lado, es evidente
que si definimos un dominio y una cierta
clase de objetos sobre él,
estamos describiendo directamente algunas
de las restricciones semánticas
del sistema de información, en concreto
las que limitan los
valores que puede tomar un objeto.
producto
cartesiano
Dada una colección de
conjuntos D1, D2, ..., Dn , no necesariamente
disjuntos, el producto
cartesiano de los n conjuntos D1 × D2 × ...× Dn es
el conjunto de todas las
posibles n-tuplas < d1, d2, ..., dn >
tales que la
componente i-ésima de la
misma pertenece al i-ésimo conjunto.
D1 × D2 × ...× Dn = { < d1, d2, ..., dn > /
d1 ∈ D1, d2 ∈ D2, ..., dn ∈ Dn }
relación
matemática
R es una Relación
Matemática definida sobre los dominios
D1, D2, ..., Dn si es un
subconjunto del producto cartesiano
D1 × D2 × ...× Dn .
R ⊆ D1 × D2 × ...× Dn
6 Desde un
punto de vista formal, el termino correcto sería relación, sin embargo se
utilizan indistintamente
los términos tabla y relación.
grado de
una relación matemática
A los conjuntos Di se les
denomina dominios. El número de dominios
sobre el que está definida
una Relación Matemática recibe el nombre
de grado de la
relación.
Grado(R) = n.
cardinalidad
de una relación matemática
Asimismo, se denomina cardinalidad
de la relación al número de ntuplas
que contiene R.
Resulta evidente que mientras el grado es
constante, la cardinalidad
de una relación varía en el tiempo (a medida
que se incluyen o eliminan
tuplas de la relación).
De la definición de
Relación Matemática podemos deducir las
siguientes conclusiones:
1. En una Relación
Matemática, por ser un conjunto, no hay tuplas
duplicadas. Es evidente
que el producto cartesiano de los
dominios no produce la
misma tupla dos veces, y la relación es
un subconjunto de ese
producto cartesiano.
2. Las tuplas, por la
misma razón, no están ordenadas entre sí.
3. La tupla es un conjunto
ordenado de valores (lista de valores) de
forma que el i-ésimo valor
siempre pertenece al i-ésimo dominio.
Supongamos una relación
que agrupe a los ALUMNOS DE
INFORMÁTICA, de los que se
conoce información tal como el número
de
expediente, nombre, titulación, curso y grupo,
que toman valores,
respectivamente, en los siguientes
dominios:
número de expediente ∈ domExp = { 1..
3000 }
dni ∈ domDni = { c / c
es cadena(8) }
nombre ∈ domNom = { c / c
es una cadena(30) }
titulación ∈ domTit = { ‘II’,
‘ITIG’, ‘ITIS’ }
curso ∈ domCur = { 1, 2,
3, 4, 5 }
grupo ∈ domGrp = { ‘A’
.. ‘Z’ }
La relación matemática
ALUMNO sería un conjunto de tuplas cuya
primera componente
pertenecería al primer dominio, domExp, la
segunda al segundo
dominio, etc.:
ALUMNO ⊆ domExp × domDni × domNom × domTit × domCur ×
domGrp
El grado de la relación es
6, y un posible subconjunto de tuplas del
producto cartesiano antes
definido podría ser el mostrado a
continuación, de
cardinalidad 3.
III3. representación de objetos
Una base de datos
representa objetos y conceptos de la vida real. Hay
procesos previos a la
introducción de datos en el ordenador que
implican la identificación
de tales objetos y su diseño para aplicarlos a
un sistema informático
concreto.
Podemos decir que, tras
una fase de investigación en la que se
detectan las necesidades
de información de una determinada
organización o sistema, la
información se estructura en clases de
objetos que pretenden
representar esa realidad particular.
En este punto veremos en
primer lugar, de forma general, cuáles son
los mecanismos a través de
los cuales se llega a esa estructuración
concreta de los datos.
Posteriormente, ya dentro del modelo relacional,
se detallarán las
herramientas y conceptos del mismo que ayudan a
esa representación.
Es importante destacar que
los conceptos que se desarrollan en este
punto no son exclusivos
del modelo relacional sino que, por necesidad
de justificación del
porqué se definen las tablas como se definen, se
exponen ahora.
Como recordaremos en el
tema de modelos de datos, estos conceptos
son generales y aplicables
a cualquier modelo de datos, sean cuales
sean sus herramientas de
representación.
III3.1.mecanismos de abstracción
La realidad, el sistema de
información a representar, tiene demasiados
detalles como para poder
tenerlos todos en cuenta. De hecho, muchos
de ellos son irrelevantes
para nuestro objetivo final, que es administrar
un conjunto de datos que
refleje la problemática de nuestro sistema de
datos. Se hace necesario
obtener una representación que únicamente
abarque los detalles importantes
para nuestros objetivos.
Los esquemas de base de
datos hacen precisamente eso, resumir las
características más
importantes de nuestro sistema de información y
hacerlas comprensibles a
nuestro SGBD. Esos esquemas se apoyan
en un determinado modelo
de datos.
Un modelo de datos es
un conjunto de conceptos y unas reglas de
composición de esos
conceptos que, combinados de alguna forma, son
capaces de representar un
sistema de información, tanto en su parte
estática como dinámica.
Dicho de otra manera, un
lenguaje de descripción de datos, apoyado
en un modelo de datos, nos
permite definir las estructuras de datos que
van a almacenar nuestra
información, las operaciones que se realizan
sobre esas estructuras y
la definición de las restricciones de integridad
que determinan cuales son
los valores válidos en todo momento.
Pensemos, por ejemplo, en
un modelo de datos cuyas herramientas de
representación sean
registros, campos de registro y algunos tipos de
datos, y que queremos
representar el hecho de la matriculación de los
alumnos en ciertas
asignaturas.
Así, la primera tarea a
realizar es seleccionar el conjunto de
características
representativas del sistema y excluir lo irrelevante. En
este proceso de abstracción
identificaremos los objetos importantes,
las relaciones que se dan
entre ellos, las operaciones a realizar, y los
límites de comportamiento
que afectan a todos, tanto datos como
operaciones (restricciones
semánticas o de integridad).
Al modelar una determinada
situación estamos aplicando los siguientes
mecanismos de abstracción:
- Clasificación: definir
un concepto como una clase de objetos
- Agregación: definir una
nueva clase de objetos a partir de otras
clases
- Generalización: definir
subtipos de una clase
clasificación.
Entendemos por
clasificación como la definición de un concepto como
una clase de objetos.
Si observamos los objetos enero,
febrero, marzo, ..., y diciembre,
podemos establecer una
clase de objetos que represente al concepto
MES, que será, por decirlo
de otra manera, un conjunto de objetos (los
meses en sí) agrupados
bajo un mismo epígrafe.
Los nombres de persona se
pueden clasificar como una clase de
objetos que los defina:
NOMBRE = { Alfredo, Antonio, Antonia,
Armando, … }
o, de forma más general:
NOMBRE = { s / s es una cadena de
caracteres de longitud variable}
También, para el D.N.I.:
DNI = { s / s es una cadena de 8 dígitos
}
Resumiendo, la
clasificación tipifica en una clase de objetos un
conjunto de objetos reales
o, desde otro punto de vista, dichos objetos
son miembros_de una
clase de objetos
agregación
La definición de una clase
de objetos a partir de otras ya definidas se
conoce como agregación.
Por ejemplo, la clase PROFESOR se define
a partir de la agregación
de los objetos dni, nombre, y dirección.
Definimos la clase de
objetos como una agregación de sus partes
componentes, (dni es_parte_de
profesor). Un ejemplo un poco más
complejo de agregación
sería el siguiente, que define una clase
IMPARTE, en función de las
clases profesor y asignatura.
Por otro lado, una misma
clase de objetos puede participar en más de
una agregación.
generalización
Este mecanismo nos sirve
para definir subtipos de una clase de
objetos. Pensemos en
COCHES y MOTOS: todos ellos son
VEHÍCULOS, pero aunque la
agregación de matrícula es común a
todos ellos, sólo podemos
hablar de número de puertas en los coches,
mientras que el tipo de
refrigeración del motor es una propiedad
relevante únicamente en
las motocicletas.
Un objeto generalizado es
un objeto definido a partir de dos o más
objetos especializados con
propiedades comunes. Las propiedades del
objeto generalizado serán
las comunes a todos los especializados,
mientras que estos
últimos, además, aportan las suyas que no se
pueden aplicar al resto de
objetos dentro de la generalización.
Decimos que un objeto
especializado es_un objeto generalizado (un
coche es un vehículo).
III3.2.restricciones semánticas
Las restricciones de
integridad hacen referencia a todas aquellas
reglas o normas que
delimitan los valores que pueden tomar las
ocurrencias del esquema, y
que modifican, en un sentido amplio, el
significado
de los conceptos en él recogidos. Estas restricciones
pueden reflejarse
simplemente mediante la utilización de los
mecanismos de abstracción
antes mencionados, o como añadidos no
soportados por tales
representaciones (los nacidos en Alicante tienen
un
descuento del 10% en su declaración de renta). Afectan tanto a las
propiedades estáticas del
sistema de información como a las dinámicas
(las operaciones).
Veremos qué tipo de
restricciones semánticas se aplican a cada uno de
los conceptos que aparecen
en un modelo de datos:
-
restricciones de dominio
-
restricciones de identificación
-
restricciones de correspondencia entre clases
restricciones
de dominio.
Al definir una clase como
una asociación de objetos estamos
determinando cuales son
los valores válidos para la instanciación de
esa clase, es decir,
estamos estableciendo, por definición, el dominio
sobre el que tomará
valores.
restricciones
de identificación.
No existen duplicados
entre los posibles valores de una instanciación
de la clase de objetos
(aún dos hermanos clónicos, siendo
exactamente iguales,
ocupan espacios diferentes y son, a efectos de
identificación, dos
personas diferentes).
restricciones
de correspondencia entre clases.
Tanto la agregación como
la generalización establecen
correspondencias entre las
clases de objetos involucradas.
En la agregación IMPARTE,
un profesor puede impartir varias
asignaturas y una
asignatura ser impartida por varios profesores, y
podemos obligar a que todo
profesor imparta al menos una asignatura.
Estamos estableciendo
restricciones de cardinalidad.
Entendemos como
cardinalidad mínima CardMin(o, a) como el número
de correspondencias mínimo
que se establece entre el objeto o y la
agregación a. De
igual forma, la cardinalidad máxima, CardMax(o, a),
es el máximo de
correspondencias entre la clase de objetos o y la
agregación a.
Por abreviar, utilizaremos
la notación Card(o, a) = (m, M) donde m es la
cardinalidad mínima y M la
máxima.
Siguiendo el mismo ejemplo
las cardinalidades serían:
Card(profesor, imparte) = (1, n)
Card(asignatura, imparte) = (0, n)
Aunque los valores típicos
para la mínima son 0 y 1 y para la máxima 1
y n (n indicaría
que no existe límite) se admiten otros valores si así lo
requiere el sistema de
información a representar. Serían del tipo que un
profesor ha de impartir al
menos 3 asignaturas y/o que el máximo de
asignaturas que puede
impartir son 5.
En las cardinalidades
indicadas arriba estamos representando la
obligatoriedad para todo
profesor de impartir al menos una asignatura,
mientras que una
asignatura pudiera no tener profesor que la
impartiera. Si nos fijamos
en los límites máximos, ninguno de los
objetos de la agregación
tiene restricción alguna.
En esta agregación, la
definición de la clase de objetos agregada se
apoya en otras dos clases
ya definidas. Sería el caso de una
agregación binaria; en
general, hablamos de agregación n-aria cuando
el número de clases
participantes es n.
Sea la agregación
siguiente, que representa que la correspondencia
entre profesor, asignaturas
que imparte y aula donde las imparte, así
como las restricciones de
cardinalidad que se especifican para tal
agregación.
Card(profesor, imparte) =
(1, n)
Card(asignatura, imparte)
= (0, n)
Card(aula, imparte) = (0,
n)
En este caso, la semántica
asociada a la agregación indica que un
profesor imparte una
asignatura en un aula determinada, con la única
profesor aula asignatura
imparte
restricción de que todo
profesor ha de estar asignado a un aula y una
asignatura al menos.
Las restricciones de
integridad que se refieren a las correspondencias
entre clases que se
producen por la generalización se conocen como
propiedades
de cobertura de la generalización.
Si dividimos a las
personas entre varones y hembras todas ellas serán
o varón o hembra pero no
las dos cosas a la vez.
Por contra, de todas las
asignaturas obligatorias de Informática, unas
son compartidas por dos o
más titulaciones (ITIG, ITIS, o II), y toda
asignatura obligatoria
pertenece a alguna titulación.
Si generalizamos a los
pintores y escultores como ARTISTA (un pintor
o un escultor es un artista),
no todos los artistas son de las dos artes
mencionadas, pero un
pintor puede ser al mismo tiempo escultor.
Resumiendo, la
generalización puede ser total o parcial, y disjunta
o
solapada:
total: si toda
ocurrencia del objeto generalizado se corresponde con
una de al menos uno de los
objetos especializados.
parcial: si
alguna ocurrencia del objeto generalizado no tiene su
correspondiente ocurrencia
en uno de los objetos especializados.
disjunta: si una
ocurrencia del objeto generalizado se corresponde,
como máximo, con una y
sólo una ocurrencia de uno de los
objetos especializados.
solapada: si una
ocurrencia del objeto generalizado se corresponde
con ocurrencias de objetos
especializados distintos.
Las generalizaciones
mencionadas tienen las siguientes propiedades
de cobertura:
- PERSONA: total y
disjunta.
- ASIGNATURA OBLIGATORIA
DE INFORMÁTICA: total y
solapada.
- ARTISTA: parcial y
solapada.
III3.3.adaptación del concepto de relación
matemática al modelo relacional.
La relación es la
estructura básica que proporciona el modelo relacional
para representar una
determinada realidad. Es el medio por el que
podemos hacer referencia
en una BD relacional a personas, cosas o
interrelaciones entre esos
objetos o individuos.
No obstante, necesitamos
adaptar el concepto matemático antes
expuesto para la “tarea”
que va a realizar como estructura del modelo
relacional. Veamos cuáles
son esas adaptaciones y como representar
con él los objetos y
relaciones entre objetos de nuestro sistema de
información.
En primer lugar, recalcar
el hecho de que la única referencia a una
componente de una tupla,
en una relación matemática, es su posición
relativa dentro de ella.
En otras palabras, la única información sobre la
“forma” que tiene la
relación son los dominios de los que se extraen los
valores y el orden que
ocupan en el producto cartesiano.
En el contexto del Modelo
Relacional, pretendemos evitar tratar así las
tuplas de la relación,
como listas de valores donde cada componente
se referencia por la
posición que ocupa. Modificaremos, pues, la
definición que se ha dado
de Relación Matemática.
Una relación sobre
los dominios D1, D2, ..., Dn (no
necesariamente
disjuntos) consta de una intensión y una
extensión.
• Intensión: un
conjunto de nombres de atributos distintos
A1, A2, ..., An, cada uno
de ellos asociado a su dominio
correspondiente. También
recibe el nombre de esquema o
cabecera de la relación.
Consta del nombre de la relación y de
los nombres de los
atributos y los dominios asociados, en forma
de pares <
nombreDeAtributo : Dominio >. Por ejemplo:
ALUMNO = { <exp :
domExp>, <nombre : domNom>, <titulación : domTit>,
<curso : domCur>,
<grupo : domGrp> }7
• Extensión: un
conjunto de n-tuplas donde cada tupla es un
conjunto de pares
(nombreDeAtributon: Valor), siendo n el
grado de la relación, uno
por cada atributo del conjunto anterior,
donde Valor siempre es un
valor del dominio asociado a
nombreDeAtributo. Se le
conoce también como cuerpo de la
relación.
T = {
{<exp: 3>,<nombre:
LUISA>,<titulación: ITIS>,<curso: 2>,
<grupo: C>}
{<nombre: PEPE>, <grupo: A>,
<titulación: ITIG>, <exp: 1>,
<curso: 2>}
{<exp: 2>, <titulación:
ITIG>, <curso: 2>, <grupo: A>, <nombre:
ANA>}
7 Aunque
ésta es la notación formal, para abreviar, en adelante utilizaremos la forma
ALUMNO( exp: domExp, nombre
: domNom, titulación : domTit, curso : domCur,
grupo : domGrp )
BD1 2006-2007
40
}
( T es la extensión de ALUMNO )
En la definición del punto
anterior, la relación matemática era
simplemente un conjunto de
tuplas, donde cada valor se movía en el
dominio que le
correspondía por la posición que ocupaba en la tupla.
Ahora una relación
matemática consta de dos conjuntos, el de nombres
de atributo y el de tuplas
de valores.
Fijémonos que ahora no
existe un orden entre los componentes de una
tupla, puesto que siempre
sabemos qué dominio, por ser el asociado al
nombre de atributo, es el
conjunto al que pertenece ese valor.
Disponemos, pues, de dos
formas de describir una Relación
Matemática (según la nueva
definición del concepto): por intensión o
por extensión.
- - por intensión: R { (A1 : D1), (A2 : D2), ...,
(An : Dn) }.
- - por extensión: {{(A1 : vi1), (A2 : vi2), ...,
(An : vin)}} i=1, 2, ..., m.
- ( Grado(R) = n;
Cardinalidad(R) = m )
Así definida la relación,
los componentes de una tupla se referencian
por el nombre del
atributo, no por su posición relativa dentro de ella; no
existe, pues, un orden
dentro de cada tupla para sus componentes.
III3.4.percepción de la relación: la tabla
Una vez familiarizados con
el concepto matemático necesitamos
trasladar el concepto a un
medio “físico” con el que podamos trabajar,
ya sea en papel o en el
ordenador, debemos representar la relación de
alguna manera. La
representación de la idea abstracta de relación
sobre un SGBD relacional
es la tabla.
La tabla se asemeja a una
matriz donde la fila representa una tupla de
la relación matemática, y
la columna los valores de las componente de
cada tupla asociados al
dominio correspondiente.
Decimos que la tabla es la
representación física de la relación
matemática. Sin embargo,
una tabla sugiere unas características que
no tiene la relación:
- En una tabla vemos que
existe un orden entre sus filas. Por tanto,
si podemos diferenciar
cada tupla por el orden que ocupa dentro
de la tabla, es
perfectamente posible tener dos tuplas con los
mismos valores para todos
sus atributos.
- También sugiere un orden
entre las columnas: podemos referirnos
a una componente de una
fila por su nombre o por la posición
dentro de ella.
No obstante, son detalles
de representación que no influyen a la hora
de su tratamiento:
nosotros entenderemos una tabla como una
Relación Matemática, con
todas las características de la definición
antes expuesta.
Así pues, al trasladar el
concepto de Relación Matemática al Modelo
Relacional, nos encontramos
con que los conceptos matemáticos
tienen un equivalente
informal.
Concepto formal
Equivalente informal
relación tabla
atributo columna
tupla fila
grado número de columnas
cardinalidad número de
filas
Por último, mencionar que
si bien la percepción del usuario de la
"forma" de sus
datos es la tabla, nada tiene que ver con su almacenaje
físico. La representación
de los datos en los dispositivos físicos del
ordenador no es en forma
de tablas sino registros estructurados de una
manera más o menos
eficiente (o, en general, cualquier otro método).
La tabla es, por tanto,
una abstracción de su representación física la
cual es desconocida por el
usuario final.
III3.5.abstracciones.
Las clases de objetos se
representan por medio de relaciones (tablas).
Veamos cuál es la mecánica
de definición de esas relaciones.
El proceso de abstracción
de clases de objetos utiliza tres mecanismos
concretos, tal como
mencionamos anteriormente:
• clasificación: La
descripción de dominios y la definición de
atributos que toman valores
en esos dominios.
• agregación: La
definición de relaciones.
• generalización: La
definición de relaciones como subtipos de
otra relación.
Veremos, con ejemplos
sencillos, como trata el modelo relacional estos
mecanismos de abstracción.
Como ya hemos dicho, la clasificación
consiste en la
identificación de objetos y los dominios sobre los que
trabajan.
El esquema de la base de
datos (el conjunto de todos los esquemas de
relación), según las
agregaciones anteriores, sería el siguiente8:
PROFESOR ( dni:domDni,
nombre:domNombre, dirección:domDir )
ASIGNATURA ( código:
domCod, descripción: domNom, créditos:
domCdt )
IMPARTE ( profesor:domDni,
asignatura:domCod )
La simple comparación de
valores entre las relaciones nos permite
saber qué profesores
imparten qué asignaturas, como se puede ver en
las extensiones de las
relaciones que se muestran seguidamente.
Por la estructuración de
las relaciones, sabemos que el vehículo con
matrícula A-0000-AA es un
coche de marca Xeat y modelo Kordoba y
que tiene 5 puertas. El
vehículo A-1111-BB es una moto Susuki Fantom
refrigerada por agua.
Los atributos comunes a
todos los tipos se mantienen en la relación
vehículo, mientras que el
número de puertas únicamente es aplicable a
los coches, como el tipo
de refrigeración sólo lo es para las motos.
Más adelante veremos como
se completan los esquemas de relación
para dotarles de una
semántica adecuada y preservar la integridad de
los datos.
III4.2.restricciones de identificación
Como ya hemos dicho, no
existen dos tuplas iguales en una relación.
Es obvio, pues, que
podemos encontrar un conjunto de atributos que
modelo
relacional
45
por su combinación de
valores nos identifique unívocamente una
determinada tupla de la
relación (o fila de una tabla)9.
Pensemos en una relación
que contenga información sobre
PERSONAS. Parece obvio que
nunca nos encontraremos el caso de
dos personas con el mismo
D.N.I.: si éste es un atributo de la relación,
podremos diferenciar cada
tupla (cada persona) de las demás.
Estamos buscando, pues, un
atributo (o subconjunto de atributos) que
nos permita especificar
una única tupla.
Clave
candidata
Una clave candidata es un
subconjunto de atributos que cumple que
cualquier combinación de
sus valores es única; no existirán dos filas
con valores iguales en las
mismas columnas que constituyen tal
subconjunto. Además, no
debe contener atributos que no sean
relevantes para esa
identificación.
Sea R una relación con
atributos A1, A2, ..., An. Se dice que un
subconjunto de esos
atributos K = { Ai, Aj, ..., Ak } es una clave
candidata
si satisface las dos propiedades siguientes: identificación
única e irreducibilidad.
Identificación
única
No hay dos tuplas en R, Tm y Tn tales
que:
Aim = Ain
Ajm = Ajn
....
Akm =
Akn
Para cada tupla, la
combinación de valores de los atributos que forman
la clave candidata es
única, no se repite para ninguna otra tupla.
K es
irreducible
Ninguno de los atributos
de K puede eliminarse sin que se deje de
cumplir la propiedad
anterior, o lo que es lo mismo, ningún subconjunto
de K puede diferenciar
cada tupla del resto de tuplas de la relación.
Supongamos una relación R
con atributos a, b, c, y d. Si (a,d) es clave
candidata entonces10:
(a) no lo es,
ni (d)
(a, b, d)
no lo es, ni (a, c, d), ni (a, b, c, d)
(b) sí puede
serlo, y (c)
(c, d) sí puede
serlo, y (a, b), (a, c), (b, c)
9En
general, no vamos a diferenciar términos tales como tupla de relación y fila, o
atributo
y columna: véase la
discusión del punto anterior.
10 Téngase en
cuenta que el orden de las columnas no importa: (a, d) es lo mismo que (d,
a).
BD1 2006-2007
46
Sea la relación
SUMINISTRA, representada por la tabla que se muestra
a continuación, que asocia
unos proveedores (representados por su
D.N.I.) con unos artículos
(código de artículo) que el primero vende a
un precio determinado,
dato éste último que se refleja en la columna
que representa al atributo
importe. Veamos ahora cuáles podrían ser
las claves candidatas.
dni numartículo importe
21455855 0001 1.200.000
21455855 0002 500.000
10154123 0001 25.000
14456789 0001 135.500
- { dni } no puede ser
clave candidata porque viola la primera
propiedad: hay dos tuplas
con el valor de dni = 21455855
- Lo mismo ocurre con {
numartículo }.
- Sin embargo { dni,
numartículo } si que posee valores distintos
para cada tupla
(‘21455855,0001’ es distinto de ‘21455855,0002’,
...) y, además, ninguno de
los dos atributos, como hemos dicho,
puede ser clave por
separado. Ésta si sería clave candidata.
- { dni, numa, importe }
no sería clave candidata porque viola la
segunda propiedad: existe
un subconjunto de éste, { dni,
numartículo }, que ya lo
es.
No obstante el ejemplo, no
debe pensarse en la búsqueda de las
claves candidatas a partir
del conjunto de tuplas que contiene la
relación en ese instante,
sino por el concepto al que representan. La
relación ALUMNO puede dar
la casualidad que no contenga ninguna
tupla con el nombre
repetido, pero es obvio que en la realidad es el
número de expediente (exp)
la clave candidata, y no el atributo nombre
que viola el principio de
identificación única.
Toda relación tiene al
menos una clave candidata, ya que el conjunto
de todos sus atributos
siempre cumple la primera propiedad (por la
definición de relación, no
existen tuplas duplicadas), de forma que si
este conjunto no es clave
es porque existe un subconjunto que sí lo es.
Clave
Primaria y Claves Alternativas
Una clave primaria es
una de las claves candidatas. Es la que vamos
a utilizar para
identificar cada tupla de la relación, y es decisión del
analista/diseñador decidir
cual de entre todas, si hay más de una, es la
que va a hacer el papel de
primaria en el sistema. Siempre existirá una
clave primaria puesto que
siempre existe al menos una clave candidata.
Una clave alternativa es
una clave candidata no primaria.
Una consecuencia de la
definición de clave candidata, la identificación
única de cada tupla, es la
conocida como integridad de clave, que
dice que ningún atributo
de una clave candidata puede contener
valores nulos. Si el nulo
significa valor desconocido, parece un
contrasentido que una
clave candidata (o parte de ella) sea nula,
puesto que entonces el
objeto al que queremos identificar nos es
desconocido. Si
permitiéramos nulos en el dni de un empleado que se
modelo
relacional
47
llame Juan, ¿como podemos
diferenciarlo de otro empleado que se
llame de la misma manera?
¿Son la misma persona o son distintas?
¿Cómo podemos almacenar
información de una persona a la que no
conocemos?
Con esto aseguramos que
siempre vamos a poder identificar todas y
cada una de las tuplas de
una determinada relación; no tendría sentido
una clave nula ya que nos
faltaría precisamente la información que la
diferencia de las demás
tuplas11.
Aunque pueda parecerlo, la
definición de las claves primarias y
alternativas no se emplea
en mejorar el rendimiento del sistema a la
hora de recuperar datos de
nuestra BD. Los dos conceptos anteriores
se utilizan, básicamente,
para mantener en las tablas la propiedad de
las Relaciones Matemáticas
de no duplicidad entre sus tuplas, y para
expresar restricciones de
correspondencia entre clases de objetos
también agregadas. En
otras palabras, las claves nos sirven para
representar la semántica
de nuestro esquema conceptual.
No tiene, por tanto, el
sentido de una organización indexada (aún
cuando utilice esta para
implementar los mecanismos de identificación),
por poner un ejemplo, en
un fichero convencional, puesto que
pretendemos dejar al SGBD
las tareas de la administración física de los
datos.
III4.3.restricciones de correspondencia
La agregación y la
generalización no están totalmente soportadas por
el modelo relacional ya
que el modelo carece de recursos para
representar todas las
restricciones de correspondencias entre clases de
este tipo de abstracciones.
No obstante, veremos las herramientas que
nos proporciona la teoría
relacional con respecto a estos mecanismos
de abstracción.
Las claves ajenas sirven
para asociar tuplas de relaciones distintas (o
de una relación consigo
misma). Es un mecanismo utilizado para
expresar agregaciones de
objetos ya agregados.
11 Tradicionalmente,
la integridad de clave se aplicaba únicamente a la clave primaria.
Aunque la bibliografía no
es clara a este respecto, en nuestra opinión parece un
contrasentido no permitir
nulos en la clave primaria pero si en el resto de candidatas,
puesto que toda clave
candidata debería ser capaz de identificar todas, sin excepción,
las tuplas de una relación.
empleado
dni nombre
departamento
código nombre
trabaja_en
BD1 2006-2007
48
Sea el árbol de
agregaciones anterior, donde definimos las
cardinalidades siguientes:
Card(empleado, trabaja_en)
= (0,1)
Card(departamento,
trabaja_en) = (0, n)
¿Cómo podemos expresar,
dentro del modelo relacional, que un
empleado trabaja en un
determinado departamento dentro de una
empresa? Una solución es
anotar, como una característica más del
empleado, cuál es ese
departamento en el que desempeña su labor.
Tal información está
representada por dos relaciones: EMPLEADO y
DEPARTAMENTO, donde se han
definido los atributos necesarios para
cada uno: número de
empleado, nombre, y código de departamento al
que está asignado para la
primera, y código y descripción para la
segunda.
En el modelo relacional,
una clave ajena es un subconjunto de
atributos de una relación
de tal forma que el valor de todos ellos debe
coincidir con el valor de
la clave primaria de una tupla de otra relación,
en el caso de tener algún
valor.
El atributo departamento
de la tabla EMPLEADO actúa como clave
ajena, y referencia, por
su valor en cada tupla, una determinada fila de
la tabla DEPARTAMENTO. Con
este mecanismo de representación
estamos diciendo que el
empleado Antonio, de clave 001, trabaja en el
departamento de Ventas,
lo mismo que Pilar, mientras Susana lo hace
en el de Investigación.
Así, tal y como está
definida la clave ajena podemos deducir (con la
información de que
disponemos acerca de la definición de las tablas)
que un departamento tiene
asignados ninguno o varios empleados, y
que un empleado no
necesariamente está asignado a un departamento
en concreto (el empleado 002
no está asignado a ningún
departamento, y el
departamento DEP3 no tiene empleados).
Integridad Referencial
Toda clave ajena
perteneciente a una relación S que haga referencia a
la clave primaria de otra
relación R (R y S no han de ser
necesariamente distintas)
debe cumplir que todo valor no nulo en dicha
clave ajena ha de ser
exactamente igual al valor de clave primaria de
alguna tupla de R.
Todo SGBD basado en el
Modelo Relacional que posea mecanismos
de claves ajenas debe
garantizar todas las restricciones de integridad
que se puedan expresar en
él; en particular, la integridad referencial.
EMPLEADO
número
nombre departamento
001 Antonio DEP1 DEPARTAMENTO
002 José código
nombre
003 Susana DEP2 DEP1
Ventas
004 Pilar DEP1 DEP2
Investigación
DEP3 Contabilidad
modelo
relacional
49
En este caso, debe
asegurar que una clave ajena de una relación, o
bien no referencia a nada
(la tupla no está relacionada con otra), o bien
referencia a una tupla
existente en otra relación. Nunca podrá tener
valores que no se
encuentren en la clave primaria de alguna tupla de
otra relación.
¿Cómo puede el SGBD
garantizar la integridad referencial?
Suponiendo que disponga de
toda la información necesaria sobre
claves (primarias y
ajenas, al menos) se encuentra con el problema de
las actualizaciones y
borrados de claves primarias referenciadas por
alguna clave ajena.
Sea el caso de la relación
entre EMPLEADO y DEPARTAMENTO,
antes descrita. El
operador pretende borrar de la tabla
DEPARTAMENTOS la tupla del
“Dpto. de Investigación”. Si así lo
hiciere, en EMPLEADOS, la
tupla de “Susana” tendría su clave ajena
apuntando a un valor de
clave primaria que no existe en
DEPARTAMENTOS, lo que
viola la integridad referencial.
También se puede dar el
caso de que dicho Dpto. de Investigación
cambie de clave primaria y
pase a identificarse como “DEP5”.
Nuevamente, si no tomamos
las medidas oportunas, estaríamos
violando la integridad
referencial. En definitiva, para actualizaciones y
borrados de tuplas
referenciadas por claves ajenas en otras tablas, el
SGBD debe conocer, por las
especificaciones oportunas en el esquema
de la BD, cual de las
siguientes estrategias debe utilizar para garantizar
la restricción:
• Rechazar
• Anular
• Propagar
RECHAZAR
El SGBD sólo permitirá la
operación en caso de que no produzca
problemas. En nuestro
ejemplo no dejaría que realizásemos la
operación.
ANULAR
El SGBD pondrá a nulos
todas las claves ajenas que hagan referencia
a la clave primaria que
sufre la operación. En nuestro ejemplo, si
pretendemos borrar la
tupla de “Investigación”, la tupla de “Susana”
quedaría con el atributo
DEPARTAMENTO a valor nulo.
EMPLEADO DEPARTAMENTO
número
nombre departament
o
código
nombre
1 Antonio DEP1 DEP1 Ventas
2 José DEP3 Contabilidad
3 Susana
4 Pilar DEP1
BD1 2006-2007
50
Supongamos, ahora, que
para actualizar el dpto. de Ventas a un nuevo
código, cambiarlo de
“DEP1” a “DEP4”, adoptamos la misma estrategia.
Obtendríamos:
EMPLEADO
número
nombre departamento
001 Antonio DEPARTAMENTO
002 José código
nombre
003 Susana DEP4 Ventas
004 Pilar DEP2
Investigación
PROPAGAR
También conocida como “en
cascada” porque reproduce la operación
sobre todas las tuplas que
hagan referencia a la clave primaria. Si
partimos, nuevamente, del
ejemplo original y borramos la tupla del dpto.
de Investigación, la tupla
de “Susana” también sería borrada:
EMPLEADO
número
nombre departamento
001 Antonio DEP1
DEPARTAMENTO
002 José código
nombre
004 Pilar DEP1 DEP1 Ventas
DEP3 Contabilidad
Y en el caso de la
actualización antes mencionada de Ventas:
EMPLEADO
número
nombre departamento
001 Antonio DEP4
DEPARTAMENTO
002 José código
nombre
004 Pilar DEP4 DEP4 Ventas
DEP3 Contabilidad
Por ejemplo, en un
lenguaje de definición de datos ficticio podríamos
definir la estructura de
la tabla EMPLEADO como sigue:
CREAR TABLA EMPLEADO (
número carácter(3),
nombre carácter(20), departamento
carácter(4),
CLAVE PRIMARIA ( número
),
CLAVE AJENA (
departamento ) REFERENCIA
DEPARTAMENTO
NULOS PERMITIDOS
BORRADOS EN DEPARTAMENTO
RECHAZAR
ACTUALIZACIONES EN DEPARTAMENTO
PROPAGAR
);
Nótese que para cada una
de las operaciones se han definido métodos
distintos para mantener la
integridad referencial. Además, dicha
definición ha de hacerse
con todas y cada una de las claves ajenas aún
estando en la misma
relación:
modelo
relacional
51
CREAR TABLA SUMINISTRA
(
prov carácter(4),
art carácter(5), precio entero largo,
CLAVE PRIMARIA ( prov,
art ),
CLAVE AJENA ( prov ) REFERENCIA
PROVEEDOR
BORRADOS EN PROVEEDOR RECHAZAR
ACTUALIZACIONES EN PROVEEDOR
PROPAGAR );
CLAVE AJENA ( art ) REFERENCIA
ARTÍCULO
BORRADOS EN ARTÍCULO PROPAGAR
ACTUALIZACIONES EN ARTÍCULO
PROPAGAR );
restricciones de cardinalidad
Las restricciones de
cardinalidad limitan el número de tuplas de varias
relaciones que se pueden
asociar entre sí.
La representación de las
siguientes restricciones de cardinalidad se
hace mediante la
definición apropiada de claves ajenas, tantas como
sean necesarias, y de la
definición de claves primarias. Más que saber
cómo traducir un esquema
conceptual (en el modelo de datos que sea)
a un esquema lógico
relacional, interesa comprender cómo, mediante
tablas y claves, se puede
“simular” una relación entre entidades.
Card(E1, R) = ( 0, n )
Card(E2, R) = ( 0, 1 )
La forma de representar
estas cardinalidades entre E1 y E2 es definir
una tabla para cada objeto
y añadir una columna a la tabla E2 que
actúe como clave ajena
hacia la tabla E1:
E1 (A : domA, B : domB, C
: domC)
Clave Primaria: A
E2 (D : domD, E : domE, aE1
: domA)
Clave Primaria: D
Clave
Ajena: aE1 →
E1
Este es el mecanismo utilizado
para relacionar EMPLEADO y
DEPARTAMENTO en un ejemplo
anterior.
E1
A B
E2
C D
R
BD1 2006-2007
52
El número de columnas que
son clave ajena debe coincidir con el
número de columnas de la
clave primaria de la tabla con la que se
relaciona y, además, coincidir
en dominios para poder compararlas.
Una clave ajena, en
principio, no es una clave candidata dentro de la
tabla en la que se define,
y por lo tanto admite, en principio, duplicados
y valores nulos. Por eso
podíamos tener empleados que no estuvieran
asignados a ningún
departamento, y varios empleados con el mismo
valor de código de
departamento en la columna que actúa como clave
ajena.
Es importante, también,
darse cuenta de que se respetan las
cardinalidades mínimas. En
concreto, existen departamentos que no
están asociados a ningún
empleado, y el hecho ya comentado de
empleados sin
departamento.
Card(E1, R) = ( 0, n )
Card(E2, R) = ( 1, 1 )
La representación es la
misma que en el caso anterior pero obligando a
que la clave ajena tenga
siempre valor (que sea de Valor No Nulo):
E1 (A : domA, B : domB, C
: domC)
Clave Primaria: A
E2 (D : domD, E : domE, aE1
: domA)
Clave Primaria: D
Clave Ajena: aE1 → E1 VNN
Este sería el caso, aplicándolo
a la agregación TRABAJA_EN, en el
que todos los empleados,
sin excepción, están asignados a un
departamento.
Card(E1, R) = ( 0, n )
Card(E2, R) = ( 0, n )
En este caso, se define
una tercera tabla con un número de columnas
igual a la suma del número
de columnas que son clave primaria de las
entidades relacionadas.
E1 (A : domA, B : domB, C
: domC)
Clave Primaria: A
E2 (D : domD, E : domE)
Clave Primaria: D
R (aE1 :
domA, aE2 : domD)
Clave Primaria: (aE1, aE2)
Clave Ajena: aE1 → E1
Clave Ajena: aE2 → E2
Éste es el caso de la
relación SUMINISTRA, suponiendo que existieran
dos tablas más, PROVEEDOR
y ARTÍCULO, donde la clave primaria
de la primera es el D.N.I.
del vendedor y el código de artículo la de la
segunda.
Es evidente que las parejas
(dni, numartículo) no se repiten nunca: un
vendedor no vende un mismo
artículo a dos precios distintos. Sin
embargo, si nos fijamos en
las claves ajenas, como tales, el proveedor
21455855 aparece
dos veces en su columna, y lo mismo ocurre para el
artículo 0001.
Las cardinalidades mínimas
se respetan, ya que puede haber
vendedores de la tabla
PROVEEDOR, o piezas de PIEZA, que no
aparezcan referenciados en
la tabla SUMINISTRA.
modelo
relacional
53
Card(E1, R) = ( 0, 1 )
Card(E2, R) = ( 0, 1 )
En este caso, también se
define una tercera tabla, pero una de las
claves ajenas actúa ahora
como primaria y la otra como alternativa.
E1 (A : domA, B : domB, C
: domC)
Clave Primaria: A
E2 (D : domD, E : domE)
Clave Primaria: D
R (aE1 :
domA, aE2 : domD)
Clave Primaria: aE1
Clave Alternativa: aE2
Clave Ajena: aE1 → E1
Clave Ajena: aE2 → E2
Pensemos, por ejemplo, en
una agregación SER_JEFE_DE entre
EMPLEADO y DEPARTAMENTO en
la que uno de los empleados es el
director de un único
departamento, y todo departamento, a su vez, tiene
un único jefe.
Veamos ahora los casos con
cardinalidad mínima en uno o los dos
objetos:
Card(E1, R) = ( 0, 1 )
Card(E2, R) = ( 1, 1 )
E1 (A : domA, B : domB, C
: domC)
Clave Primaria: A
E2 (D : domD, E : domE, aE1
: domA)
Clave Primaria: D
Clave Alternativa: aE1
Clave Ajena: aE1 → E1
Card(E1, R) = ( 1, 1 )
Card(E2, R) = ( 1, 1 )
R (A : domA, B :
domB, C : domC, D : domD, E : domE)
Clave Primaria: A
Clave Alternativa: D
Sin embargo, el modelo
relacional no es capaz de representar todas las
restricciones de
cardinalidad, como puedan ser, entre otras, las
siguientes12:
Card(E1, R) = ( 0, n )
Card(E2, R) = ( 1, n )
Card(E1, R) = ( 1, n )
Card(E2, R) = ( 0, 1 )
Card(E1, R) = ( 2, n )
Card(E2, R) = ( 0, 3 )
12 No es
exactamente cierto, lo que ocurre es que ciertas representaciones que pretendan
resolver estas
restricciones de cardinalidad introducen redundancia o facilitan la
inconsistencia de la base
de datos. La correcta interpretación de esta afirmación se da
en el tema de Teoría de la
Normalización.
BD1 2006-2007
54
Un caso particular de
restricción de cardinalidad es el siguiente:
E1 (A : domA, B : domB, C
: domC)
Clave Primaria: A
E2 (aE1 :
domA, D : domD, E : domE)
Clave Primaria: (aE1, D)
Clave Ajena: aE1 → E1
Es el caso, por ejemplo,
de calles que pertenecen a distintas
localidades. La Avda.
de la Constitución, con tal denominación, se
encuentra en varias
poblaciones, pero no es la misma avenida la de
Elda que la de
Monóvar: aún llamándose igual, son dos objetos
diferentes físicamente. El
problema está en que el nombre de la calle
no es clave candidata, y
debe apoyarse en el nombre de la población
para distinguirse de las
otras calles de nuestra base de datos. Ahora
éstas se denominan,
respectivamente, <Avda. de la Constitución, Elda>
y <Avenida de la
Constitución, Monóvar>13. Teniendo esto en cuenta,
pese a lo que pudiera
pensarse por la declaración de la clave primaria
de E2, las cardinalidades
de ambos objetos en la agregación que los
asocia son:
Card(E1, R) = ( 0, n )
Card(E2, R) = ( 1, 1 )
Según el ejemplo, E1 se
correspondería con la población y E2 con la
calle. Como se puede ver,
es fácil distinguir este tipo de agregación por
la definición de una clave
primaria que, en parte y no totalmente, es al
mismo tiempo clave ajena
hacia otra relación. Cuando una clave
primaria es enteramente
una clave ajena estamos ante una
generalización, como se
desarrolla a continuación.
generalización y propiedades de cobertura
La generalización se
representa, en el modelo relacional, mediante la
utilización de una clave
ajena que es, al mismo tiempo, clave primaria
de la relación.
VEHÍCULO (matrícula :
domMat, marca : domMarca, modelo : domMod)
Clave primaria: matrícula
COCHE (mat : domMat,
puertas :
domPp)
Clave Primaria: mat
Clave Ajena: mat → VEHÍCULO
MOTO (mat : domMat,
refrigeración : domRfr)
Clave Primaria: mat
Clave Ajena: mat → VEHÍCULO
En el modelo relacional no
podemos representar las propiedades de
cobertura de la
generalización. En realidad sería más propio decir que
únicamente podemos reflejar
generalizaciones parciales y solapadas,
13 Claramente,
se trata de un ejemplo; no hemos comprobado que tal avenida se encuentre en
dichas poblaciones.
modelo
relacional
55
puesto que no existe
ningún método para las otras combinaciones de características
No hay comentarios:
Publicar un comentario