Unidad II: Modelado de Datos
El modelado conceptual es una fase importante del diseño de una
aplicación fructífera de base de datos. Vimos en unidades anteriores que una de
las características fundamentales de los SGBD es que proporciona cierto nivel
de abstracción de los datos, al ocultar detalles de almacenamiento que la
mayoría de los usuarios no necesita conocer. Un modelo de datos
(colección de conceptos que sirven para describir la estructura de una base de
datos) proporciona los medios necesarios para conseguir dicha abstracción. Cuando
hablamos de estructura de la base de
datos nos referimos a los tipos de datos, los vínculos y las restricciones
que deben cumplirse para esos datos.
Se han propuesto muchos modelos de datos y se pueden clasificar
dependiendo de los tipos de conceptos que ofrecen para describir la estructura
de la base de datos. Los modelos de
datos de alto nivel o conceptuales
disponen de conceptos muy cercanos al modo como la mayoría de los usuarios
percibe los datos, mientras que los modelos
de bajo nivel o físicos proporcionan
conceptos que describen los detalles sobre cómo se almacenan los datos en el
ordenador.
El modelo de datos Entidad-Relación (ER) permite describir los datos
implicados en una empresa real en términos de objetos y de sus relaciones, y se
emplea mucho para desarrollar el diseño preliminar de la base de datos. Aporta
conceptos útiles que permiten pasar de una descripción informal de los que los
usuarios desean de su base de datos a otra más detallada y precisa que se pueda
implementar en un SGBD.
Proceso de diseño de la Base de Datos
La figura
muestra una descripción simplificada del proceso de diseño de la base de datos.
El primer paso que aparece es la obtención y análisis de requisitos.
Durante este paso los diseñadores entrevistan a los futuros usuarios de la base
de datos para entender y documentar sus requisitos
de datos. El resultado de este paso será un conjunto de requisitos del
usuario, redactado de forma concisa. Estos requisitos deben especificarse de la
forma más detallada y completa posible.
En paralelo con la especificación de los
requisitos de datos, conviene especificar los requisitos funcionales conocidos de la aplicación. Éstos consisten
en las transacciones definidas por el
usuario que se aplicarán a las bases de datos, e incluyen la obtención de datos
y la actualización.
Una vez recogidos y analizados todos los
requisitos, el siguiente paso es crear un esquema
conceptual para la base de datos mediante un modelo conceptual de datos de alto nivel. Este paso se denomina
diseño conceptual. El esquema
conceptual es una descripción concisa de
los requisitos de información de los usuarios, y contiene descripciones
detalladas de los tipos de entidad, vínculos y restricciones representados
según el modelo conceptual de datos usado (en esta unidad veremos el ER).
Puestos que estos conceptos no incluyen detalles de implementación, suelen ser
fáciles de entender y pueden servir para comunicarse con usuarios no técnicos.
El esquema conceptual de alto nivel también
pude servir como referencia para asegurarse de satisfacer todos los
requerimientos de los usuarios y de que no haya conflictos entre dichos
requisitos. Este enfoque permite a los diseñadores de la base de datos
concentrarse en especificar las propiedades de los datos, sin preocuparse por
detalles del almacenamiento. En consecuencia, tienen menos problemas para
elaborar un diseño conceptual de la base de datos.
Una vez diseñado el esquema conceptual o
durante dicho proceso, es posible utilizar las operaciones básicas del modelo
de datos para especificar operaciones de usuario de alto nivel identificadas
durante el análisis funcional. Esto también sirve para confirmar que el esquema
conceptual satisfaga todos los requisitos funcionales identificados. Se puede
modificar el esquema conceptual si no resulta factible especificar algunos
requisitos funcionales en el esquema inicial.
A partir de allí se debe usar un SGBD para
implementar la base de datos. Esto se logra transformando el esquema conceptual
del modelo usado al modelo de datos de implementación. Este paso se llama diseño lógico o transformación del modelo de datos, y su resultado es un esquema de
la base de datos en el modelo de datos que se usará para la implementación de
la base de datos.
El paso final es la fase de diseño físico, durante la cual se
especifican las estructuras de almacenamiento internas, los caminos de acceso y
la organización de ficheros de la base de datos. En paralelo con estas
actividades, se diseñan e implementan programas de aplicación en forma de
transacciones de la base de datos que correspondan a las especificaciones de
transacciones de alto nivel.
Entidades, atributos y conjuntos de entidades
Una entidad
es un objeto del mundo real que puede distinguirse de otros objetos. Una
entidad puede ser un objeto con existencia física (una persona, un automóvil,
una casa, un empleado) o un objeto con existencia conceptual (una empresa, un
puesto de trabajo, un curso universitario, una cuanta de cliente).
Cada entidad tiene propiedades específicas
llamadas atributos que la describen.
Por ejemplo, una entidad empleado puede describirse por su nombre, edad,
dirección, salario y puesto de trabajo. Una entidad particular tendrá un valor para cada uno de esos atributos.
En el modelo ER se manejan distintos tipos de
atributos, como ser: simples o compuestos, monovaluados o multivaluados, y
almacenados o derivados.
Atributos compuestos o simples: Los atributos compuestos se
pueden dividir en componentes más pequeños (por ej.: el atributo Dirección de
la entidad Empleado se puede subdividir en Calle, Número, Departamento,
Piso. A su vez, los atributos simples no son divisibles.
Atributos monovaluados o multivaluados: Los atributos monovaluados son
aquellos que pueden tener un único valor por entidad, el atributo Edad es
monovaluado. En cambio un atributo que puede tener un conjunto de valores para
la misma entidad se dice multivaluado,
por ejemplo Título de la entidad Persona, dado que la misma persona puede tener
varios títulos.
Atributos almacenados o derivados: En algunos casos se relacionan dos o más atributos a la misma
entidad, siendo que uno es almacenado y los demás son derivados, por ejemplo,
el atributo Fecha de Nacimiento es almacenado, pero el atributo Edad es
derivado de Fecha de Nacimiento (se calcula según la fecha actual cada vez que se
consulta la entidad).
Resulta útil identificar conjuntos de
entidades similares (conjunto de entidades). Por ejemplo la entidad Empleados
del Departamento Ventas y la entidad Empleados del departamento Compras son
entidades similares, y forman parte del mismo conjunto de entidades. Estas entidades
comparten los mismos atributos, pueden formar conjuntos disjuntos o no (es
decir que puede haber un empleado que forme parte de ambas entidades).
Cada
atributo que compone una entidad está asociado a un dominio de valores posibles, por ejemplo el dominio asociado al
atributo nombre de Empleados podría
ser el conjunto de cadena de caracteres de longitud 20 (veinte). Otro ejemplo
podría ser, si la empresa califica a sus empleados según una escala del uno al
diez, y guarda las calificaciones en un campo denominado calificaciones, el dominio asociado a ese campo será los enteros
del uno al diez.
Además, para cada conjunto de entidades se
escoge una clave. Una clave es un conjunto mínimo de
atributos cuyos valores identifican de manera unívoca a cada entidad del
conjunto. Puede haber más de una clave
candidata; en ese caso, se escogerá una de ellas como clave principal.
Cada conjunto de entidades se representa
mediante un rectángulo, y cada atributo de la misma mediante un óvalo. Los
atributos de la clave principal están subrayados.
 |
| Conjunto de entidades Empleados |
Las relaciones y los conjuntos de relaciones
Una relación
(vínculo) es una asociación entre dos o más entidades. Por ejemplo, puede que
se tenga una relación en que Avelino trabaja en el departamento ventas. Al
igual que con las entidades, puede que se desee reunir un conjunto de
relaciones similares en un conjunto de relaciones. Se puede
considerar a los conjuntos de relaciones como conjuntos de n-tuplas:
{(e1,
… , en) | e1 Î E1,
… , en Î En}
Cada n-tupla denota una relación que implica a
n entidades, e1, … , en, donde la entidad ei
se halla en el conjunto de entidades Ei.
 |
| Conjunto de relaciones Trabaja_en |
En el conjunto de relaciones Trabaja_en cada
relación indica un departamento en el que trabaja ese empleado puede verse.
Obsérvese que puede que varios conjuntos de relaciones impliquen a los mismos conjuntos de entidades. Por
ejemplo, también se podría tener un conjunto de relaciones Dirige que implique
a Empleados y a Departamentos.
Las relaciones también pueden tener atributos descriptivos. Los atributos
descriptivos se emplean para registrar la información sobre la relación, más
que sobre las entidades participantes; por ejemplo, puede que se desee
registrar que Avelino trabaja en el departamento ventas desde enero de 1998.
Cada relación debe identificarse de manera
unívoca por sus entidades participantes, sin necesidad de referencia alguna a
los atributos descriptivos. En el conjunto de relaciones Trabaja_en, por
ejemplo, cada relación Trabaja_en debe quedar identificada de manera unívoca
por la combinación de dni de empleado
y idd de departamento. Por lo tanto,
para una pareja empleado-departamento dada, no se puede tener más de un valor desde asociado.
Cada ejemplar de un conjunto
de relaciones es un conjunto de relaciones en sí mismo. De manera gráfica, se
puede pensar en un ejemplar como una “instantánea” del conjunto de relaciones
en un momento temporal dado. En el siguiente ejemplo se puede ver un ejemplar
del conjunto de relaciones Trabaja_en. Cada entidad Empleados se denota por su dni, y cada entidad Departamento por su idd, para simplificar el ejemplo. El
valor desde se muestra junto a cada
relación.
 |
| Un ejemplar del conjunto de relaciones Trabaja_en |
Como ejemplo
adicional de diagrama ER, supóngase que cada departamento tiene oficinas en
varias ubicaciones y que se desea registrar las ubicaciones en las que trabaja
cada empleado. Esta relación es ternaria,
ya que hay que registrar la asociación entre cada empleado, el departamento y
la ubicación.
 |
| Conjunto de relaciones ternarias |
No hace falta que los conjuntos de entidades
que participan en un conjunto de relaciones sean distintos; puede que a veces
una relación implique a dos entidades del mismo conjunto de entidades. Por
ejemplo, considérese el conjunto de relaciones Informa_a. Como los empleados
rinden cuentas a otros empleados, las relaciones de Informa_a son de la forma
(empl1, empl2), donde tanto empl1 como empl2
son entidades de Empleados. Sin embargo interpretan papeles o roles diferentes:
empl1 rinde cuentas al empleado encargado empl2, lo que
se refleja en los indicadores de papeles
o roles supervisor y subordinado de la figura.
 |
| Conjunto de relaciones Informa_a |
Si un conjunto de entidades desempeña más de
un papel, el indicador de papeles concatenado con un nombre de atributo de un
conjunto de entidades da un nombre único para cada atributo del conjunto de
relaciones. Por ejemplo, el conjunto de relaciones Informa_a tiene atributos
correspondientes al dni del
supervisor y al dni del subordinado,
y el nombre de estos atributos es dni_supervisor
y dni_subordinado.
Otras características del modelo ER
A continuación se examinan algunas de las
estructuras del modelo ER que permiten describir algunas propiedades sutiles de
los datos. La expresividad del modelo ER es una de las razones de su amplia
utilización.
Restricciones de clave en relaciones
Considerando la relación Trabaja_en de la
página 6, cada empleado puede trabajar en varios departamentos, y cada
departamento puede tener varios empleados. Como podemos ver en la figura del
ejemplar de Trabaja-en de la página 7, el empleado 18.564.008 ha trabajado en
el Departamento 51 desde el 3/3/93 y en el Departamento 56 desde el 2/2/92. Así
mismo, el Departamento 51 tiene dos empleados.
Considérese ahora otro conjunto de relaciones
denominado Dirige entre los conjuntos de entidades Empleados y Departamentos,
tal que cada departamento tenga como máximo un empleado, aunque se permite que
un empleado dirija más de un departamento. La restricción de que cada
departamento tenga como máximo un encargado es un ejemplo de restricción de clave, e implica que
cada entidad de departamento aparezca como máximo en una relación Dirige en
cada ejemplar admisible de Dirige. Esta restricción se indica en el diagrama ER
de Dirige mediante la flecha que va de Departamentos a Dirige. De manera
intuitiva, la flecha indica que, dada una entidad Departamentos, se puede determinar
de manera unívoca la relación Dirige en la que aparece.
 |
| Restricción de clave en Dirige (1..N) |
A continuación se muestra un ejemplar del conjunto de relaciones
Dirige. Aunque se trate también de un posible ejemplar del conjunto de Trabaja_en,
el ejemplar de Trabaja_en violaría la restricción de clave de Dirige.
 |
| Ejemplar de conjunto de relaciones Dirige |
Se dice a veces que el conjunto de relaciones
como Dirige son de una a varias
(1…N), para indicar que cada empleado
se puede asociar con varios
departamentos (en función de encargado), mientras que cada departamento se
puede asociar, como máximo, con un empleado como encargado. Por el contrario,
se dice que el conjunto de relaciones Trabaja_en, en el que se permite que cada
empleado trabaje en varios departamentos y que cada departamento tenga varios
empleados, es de varias a varias
(N...N).
Si se añade al conjunto de relaciones Dirige
la restricción de que cada empleado puede dirigir como máximo un departamento,
lo que se indicaría añadiendo una fecha de Empleado a Dirige, se tendría un
conjunto de relaciones de una a una
(1…1).
 |
| Restricción de clave en Dirige (1..1) |
Restricciones de clave en relaciones ternarias
Se puede ampliar este concepto a los conjuntos
de relaciones que abarcan tres o más conjuntos de entidades: si el conjunto de
entidades E tiene una restricción de clave en el conjunto de relaciones R, cada
entidad de un ejemplar concreto de E aparecerá, como máximo, en una relación de
(el ejemplar correspondiente de) R. Para indicar una restricción de clave sobre
el conjunto de entidades E del conjunto de relaciones R, se traza una flecha de
E a R.
Como ejemplo de restricción de clave en
relaciones ternarias, podemos suponer que cada empleado trabaja, como máximo,
en un departamento y en una única ubicación. Debemos tener en cuenta que cada
departamento puede asociarse con varios empleados y ubicaciones, y que cada
ubicación puede asociarse con varios departamentos y empleados; sin embargo,
cada empleado está asociado con un solo departamento y una única ubicación.
 |
| Conjunto de relaciones ternarias con restricción de clave |
 |
| Ejemplar de Trabaja_en3 |
Restricciones de participación
La restricción de clave sobre Dirige indica
que cada departamento tiene, como máximo, un encargado. Una pregunta que
resulta lógica formularse es si todos los departamentos tienen encargado.
Supongamos que se exige que cada departamento tenga un encargado. Este
requisito es un ejemplo de restricción
de participación; se dice que la participación del conjunto de entidades
Departamento en el conjunto de relaciones Dirige es total. Una participación que no es total se dice que es parcial. A modo de ejemplo, la
participación del conjunto de entidades Empleados en Dirige es parcial, ya que
no todos los empleados consiguen dirigir un departamento.
Volviendo al conjunto de relaciones
Trabaja_en, resulta natural esperar que cada empleado trabaje, como mínimo, en
un departamento y que cada departamento tenga como mínimo un empleado. Esto
significa que tanto la participación de Empleados como la de Departamentos en
Trabaja_en es total.
 |
| Dirige y Trabaja_en |
En el diagrama ER precedente, se muestra tanto
el conjunto de relaciones Dirige como el conjunto de relaciones Trabaja_en y a
todas las restricciones dadas. Si la participación de un conjunto de entidades
en un conjunto de relaciones es total, ambas se conectan mediante una línea
gruesa; de manera independiente, la presencia de una flecha indica una
restricción de clave.
Entidades débiles
Hasta ahora se ha supuesto que entre los
atributos asociados a un conjunto de entidades se incluye una clave. Esta
suposición no siempre se cumple. Por ejemplo, supóngase que los empleados
pueden suscribir pólizas de seguros que cubran a las personas que dependen de
ellos. Se desea registrar información sobre esas pólizas, incluyendo a las
personas cubiertas en cada póliza; pero esa información es, en realidad, lo
único que interesa de las personas que depende de cada empleado. Si un empleado
deja de serlo, las pólizas que hubiera suscripto se cancelan, y se desea
eliminar de la base de datos toda la información relevante sobre esas pólizas y
sobre las personas que dependen de ese antiguo empleado.
Se podría decidir identificar en este caso a
cada persona que depende de un empleado únicamente por su nombre, ya que es
razonable esperar que todas las personas que dependen de un empleado tengan
nombres diferentes. Por lo tanto, los atributos del conjunto de entidades
Beneficiarios podrían ser nombrep y edad. El atributo nombrep no identifica de manera unívoca a cada persona que depende
de un empleado. Recuérdese que la clave para Empleados es dni; por lo tanto, se podría tener dos empleados llamados Sánchez
con un hijo llamado José.
Beneficiarios es un ejemplo de un conjunto de entidades débiles. Cada
entidad débil sólo se puede identificar de manera unívoca tomando en
consideración alguno de sus atributos junto con la clave principal de otra
entidad, que se conoce como propietaria
identificadora.
Se debe cumplir las restricciones siguientes:
ü El conjunto de entidades propietario y el conjunto de entidades débiles
deben participar en un conjunto de relaciones de uno a varias (cada entidad
propietaria se asocia con una o varias entidades débiles, pero cada entidad
débil solo tiene una propietaria). Este conjunto de relaciones se denomina conjunto de relaciones identificadoras
del conjunto de entidades débiles.
ü El conjunto de entidades débiles debe tener participación total en el
conjunto de relaciones identificadoras.
Por ejemplo, cada entidad Beneficiario sólo se
puede identificar de manera unívoca si se toma la clave de la entidad Empleados propietaria y nombrep de la entidad Beneficiarios. El conjunto de atributos de un
conjunto de entidades débiles que identifica de manera unívoca a una entidad
débil para una entidad propietaria dada se denomina clave parcial del conjunto de entidades débiles. En nuestro ejemplo
nombrep es una clave parcial de
Beneficiarios.
 |
| Conjunto de entidades débiles |
La participación total de Beneficiarios en
Póliza se indica enlazándolos mediante una línea gruesa. La flecha que va de
Beneficiarios a Póliza indica que cada entidad de Beneficiarios aparece, como
máximo, en una relación de Póliza. Para subrayar el hecho de que Beneficiarios
es una entidad débil y Póliza es una relación identificadora se dibujan las dos
en líneas oscuras. Para indicar que nombrep
es una clave parcial de Beneficiarios, se subraya con línea punteada. Esto
significa que puede haber perfectamente dos personas que dependan de empleados
y tengan el mismo valor de nombrep.
Jerarquías de clases
A veces resulta natural clasificar las
entidades en un conjunto de entidades en subclases. Por ejemplo, puede que se
desee hablar del conjunto de entidades Empleados_temp y del conjunto de
entidades Empleados_fijos para distinguir el modo en que se calcula su sueldo.
Puede que se hayan definido los atributos horas_trabajadas
y sueldo_hora definidos para
Empleados_temp y el atributo idcontrato
para Empleados_fijos.
Se desea que todas las entidades de cada uno
de esos conjuntos sean también entidades de Empleados y, como tales, deberán
tener definidos todos los atributos de Empleados. Por lo tanto, todos los
atributos definidos para una entidad Empleados_temp dada son los atributos de
Empleados más los de Empleados_temp. Se dice que los atributos del conjunto de
entidades Empleados se heredan por
el conjunto de entidades Empleados_temp y que una entidad de Empleados_temp ES una entidad de Empleados. Además, y
a diferencia de la jerarquía de clases de los lenguajes de programación
orientados a objetos, hay una restricción para las consultas sobre los
ejemplares de estos conjuntos de entidades: las consultas que pidan todas las
entidades Empleados también deben tomar en consideración las entidades
Empleados_temp y Empleados_fijos.
 |
| Jerarquía de clases |
El conjunto de entidades Empleados también se
puede clasificar según un criterio diferente. Por ejemplo se puede identificar
un subconjunto de empleados como Empleados_veteranos. Se puede modificar el
diagrama anterior para que refleje esta modificación añadiendo un segundo nodo
ES como hijo de Empleados y haciendo a Empleados-veteranos hijo de ese nodo. Y
así, se puede seguir clasificando cada uno de esos conjuntos de entidades y
crear jerarquías ES multinivel.
Las jerarquías de clases se pueden considerar
desde dos puntos de vista:
ü Empleados está especializado
en subclases. La especialización es el proceso de identificación de
subconjuntos de un conjunto de entidades dado (la superclase) que comparten alguna característica distintiva.
Generalmente se define en primer lugar la superclase, a continuación se definen
las subclases y luego se añaden los atributos y los conjuntos de relaciones
específicos de cada subclase.
ü Empleados_temp y Empleados_fijos se generalizan mediante Empleados. Como ejemplo adicional, se pueden
generalizar los conjuntos de entidades Motos y Coches en el conjunto de
entidades Vehículos_motorizados. La generalización consiste en identificar
alguna característica común de un conjunto de conjuntos de entidades y crear un
nuevo conjunto de entidades que contenga entidades que posean esas
características comunes. Generalmente se definen en primer lugar las subclases,
a continuación se define la superclase y luego se definen los conjuntos de
relaciones que implican a las superclases.
Se pueden especificar dos tipos de
restricciones con respecto a las jerarquías ES: las restricciones de solapamiento y de cobertura. Las restricciones
de solapamiento determinan si se permite que dos clases contengan la misma
entidad. Por ejemplo, ¿puede Avelino ser una entidad Empleados_temp y una
entidad Empleados_fijos a la vez? De manera intuitiva, no. ¿Puede ser una
entidad Empleados_fijos a su vez una entidad de Empleados_veteranos? De manera
intuitiva, si. Esto se denota escribiendo “Empleados_fijos SOLASPA A
Empleados_veteranos. En ausencia de una afirmación de este tipo, se da por
supuesto de manera predeterminada que se restringe a los conjuntos de entidades
a no solaparse.
Las restricciones
de cobertura determinan si las entidades de las subclases incluyen de
manera colectiva a todas las entidades de la superclase. Por ejemplo, ¿tienen
que pertenecer todas las entidades Empleados a alguna de las subclases? De
manera intuitiva, no. ¿Tienen que ser todas las entidades Vehículos_motorizados
una entidad de Motos o de una entidad Coches? De manera intuitiva, si; una
propiedad característica de las jerarquías de generalización es que todos los
ejemplares de una superclase son, a su vez, ejemplares de una subclase. Esto se
denota escribiendo “Motos Y Coches CUBREN Vehículos_motorizados”. En ausencia
de una afirmación de este tipo se supone de manera predeterminada que no hay
ninguna restricción de cobertura; se pueden tener vehículos de motor que no
sean ni motos ni coches.
Hay dos motivos básicos para identificar
subclases (por especialización o por generalización):
1-
Puede que se desee añadir
atributos descriptivos que solo lengan sentido para las entidades de una subclase
dada. Por ejemplo, sueldo_hora no
tiene sentido para la entidad Empleados_fijos, cuya paga se determina mediante
un contrato individual o un salario básico.
2-
Puede que se desee identificar el
conjunto de entidades que participan en una relación dada. Por ejemplo, puede
que se desee definir la relación Dirige de modo que los conjuntos de entidades
participantes sean Empleados_veteranos y Departamentos, para garantizar que
solo los empleados veteranos puedan ser encargados o jefes de departamento.
Como ejemplo adicional, puede que Motos y Coches tengan atributos descriptivos
diferentes (por ejemplo, tonelaje y número de puertas) pero, como entidades de
Vehículos_motorizados, deben estar matriculados. La información sobre la
matrícula se puede capturar mediante una relación Matriculado_por entre
Vehículos_motorizados y un conjunto de entidades denominado Propietarios.
Agregación
Como se ha definido hasta ahora, un conjunto
de relaciones es una asociación entre conjuntos de entidades. A veces hay que
modelar las relaciones entre un conjunto de entidades y de relaciones.
Supóngase que se tiene un conjunto de entidades denominados Proyectos y que
cada entidad de Proyectos está financiada por uno a varios departamentos. El
conjunto de relaciones Financia captura esta información. El departamento que
financia un proyecto puede asignar empleados para que controlen el trabajo. De
manera intuitiva, Controla debería ser un conjunto de relaciones que asocie
relaciones de Financia (en vez de Proyectos o Departamento) con entidades de
Empleados. Sin embargo, las relaciones que se han definido asocian dos o más
entidades, no relaciones.
Para definir un conjunto de relaciones como Controla se introduce una
nueva característica del modelo ER, denominada agregación. La agregación permite indicar que un
conjunto de relaciones (identificado mediante un cuadro discontinuo) participa
en otro conjunto de relaciones. Esto se ve en la figura, con un cuadro
discontinuo alrededor de Financia (y sus conjuntos de entidades participantes)
para denotar la agregación. Esto permite tratar de manera efectiva Financia
como un conjunto de entidades a los efectos de definir el conjunto de
relaciones Controla.
 |
| Agregación ¿Cuándo se debe emplear la agregación? Se emplea cuando hace falta expresar una relación entre relaciones. ¿Pero no se pueden expresar relaciones que impliquen a otras relaciones sin emplear la agregación? En el ejemplo, ¿Por qué no hacer de Financia una relación ternaria? La respuesta es que realmente hay dos relaciones diferentes, Financia y Controla, cada una de las cuales tendrá sus propios atributos. Por ejemplo, la relación controla tiene el atributo hasta que registra la fecha hasta la que un empleado ha sido nombrado supervisor del financiamiento. Compárese éste atributo con el atributo desde de Financia, que es la fecha en que el financiamiento entró en vigor. El empleo de la agregación en lugar de una relación ternaria también puede deberse a determinadas restricciones de integridad, como se explica más adelante. |
