Mariela Vergara Sols 8 A

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 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 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, 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, estructura de objeto y constructores de tipos

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 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 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})o8 = (i8, tupla, )o9 = (i9, tupla, )o10 = (i10, conjunto, {i12, i13, i14})o11 = (i11, conjunto, {i15, i16, i17})o12 = (i12, tupla, )

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 = (i1, tupla, )o2 = (i2, tupla, )o3 = (i3, tupla, )o4 = (i4, tomo, 10)o5 = (i5, tomo, 10)o6 = (i6, 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.

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 Empleadotuple (nombre:string;inic:char;apellido:string;nss:string;fechanacimiento:Fecha;direccin:string;sexo:char;salario:float;supervisor:Empleado;dept:Departamento;);define type Fechatuple (ao:integer;mes:integer;da:integer; );define type Departamentotuple (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.

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 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 Empleadotype 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 Departamentotype tuple (nombred:string;nmerod:integer;jf:tuple (jefe:Empleado;fechainicio:Fecha;);localizaciones:set (string);empleados:set (Empleado);proyectos:set (Proyecto););operationsnum_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;

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 ConjuntoDepartamentotypeset (Departamento);operationsaadir_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;

.......

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 al conjunto persistente TodosDepartamento *)

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.

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, AntigedadESTUDIANTE: 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, AntigedadESTUDIANTE subtype-of PERSONA: Titulacin, NM

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 (entidad-relacin). 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.

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.