Vous êtes sur la page 1sur 6

FUNDAMENTOS DE BASES DE DATOS

8.2. EL MODELO DE DATOS ORIENTADO A OBJETOS


En esta seccin se presentan los conceptos principales
del modelo de datos orientado a objetos: la estructura de
stos y las nociones de clases, herencia e identidad
de objetos.

junto de mensajes a los que responde, resulta posible


modificar las definiciones de los mtodos y de las variables sin afectar al resto del sistema. La posibilidad de
modificar la definicin de un objeto sin afectar al resto del sistema se considera una de las mayores ventajas del paradigma de la programacin orientada a objetos.
Los mtodos de cada objeto pueden clasificarse como
slo de lectura o de actualizacin. Los mtodos slo de
lectura no afectan al valor de las variables de los objetos, mientras que los mtodos de actualizacin s pueden modificarlo. Los mensajes a los que responde cada
objeto pueden clasificarse de manera parecida como
slo de lectura o de actualizacin, segn el mtodo que
los implemente.
Los atributos derivados de las entidades del modelo
E-R pueden expresarse en el modelo orientado a objetos como mensajes slo de lectura. Por ejemplo, el atributo derivado antigedad de una entidad empleado puede expresarse como el mensaje antigedad de un objeto
empleado. El mtodo que implemente los mensajes,
puede determinar la antigedad restando la fecha-alta
del empleado de la fecha actual.
Hablando con rigor, en el modelo orientado a objetos hay que expresar cada atributo de las entidades como
una variable y un par de mensajes del objeto correspondiente. La variable se utiliza para guardar el valor
del atributo, uno de los mensajes se utiliza para leer el
valor del atributo y el otro mensaje se utiliza para actualizar ese valor. Por ejemplo, el atributo direccin de la
entidad empleado puede representarse mediante:

8.2.1. Estructura de los objetos

Hablando en general, los objetos se corresponden con


las entidades del modelo E-R. El paradigma orientado
a objetos est basado en el encapsulamiento de los datos
y del cdigo relacionados con cada objeto en una sola
unidad cuyo contenido no es visible desde el exterior.
Conceptualmente, todas las interacciones entre cada
objeto y el resto del sistema se realizan mediante mensajes. Por tanto, la interfaz entre cada objeto y el resto
del sistema se define mediante un conjunto de mensajes permitidos.
En general, cada objeto est asociado con
Un conjunto de variables que contiene los datos
del objeto; las variables se corresponden con los
atributos del modelo E-R.
Un conjunto de mensajes a los que responde; cada
mensaje puede no tener parmetros, tener uno o
varios.
Un conjunto de mtodos, cada uno de los cuales
es cdigo que implementa un mensaje; el mtodo
devuelve un valor como respuesta al mensaje.
El trmino mensaje en un entorno orientado a objetos
no implica el uso de mensajes fsicos en redes informticas. Por el contrario hace referencia al intercambio
de solicitudes entre los objetos independientemente de
los detalles concretos de su implementacin. Se utiliza
a veces la expresin invocar a un mtodo para denotar el hecho de enviar un mensaje a un objeto y la ejecucin del mtodo correspondiente.
Se puede explicar la razn del uso de este enfoque
considerando las entidades empleado de una base de
datos bancaria. Supngase que el sueldo anual de cada
empleado se calcula de manera diferente para los distintos empleados. Por ejemplo, puede que los jefes
obtengan una prima en funcin de los resultados del
banco, mientras que los cajeros reciben una prima en
funcin de las horas que hayan trabajado. Se puede (en
teora) encapsular el cdigo para calcular su sueldo con
cada empleado en forma de mtodo que se ejecute en
respuesta a un mensaje de sueldo-anual.
Todos los objetos empleado responden al mensaje
sueldo-anual, pero lo hacen de manera diferente. Al
encapsular con el objeto empleado la informacin sobre
el clculo de su sueldo anual, todos los objetos empleado presentan la misma interfaz. Dado que la nica interfaz externa presentada por cada objeto es el con-

Una variable direccin.


Un mensaje obtener-direccin cuya respuesta sea
la direccin.
Un mensaje establecer-direccin, que necesita un
parmetro nueva-direccin, para actualizar la direccin.
Sin embargo, en aras de la sencillez, muchos modelos
orientados a objetos permiten que las variables se lean
o se actualicen de manera directa, sin necesidad de definir los mensajes para ello.
8.2.2. Clases de objetos

Generalmente, en una base de datos hay muchos objetos similares. Por similar se entiende que responden a
los mismos mensajes, utilizan los mismos mtodos y
tienen variables del mismo nombre y del mismo tipo.
Sera un derroche definir por separado cada uno de estos
objetos. Por tanto, los objetos parecidos se agrupan para
formar una clase. Cada uno de estos objetos se denomina ejemplar de su clase. Todos los objetos de una
194

CAPTULO 8

clase comparten una definicin comn, pese a que se


diferencien en los valores asignados a las variables.
El concepto de clase del modelo orientado a objetos
se corresponde con el concepto de entidad del modelo
E-R. Algunos ejemplos de clases en la base de datos
bancaria son los empleados, los clientes, las cuentas y
los prstamos.
La Figura 8.1 define la clase empleado en pseudocdigo. La definicin muestra las variables y los mensajes a los que responden los objetos de la clase. En esta
definicin, cada objeto de la clase empleado contiene
las variables nombre y direccin, ambas cadenas de
caracteres; fecha-alta, que es una fecha, y sueldo, que
es un entero. Cada objeto responde a los cinco mensajes mostrados, llamados sueldo-anual, obtener-nombre,
obtener-direccin, establecer-direccin y antigedad.
El nombre de tipo que precede a cada mensaje indica el
tipo de la respuesta al mismo. Obsrvese que el mensaje establecer-direccin utiliza el parmetro nuevadireccin que especifica el nuevo valor de la calle. Aunque no lo hemos mostrado aqu, la clase empleado
soportara tambin mensajes que establecen el nombre,
el sueldo y la fecha de alta.
Los mtodos para el manejo de mensajes suelen definirse separados de la definicin de clases. Los mtodos
obtener-direccin() y establecer-direccin() estaran
definidos, por ejemplo, por el pseudocdigo:

BASES DE DATOS ORIENTADAS A OBJETOS

El concepto de clases es parecido al concepto de los


tipos abstractos de datos. Sin embargo, hay varios aspectos adicionales en el concepto de clase respecto al de
tipos abstractos de datos. Para representar estas propiedades adicionales, cada clase se trata como si fuera un
objeto. Un objeto clase incluye
Una variable de tipo conjunto cuyo valor es el conjunto de todos los objetos que son ejemplares de
la clase.
La implementacin de un mtodo para el mensaje nuevo, que crea un nuevo ejemplar de la clase.
Se retomarn estas caractersticas en el Apartado 8.5.2.
8.2.3. Herencia

Los esquemas de las bases de datos orientadas a objetos suelen necesitar gran nmero de clases. Frecuentemente, sin embargo, varias de las clases son parecidas
entre s. Por ejemplo, supngase que se tiene una base
de datos orientada a objetos en la aplicacin bancaria.
Cabe esperar que la clase de los clientes del banco sea
parecida a la clase de los empleados en que ambas definan variables para nombre, direccin, etctera. Sin
embargo, hay algunas variables especficas de los empleados (sueldo, por ejemplo) y otras especficas de los
clientes (inters-prstamo, por ejemplo). Sera conveniente definir una representacin de las variables comunes en un solo lugar. Esto slo puede hacerse si se combinan los empleados y los clientes en una sola clase.
Para permitir la representacin directa de los parecidos entre las clases hay que ubicarlas en una jerarqua
de especializaciones (la relacin ES) como la definida en el Captulo 2 para el modelo entidad-relacin. Por
ejemplo, se puede decir que empleado es una especializacin de persona, dado que el conjunto de los empleados es un subconjunto del conjunto de personas. Es
decir, todos los empleados son personas. De manera
parecida, cliente es una especializacin de persona.
El concepto de jerarqua de clases es parecido al de
especializacin del modelo entidad-relacin. Los empleados y los clientes pueden representarse mediante
clases que son especializaciones de la clase persona.
Las variables y los mtodos especficos de los empleados se asocian con la clase empleado. Las variables y
los mtodos especficos de los clientes se asocian con
la clase cliente. Las variables y los mtodos que se aplican tanto a empleados como a clientes se asocian con
la clase persona.
En la Figura 8.2 se muestra un diagrama E-R con
una jerarqua de especializaciones que representa a las
personas implicadas en la operacin del ejemplo bancario. En la Figura 8.3 se muestra la jerarqua de clases
correspondiente. Las clases mostradas en la jerarqua
pueden definirse en pseudocdigo como se muestra en
la Figura 8.4. Por brevedad no se presentan todos los
mensajes y mtodos asociados con estas clases, aunque

string obtener-direccin() {
return direccin;
}
int establecer-direccin(string nueva-direccin) {
direccin = nueva-direccin;
}
mientras que el mtodo antigedad() se definira:
int antigedad(){
return today() fecha-alta;
}
Aqu, asumimos que la funcin today() es una funcin
que devuelve la fecha actual, y el opera con ellas
devolviendo el intervalo entre las dos fechas.
class empleado {
/* Variables */
string nombre;
string direccin;
date fecha-alta;
int
sueldo;
/* Mensajes */
int
sueldo-anual ();
string obtener-nombre ();
string obtener-direccin ();
int
establecer-direccin (string nueva-direccin);
int
antigedad();
};

FIGURA 8.1. Definicin de la clase empleado.


195

FUNDAMENTOS DE BASES DE DATOS

class persona {
string nombre;
string direccin;
string obtener-nombre();
string obtener-direccin();
int
establecer-direccin(string nueva-direccin);
};
class cliente isa persona {
int
inters-prstamo;
};
class empleado isa persona {
date fecha-alta;
int
sueldo;
int
sueldo-anual();
int
antigedad();
};
class administrativo isa empleado {
int
nmero-despacho;
int
nmero-cuenta-corriente;
};
class cajero isa empleado {
int
horas-semana;
int
nmero-ventanilla;
};
class secretario isa empleado {
int
horas-semana;
string jefe;
};

persona

ES

empleado

cliente

ES

administrativo

cajero

secretario

FIGURA 8.2. Jerarqua de especializaciones para el ejemplo


bancario.

se deben incluir en una definicin completa de la base


de datos bancaria.
La palabra clave isa (es) se utiliza para indicar que
una clase es una especializacin de otra. Las especializaciones de las clases se denominan subclases. Por tanto, por ejemplo, empleado es una subclase de persona
y cajero es una subclase de empleado. Anlogamente,
empleado es una superclase de cajero y persona es una
superclase de empleado.
Los objetos que representan a administrativos contienen todas las variables de la clase administrativo;
adems, los objetos que representan a administrativos
contienen tambin todas las variables de las clases
empleado y persona. Esto se debe a que los administrativos se definen como empleados y, como los empleados a su vez se definen como personas, se puede
deducir que los administrativos son tambin personas.
Esta propiedad de que los objetos de una clase contengan las variables definidas en sus superclases se denomina herencia de las variables.
Los mensajes y los mtodos se heredan de modo
idntico a las variables. Una ventaja importante de la

FIGURA 8.4. Definicin en pseudocdigo de una jerarqua


de clases.

herencia en los sistemas orientados a objetos es el concepto de posibilidad de sustitucin: cualquier mtodo de una clase dada por ejemplo, A (o una funcin
que utilice un objeto de la clase A como argumento)
puede ser llamado de igual modo con cualquier objeto perteneciente a cualquier subclase B de A. Esta
caracterstica lleva a la reutilizacin del cdigo, dado
que no hace falta volver a escribir los mensajes, mtodos y funciones para los objetos de la clase B. Por
ejemplo, si se define el mensaje obtener-nombre para
la clase persona, se puede llamar con un objeto persona o con cualquier objeto perteneciente a cualquiera de las subclases de persona, como cliente o administrativo.
En el Apartado 8.2.2 se observ que cada clase es un
objeto por s misma y que ese objeto incluye una variable que contiene el conjunto de todos los ejemplares de
la clase. Resulta sencillo determinar los objetos que se
hallan asociados con las clases en las hojas de la jerarqua. Por ejemplo, se asocia con la clase cliente el conjunto de los clientes del banco. Para las clases que no
son hojas, sin embargo, el problema resulta ms complejo. En la jerarqua de la Figura 8.3 hay dos maneras
posibles de asociar los objetos con las clases:

persona

empleado

administrativo

cajero

cliente

1. Se pueden asociar todos los objetos empleado,


incluyendo aquellos que sean elementos de administrativo, de cajero o de secretario, con la clase
empleado.

secretario

FIGURA 8.3. Jerarqua de clases correspondiente a la Figura 8.2.


196

CAPTULO 8

2. Slo se pueden asociar con la clase empleado los


objetos empleado que no sean elementos de administrativo ni de cajero ni de secretario.

BASES DE DATOS ORIENTADAS A OBJETOS

nes de la compaa, que no es aplicable a los empleados por horas.


La clasificacin expuesta de empleados como temporal y a tiempo completo es independiente de la clasificacin basada en el trabajo que ellos realizan, es
decir, administrativo, cajero, o secretario. Se podran
tener administrativos a tiempo completo, administrativos por horas, cajeros a tiempo completo y cajeros por
horas. Usando la herencia mltiple, simplemente se
crea una nueva clase, tal como cajero-por-horas, que
es una subclase de por-horas y de cajero, y cajero-atiempo-completo, que es una subclase de a-tiempo-completo y de cajero. La combinacin que no puede ocurrir en la vida real no necesita ser creada; por ejemplo,
si todos los administrativos son a tiempo completo, no
es necesario crear una clase de administrativos por
horas. La jerarqua de clases resultantes aparece en la
Figura 8.5.
Gracias a la herencia mltiple, los atributos y los
mtodos concretos de los empleados por horas y a tiempo completo se especifican slo una vez y los heredan
todas las subclases. En cambio, sin la herencia mltiple, se debera, por ejemplo, definir administrativo-porhoras como una subclase de administrativo, y cajeropor-horas como una subclase de cajero. Los atributos
y mtodos especficos para empleados por horas tendran que ser repetidos en cada una de las subclases
expuestas.
Otro ejemplo de herencia mltiple es considerar una
base de datos universitaria, donde una persona puede
ser estudiante o profesor. La base de datos universitaria puede tener clases estudiante y profesor, que son
subclases de persona, para modelar esta situacin. Consideremos ahora tambin una categora de estudiantes
que trabajan como ayudantes de profesor; para modelar esta situacin se puede crear una clase ayudante-pro-

En los sistemas orientados a objetos generalmente


se escoge la segunda opcin. En este caso resulta posible determinar el conjunto de objetos empleado tomando la unin de los objetos asociados con todas las subclases de empleado. La mayor parte de los sistemas
orientados a objetos permiten que la especializacin sea
parcial; es decir, permiten objetos que pertenezcan a una
clase, como empleado, pero que no pertenezcan a ninguna de las subclases de la misma.
8.2.4. Herencia mltiple

En la mayor parte de los casos una organizacin de clases con estructura de rbol resulta adecuada para describir las aplicaciones; en la organizacin con estructura de rbol, cada clase puede tener a lo sumo una
superclase. Sin embargo, hay situaciones que no pueden representarse bien en una jerarqua de clases con
estructura de rbol.
La herencia mltiple permite a las clases heredar
variables y mtodos de mltiples superclases. La relacin entre clases y subclases se representa mediante un
grafo acclico dirigido (GAD) en el que las clases pueden tener ms de una superclase.
Por ejemplo, supngase que los empleados pueden
ser contratados por horas (para un periodo limitado) o
bien a tiempo completo. Se pueden crear las subclases
por-horas y a-tiempo-completo de la clase empleado.
La subclase por-horas tendra un atributo ltimo-da
que especifica cundo concluye el periodo de empleo.
La subclase a-tiempo-completo puede tener un mtodo
para el clculo de las contribuciones al plan de pensio-

persona

empleado

temporal

permanente

administrativo

administrativo-a-tiempo-completo

cajero-por-horas

cliente

cajero

secretario

cajero-a-tiempo-completo secretario-a-tiempo-completo

secretario-por-horas

FIGURA 8.5. GAD de clases del ejemplo bancario.


197

FUNDAMENTOS DE BASES DE DATOS

fesor como una subclase tanto de estudiante como de


profesor.
Cuando se utiliza la herencia mltiple aparece una
ambigedad potencial si se puede heredar la misma
variable o el mismo mtodo de ms de una superclase. Por ejemplo, la clase estudiante puede tener una
variable dept que identifica el departamento del estudiante y la clase profesor puede tener anlogamente
una variable dept que identifica el departamento del
profesor. La clase ayudante-profesor hereda ambas
definiciones de la variable dept; as el uso de la variable dept en el contexto de ayudantes de profesor se
vuelve ambigua.
El resultado de usar dept vara dependiendo de la
implementacin particular del modelo orientado a objetos. Por ejemplo, la implementacin puede manejar dept
de una de estas formas:

necer a alguna clase que es subclase de ambas de estas


clases. Se tiene que usar entonces herencia mltiple para
crear todas las subclases requeridas, tales como ayudante-profesor (que es una subclase de estudiante y profesor), estudiante-miembro-consejo, ayudante-profesormiembro-consejo, etctera, para modelar la posibilidad
de que un objeto tenga varios papeles de manera simultnea.
Claramente, la creacin de muchas subclases es bastante incmoda, y los sistemas que no tienen necesidad
de objetos con una clase ms especfica son preferibles
para modelar papeles. En el Captulo 9 se discute una
ampliacin de SQL que presenta una manera alternativa de modelar papeles.
8.2.5. Identidad de los objetos

Los objetos de las bases de datos orientadas a objetos


suelen corresponder a entidades del sistema modelado
por la base de datos. Las entidades conservan su identidad aunque algunas de sus propiedades cambien con
el tiempo. De manera parecida, los objetos conservan
su identidad aunque los valores de las variables o las
definiciones de los mtodos cambien total o parcialmente con el tiempo. Este concepto de identidad no se
aplica a las tuplas de las bases de datos relacionales. En
los sistemas relacionales las tuplas de una relacin slo
se distinguen por los valores que contienen.
La identidad de los objetos es un concepto de identidad ms potente que el que suele hallarse en los lenguajes de programacin o en los modelos de datos que
no se basan en la programacin orientada a objetos.
A continuacin se ilustran varios ejemplos de identidad.

Incluir las dos variables, dndoles el nombre estudiante.dept y profesor.dept.


Escoger una de las dos segn el orden en que se
crearon las clases estudiante y profesor.
Hacer que el usuario escoja de manera explcita
una de las opciones en la definicin de la clase ayudante-profesor.
Tratar la situacin como si fuera un error.
Ninguna de estas soluciones se ha aceptado como ptima y los diferentes sistemas implementan opciones diferentes.
No todos los casos de herencia mltiple llevan a
ambigedad. Por ejemplo, la variable sueldo est definida en la clase empleados; todas las clases administrativo, cajero y secretario igual que por-horas y a-tiempo-completo heredan sueldo de empleado. Dado que
estas tres clases comparten la misma definicin de sueldo, no surge ambigedad de la herencia de sueldo por
cajero-a-tiempo-completo, administrativo-a-tiempocompleto, y as sucesivamente.
Considrese de nuevo la base de datos universitaria.
La base de datos puede tener varias subclases de persona, incluyendo estudiante y profesor como se vio anteriormente en este apartado, y adems subclases como
miembro-consejo (esto es, un miembro de un consejo
de estudiantes y profesores que se encarga de los asuntos de los estudiantes). Un objeto puede pertenecer a
varias de estas categoras de manera simultnea y cada
una de stas se denomina papel. La nocin de papel aqu
es similar a los papeles usados para la autorizacin en
SQL (vase el Captulo 6).
Muchos lenguajes de programacin orientados a
objetos insisten en que un objeto debe tener una clase
ms especfica, es decir, si un objeto pertenece a muchas
clases, se debe pertenecer a una clase que es (directa o
indirectamente) subclase de todas las otras clases a las
que el objeto pertenece. Por ejemplo, si un objeto pertenece a las clases persona y profesor, tiene que perte-

Valor. Se utiliza un valor de datos como identidad.


Esta forma de identidad se utiliza en los sistemas
relacionales. Por ejemplo, el valor de la clave primaria de una tupla identifica a la tupla.
Nombre. Se utiliza como identidad un nombre proporcionado por el usuario. Esta forma de identidad suele utilizarse para los archivos en los sistemas de archivos. Cada archivo recibe un nombre
que lo identifica de manera unvoca, independientemente de su contenido.
Incorporada. Se incluye el concepto de identidad
en el modelo de datos o en el lenguaje de programacin y no hace falta que el usuario proporcione ningn identificador. Esta forma de identidad
se utiliza en los sistemas orientados a objetos. Cada
objeto recibe del sistema de manera automtica un
identificador en el momento en que se crea.
La identidad de los objetos es una nocin conceptual; los sistemas reales necesitan un mecanismo fsico
que identifique los objetos de manera unvoca. Para los
seres humanos se suelen utilizar como identificadores
198

CAPTULO 8

los nombres, junto con otra informacin como la fecha


y el lugar de nacimiento. Los sistemas orientados a objetos proporcionan el concepto de identificador del objeto para identificar a los objetos. Los identificadores de
los objetos son nicos; es decir, cada objeto tiene un
solo identificador y no hay dos objetos que tengan el
mismo identificador. Los identificadores de los objetos
no tienen por qu estar en una forma con la que los seres
humanos se encuentren cmodos; pueden ser nmeros
grandes, por ejemplo. La posibilidad de guardar el identificador de un objeto como un campo de otro objeto es
ms importante que tener un nombre que resulte fcil
de recordar.
Como ejemplo del uso de los identificadores de los
objetos, uno de los atributos de los objetos persona puede ser el atributo cnyuge, que es en realidad un identificador del objeto persona correspondiente al cnyuge de la primera persona. Por tanto, el objeto persona
puede guardar una referencia del objeto que representa al cnyuge de esa persona.
Generalmente el identificador lo genera el sistema
de manera automtica. Por el contrario, en las bases de
datos relacionales, el campo cnyuge de la relacin persona ser generalmente un identificador unvoco (quizs un nmero de DNI) del cnyuge de esa persona
generado de manera externa al sistema de bases de
datos. Hay muchas situaciones en las que hacer que el
sistema genere identificadores de manera automtica
resulta una ventaja, dado que libera a los seres humanos de llevar a cabo esa tarea. Sin embargo, esta posibilidad debe utilizarse con precaucin. Los identificadores generados por el sistema suelen ser especficos
del mismo y, si se desplazan los datos a un sistema de
bases de datos diferente, hay que traducirlos. Adems,
los identificadores generados por el sistema pueden
resultar redundantes si las entidades que se modelan ya
disponen de identificadores unvocos externos al sistema. Por ejemplo, en Espaa los nmeros del DNI suelen utilizarse como identificadores unvocos de las personas.

BASES DE DATOS ORIENTADAS A OBJETOS

trar los continentes de objetos considrese la base de


datos simplificada para diseo de bicicletas de la Figura 8.6. Cada diseo de bicicletas contiene las ruedas,
el cuadro, los frenos y los cambios. Las ruedas, a su
vez, contienen la llanta, un conjunto de radios y el neumtico. Todos los componentes del diseo pueden
modelarse como objetos y los continentes de los componentes puede modelarse como continentes de objetos.
Los objetos que contienen a otros objetos se denominan objetos complejos o compuestos. Puede haber
varios niveles de continentes, como se muestra en la
Figura 8.6. Esta situacin crea entre los objetos una
jerarqua de continentes.
La jerarqua de la Figura 8.6 muestra la relacin de
continentes entre los objetos de manera esquemtica
dando los nombres de las clases en vez de los de los
objetos concretos. Los enlaces entre las clases deben
interpretarse como es parte de en lugar de la interpretacin es de los enlaces de una jerarqua de herencias.
Las variables de las diferentes clases no se muestran
en la figura. Considrese la clase bicicleta. Puede incluir
variables como marca que contengan datos descriptivos de los elementos de la clase bicicleta. Adems, la
clase bicicleta incluye las variables que incluyen referencias o conjuntos de referencias a los objetos de las
clases ruedas, frenos, cambio y cuadro.
El concepto de continente es importante en los sistemas orientados a objetos porque permite que los
diferentes usuarios examinen los datos con diferente
detalle. Los diseadores de ruedas pueden concentrarse en los elementos de la clase ruedas sin tener
que preocuparse mucho, si no tienen que preocuparse en absoluto, de los objetos de las clases cambio o
frenos. Los empleados de mrketing que intenten fijar
el precio de toda la bicicleta pueden hacer referencia
a todos los datos correspondientes a la bicicleta
haciendo referencia al elemento adecuado de la clase
bicicleta. La jerarqua de continentes se utiliza para
buscar todos los objetos contenidos en los objetos bicicleta.
En ciertas aplicaciones un objeto puede estar incluido en varios objetos. En esos casos la relacin de continentes se representa mediante un GAD en lugar de
mediante una jerarqua.

8.2.6. Continentes de objetos

Se pueden utilizar las referencias entre objetos para


modelar diferentes conceptos del mundo real. Uno de
estos objetos es el de continentes de objetos. Para ilus-

bicicleta

rueda

llanta

radios

freno

neumtico

palanca

cambio

zapata

cable

FIGURA 8.6. Jerarqua de continentes de la base de datos para el diseo de bicicletas.


199

cuadro