Mariela Vergara Sols 8 A

Panorama sobre conceptos de orientacin a objetos

El trmino de orientacin a objetos (OO) tiene sus orgenes en los
lenguajes de programacin OO. Hoy, los conceptos asociados a la
orientacin a objetos se aplican en los campos de las bases de datos,
ingeniera del software, bases de conocimiento, inteligencia artificial y
sistemas de computacin en general. Los lenguajes de programacin OO
tienen sus races en el lenguaje SIMULA, propuesto en el ao 1960. En
dicho lenguaje, el concepto de clase agrupa la estructura interna de un
objeto en una declaracin de clase. En consecuencia, los investigadores
propusieron el concepto de tipo de datos abstracto, que ocultaba la
estructura de datos interna y especificaba todas las operaciones
externas que se le podan aplicar a dicha estructura, llegando al
concepto de encapsulacin. El lenguaje SMALLTALK, desarrollado por
Xerox PARC en los aos 70, fue uno de los primeros en incorporar
conceptos de OO, como paso de mensajes y herencia.
Un lenguaje de programacin OO puro, se conoce como aquel que ha
sido explcitamente diseado para ser orientado a objetos. Por otro lado,
existen los lenguajes de programacin OO hbridos, que no son ms que
lenguajes de programacin tradicionales a los que se les han
incorporado unos conceptos de orientacin a objetos. Un buen ejemplo
de ello es el lenguaje C++.
Un objeto consta de dos componentes: el estado (el valor) y el
comportamiento (las operaciones). Por lo tanto, es algo similar a una
variable de programa en un lenguaje de programacin, excepto que
tpicamente tendr una compleja estructura de datos as como unas
operaciones especficas definidas por el programador. Los objetos en
lenguajes de programacin orientados a objetos existen nicamente
durante la ejecucin del programa y se les llama objetos transitorios.
Una base de datos OO puede alargar la existencia de los objetos de
forma que sean almacenados de forma permanente, y as los objetos
persisten incluso despus de la ejecucin del programa y puedan ser
recuperados ms tarde y compartidos con otros programas. En otras
palabras, las bases de datos OO almacenan objetos persistentes
permanentemente en un almacenamiento secundario, y permite la
comparticin de esos objetos con otros programas y aplicaciones. Esto
requiere la incorporacin de otros detalles relacionados con bases de
datos, como son mecanismos de indexacin, control de concurrencia y
recuperacin.
Uno de los objetivos de una base de datos OO es mantener una cierta
correspondencia entre objetos de la base de datos y el mundo real, de
forma que los objetos no pierdan su integridad e identidad y puedan ser

Mariela Vergara Sols 8 A

fcilmente identificables y utilizables. Por ello, las BDOO proporcionan un
identificador nico a cada objeto (OID). Esto se puede comparar con el
modelo relacional donde cada relacin tena su propia clave primaria
que la identificaba de forma nica. Si el valor de la clave primaria
cambia, la tupla tendr una nueva identidad, incluso si sigue
representando al mismo objeto del mundo real. De forma alternativa, un
objeto del mundo real puede tener diferentes nombres para atributos
claves en diferentes relaciones, haciendo difcil de comprender que las
claves representan al mismo objeto (por ejemplo, un identificador de
objeto puede ser representado como EMP_ID en una relacin y como
SSN en otra).
Otra caracterstica de las BDOO es que los objetos pueden tener una
estructura de objeto de complejidad arbitraria, con el objetivo de
contener toda la informacin necesaria que describa al objeto. Por el
contrario, en los sistemas de bases de datos tradicionales, la
informacin sobre un objeto complejo est dispersa entre muchas
relaciones o registros, llevando a la prdida de correspondencia directa
entre un objeto del mundo real y su representacin en una BD.
La estructura interna de un objeto en lenguajes de programacin OO
incluye la especificacin de variables de instancias, que almacenan el
valor que define el estado interno del objeto. De esta forma, una
variable de instancia es similar al concepto de un atributo, excepto que
las variables de instancia pueden ser encapsuladas en los objetos y as
no es necesario que sean visibles a usuarios externos. Tambin pueden
ser de tipos de datos arbitrariamente complejos. Los sistemas OO
permiten la definicin de operaciones o funciones que pueden ser
aplicadas a objetos de un tipo en particular. De hecho, algunos modelos
de OO insisten en que todas las operaciones que un usuario pueda
aplicar a un objeto deben ser predefinidas. Esto fuerza una completa
encapsulacin de los objetos. Esta aproximacin rgida se ha relajado en
la mayora de los modelos de datos OO por varias razones. En primer
lugar, el usuario de la BD muchas veces necesita saber los nombres de
los atributos para que pueda especificar condiciones de seleccin en los
atributos para obtener objetos especficos. En segundo lugar, la
completa encapsulacin implica que cada simple obtencin requiere una
operacin predefinida, haciendo que las consultas hechas ad hoc sean
difciles de especificar en el momento.
Para fomentar la encapsulacin, una operacin se define en dos partes.
En la primera, llamada la signatura o interfaz de la operacin, se
especifican el nombre de la operacin y los argumentos. En la segunda
parte, llamada el mtodo o el cuerpo, se especifica la implementacin
de la operacin. Las operaciones pueden ser invocadas mediante el paso
de un mensaje al objeto, que incluye el nombre de la operacin y los

Mariela Vergara Sols 8 A

argumentos. Entonces, el objeto ejecuta el mtodo para dicha
operacin. Esta encapsulacin permite la modificacin, de la estructura
interna de un objeto, as como la implementacin de sus operaciones sin
tener que molestar a programas externos que invocan esas operaciones.
De esta forma, la encapsulacin proporciona cierta independencia de los
datos y las operaciones.
Otros conceptos clave en los sistemas OO son la jerarqua de tipos y
clases y la herencia. Esto permite la especificacin de nuevos tipos de
clases que heredan parte de la estructura y operaciones de otros tipos
que fueron previamente definidos. Esto facilita el desarrollo incremental
de tipos de datos de un sistema, y la reutilizacin de definiciones de
tipos existentes cuando creamos nuevos tipos de objetos.
Un problema en las BDOO iniciales era la forma en que se representaban
las relaciones entre los objetos. La insistencia inicial de que era
necesaria una completa encapsulacin llevaba a argumentar que las
relaciones no se deban expresar explcitamente, sino que se tenan que
describir definiendo mtodos apropiados que localizasen objetos
relacionados. Sin embargo, esta aproximacin no funcionaba muy buen
en bases de datos complejas con muchas relaciones, porque es muy til
identificar esas relaciones y hacerlas visibles para los usuarios. El
estndar ODMG 2.0 ha reconocido esta necesidad y representa
relaciones binarias en forma de par de relaciones inversas (esto es,
introduciendo los OID de los objetos relacionados en el mismo objeto).
Algunos sistemas OO proporcionan capacidades para manejar mltiples
versiones del mismo objeto (una caracterstica que es esencial en el
diseo y aplicaciones de ingeniera). Por ejemplo, una versin antigua de
un objeto que representa a u un diseo testado y verificado debera ser
retenida hasta que la nueva versin es testada y verificada. La nueva
versin puede incluir slo unas pocas versiones actualizadas de los
componentes del objeto, dejando intactas las restantes. Adems de
permitir versiones, las BDOO tambin deberan permitir la evolucin del
esquema que se da cuando las declaraciones de los tipos cambian o
cuando se crean nuevos tipos o relaciones. Estas dos ltimas
caractersticas no son propias de BDOO y deberan ser incluidas en todos
los tipos de SGBD.
Otro concepto de OO es el polimorfismo, que es la capacidad de aplicar
diferentes objetos en una operacin. Es una situacin as, el nombre de
una operacin puede referirse a distintas implementaciones,
dependiendo del tipo de objeto al que se le est realizando la operacin.
Esta caracterstica tambin se denomina operator overloading o
sobrecarga de operadores. Por ejemplo, una operacin para calcular el
rea de una figura geomtrica puede diferir en la implementacin,

Mariela Vergara Sols 8 A

dependiendo de si es un tringulo, cuadrado, o crculo. Esto puede
requerir el uso de una asociacin tarda del nombre de la operacin al
mtodo apropiado en tiempo de ejecucin, cuando se sabe cul es el
tipo de objeto al que se quiere aplicar la operacin.

Identidad
de
objeto,
constructores de tipos

estructura

de

objeto

Identidad de objeto
Un sistema de bases de datos orientado a objetos proporciona una
identidad nica a cada objeto independiente almacenado en la base de
datos. Esta identidad, normalmente se implementa mediante un
identificador de objeto nico (OID), generado por el sistema. El valor de
este identificador no es visible al usuario externo, pero se usa
internamente por el sistema para identificar a cada objeto y poder crear
y manejar referencias entre objetos.
La principal propiedad de un OID es que debe ser inmutable; es decir, el
valor del OID de un determinado objeto no debe cambiar nunca. Esto
preserva la identidad del objeto del mundo real que se representa. Por lo
tanto, una BDOO debe tener algn mecanismo para generar
identificadores nicos y que permita preservar la propiedad de
inmutabilidad de los mismos. Tambin sera deseable que cada
identificador se usara una sola vez, o sea, que incluso si un objeto se
elimina de la BD, su identificador no sea asignado a otro objeto. Estas
propiedades implican que el OID no depende de ninguno de los atributos
del objeto, ya que stos pueden cambiarse o corregirse. Tambin se
considera como inapropiado basar el OID del objeto en la direccin fsica
del objeto almacenado, porque la misma direccin puede cambiar
cuando se efecte una reorganizacin fsica de la BD. Sin embargo,
algunos sistemas utilizan la direccin fsica para aumentar la eficiencia
al obtener un objeto. Si la direccin cambiase, se utilizara un apuntador
indirecto, que dara la nueva direccin.
Algunos modelos de datos orientados a objetos antiguos requeran que
todo (desde un simple valor hasta un objeto complejo) deba
representarse como un objeto, lo que quiere decir que hasta el valor
ms simple tena su propio OID. Esto permita que dos valores iguales
tuvieran distintos OIDs, lo cual podra ser til en determinados casos. Por
ejemplo, el entero de valor 50 puede usarse a veces para representar un
peso en kilogramos y otras veces para representar la edad de una
persona. Aunque sea til en el plano terico, no es muy prctico ya que
lleva a la generacin de demasiados OIDs. As, la mayora de sistemas

Mariela Vergara Sols 8 A

de BDOO permiten la representacin de objetos y de valores. Todos los
objetos deben tener su propio OID inmutable, mientras que un valor no
tiene OID y permanece por s mismo. As, un valor normalmente se
almacena dentro de un objeto y no puede ser referenciado desde otros
objetos.

Estructura de objeto
En las BDOO, los objetos complejos pueden construirse a partir de otros
objetos ms simples mediante constructores de tipos. Podemos
representar a estos objetos como una tupla (i, c, v) donde i es un
identificador de objeto (su OID), c es un constructor de tipo y v es el
estado (el valor) del objeto.
Los constructores ms utilizados son los de tomo, tupla y conjunto,
junto a los de lista, bolsa y array. El constructor de tomo es usado para
representar a los valores atmicos bsicos que puede tener un objeto
(como nmeros enteros, reales, booleanos...).
El estado de un objeto (v en la tupla) se interpreta a partir del
constructor (c). Si c es tomo, entonces v es un valor atmico de valores
bsicos que utiliza el sistema. Si c es conjunto, v es un conjunto de
identificadores de objetos ({i1, i2, i3...}). Con c siendo una tupla, v es
una tupla de la forma <a1:i1, a2:i2, a3:i3...> donde aj es un nombre de
atributo, y cada ij es un identificador de objeto. Con c siendo lista v es
una lista ordenada [i1, i2, i3...] de identificadores de objetos del mismo
tipo.
La lista es similar al conjunto salvo en que la lista est ordenada, por lo
que podemos hablar del i-simo elemento. Una lista puede tener un
nmero arbitrario de elementos. Pero si hablamos de un nmero
determinado, entonces c es un array.
Una bolsa se diferencia del conjunto en que en el conjunto todos los
elementos deben ser diferentes, mientras que en la bolsa puede haber
duplicados.
Ejemplos de estructuras:
o1 = (i1, tomo, Houston)
o2 = (i2, tomo, Bellaire)
o3 = (i3, tomo, Sugarland)
o4 = (i4, tomo, 5)
o5 = (i5, tomo, Investigacin)
o6 = (i6, tomo, 22-05-1988)
o7 = (i7, conjunto, {i1, i2, i3})

Mariela Vergara Sols 8 A

o8 = (i8, tupla, <NOMBRED:i5, NUMEROD:i4, JF:i9, LOCALIZACIONES:i7,
EMPLEADOS:i10, PROYECTOS:i11>)
o9 = (i9, tupla, <JEFE:i12, FECHA_INIC_JEFE:i6>)
o10 = (i10, conjunto, {i12, i13, i14})
o11 = (i11, conjunto, {i15, i16, i17})
o12 = (i12, tupla, <NOMBRE:i18, INIC:i19, APELLIDO:i20, NSS:i21,
SALARIO:i26, SUPERVISOR:i27, DEPT:i8>)
Puede verse que los primeros seis objetos son simplemente valores
atmicos. Pero hay otros que estn compuestos por otros objetos. El
objeto o7 es un objetos con valor de conjunto que representa todas las
ubicaciones de un departamento. El objeto o8 es un objeto con valor de
tupla que representa al departamento 5. El objeto o9 representa a un
jefe de departamento, y el objeto o12 representa a un empleado.
Con este modelo, un objeto puede representarse como una estructura
de grfico que se puede construir aplicando repetidamente
constructores de tipo. Un nodo puede representarse mediante su
identificador y su constructor de tipo. En el caso de los objetos con valor
atmico, se indica con una flecha que va desde el objeto que tiene ese
valor atmico hasta el valor propiamente dicho.
Este modelo permite dos tipos de definiciones para una comparacin
entre objetos. Dos objetos tienen estados idnticos si los grficos que
representan sus estados son idnticos en todos los sentidos, hasta los
OIDs en cada nivel. Una definicin menos estricta es la de estados
iguales. En este caso, la estructura de los grficos debe ser igual en
ambos casos, y todos los valores atmicos deben ser iguales. Sin
embargo, se permite que algunos nodos internos correspondientes en
los dos grficos puedan tener objetos con distintos OIDs.
Ejemplo:
o1
o2
o3
o4
o5
o6

=
=
=
=
=
=

(i1,
(i2,
(i3,
(i4,
(i5,
(i6,

tupla, <a1:i4, a2:i6>)

tupla, <a1:i5, a2:i6>)
tupla, <a1:i4, a2:i6>)
tomo, 10)
tomo, 10)
tomo, 20)

Los objetos o1 y o2 tienen estados iguales, ya que sus estados en el

nivel atmico son los mismos, aunque se llega a los mismos valores a
travs de objetos distintos (o4 y o5). Los estados de los objetos o1 y o3
son idnticos, aunque no lo son los propios objetos porque tienen
distintos OIDs.

Mariela Vergara Sols 8 A

Constructores de tipos
Se puede utilizar un lenguaje de definicin de objetos (ODL) para definir
los tipos de objetos para una aplicacin de base de datos determinada.
Los constructores de tipos pueden servirnos para definir las estructuras
de datos de un esquema de base de datos orientada a objetos.
Ejemplo:
define type Empleado
tuple (
nombre:
string;
inic:
char;
apellido:
string;
nss:
string;
fechanacimiento: Fecha;
direccin:
string;
sexo:
char;
salario:
float;
supervisor:
Empleado;
dept:
Departamento; );
define type Fecha
tuple (
ao:
integer;
mes:
integer;
da:
integer;
);
define type Departamento
tuple (
nombred:
string;
nmerod:
integer;
jf:
tuple (
jefe:
Empleado;
fechainicio: Fecha;
);
localizaciones:
set (string);
empleados:
set (Empleado);
proyectos:
set (Proyecto);
);
Los atributos que hacen referencia a otros objetos pueden considerarse
como referencias a otros objetos, y por lo tanto pueden usarse para
representar relaciones entre objetos. El valor del atributo en cuestin
podra ser el OID del objeto al que referencia. Una relacin binaria puede
representarse en una direccin, o bien tener una referencia inversa. Por
ejemplo, el objeto Empleado tiene una referencia al departamento en el
que trabaja, y el objeto Departamento puede tener una serie de
referencias a empleados que trabajan en l. El estndar ODMG 2.0
permite declarar explcitamente los inversos como atributos de relacin
para asegurar que las referencias inversas sean consistentes.

Mariela Vergara Sols 8 A

Encapsulacin de operaciones, mtodos y persistencia
El concepto de encapsulacin es una de las principales caractersticas de
los lenguajes y sistemas OO. Est relacionado con los conceptos de tipos
de datos abstractos y de ocultacin de la informacin en los lenguajes
de programacin. En los sistemas tradicionales no era lo habitual, dado
que la costumbre era hacer que la estructura de los objetos fuera visible
para los usuarios y los programas externos.

Especificacin del comportamiento del objeto mediante

operaciones de clase
La idea principal es definir el comportamiento de un tipo de objeto
basado en las operaciones que se pueden aplicar externamente a
objetos de ese tipo. La estructura interna del objeto queda oculta y slo
se puede acceder a ella mediante una serie de operaciones predefinidas
(para crear y destruir los objetos, para modificar su estado, o para
obtener informacin de l). En general, la implementacin de una
operacin puede especificarse en un lenguaje de programacin de
propsito general que ofrezca flexibilidad y potencia para definir las
operaciones.
Mediante esta idea, los usuarios slo perciben la interfaz del objeto
donde se definen los nombres y argumentos de las operaciones que
pueden hacerse con l. La implementacin queda oculta, que incluye la
definicin de las estructuras de datos y la implementacin de las
operaciones que permiten acceder a esas estructuras.
En terminologa de OO, se denomina signatura a la interfaz de cada
operacin, y mtodo a la implementacin.
En las aplicaciones de BD, el requisito de que todos los objetos queden
encapsulados es demasiado estricto. Una forma de relajarlo un poco
consiste en dividir la estructura en atributos visibles y ocultos. Los
operadores externos o un lenguaje de consulta de alto nivel pueden
tener acceso directo a los atributos visibles para leerlos. Casi todos los
SGBGOO emplean lenguajes de consulta de alto nivel para tener acceso
a los atributos visibles. El lenguaje de consulta OQL se propone como
lenguaje de consulta estndar para BDOO.
En la mayora de los casos, las operaciones que actualizan el estado de
un objeto estn encapsuladas. Es una forma de definir la semntica de
actualizacin de los objetos. Cada tipo de objeto tiene sus restricciones
de integridad programadas en los mtodos que crean, eliminan y

Mariela Vergara Sols 8 A

actualizan los objetos. Ms recientemente, el ODL para el estndar
ODMG 2.0 permite la especificacin de algunas restricciones como
claves y relaciones inversas (integridad referencial).
El trmino clase se utiliza para referirse a una definicin de tipo de
objetos, junto con las definiciones de las operaciones para ese tipo. Para
cada clase se declaran varias operaciones, y la signatura de cada
operacin se incluye en la definicin de la clase. Para cada operacin se
debe definir un mtodo (implementacin) en otro lugar. Las operaciones
ms habituales incluyen el constructor de objeto, el destructor y varias
operaciones para modificar el objeto. Otras operaciones nos permitirn
recuperar informacin acerca del objeto.
Ejemplo:
define class Empleado
type tuple (nombre:
string;
inic:
char;
apellido:
string;
fechanacimiento: Fecha;
direccin:
string;
sexo:
char;
salario:
float;
supervisor:
Empleado;
dept:
Departamento;
operations edad:
integer;
crear_emp:
Empleado;
borrar_emp:
boolean;
end Empleado;
define class Departamento
type tuple (nombred:
nmerod:
jf:

);

string;
integer;
tuple (
jefe:
Empleado;
fechainicio: Fecha;
);
localizaciones:
set (string);
empleados:
set (Empleado);
proyectos:
set (Proyecto);
);
operations num_de_emps: integer;
crear_dept:
Departamento;
borrar_dept:
boolean;
asignar_emp(e: Empleado): boolean;
(* aade un empleado al departamento *)
quitar_emp(e: Empleado):
bolean;
(* elimina un empleado del departamento *)
end Departamento;

Mariela Vergara Sols 8 A

Una operacin se aplica automticamente a un objeto mediante la
notacin de punto. Por ejemplo, para averiguar el nmero de empleados
de un departamento d, haramos d.num_de_emps.

Especificacin de la persistencia de objetos a travs del

nombramiento y la alcanzabilidad
Lo normal es que los objetos sean creados por programas en ejecucin,
al invocar la operacin de construccin de objetos. Por supuesto, no
todos los objetos estn destinados a ser almacenados en la BD. Hay
objetos transitorios que slo existen durante la ejecucin del programa.
Los objetos persistentes, por su parte, son los que se almacenan en la
BD y persisten despus de la ejecucin del programa. Los mecanismos
habituales para hacer persistente un objeto son el nombramiento y la
alcanzabilidad.
El mecanismo de nombramiento implica dar al objeto un nombre
persistente y nico mediante el cual pueda ser recuperado. Ese nombre
persistente se le puede dar mediante una sentencia o una operacin en
un programa. Todos los nombres que se den a los objetos deben ser
nicos en cada base de datos particular. As, los objetos persistentes
nombrados se usan como puntos de entrada a la base de datos.
Obviamente, en una BD extensa, con miles de objetos no resulta nada
prctico dar nombres a todos los objetos, por lo que a la mayora de los
objetos se los convierte en persistentes utilizando el segundo mtodo,
la alcanzabilidad. ste funciona haciendo que el objeto sea alcanzable
desde algn objeto persistente. Se dice que un objeto es B es alcanzable
desde un objeto A si una secuencia de referencias del grfico del objeto
conduce del objeto A al objeto B.
Ejemplo:
define class ConjuntoDepartamento
type
set (Departamento);
operations aadir_dept (d: Departamento): boolean;
(* aade un departamento al objeto ConjuntoDepartamento
*)
quitar_dept (d: Departamento): bolean;
(*
elimina
un
departamento
del
objeto
ConjuntoDepartamento *)
crear_conjunto_dept: ConjuntoDepartamento;
borrar_conjunto_dept: bolean;
end ConjuntoDepartamento;

Mariela Vergara Sols 8 A

.......
persistent name TodosDepartamentos: ConjuntoDepartamento;
(* TodosDepartamentos es un objeto nombrado persistente de tipo
ConjuntoDepartamento *)
......
d:= crear_dept;
(* crear un nuevo objeto Departamento en la variable d *)
..........
b:= TodosDepartamentos.aadir_dept (d);
(* hace a de persistente aadindolo
TodosDepartamento *)

al

conjunto

persistente

Hemos creado un objeto del tipo ConjuntoDepartamento, y le hemos

dado un nombre, hacindolo as persistente. Cualquier objeto del tipo
Departamento que se aada al conjunto con la operacin pertinente se
vuelve
persistente
en
virtud
de
ser
alcanzable
desde
TodosDepartamentos. Al objeto TodosDepartamentos se le denomina a
menudo la extensin de la clase Departamento, ya que contendr todos
los objetos persistentes de tipo Departamento. El estndar ODL de
ODMG ofrece al diseador del esquema la opcin de nombrar una
extensin como parte de la definicin de la clase.
Hay que destacar la diferencia entre los modelos de bases de datos
tradicionales y las bases de datos OO. En un modelo tpico de bases de
datos, se da por hecho que todos los objetos son persistentes. As pues,
cuando se define un tipo de entidad o una clase como Empleado en el
modelo EER, representa tanto la declaracin de tipo Empleado como un
conjunto persistente de todos los objetos Empleado. En el enfoque OO,
una declaracin de clase Empleado slo especifica el tipo y las
operaciones de una clase de objetos. El usuario debe definir por
separado un objeto persistente de tipo conjunto o lista cuyo valor sea la
coleccin de referencias a todos los objetos Empleado persistentes.

Jerarquas de tipo y herencia

Son caractersticas importantes de los sistemas de bases de datos
orientadas a objetos. Las jerarquas de tipo implican habitualmente una
restriccin sobre las extensiones correspondientes a los tipos de
jerarqua.

Mariela Vergara Sols 8 A

Jerarquas de tipo y herencia
Dado que en gran parte de aplicaciones de BD hay un gran nmero de
objetos, sera deseable poderlos clasificar segn su tipo. Pero adems,
tenemos un requisito adicional: que el sistema permita la definicin de
nuevos tipos basados en tipos predefinidos, dando origen a una
jerarqua de tipos (o de clases).
Por lo general, para definir un tipo se le asigna un nombre de tipo y una
serie de atributos y operaciones para el mismo. En algunos casos, los
atributos y las operaciones se denominan funciones, porque podemos
considerar a los atributos como operaciones con cero argumentos.
NOMBRE_DE_TIPO: funcin, funcin,..., funcin
PERSONA: Nombre, Direccin, Fechanac, Edad, NSS
En el tipo PERSONA, el nombre, la direccin la fecha de nacimiento y el
NSS pueden impementarse como atributos almacenados, mientras que
la edad se puede implementar mediante un mtodo que calcula la edad
a partir del valor del atributo Fechanac y de la fecha actual.
Cuando el diseador o el usuario desean crear un nuevo tipo similar,
pero no idntico, a un tipo ya existente, resulta til el concepto de
subtipo. El subtipo heredara todas las funciones del tipo predefinido, al
cual se le llama supertipo.
EMPLEADO: Nombre, Direccin, Fechanac, Edad, NSS, Salario, FechaAlta,
Antigedad
ESTUDIANTE: Nombre, Direccin, Fechanac, Edad, NSS, Titulacin, NM
Como ESTUDIANTE y EMPLEADO incluyen todas las funciones de
PERSONA ms algunas funciones adicionales, podemos declararlos como
subtipos de PERSONA. Los dos heredarn las funciones definidas en
PERSONA. As, slo ser necesario definir las nuevas funciones que no se
heredan.
La idea de definir un tipo implica definir todas sus funciones e
implementarlas. Cuando se define un subtipo, puede heredar todas
estas funciones y su implementacin. Slo es necesario definir e
implementar las funciones que son especficas o locales para el subtipo
y que no estn implementadas en el supertipo.
EMPLEADO subtype-of PERSONA: Salario, FechaAlta, Antigedad
ESTUDIANTE subtype-of PERSONA: Titulacin, NM

Mariela Vergara Sols 8 A

En general, un subtipo incluye todas las funciones que estn definidas
para su supertipo, ms algunas adicionales que le son especficas. Por
ello, es posible definir una jerarqua de tipos para indicar los vnculos
subtipo/supertipo entre todos los tipos declarados en el sistema.

Restricciones sobre extensiones correspondientes a una

jerarqua de tipos
En las aplicaciones de BD es habitual que cada tipo o subtipo tenga una
extensin asociada a l, que contenga la coleccin de todos los objetos
persistentes de ese tipo o subtipo. En ese caso, la restriccin es que
todos los objetos de una extensin que pertenezcan a un subtipo deben
ser tambin miembros de la extensin que corresponda a su supertipo.
En algunos sistemas, existe un tipo predefinido (llamado RAIZ o clase
OBJETO), cuya extensin contiene a todos los objetos del sistema.
Entonces, se lleva a cabo una clasificacin asignando los objetos a
subtipos adicionales, creando una jerarqua de tipos o una jerarqua de
clases para el sistema. En el modelo ODMG el usuario puede especificar
una extensin para cada tipo dependiendo de la aplicacin.
En la mayor parte de los sistemas OO, se hace una distincin entre
objetos y colecciones persistentes y transitorias. Una coleccin
persistente contiene una coleccin de objetos que se almacena
permanentemente en la BD, de modo que mltiples programas puedan
tener acceso a ella. Una coleccin transitoria slo existe temporalmente
durante la ejecucin de un programa, que desaparece cuando el
programa termina.
EER-OO en Base de Datos Orientada a Objetos
Los objetos se corresponden con las entidades del modelo E-R (entidadrelacin). El paradigma orientado a objetos est basado en el
encapsulamiento de los datos y del cdigo relacionado 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.
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.

Mariela Vergara Sols 8 A

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: 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.