Modelo Relacional
El modelo relacional fue presentado por primera vez por Ted Codd y atrajo la atención
inmediatamente debido a su simplicidad y fundamentación matemática. El modelo utiliza el
concepto de una relación matemática (algo parecido a una tabla de valores) como su bloque de
construcción básico, y tiene su base teórica en la teoría de conjuntos y la lógica de predicado de
primer orden.
2.1 Conceptos del modelo relacional
El modelo relacional representa la base de datos como una colección de relaciones. Informalmente,
cada una de estas relaciones se parece a una tabla. Sin embargo, existen importantes diferentes entre
las relaciones y las tablas, como veremos muy pronto.
Cuando una relación está pensada como una tabla, cada fila representa una colección de valores
relacionados. Anteriormente se presentaron las entidades y relaciones como conceptos para el
modelado de datos reales. En el modelo relacional, cada fila de la tabla representa un hecho que, por
lo general, se corresponde con una instancia de una entidad o de una relación. El nombre de la tabla
y de las columnas se utiliza para ayudar a interpretar el significado de cada uno de los valores de las
filas. Todos los datos de una columna son del mismo tipo de dato.
En la terminología formal del modelo relacional, una fila recibe el nombre de tupla, una cabecera de
columna es un atributo y el nombre de la tabla una relación. El tipo de dato que describe los valores
que pueden aparecer en cada columna está representado por un dominio de posibles valores. Ahora
pasaremos a describir con más detalle todos estos términos.
2.1.1 Esquema de relación
Un esquema de relación R, denotado por R(A1, A2, …, An), está constituido por un nombre de
relación R y una lista de atributos A1, A2, …, An.
ESTUDIANTE(DNI, Nombre, Apellido, FechaNac, Telefono, Direccion)
Un atributo A puede cualificarse con el nombre de la relación R al cual pertenece usando la
notación de punto, R.A: por ejemplo, [Link] o [Link]. Esto es así
porque dos atributos en relaciones diferentes pueden usar el mismo nombre. Sin embargo, todos los
nombres de atributos en una relación particular deben ser distintos.
2.1.2 Dominio de un atributo
El dominio de un atributo es el conjunto de todos los valores posibles que el atributo puede tomar.
El dominio de un atributo Ai se especifica como dom(Ai).
2.1.3 Estado de relación
Un estado de relación r del esquema R(A1, A2, …, An) es un conjunto de n tuplas
r={t1, t2, …, tn} donde cada tupla t es una lista ordenada de n valores v1, v2, …, vn. Cada valor vi
(1 ≤ i ≤ n) es un elemento de dom(Ai) o un valor especial denominado NULL. El i-ésimo valor la
tupla t se corresponde con el atributo Ai.
La siguiente figura muestra un ejemplo de una relación ESTUDIANTE que se corresponde con el
esquema del mismo nombre recién especificado. Cada tupla de la relación representa a un
estudiante en particular.
Mostramos la relación como una tabla en la que cada tupla aparece como una fila y cada atributo
como un encabezamiento de columna que indica la interpretación que habrá que dar a cada uno de
los valores de la misma. Los valores NULL representan atributos cuyos valores no se conocen, o no
existen, para una tupla ESTUDIANTE individual.
Un estado de relación en un momento dado (el estado de relación actual) refleja las tuplas válidas
que representan un estado particular del mundo real. En general, a medida que varía el estado del
mundo real lo hace también la relación, convirtiéndose en otro estado de relación diferente. Sin
embargo, el esquema R es relativamente estático y no cambia salvo en circunstancias excepcionales
(por ejemplo, como resultado de añadir un atributo para representar nueva información que no se
encontraba originalmente en la relación).
2.1.4 Grado de una relación
El grado de una relación es el número de atributos n de la misma.
2.1.5 Cardinalidad de una relación
La cardinalidad de una relación está definida por la cantidad de tuplas que posee la misma.
2.2 Características de las relaciones
La definición anterior de relación implica ciertas características que la hacen diferente de una tabla.
Vamos a ver a continuación algunas de esas características.
2.2.1 Ordenación de tuplas en una relación
Una relación está definida como un conjunto de tuplas. Matemáticamente, los elementos de un
conjunto no guardan un orden entre ellos; por tanto, las tuplas en una relación tampoco la tienen.
En otras palabras, una relación no es sensible al ordenamiento de las tuplas. Sin embargo, cuando
mostramos una relación como una tabla, las filas aparecen con un cierto orden.
En una relación pueden especificarse muchos órdenes. Por ejemplo, las tuplas en la relación
ESTUDIANTE podrían ordenarse lógicamente por Nombre, DNI, Edad o cualquier otro atributo.
La definición de una relación no especifica ningún orden: no hay una preferencia por un orden con
respecto a otro. Cuando se muestra una relación como una tabla, es posible especificar un orden en
las filas.
2.2.2 Ordenación de los valores dentro de una tupla
Según lo anterior, una tupla es una lista ordenada de n valores, por lo que el orden de valores dentro
de una de ellas (y por consiguiente de los atributos de un esquema de relación) es importante. Sin
embargo, a nivel lógico, el orden de los atributos y sus valores no es tan importante mientras se
mantenga la correspondencia entre ellos.
2.2.3 Valores y NULLs en las tuplas
Cada valor en una tupla es un valor atómico, es decir, no es divisible en componentes dentro del
esqueleto del modelo relacional básico. Por tanto, no están permitidos los atributos compuestos ni
multivaluados. Los atributos multivaluados deben representarse en relaciones separadas, mientras
que los compuestos lo están solo por sus atributos de componente simple en el modelo relacional
básico.
Un concepto importante es el de los valores NULL (nulo), que se utilizan para representar los
valores de atributos que pueden ser desconocidos o no ser aplicables a una tupla. Para estos casos,
existe un valor especial llamado NULL. Por ejemplo, algunas tuplas ESTUDIANTE tienen NULL
en sus número de teléfono del trabajo porque no cuentan con una oficina donde localizarlos. Otros
lo tienen en el teléfono particular, presumiblemente porque no cuenten con un terminal en su casa o
no lo conozcan (el valor es desconocido). En general, los valores NULL pueden tener varios
significados, como lo de valor desconocido, valor existente pero no disponible o atributo no
aplicable a esta tupla.
Los valores NULL se originaron por las razones comentadas anteriormente (datos indefinidos,
desconocidos o no presentes en un determinado momento). El significado exacto de un valor NULL
controla la forma en que se comporta durante las operaciones de agregación o comparación
aritmética con otros valores. Por ejemplo, una comparación de dos valores NULL provoca
ambigüedades: si los clientes A y B tienen direcciones NULL, ¿significa esto que ambos la
comparten? Durante el diseño de una base de datos es preferible evitar los valores NULL tanto
como sea posible.
2.2.4 Interpretación (significado) de una relación
Un esquema de relación puede interpretarse como una declaración. Por ejemplo, el esquema de la
relación ESTUDIANTE afirma que, en general, una entidad estudiante tiene un Nombre, un Dni, un
TlfParticular, una Dirección, un TlfTrabajo, una Edad y una Mnc. Cada tupla de la relación puede
ser interpretada entonces como un hecho o una instancia particular de la declaración. Por ejemplo,
la primera tupla de la relación asevera el hecho de que hay un ESTUDIANTE cuyo Nombre es
Benjamín Bayer, su Dni es 305612435, su Edad es 19, etc.
Observe que algunas relaciones pueden representar hechos sobre entidades, mientras que otras
pueden hacerlo sobre relaciones. Por ejemplo, un esquema de relación
ESPECIALIDAD(DniEstudiante, CodDpto) afirma que los estudiantes están especializados en
disciplinas académicas. Una tupla en esta relación une un estudiante con su especialidad. Por tanto,
el modelo relacional representa hechos sobre entidades y relaciones uniformemente como
relaciones. Esto puede comprometer a veces la comprensibilidad porque se tiene que adivinar si una
relación representa una entidad o una relación.
2.3 Restricciones del modelo relacional
En una base de datos relacional, existirán por lo general muchas relaciones, y las tuplas de las
mismas estarán relacionadas de muy diferentes formas. El estado de toda la base de datos se
corresponderá con los estados de todas sus relaciones en un momento de tiempo concreto.
Generalmente, existen muchas restricciones, o constraints, en los valores de un estado de base de
datos. Estas restricciones están derivadas de las reglas del minimundo que dicha base de datos
representa.
A continuación, vamos a estudiar las diversas restricciones de datos que pueden especificarse en
una base de datos relacional. Éstas pueden dividirse generalmente en dos categorías principales:
1. Restricciones que son inherentes al modelo de datos y que reciben el nombre de
restricciones implícitas o inherentes basadas en el modelo.
2. Restricciones que pueden expresarse directamente en los esquemas del modelo de datos, por
lo general especificándolas en el DDL (Lenguaje de definición de datos, Data Definition
Language). Las llamaremos restricciones explícitas o basadas en el esquema.
Las características de las relaciones que hemos tratado hasta ahora son las restricciones inherentes
del modelo relacional y pertenecen a la primera categoría; por ejemplo, la restricción de que una
relación no puede tener tuplas duplicadas es una restricción inherente. Las restricciones que
tratamos a continuación son las de la segunda categoría, es decir, las que pueden ser expresadas en
el esquema del modelo relacional a través del DDL.
Vamos a ver los tipos de restricciones principales que pueden aplicarse en el modelo relacional: las
basadas en esquema.
2.3.1 Restricciones de dominio
Las restricciones de dominio especifican que dentro de cada tupla, el valor de un atributo A debe ser
un valor atómico del dominio dom(A).
2.3.2 Restricciones de clave
Una relación está definida como un conjunto de tuplas. Por definición, todos los elementos de un
conjunto son distintos; por tanto, todas las tuplas en una relación también deben serlo. Esto significa
que dos tuplas no pueden tener la misma combinación de valores para todos sus atributos.
Habitualmente existen otros subconjuntos de atributos de una relación R con la propiedad de que
dos tuplas de R no deben tener la misma combinación de valores para estos atributos. Suponga que
designados uno de estos subconjuntos de atributos como SK; a continuación, para dos tuplas
cualesquiera distintas t1 y t2 de una relación R, tenemos la restricción:
t1[SK] ≠ t2[SK]
Cualquier conjunto de atributos SK recibe el nombre de superclave del esquema de relación R. Una
superclave especifica una restricción de exclusividad por la que dos tuplas distintas no pueden tener
el mismo valor para SK. Cada relación tiene, al menos, una superclave predeterminada: el conjunto
de todos sus atributos. Sin embargo, una superclave puede contar con atributos redundantes, por lo
que un concepto más importante es el de clave, que no tiene redundancia. Una clave K de un
esquema de relación R es una superclave de R con la propiedad adicional que eliminando cualquier
atributo A de K deja un conjunto de atributos K' que ya no es una superclave de R. Por tanto, una
clave satisface dos restricciones:
1. Dos tuplas diferentes en cualquier estado de la relación no pueden tener valores idénticos
para (todos) los atributos de la clave.
2. Es una superclave mínima, es decir, una superclave de la cual no podemos eliminar ningún
atributo y 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 ESTUDIANTE presentada anteriormente. El
conjunto de atributos {Dni} es una clave de ESTUDIANTE porque dos tuplas de estudiantes
distintas no pueden tener el mismo valor para el Dni. 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 ESTUDIANTE porque la eliminación del Nombre, la Edad, o
ambas, del conjunto aun no deja una superclave. En general, cualquier superclave formada 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.
Observe que un conjunto de atributos que constituyen una clave son una propiedad del esquema 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 mantenerse cuando insertemos nuevas tuplas en la relación. Por ejemplo, no demos, y no
debemos, designar el atributo Nombre de la relación ESTUDIANTE como una clave porque es
posible que dos estudiantes con nombres idénticos existieran en algún punto en un estado válido.
En general, un esquema de relación puede contar con más de una clave. En este caso, cada una de
ellas recibe el nombre de clave candidata. Por ejemplo, una relación ESTUDIANTE podría tener
las claves cantidatas {DNI} y {NroDoc, TipoDoc}. 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. 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.
Otras restricción en los atributos especifica si se permiten o no los valores NULL. Por ejemplo, si
cada tupla de ESTUDIANTE debe contar con un valor válido y no nulo para el atributo Nombre,
entonces el Nombre de ESTUDIANTE esta obligado a ser NOT NULL.
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.
Un esquema de base de datos relacional S es un conjunto de esquemas de relación S={R1, R2, …,
Rn} y de restricciones de integridad. Un estado de base de datos relacional DB de S es un
conjunto de estados de relación DB={r1, r2, …, rn} en el que cada ri es un estado de Ri y satisface las
restricciones de integridad especificadas. A continuación se muestra un esquema de base de datos
relacional que llamamos EMPRESA = {EMPLEADO, DEPARTAMENTO,
LOCALIZACIONES_DPTO, PROYECTO, TRABAJA_EN, SUPERVISADO_POR}.
EMPLEADO(DNI, Nombre, Apellido, FechaNac, Direccion, Sexo, Sueldo, DNISuperior, NroDpto)
DEPARTAMENTO(NumeroDpto, NombreDpto, DniDirector)
LOCALIZACIONES_DPTO(NumeroDpto, UbicacionDpto)
PROYECTO(NumProyecto, NombreProyecto, UbicacionProyecto, NumDptoProyecto)
TRABAJA_EN(DNIEmpleado, NumProy, Horas)
SUPERVISADO_POR(DNIEmpleado, NombreSubordinado, Sexo, FechaNac, Relacion)
Los atributos subrayados representan las claves primarias. Usaremos este esquema para el
desarrollo de los ejemplos.
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 Nombre tanto para el NombreProyecto de PROYECTO como para el
NombreDpto de DEPARTAMENTO; en este caso, tendríamos dos atributos con el mismo nombre
pero que representarían dos conceptos diferentes: nombres de proyectos y de departamentos.
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 relaciones. 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 relación EMPLEADO: una como el DNI del empleado y otra
como el del supervisor. Le dimos distintos nombres de atributo (DNI y SuperiorDNI,
respectivamente) para distinguirlos.
2.3.3 Restricciones de integridad de entidad
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 permitiera este valor, significaría que no se podrían identificar ciertas tuplas.
Por ejemplo, si dos o más tuplas tuvieran NULL en sus claves primarias, no seríamos capaces de
diferenciarlas si intentásemos hacer referencia a ellas desde otras relaciones.
2.3.4 Restricciones de integridad referencial
Las restricciones de integridad 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, el atributo NroDpto de
EMPLEADO devuelve el número de departamento en el que trabaja cada empleado; por tanto, su
valor en cada tupla EMPLEADO debe 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 foránea). Las condiciones de una foreign key, dadas más abajo,
especifican una restricción de integridad referencial entre dos esquemas de relación R1 y R2. Un
conjunto de atributos FK en una relación R1 es una foreign key de R1 que referencia a la relación
R2 si satisface las siguientes reglas:
1. Los atributos en FK tienen el mismo dominio, o dominios, que los atributos de la clave
principal PK de R2; se dice que los atributos FK referencian o hacen referencia a la relación
R2.
2. Un valor de FK en una tupla t1 de R1 tampoco aparece como valor de PK en alguna tupla t2
de R2 o es NULL. En el caso anterior, tenemos que t1[FK] = t2[PK], y decimos que la tupla t1
referencia o hace referencia a la tupla t2.
En esta definición, R1 recibe el nombre de relación de referencia y R2 es la relación referenciada.
Si se mantienen ambas condiciones, se establece una restricción de integridad referencial de R1 a
R2. En una base de datos de muchas relaciones, suelen existir muchas de estas restricciones.
Las restricciones de integridad referencial suelen originarse a partir de las relaciones entre las
entidades representadas por los esquemas de relación. Por ejemplo, en la relación EMPLEADO, el
atributo NroDpto hace referencia al departamento en el que éste trabaja; por consiguiente,
designamos NroDpto como una foreign key de EMPLEADO que hace referencia a la relación
DEPARTAMENTO. Esto implica que un valor de NroDpto en cualquier tupla t1 de la relación
EMPLEADO debe coincidir con otro de la clave principal de DEPARTAMENTO (el atributo
NumeroDpto) en alguna tupla t2 de la relación DEPARTAMENTO, o puede ser NULL si el
empleado no pertenece a un departamento o será asignado más adelante.
Observe que una foreign key puede hacer referencia a su propia relación. Por ejemplo, el atributo
SuperiorDNI de EMPLEADO se refiere al supervisor de un empleado, el cual es a su vez otro
empleado representado por una tupla en la misma relación. Por tanto, SuperiorDNI es una foreign
key que enlaza con la propia relación EMPLEADO.
2.4 Mapeado de DER a MR
A continuación, se muestra cómo diseñar el esquema de una base de datos relacional basándose en
el diagrama ER.
Entidades
DER MR
Entidad fuerte
E(a1, a2, …, aN)
Entidad débil
E1(a1, a2, …, aN)
E2(a1, b1, b2)
Atributos
DER MR
Atributo compuesto
E(a1, a2, a4, a5, a6, …, aN)
Atributo multivaluado
E(a1, a2, …, aN)
a3(a1, v1)
Atributo calculado
No se representa en el MR
E(a1, a2, …, aN)
Relaciones Unarias
DER MR
1:1
E(a1, a1', a2, …, aN, r)
1:N
E(a1, a1', a2, …, aN, r)
N:N
E(a1, a2, …, aN)
R(a1, a1', r)
Relaciones Binarias
DER MR
1:1
E1(a1, a2, …, aN)
E2(b1, b2, …, bN, a1, r)
E1(a1, a2, …, an, b1, r)
E2(b1, b2, …, bn)
1:N
E1(a1, a2, …, an)
E2(b1, b2, …, bn, a1, r)
N:N
E1(a1, a2, …, an)
E2(b1, b2, …, bn)
R(a1, b1, r)
Relaciones Ternarias
DER MR
[Link]
E1(a1, a2, …, aN)
E2(b1, b2, …, bN)
E3(c1, c2, …, cN)
R(a1, b1, c1, r)
o
R(a1, b1, c1, r)
o
R(a1, b1, c1, r)
[Link]N
E1(a1, a2, …, aN)
E2(b1, b2, …, bN)
E3(c1, c2, …, cN)
R(a1, b1, c1, r)
o
R(a1, b1, c1, r)
1:N:N
E1(a1, a2, …, aN)
E2(b1, b2, …, bN)
E3(c1, c2, …, cN)
R(a1, b1, c1, r)
N:N:N
E1(a1, a2, …, aN)
E2(b1, b2, …, bN)
E3(c1, c2, …, cN)
R(a1, b1, c1, r)
Jerarquías
DER MR
Solapada
E(a1, a2, a3)
E1(a1, a4)
E2(a1, a5)
E3(a1, a6)
No solapada
E(a1, a2, a3, Tipo)
E1(a1, a4)
E2(a1, a5)
E3(a1, a6)
