Universitat Politcnica de Catalunya

Departament de Llenguatges i Sistemes Informtics

Esquemas Externos en Bases de Datos Orientadas a Objetos

Programa de Doctorado de Software

Director:

Flix Saltor i Soler

Doctorando:

Jos Samos Jimnez

Barcelona, 12 de Mayo de 1995

External Schemes in Object Oriented Databases Abstract

An external schema definition mechanism is very useful for object oriented databases; conceptually speaking, this kind of databases is more robust than structural databases, but they also have to be more flexible because they hold more information. In this work, once the main concepts of object oriented data models are introduced, and also the external schema concept, we present the state of the art and a classification of external schema definition methodologies for object oriented databases. The definition of derived classes is one of the main steps of these methodologies; so, we also present a classification of derived class definition methodologies. Lastly, we present the general lines of a new external schema definition methodology that solves some of the problems of existing methodologies.

Esquemas Externos en Bases de Datos Orientadas a Objetos Resumen

Un mecanismo de utilidad en las conceptualmente datos puramente utilizacin por definicin de esquemas externos resulta de gran bases de datos orientadas a objetos; aunque estas bases de datos son ms robustas que las bases de estructurales, tambin exigen mayor flexibilidad en su contener ms informacin.

En este trabajo, una vez introducidos los conceptos fundamentales de los modelos orientados a objetos, as como el concepto de esquema externo, se presenta el estado del arte y una clasificacin de las metodologas de definicin de esquemas externos en bases de datos orientadas a objetos. Uno de los pasos ms importantes de estas metodologas es la definicin de clases derivadas; por tanto, tambin se presenta una clasificacin las distintas metodologas de definicin de clases derivadas. Por ltimo, presentamos las lneas generales de una nueva metodologa de definicin de esquemas externos que resuelve algunos de los problemas de las metodologas anteriores.

Contenido
1. Introduccin .................................................. 4 1.1. Modelos Orientados a Objetos........................... 5 2. Esquemas Externos ............................................. 7 2.1. Arquitectura General de la Base de Datos............... 7 2.2. Esquemas Externos y Vistas............................. 8 2.3. Propiedades de los Esquemas Externos................... 8 3. Metodologas de Definicin de Esquemas Externos ............... 9 3.1. Esquema Externo Subesquema del Esquema Conceptual.................................................. 9 3.2. Esquema Externo NO Subesquema del Esquema Conceptual.................................................. 10 3.3. Esquema Externo como Clase del Esquema Conceptual.................................................. 11 4. Definicin de Clases Derivadas ................................ 12 4.1. Objetos de las Clases Derivadas........................ 12 4.2. Integracin de una Clase Derivada en un Esquema........ 13 5. Nueva Metodologa de Definicin de Esquemas Externos .......... 17 5.1. Caractersticas de las Metodologas Presentadas........ 18 5.2. Definicin de la Metodologa........................... 20 5.3. Relaciones de Derivacin............................... 23 5.4. Obtencin del Esquema Externo a Partir del Esquema Global.............................................. 24 5.5. Caractersticas de la Nueva Metodologa................ 27 6. Conclusiones .................................................. 28 Bibliografa ..................................................... 30

1. Introduccin
Las bases de datos orientadas a objetos (BDOO) son una extensin de las bases de datos puramente estructurales, p.e. bases de datos relacionales (BDR), en las que se ha sacado como factor comn e introducido en la base de datos (BD) elementos que anteriormente estaban en las aplicaciones que las utilizaban. Las BDOO contienen datos y adems modelan el comportamiento de stos; el diseador del esquema de la BD ha de considerar aspectos estructurales y de comportamiento del dominio a modelar. Por regla general, no basta con disponer de una sola visin de los datos, es decir, no basta con disponer de un solo esquema de BD; las BD requieren frecuentemente la coexistencia de mltiples abstracciones sobre los mismos datos. Puede haber aplicaciones que necesiten ver los datos de la BD de acuerdo con una estructura y comportamiento diferentes de los definidos en el esquema original, o bien tan slo necesiten una parte de la BD. El mecanismo que permite la posibilidad de trabajar con varios esquemas sobre una misma BD es el de definicin de esquemas externos. En las BDOO, respecto a las BD puramente estructurales, se acenta la necesidad de disponer de un mecanismo de definicin de esquemas externos. La razn principal es que la BD contiene ms informacin en el caso de las BDOO, ya que adems de contener datos, la BD modela el comportamiento de stos. As, los esquemas externos ayudan a gestionar la complejidad que supone interaccionar con los datos, ocultando los detalles no necesarios, presentando la informacin en el formato ms apropiado para cada usuario y adaptando la interpretacin que se hace de los datos a las necesidades especficas del usuario. Adems pueden proporcionar un nivel de seguridad donde slo la informacin permitida para algunos usuarios est presente en los esquemas externos que usan. Es decir, los esquemas externos permiten tener relativismo semntico [SaGa93] en la BD. En el caso de las BDR, los esquemas externos son de uso bastante limitado, pues slo se pueden realizar modificaciones en los datos mediante esquemas externos bajo condiciones muy estrictas. Este problema se puede subsanar en parte en las BDOO gracias a los mecanismos que ofrecen (especialmente la identidad y el encapsulamiento), flexibilizndose as las condiciones en las que es posible realizar modificaciones sobre los datos base. Dada la importancia de disponer de un mecanismo de definicin de esquemas externos, en este trabajo se proponen las lneas generales de una metodologa de definicin de esquemas externos para BDOO. En primer lugar, en el resto de este apartado, se presentan los conceptos generales comunes a gran parte de los modelos orientados a objetos. En el apartado segundo se describe la arquitectura de la BD, se presentan los distintos niveles de esquemas de la BD para situar convenientemente los esquemas externos dentro de esta arquitectura. El apartado tercero est dedicado a realizar una clasificacin de las metodologas de definicin de esquemas externos para BDOO. Una fase de las metodologas consideradas es la definicin de clases derivadas; por su importancia, esta fase se estudia con ms nivel de detalle en el apartado cuarto. En el apartado quinto se presentan las lneas generales de la nueva metodologa propuesta, mostrndose cmo soluciona algunos de los problemas de las metodologas anteriores. Por ltimo, se sealan una serie de conclusiones en el apartado sexto.

1.1. Modelos Orientados a Objetos

Independientemente de las diferencias existentes entre los distintos modelos orientados a objetos, existen un conjunto de conceptos comunes a gran parte de ellos, dichos conceptos se describen en este apartado. Se consideran tres dimensiones de organizacin de los distintos elementos que intervienen, representadas por las siguientes abstracciones semnticas [CaSG92]: clasificacin/instanciacin, generalizacin/especializacin y agregacin/descomposicin.

a. Objetos
Un objeto representa un concepto abstracto o concreto del mundo de la aplicacin. Corresponde al concepto de entidad en los modelos semnticos. Cada objeto tiene un estado y una identidad, adems presenta un comportamiento determinado. El estado son los valores que toman los distintos atributos del objeto. La identidad es un identificador nico en la BD, definido globalmente por el sistema e independiente del estado del objeto, se le asigna a cada objeto en el momento de su creacin y es propio del objeto. No se puede acceder directamente a los componentes de un objeto, sino que se aplica el principio de encapsulamiento y slo pueden ser manipulados mediante la interfaz asociada al objeto; la implementacin de las operaciones definidas en la interfaz define el comportamiento del objeto, en el sentido de cmo reacciona a dichas operaciones en trminos de cambios de estado e interaccin con otros objetos.

b. Clases
Una clase est formada por un conjunto de objetos "similares" del dominio de aplicacin que forma su extensin. La similitud entre los objetos pertenecientes a una clase consiste en que todos ellos son del mismo tipo (en el sentido de tipo abstracto de datos, que define la estructura y el comportamiento de los objetos). La nocin de clase tiene una doble vertiente: Por una parte es una descripcin genrica de todos los objetos que pertenecen a ella, se define el tipo de los objetos; por otro lado, la clase contiene el conjunto de objetos que forman parte de ella, siendo todos ellos del mismo tipo. As, al hablar de clase nos referimos a la vez al conjunto de objetos que forman parte de la clase y a la definicin del tipo comn de todos ellos asociado a la clase. Una clase tiene asociado un nico tipo, sin embargo, varias clases pueden tener asociado el mismo tipo para sus objetos. Un objeto puede pertenecer a varias clases al mismo tiempo, incluso teniendo stas asociados tipos distintos, por tanto, un objeto puede ser de varios tipos distintos al mismo tiempo. La relacin existente entre una clase y los objetos que contiene es una abstraccin semntica correspondiente a la dimensin de clasificacin/instanciacin: Los objetos son instancias de las clases a las que pertenecen.

c. Esquema de la BD
Un esquema de una BD est formado por un conjunto de clases relacionadas entre si. Entre las distintas clases de un esquema

existen dos tipos de relaciones fundamentales: Relaciones de agregacin y relaciones de herencia.

Herencia Agregacin

OBJETOS

PERSONAS
...

DIRECCIONES
... Poblacin()

Domiclio()

EMPLEADOS CLIENTES
... Categora() Sueldo()

Figura 1. Ejemplo de esquema de BDOO. Agregacin Los objetos no son necesariamente entidades simples, sino que pueden estar formados a su vez por otros objetos. Las relaciones de agregacin asocian un objeto con los distintos objetos que lo componen, estas relaciones se definen entre las clases que contienen dichos objetos. En la figura (1) tenemos un ejemplo de este tipo de relacin, se asocia la clase PERSONAS con la clase DIRECCIONES mediante una relacin de agregacin, considerando que el domicilio forma parte de los datos personales. Las relaciones de correspondiente a una clase con las los objetos de la Herencia En el ejemplo de la figura (1) existe una relacin de herencia entre las clases CLIENTES y PERSONAS. La clase CLIENTES es una subclase de la clase PERSONAS. A partir de esta definicin inicial, se pueden realizar modificaciones en la definicin de la clase CLIENTES, pero siempre han de cumplirse los requerimientos enunciados a continuacin. Por la doble vertiente del concepto de clase, como tipo y como conjunto de objetos, el que una clase sea subclase de otra significa que entre sus tipos existe una relacin de subtipo, y entre sus conjuntos de objetos respectivos una relacin de subconjunto. Por tanto, si CLIENTES es una subclase de PERSONAS, dado un objeto de la clase CLIENTES, ste pertenecer tambin a la clase PERSONAS, y dicho objeto podr ser usado indistintamente, segn las necesidades, como un objeto de una u otra clase. La relacin de herencia cumple la propiedad transitiva. Todas las clases de un esquema son subclases (directa o indirectamente) de la clase predefinida OBJETOS. En caso de permitir herencia mltiple, una clase puede ser directamente subclase de varias agregacin son una abstraccin semntica la dimensin de agregacin/descomposicin: Se asocia clases que contienen objetos que son componentes de primera y viceversa.

clases al mismo tiempo. As, en lugar de una jerarqua, por tener herencia mltiple las clases se organizan en un semi-retculo cuya raz es la clase predefinida OBJETOS. La relacin de herencia entre las clases es una abstraccin semntica correspondiente a la dimensin de generalizacin/especializacin: En el ejemplo considerado, la clase CLIENTES sera una especializacin de la clase PERSONAS a partir de la que se define, por tanto, tambin de todas las superclases de PERSONAS; por otro lado, la clase PERSONAS sera una generalizacin de la clase CLIENTES, as como de todas las posibles subclases de CLIENTES.

2. Esquemas Externos 2.1. Arquitectura General de la Base de Datos

El grupo de estudio ANSI/X3/SPARC define la siguiente arquitectura de tres niveles para bases de datos [ANSI75]:

Esquema Externo 1

Esquema Externo 2

Esquema Externo n

Esquema Conceptual

Esquema Interno

BD

Figura 2. Arquitectura de tres niveles de ANSI/X3/SPARC. El esquema interno especifica la organizacin fsica de la BD. El esquema conceptual describe la estructura lgica de todos los componentes de la BD. El esquema interno lo asla de los aspectos fsicos de la BD. En el esquema conceptual estn representados todos los elementos de inters para los distintos usuarios de la BD. Los esquemas externos definen las vistas particulares del esquema conceptual asociadas a diferentes grupos de usuarios. Cada esquema externo contiene la parte de la BD que es de especial relevancia para el grupo de usuarios correspondiente. El esquema conceptual puede considerarse como un caso especial de esquema externo, sera el esquema externo ms completo posible, ya que contiene todos los datos de la BD. El esquema interno proporciona independencia fsica de datos al esquema conceptual, mientras que el esquema conceptual proporciona independencia lgica a los distintos esquemas externos. La distincin entre esquema conceptual y esquemas externos se ha considerado de forma bastante generalizada en las BDR. Sin embargo, es frecuente que en BDOO no se considere la posibilidad de definir esquemas externos. En BDOO, slo en algunos pocos casos se ha tratado la definicin de esquemas externos, refirindose explcitamente a la

arquitectura ANSI/X3/SPARC [BaKe93, SoAD94, KiKe951], o bien implcitamente [TaYI88, AbBo91, Rund92a, GeSD93, TrSc93] identificndolos con la definicin de vistas.

2.2. Esquemas Externos y Vistas

En general, una vista es una abstraccin simplificadora de una estructura compleja. En los distintos trabajos sobre BDOO se encuentra el concepto de vista tratado con dos significados distintos: Vista como clase y vista como esquema. 1. Vista como clase [Kim89, HeSa91, Bert92, KiKS922, AlAr93, KiKe95]: El resultado de definir una vista es una clase obtenida a partir de un conjunto de clases (que pueden ser tambin otras vistas). La nueva clase se integra en el esquema de la BD donde se define. 2. Vista como esquema [TaYI88, AbBo91, Rund92a, BaKe93, GeSD93, TrSc93, SoAD94]: La definicin de vistas consideradas como esquemas correspondera a la definicin de esquemas externos sobre el esquema conceptual de la BD. En este trabajo se estudia el concepto de vista como esquema, que llamaremos esquema externo. Por otro lado, para evitar la ambigedad creada sobre el trmino vista, para referirnos al concepto de vista como clase utilizaremos el trmino de clase derivada.

2.3. Propiedades de los Esquemas Externos

Para que los esquemas externos proporcionen la flexibilidad que necesitan las BDOO, han de cumplir las propiedades siguientes:

Clausura de la definicin: Un esquema externo ha de ser un esquema segn el modelo orientado a objetos, con las mismas caractersticas que el esquema conceptual. Clausura del esquema [TaYI88]: Un esquema es cerrado si y slo si todas las clases pertenecientes al mismo son cerradas. Clausura de una clase en un esquema: Una clase en un esquema es cerrada si y slo si todos sus objetos estn relacionados con otros objetos igualmente pertenecientes a clases del esquema.

Al inicio de [KiKe95] se marcan como objetivo estudiar la definicin del nivel de esquemas externos en OODB; en principio, identifican este nivel con el concepto de vista. Sin embargo, slo estudian el concepto de vista entendida como clase derivada. Organizan las clases derivadas en un esquema aparte mediante relaciones de herencia; este esquema de clases derivadas no implementa el concepto de esquema externo, sino que slo se usa para reutilizar las definiciones realizadas con anterioridad, como mecanismo de definicin de clases. Las clases derivadas (en su esquema independiente) se relacionan con las clases base mediante una nueva relacin: "derived_from", que asocia una clase derivada con las clases base (u otras clases derivadas) sobre las que est definida. Indican que el concepto de vista correspondera al concepto de esquema, haciendo referencia al tratamiento que se hace de ste en [AbBo91], ms que al concepto de clase tal como ellos en realidad lo consideran.
2

Los esquemas externos han de proporcionar independencia lgica de datos [Rund92a, BaKe93], es decir, la modificacin de la definicin de un esquema externo, o la definicin de un nuevo esquema externo, no debe afectar al resto de esquemas externos definidos (a no ser que estn definidos sobre el esquema considerado). Transmisin de modificaciones: Para que sean correctas las modificaciones realizadas sobre los datos, usando esquemas externos, stas han de cumplir la regla de materializacin [KiKe95] o de preservacin de la equivalencia [BaKe93]. Es decir, una modificacin realizada en los datos incluidos en el esquema externo debe tener un efecto sobre el conjunto de los datos base (del esquema conceptual) de manera que esta modificacin quede reflejada correctamente en el esquema externo.

3. Metodologas de Definicin de Esquemas Externos

A continuacin se presenta una clasificacin de las distintas metodologas de definicin de esquemas externos de la bibliografa, realizada en funcin de la forma de definicin de los esquemas externos a partir del esquema conceptual; en particular se distingue entre las metodologas que requieren que todas las clases de los esquemas externos se encuentren previamente definidas en el esquema conceptual, y aquellas que permiten definir nuevas clases derivadas en los esquemas externos. Adems de esta clasificacin principal, se presenta como un caso aparte una metodologa en la cual se realiza la definicin de un esquema externo mediante una clase nueva del esquema conceptual3.

3.1. Esquema Externo Subesquema del Esquema Conceptual

La caracterstica fundamental de las metodologas de este grupo es que el esquema conceptual ha de contener todas las clases de los esquemas externos que se definen sobre l [Rund92a, GeSD93, TrSc93]. Es decir, el esquema externo ha de ser un subesquema del esquema conceptual: El esquema externo no puede incluir ninguna clase que no pertenezca directamente al esquema conceptual. La definicin del esquema externo se lleva a cabo en dos fases. En primer lugar, se completa el esquema conceptual aadindole las clases que se necesiten en el esquema externo y que an no estuvieran definidas; posteriormente, la definicin del esquema externo propiamente dicho consiste en la seleccin de un conjunto de clases del nuevo esquema conceptual y en la obtencin del esquema que forman. El esquema externo ha de ser cerrado, para ello se han de aadir al mismo las clases del esquema conceptual necesarias para que se cumpla esta propiedad4. Las dos fases de definicin de esquemas externos se pueden descomponer en los pasos siguientes, correspondientes a los de la metodologa de

La clase de definicin del esquema externo se incluye en el esquema conceptual; sin embargo, las clases del esquema externo simuladas mediante esta clase no pertenecen necesariamente al esquema conceptual. Es por esta razn que se ha decidido tratar como un caso aparte. En [Rund92a] se presenta el algoritmo para obtener automticamente el esquema externo cerrado a partir del conjunto de clases seleccionadas.
4

definicin de vistas5 Multi View de [Rund92a], igualmente considerados en [GeSD93, TrSc93]: 1. Adaptacin del esquema conceptual. 1.1. Definicin de las clases derivadas que se consideren necesarias. 1.2. Integracin de las clases derivadas en el esquema conceptual. 2. Definicin del esquema externo. 2.1. Seleccin de las clases (base o derivadas) del esquema conceptual que compondrn el esquema externo. 2.2. Generacin del esquema externo. Si para definir un esquema externo se necesita incluir alguna clase no definida en el esquema conceptual, dicha clase ha de ser definida e integrada previamente en el esquema conceptual. El esquema conceptual acta de repositorio comn de definicin de clases derivadas para todos los esquemas externos, por lo que las nuevas clases que se definen pueden ser reutilizadas con facilidad en la definicin de nuevos esquemas externos.

3.2. Esquema Externo NO Subesquema del Esquema Conceptual

Se parte del esquema conceptual para definir el esquema externo, pero ste no es subesquema necesariamente del esquema conceptual. Es decir, el esquema externo puede contener clases definidas a partir del esquema conceptual pero no incluidas en l [TaYI88, AbBo91, SoAD94]. La manera de realizar la definicin del esquema externo a partir del esquema base (esquema conceptual u otro esquema externo) es diferente para los distintos autores (aunque los pasos lgicos son idnticos), tal como veremos a continuacin: En [AbBo91, SoAD94] el esquema externo se define inicialmente importando la definicin del esquema conceptual, es decir, en un primer momento ambos son iguales; posteriormente, se modifica este esquema mediante operaciones que permiten definir clases derivadas, as como modificar o eliminar clases existentes. Por tanto, los pasos para definir el esquema externo son: 1. Definicin del esquema externo inicial: Importando el esquema conceptual base (u otro esquema externo). 2. Modificacin el esquema externo inicial mediante los mecanismos que proporciona: a. Definicin de clases derivadas. b. Ocultacin de clases del esquema. c. Definicin de atributos derivados (en cualquier clase). d. Ocultacin de atributos (en cualquier clase) En el caso de [TaYI88], inicialmente se define el esquema externo compuesto slo por clases derivadas a partir de las clases del esquema conceptual; en algunos casos la definicin inicial es suficiente, en otros el esquema inicial es modificado aadindole subesquemas del esquema conceptual o bien de otros esquemas externos.

El concepto de vista en [Rund92a] se corresponde con el de esquema externo considerado.

10

Los pasos para definir el esquema externo son: 1. Definicin del esquema externo inicial. 1.1. Definir las clases derivadas del esquema externo. 1.2. Definir las relaciones de herencia entre las clases derivadas. 2. Modificacin el esquema externo inicial. 2.1. Definir subesquemas a partir del esquema conceptual u otro esquema externo (mediante eliminacin de subrboles). 2.2. Integrar de estos subesquemas con el esquema externo inicial definido. En ambos casos, el esquema conceptual no se complica por la definicin de esquemas externos sobre l. Por otro lado, los distintos esquemas externos se definen de forma independiente, y no se dispone de ningn repositorio comn de definicin de clases derivadas (papel que jugaba anteriormente el esquema conceptual), por tanto resulta ms difcil la reutilizacin de definiciones.

3.3. Esquema Externo como Clase del Esquema Conceptual

A diferencia de los otros mtodos de definicin de esquemas externos, en este caso la naturaleza del esquema externo no es la misma que la del esquema conceptual. El resultado de la definicin del esquema externo es una clase que representa un esquema en lugar de ser un esquema propiamente dicho. En [BaKe93] los esquemas externos se definen como clases del esquema conceptual. Para definir un esquema externo se modifica el esquema conceptual aadiendo la definicin una clase nueva que lo implementa. La implementacin de los distintos aspectos del esquema externo mediante una clase se realiza definiendo de forma adecuada las operaciones de dicha clase. Se define una operacin por cada una de las clases que componen el esquema externo, estas operaciones devuelven la extensin de dichas clases; adems, se define una operacin por cada una de las operaciones posibles a realizar sobre los objetos de las distintas clases del esquema externo. La nueva clase define una interfaz, correspondiente al esquema externo que implementa, sobre el resto de las clases del esquema conceptual. Para trabajar con el esquema externo as definido, se crea un nico objeto de esta clase sobre el que se pueden aplicar los mtodos definidos (que corresponden a los mtodos de las clases del esquema externo). Suponiendo que las clases del esquema externo se definieran explcitamente como clases (en lugar de implcitamente dentro de la clase de definicin), el esquema externo no sera necesariamente subesquema del esquema conceptual. Por tanto esta metodologa se incluira con las del apartado anterior; sin embargo, la clase de definicin del esquema externo est incluida en el esquema conceptual. Los pasos de esta metodologa para la definicin de esquemas externos son: 1. Definicin de la clase que implementa el esquema externo. 1.1. Definicin de las operaciones de la clase que definen la extensin de las clases que componen el esquema externo. 1.2. Definicin de las operaciones de la clase que definen las operaciones de consulta y modificacin de las clases que componen el esquema externo.

11

2. Creacin de una instancia de la clase definida: Crea el esquema externo propiamente dicho y puede ser utilizado mediante el objeto creado. En este caso, la naturaleza de los esquemas externos cambia respecto a la del esquema conceptual: Un esquema externo no es un esquema propiamente dicho, sino que es slo una clase dentro del esquema conceptual. Una consecuencia inmediata de esta situacin es que ha de cambiar la forma de trabajar de los usuarios segn trabajen con el esquema conceptual o con alguno de los esquemas externos definidos.

4. Definicin de Clases Derivadas

La definicin de clases derivadas es estudiada, adems de en los trabajos sobre definicin de esquemas externos mencionados anteriormente, en aquellos otros en los que se consideran las vistas como clases [Kim89, AbBo91, HeSa91, ScSc91, Bert92, KiKS92, AlAr93, SoAD94, KiKe95]. En este apartado no se pretende tratar de forma exhaustiva el problema de la definicin de clases derivadas, sino solamente los aspectos que pueden resultar ms relevantes en la definicin de esquemas externos. La definicin de clases derivadas es uno de los pasos de las metodologas de definicin de esquemas externos: Se han de definir las clases que se necesiten en el esquema externo y que an no se encuentren definidas en el sistema. Para el usuario del sistema debe ser transparente el hecho de que existan clases derivadas en el mismo. Por tanto, no debe de haber diferencia, en lo que se refiere a la forma de trabajar con ellas, entre las clases derivadas y las clases a partir de las que se definen. Segn este principio, una clase derivada ha de tener todas las caractersticas de una clase cualquiera del sistema. El resultado de la definicin de una clase derivada ha de incluir el tipo as como el conjunto de objetos que la componen; adems se han de establecer las relaciones existentes entre la clase definida y el resto de clases del esquema del que pasa a formar parte. En la definicin de clases derivadas hay diversos temas abiertos a tratar, como son: El lenguaje de definicin a usar, la posibilidad de crear nuevos objetos, la transmisin de modificaciones en ambas direcciones entre los objetos de la clase derivada y los de las clases base, la integracin en un esquema de la clase definida. Este ltimo punto es de especial relevancia respecto a la definicin de esquemas externos, ya que forma parte de la definicin de las clases derivadas que se incluyen en los esquemas externos.

4.1. Objetos de las Clases Derivadas

Los objetos de las clases derivadas pueden ser objetos previamente existentes en las clases base sobre las que se definen (directa o indirectamente), es decir, se conserva el identificador de los objetos base aunque pueden tener un tipo distinto asociado a la nueva clase: Semntica de conservacin de objetos. Tambin pueden ser nuevos objetos definidos a partir de objetos base, creando nuevos identificadores: Semntica de generacin de objetos. Los sistemas que permiten la generacin de nuevos objetos proporcionan una gran potencia de definicin de clases derivadas, pues ofrecen la capacidad de transformar valores en objetos, pero tambin presentan

12

problemas adicionales, sobre todo en lo referente a la generacin de nuevos identificadores y transmisin de modificaciones.

4.2. Integracin de una Clase Derivada en un Esquema

Una clase se relaciona con el resto de clases del esquema mediante relaciones de agregacin y de herencia. En principio, las clases derivadas no son una excepcin, tambin se relacionan con el resto de clases del esquema del que pasan a formar parte mediante este tipo de relaciones. Para una clase derivada, las relaciones de agregacin con el resto de las clases del esquema vienen dadas directamente por la definicin del tipo de los objetos de la clase, el tipo har referencia a otras clases del esquema, o bien el tipo de otras clases definidas har referencia a esta clase. Por otro lado tenemos las relaciones de herencia a definir entre la nueva clase y el resto de clases existentes, en particular con las clases a partir de las que se define; las relaciones de herencia permiten compartir propiedades e instancias entre las distintas clases de la BD, han de definirse de manera que se respete la consistencia de dichas relaciones. Por tanto, el problema de integracin de una clase derivada en un esquema determinado queda reducido a la integracin segn las relaciones de herencia [Kim89, AbBo91, ScSc91, KiKS92, Rund92a, AlAr93, TrSc93]. Otros autores [HeSa91, Bert92, SoAD94, KiKe95] consideran que la definicin de relaciones de herencia con las clases existentes no es una buena forma de integracin de una clase derivada en un esquema, por ello realizan una ampliacin del modelo orientado a objetos definiendo nuevos tipos de relaciones o conceptos adicionales a los del modelo bsico, como veremos en los apartados siguientes.

a. Integracin Usando la Relacin de Herencia

En [Rund92a] encontramos una definicin de lo que se entiende por integracin de una clase derivada en un esquema: La integracin de una clase derivada en un esquema consiste en encontrar el lugar ms "apropiado" para la nueva clase en el esquema, en trminos de (i) herencia de propiedades y (ii) relaciones de subconjuntos entre las clases. Es decir, dentro del esquema considerado hemos de definir tanto el conjunto de superclases y subclases de la clase derivada con las que se relaciona, de manera que se cumplan los principios de la herencia entre clases en sus dos vertientes (tipo y conjunto de objetos de la clase). a.1. Posicionamiento Automtico La determinacin del lugar apropiado para las clases derivadas no es siempre inmediata. Por ejemplo, a) partiendo del esquema de la figura (1), definimos la clase EMPLEADOS' a partir de EMPLEADOS, de manera que en esta nueva clase no se tenga acceso a la funcin Sueldo() y la clase slo contenga los empleados que no sean jefes. Es decir, el tipo de la nueva clase es un supertipo del tipo de la clase original, sin embargo el conjunto de objetos de la nueva clase es un subconjunto del conjunto de objetos de la clase a partir de la que se define. Por

13

tanto, la nueva clase definida no sera ni subclase ni superclase de la clase original. Se producira la misma situacin si en lugar de restringir el conjunto de objetos que pertenecen a la nueva clase hubiramos ampliado el tipo de sta aadiendo una nueva funcin (adems de haberlo simplificado por otra parte), p.e. b) definimos la clase EMPLEADOS' a partir de EMPLEADOS con la funcin Poblacin() que devuelve la poblacin en la que vive el empleado6, funcin ya definida previamente en la clase DIRECCIONES, adems de eliminar la funcin Sueldo(). Esto hara que el tipo de la nueva clase no fuera ni subtipo ni supertipo del tipo de la clase original; por tanto, la nueva clase definida no sera ni subclase ni superclase de la clase EMPLEADOS, aunque contenga el mismo conjunto de objetos, adems tendra una funcin en comn con la clase DIRECCIONES.
Herencia Agregacin

OBJETOS

PERSONAS
...

DIRECCIONES
... Poblacin()

Domiclio()

EMPLEADOS CLIENTES
... Categora()

EMPLEADOS
Sueldo()

EMPLEADOS

a. EMPLEADOS' supertipo y subconjunto de objetos de EMPLEADOS.

Herencia Agregacin

OBJETOS

CON_POBLACION
Poblacin()

PERSONAS
...

Domiclio()

DIRECCIONES
...

EMPLEADOS CLIENTES
... Categora()

EMPLEADOS
Sueldo()

EMPLEADOS

b. EMPLEADOS' el mismo conjunto de objetos y ni super ni subtipo de EMPLEADOS. EMPLEADOS' con la funcin Poblacin() en comn con DIRECCIONES.

Conserva la funcin Domicilio().

14

Figura 3. Integracin automtica segn la relacin de herencia. Este tipo de problemas se solucionan en [Rund92a, Rund92b] definiendo de forma automtica, mediante el algoritmo que propone7, un conjunto de clases intermedias que permiten que la clase derivada se pueda integrar directamente en el esquema. En el ejemplo considerado, en ambos casos se definira automticamente una nueva clase EMPLEADOS'' que sera superclase8 tanto de EMPLEADOS como de EMPLEADOS', evitando as los conflictos de herencia mencionados. En la figura (3.a) se muestra la integracin realizada para el primer ejemplo, donde el conjunto de objetos de la clase EMPLEADOS' definida es un subconjunto de conjunto original, y el nuevo tipo es subtipo del tipo original9. As, el tipo de la clase EMPLEADOS'' sera el mismo que el de EMPLEADOS', adems contendra todos los objetos de la clase EMPLEADOS. En la figura (3.b) vemos cmo se repite el proceso descrito en la figura anterior para cada una de las clases que tenga algo en comn con la nueva clase definida, generndose de esta forma la clase que hemos llamado CON_POBLACION, como factor comn entre EMPLEADOS' y DIRECCIONES10. El mismo planteamiento para tratar el problema de la clasificacin de una clase derivada se hace en [AbBo91, ScSc91, AlAr93, TrSc93], pero no se trata tan a fondo como en [Rund92b]. En [ScSc91, TrSc93] se considera igualmente la dualidad de clases como tipos y conjuntos de objetos; para cada operacin elemental de definicin de clases derivadas se define dnde se colocara el resultado respecto a las clases base. Definen la posicin de la nueva clase considerando las operaciones elementales por separado, pero no si la nueva clase se define usando varias operaciones elementales juntas. En [AbBo91, AlAr93] se presentan las reglas de colocacin de las nuevas clases derivadas en relacin con las clases base a partir de las que se definen, pero en casos similares al ejemplo presentado se acabara aadiendo la clase derivada directamente bajo la clase OBJETOS, ya que
7 Tal como se menciona en [Rund92a]: En general, el problema de la clasificacin no es decidible para el modelo orientado a objetos ya que puede requerir la comparacin de funciones y predicados arbitrarios. Por tanto, se usa un algoritmo incompleto [TrSc93]. En [Rund92a] se simplifica considerando que las funciones tienen asociado un identificador nico; as, para comparar funciones basta con comparar los identificadores respectivos. Esta misma consideracin se hace en el presente trabajo. 8 "Lowest common superclass" (superclase comn ms baja) segn terminologa de [Rund92b].

Las clases rellenas de gris son las clases derivadas; las clases adems sombreadas son las que se definen originalmente, las no sombreadas son las aadidas automticamente, slo para realizar la integracin.
10 En el modelo utilizado en [Rund92a, Rund92b] si dos clases del mismo esquema tienen alguna funcin en comn, si no son subclase una de otra, debe de existir una tercera clase en el esquema de la que ambas sean subclases, y que refleje este hecho; esta es la "lowest common superclass" de ambas clases. Tal como se menciona literalmente en [Rund92b]: En nuestro modelo, como en otros, una propiedad se define solamente una vez y, si se usa en algn otro sitio, ha de ser heredada de la clase en la que fue definida originalmente.

15

no consideran la posibilidad de definir nuevas clases intermedias (a no ser que sea manualmente).

a.2. Posicionamiento Directamente Bajo la Clase OBJETOS La solucin que se propone en [Kim89] es situar de forma sistemtica las clases derivadas que se definen como subclases inmediatas de la clase OBJETOS; adems, los objetos de las clases derivadas son siempre nuevos objetos. En este caso el problema de la integracin se soluciona directamente, sin embargo, esta solucin implica que las clases derivadas no pueden compartir propiedades o instancias con las clases base a partir de las que se definen. Por tanto, la colocacin inadecuada de las clases derivadas produce duplicacin del contenido de estas clases, tal como tambin se seala en [AlAr93]. El principal problema de esta solucin consiste en que se est dejando de representar en el esquema una relacin de herencia entre clases que existe realmente. a.3. Determinacin de la Posicin Manualmente Es la solucin adoptada en [KiKS92]. Cuando se define una clase derivada, se especifica su tipo y las relaciones de herencia con el resto de clases del esquema. Si la nueva clase derivada a integrar es subclase directa de alguna clase existente previamente la definicin manual de la posicin es sencilla; pero, si no es as, habra que aadir manualmente las clases que se generan de forma automtica en [Rund92b] o bien situarla directamente bajo la clase OBJETOS.

b. Integracin Ampliando el Modelo

La integracin de clases derivadas en los esquemas mediante las relaciones de herencia hace que resulten esquemas ms complejos, algunas veces conteniendo clases no significativas para los usuarios [Bert92], o bien, si se sitan las clases derivadas directamente bajo la clase OBJETOS, resultan esquemas incompletos, que no recogen todas las relaciones existentes. Por todo ello, algunos autores [HeSa91, Bert92, SoAD94, KiKe95] proponen usar mecanismos alternativos de integracin, ampliando el paradigma de orientacin a objetos. b.1. Relacin "May_be" Las clases derivadas se relacionan con el grafo de clases mediante un diferente tipo de relacin, la relacin "May_be"11, para distinguirla de la relacin "Is_a"12 correspondiente a la relacin de herencia convencional de los modelos orientados a objetos [SoAD94]. En este sentido, un objeto de una clase base "puede ser" una instancia de la clase derivada correspondiente. El mecanismo de resolucin se redefine de manera que tenga en cuenta la nueva relacin para que as se puedan compartir atributos y mtodos de las clases base en las clases derivadas y que incluso se puedan redefinir.

11 12

"Puede_ser". "Es".

16

En el ejemplo considerado, la clase EMPLEADOS' estara relacionada directamente con la clase EMPLEADOS mediante la relacin May_be, sin necesidad de aadir al esquema ninguna clase adicional: EMPLEADOS' May_be EMPLEADOS, de la misma forma que si fuera directamente subclase se habra indicado EMPLEADOS' Is_a EMPLEADOS. b.2. Relacin de Derivacin Para introducir clases derivadas en el esquema, en lugar de usar la relacin de herencia, se introduce un nuevo tipo de relacin entre las clases derivadas y las clases base, la relacin de derivacin "Derived_from" [Bert92, KiKe95] que no forma parte del paradigma orientado a objetos. Una clase derivada est relacionada mediante una relacin de derivacin con cada una de las clases base a partir de las que est definida. Por tanto, el esquema se extiende introduciendo una nueva dimensin: Derivacin. Una clase derivada puede definirse por derivacin igualmente a partir de otras clases derivadas. Adems, para poder reutilizar las definiciones realizadas en una clase derivada, se pueden definir nuevas clases derivadas mediante herencia a partir de otras clases derivadas; tenemos as una estructura separada para las clases derivadas relacionadas entre si mediante herencia [Bert92, KiKe95], estando algunas de las clases de esta estructura relacionadas con las clases base mediante relaciones de derivacin. b.3. "Clusters" En [HeSa91], para solucionar el problema de la integracin de una clase derivada en un esquema proponen la utilizacin de un nuevo concepto, el concepto de "cluster" o grupo de clases. Tal como se define en [HeSa91]: Un cluster consiste en al menos una clase base y varias clases derivadas teniendo todas ellas el mismo "conjunto posible de objetos" que la correspondiente clase base. Es decir, cada clase (base y derivada) tiene su tipo y conjunto de objetos propio asociado. Si definimos una clase derivada a partir de otra clase, con semntica de conservacin de objetos, ambas clases compartirn el mismo conjunto posible de objetos; por tanto, la forma de relacionar dichas clases es incluirlas en el mismo cluster. Dentro de cada cluster, las clases se organizan considerando por separado los tipos y los conjuntos de objetos de cada una de ellas: Dentro de cada cluster se tiene un retculo de tipos y otro de conjuntos de objetos, sabiendo que el conjunto total de objetos es el conjunto de la clase original que dio lugar al cluster. Si definimos una nueva clase que contenga nuevos objetos (en lugar de conservar los objetos existentes), o bien est definida sobre clases de clusters distintos, esta clase formar un nuevo cluster.

5. Nueva Metodologa de Definicin de Esquemas Externos

Partiendo de las metodologas presentadas anteriormente, en primer lugar se presentan sus caractersticas principales (ventajas e inconvenientes), posteriormente se presenta una nueva metodologa que trata de subsanar algunos de los problemas que se producan en las metodologas anteriores.

17

5.1. Caractersticas de las Metodologas Presentadas

Hemos clasificado las metodologas de definicin de esquemas externos en tres tipos. En el primer tipo el esquema externo ha de ser un subesquema del esquema conceptual; las metodologas del segundo tipo son aquellas que no tienen este requerimiento, los esquemas externos pueden contener clases no incluidas en el esquema conceptual; por ltimo, se ha presentado en un grupo aparte una metodologa en la cual se simula el esquema externo mediante una clase.

a. Esquema Externo Subesquema del Esquema Conceptual

En las metodologas de este grupo el esquema conceptual acta como repositorio de definicin de clases derivadas. Cualquier clase que se haya de incluir en un esquema externo ha de estar previamente definida en el esquema conceptual. Por tanto, uno de los pasos es la inclusin de las clases derivadas necesarias en el esquema conceptual. El usar un repositorio comn de definicin permite reutilizar de una forma fcil las definiciones de clases realizadas con anterioridad. Para integrar una clase derivada en un esquema hemos visto en el apartado anterior distintos mtodos. En particular, las metodologas de definicin de esquemas externos presentadas realizan la integracin utilizando la relacin de herencia. Considerando como ms representativo el mtodo de [Rund92a], el resultado es que el esquema conceptual se complica conforme se van definiendo esquemas externos que requieren la definicin de nuevas clases. El problema es que se integra en el mismo esquema, mediante la relacin de herencia, clases que en algunos casos no tiene mucha razn de ser que estn en el mismo esquema en trminos semnticos. Realizar esta integracin requiere frecuentemente que se hayan de aadir clases intermedias, tal como vimos el ejemplo de la figura (3).
Herencia Agregacin

OBJETOS

PERSONAS
...

DIRECCIONES
... Poblacin()

Domiclio()

EMPLEADOS CLIENTES
... Categora()

EMPLEADOS

EMPLEADOS
Sueldo()

Figura 4. Seleccin de las clases del esquema externo. En la figura (4), continuando con el ejemplo anterior de la figura (3.a), se realiza la seleccin de las clases que compondrn el esquema externo13. Se ha aadido automticamente una nueva clase EMPLEADOS''
13 Las clases inicialmente seleccionadas para componer el esquema externo son las agrupadas en la zona ms oscura. Partiendo de este conjunto de clases se obtendr el esquemas externo correspondiente.

18

slo para que fuera posible integrar la nueva clase definida que nos interesa, sin embargo la clase adicional no se necesita en el esquema externo definido, ni tampoco la clase original a partir de la que se define. Esta situacin es lgica, ya que en el ejemplo considerado uno de los objetivos de la definicin de la nueva clase era evitar que se accediera a la funcin Sueldo(). Si la clase original EMPLEADOS se incluye en el esquema externo se tendr acceso igualmente a dicha funcin, por tanto, para conseguir el objetivo marcado, la nueva clase habra de sustituir a la clase base. Es decir, se est realizando un esfuerzo de integracin de la nueva clase definida en el esquema conceptual y, sin embargo, no se va a usar la clase base y la clase derivada conjuntamente en el mismo esquema externo. Por tanto, si la nica razn para definir una nueva clase y aadirla al esquema conceptual es que se necesita para definir un esquema externo, en muchos casos, el resultado ser que semnticamente esta clase (junto con las clases aadidas automticamente para poder integrarla) no aportar nada al esquema conceptual, slo lo har ms complejo. El resultado del proceso de definicin de esquemas externos ser un esquema conceptual complejo con clases no significativas semnticamente para el usuario.

b. Esquema Externo NO Subesquema del Esquema Conceptual

En este grupo de metodologas los esquemas externos pueden contener clases derivadas no definidas en el esquema conceptual. Para realizar la definicin de esquemas externos se pueden importar definiciones realizadas en otros esquemas externos as como en el esquema conceptual. Sin embargo, se hace difcil la reutilizacin, pues en ningn mtodo se dispone de un repositorio comn donde se tengan las definiciones de todas las clases contenidas en los distintos esquemas. El esquema conceptual no hace el papel de repositorio, de esta forma no se complica conforme se definen nuevos esquemas externos, pero no se dispone de repositorio alternativo y, por tanto, tampoco de las ventajas que supone disponer de dicho repositorio.

c. Esquema Externo como Clase del Esquema Conceptual

Esta metodologa, como ya se ha mencionado, es un caso aparte, pues los distintos esquemas externos se simulan mediante un objeto de una clase definida expresamente. Los esquemas externos son de distinta naturaleza que el esquema conceptual, son simulados mediante los mtodos de la clase definida. Se aaden clases que representan los esquemas externos al esquema conceptual; por tanto, el esquema conceptual se complica con cada definicin de un esquema externo (mnimamente, ya que se aade una sola clase en cada definicin). Se mezclan conceptos de distinto mbito en el esquema conceptual, por una parte se tienen las clases base iniciales, por otro lado las clases de definicin de esquemas externos. Adems se presentan los mismos problemas de reutilizacin del grupo de mtodos del apartado anterior, agravados por la distinta naturaleza de los esquemas externos.

19

5.2. Definicin de la Metodologa

Como hemos visto, la principal ventaja de las metodologas del primer grupo es que disponen de un repositorio comn de definicin de los distintos esquemas externos que permite reutilizar las clases previamente definidas. El principal inconveniente es que el repositorio es el esquema conceptual y normalmente se complica con cada esquema externo que se define (si hay que aadir nuevas clases). En particular, se aaden clases que no se necesitan directamente en el esquema externo a definir, sino que slo se necesitan para integrar las nuevas clases derivadas en el esquema conceptual. En las metodologas del segundo grupo, el esquema conceptual no se complica con la definicin de esquemas externos, pero tampoco se dispone de un repositorio de definicin, por lo que la reutilizacin de definiciones anteriores se hace ms difcil. Por tanto, una forma de tener las ventajas del primer grupo de metodologas, evitando sus inconvenientes, es disponiendo de un repositorio de definicin alternativo sin complicar el esquema conceptual por ello. Es decir, necesitamos un repositorio donde se tengan todas las clases y esquemas definidos adicionalmente al esquema conceptual. Llamemos a dicho repositorio esquema global14. El esquema conceptual puede contener clases base y tambin clases derivadas15; el esquema global contiene, adems de las clases del esquema conceptual, todas las clases definidas por el usuario que se han necesitado para definir los distintos esquemas externos, as como la definicin de stos. Las nicas operaciones que se pueden realizar sobre el esquema global son las relacionadas con la definicin de esquemas externos, es decir, no sera un esquema del estilo del esquema conceptual o los esquemas externos, sino que slo se utilizara de soporte a la definicin de esquemas externos. Igualmente, habra que definir cmo se incluirn las nuevas clases definidas en el esquema global. Como hemos visto en el caso de la metodologa de [Rund92a], si se utiliza la herencia como mecanismo de integracin de las nuevas clases definidas, en muchos casos, el resultado es que se obtienen esquemas complejos con clases no significativas para el usuario 16. Adems, algunas de las clases incluidas en el esquema (las aadidas exclusivamente para relacionar mediante herencia la clase derivada con las clases a partir de las que se define) no se utilizaran directamente en la definicin del esquema externo. Por tanto, para que el esquema global resulte lo ms sencillo posible sera ms adecuado realizar la integracin de las nuevas
14 Con un significado distinto del usado en [Rund92a], en este, el "base schema" es un esquema que no contiene clases derivadas, es decir, slo contiene clases base. El "global schema" es una extensin del base schema, aumentado por el conjunto de clases derivadas y relaciones definidas durante la vida de la BD. De igual manera define un "view schema" como un subesquema del global schema, y un "virtual schema" como un subesquema del global schema que slo contiene clases derivadas.

Por tanto, el esquema conceptual no se correspondera con el base schema de [Rund92a], sera el global schema que tambin puede contener clases derivadas. Las clases derivadas pertenecientes al esquema conceptual estaran integradas mediante las relaciones de herencia y agregacin. Esto ocurre especialmente cuando hay que aadir nuevas clases intermedias para realizar la integracin de la nueva clase derivada.
16

15

20

clases de una forma ms directa, utilizando un tipo de relacin que no implique aadir nuevas clases que no se necesiten directamente en la definicin de los esquemas externos. La relacin que se considera ms adecuada para esta finalidad es la relacin de derivacin [Bert92, KiKe95], que asocia una clase derivada con las clases base a partir de las que se define. Por tanto, los pasos de la metodologa para definir un esquema externo, seran los siguientes: 1. Adaptacin del esquema global. 1.1. Definicin de las clases derivadas que se consideren necesarias. 1.2. Integracin de las clases derivadas en el esquema global (directamente usando la relacin de derivacin). 2. Definicin del esquema externo. 2.1. Seleccin de las clases (base o derivadas) del esquema global que compondrn el esquema externo. 2.2. Generacin del esquema externo. Bsicamente son los mismos pasos de la metodologa de [Rund92a], pero cambia su contenido. En el primer paso se procedera a la adaptacin del esquema global, definiendo las clases que se necesiten en el esquema externo y an no estn definidas. Las nuevas clases se integraran directamente usando la relacin de derivacin, que las relaciona con las clases base a partir de las que se definen, sin necesidad de aadir clases intermedias, al contrario de lo que ocurra en los ejemplos de la figura (3).
Herencia Agregacin Derivacin

OBJETOS

PERSONAS
...

DIRECCIONES
... Poblacin()

Domiclio()

EMPLEADOS CLIENTES
... Categora() Sueldo()

EMPLEADOS
... Categora()

Figura 5. Definicin del esquema externo segn la nueva metodologa. Esquema global y clases seleccionadas para el esquema externo. Una vez tenemos todas las clases necesarias se procedera a la seleccin del conjunto de clases que forman el esquema externo y a la generacin del esquema externo propiamente dicho. El esquema externo ha de cumplir los principios del paradigma de orientacin a objetos, es decir, las nicas relaciones entre sus clases son las de herencia y agregacin. Por tanto, partiendo del conjunto de clases seleccionadas y las relaciones existentes entre ellas en el esquema global (agregacin, herencia y derivacin - tanto directa o indirectamente) hemos de obtener un esquema cerrado que contenga las clases seleccionadas relacionadas exclusivamente mediante las relaciones de

21

herencia y agregacin: En este momento es cuando las nuevas clases definidas se integran realmente segn el paradigma orientado a objetos en el esquema externo, derivando las relaciones de herencia con las clases seleccionadas a partir de las relaciones de derivacin representadas en el momento de la definicin y las relaciones de herencia existentes previamente. En particular, puede darse el caso que haya que aadir nuevas clases (de una forma similar a como se haca en [Rund92a]) para que se cumpla en principio de herencia completa [Kim89]. Tal como podemos ver en la figura (5), para el ejemplo presentado anteriormente en la figura (4), en este caso no ha sido necesario aadir ninguna clase adicional (aparte de la definida por el usuario). La nueva clase derivada se integra directamente en el esquema global mediante la relacin de derivacin. El esquema externo correspondiente se obtendra de forma directa, bastara con aadir al conjunto de clases seleccionadas una relacin de herencia entre las clases PERSONAS y EMPLEADOS', derivada de las relaciones de herencia y derivacin entre estas dos clases y la clase EMPLEADOS. No sera necesario aadir ninguna clase adicional al esquema externo ya que las clases seleccionadas se pueden integrar directamente mediante herencia. En caso de necesitar aadir alguna clase adicional durante el proceso de obtencin del esquema externo, esta clase se aadir en lo que llamamos el Esquema Total, que estara formado por el esquema global ms las clases y relaciones de herencia definidas automticamente en las sucesivas ejecuciones del algoritmo de obtencin del esquema externo. Diferenciamos entre el esquema global y el esquema total ya que el usuario del sistema de definicin de esquemas externos (el administrador de datos) trabajar con el esquema global, que contiene exclusivamente las clases que l ha definido explcitamente. Por otra parte, el esquema total lo usar el algoritmo de obtencin de esquemas externos para reutilizar los resultados obtenidos en ejecuciones previas. Los esquemas global y total slo son considerados en tiempo de definicin de esquemas externos, es decir, no se ha modificado la arquitectura ANSI/X3/SPARC. Se puede considerar que los esquemas externos estn definidos directamente sobre el esquema conceptual. Podemos considerar que tampoco ha habido que realizar ninguna ampliacin del paradigma de orientacin a objetos aunque se haya definido la nueva relacin de derivacin, ya que esta relacin no interviene en los esquemas con los que trabajan las aplicaciones o el usuario final, slo aparece en los esquemas de soporte, especializados en la definicin de esquemas externos. En esta nueva metodologa se reduce considerablemente el nmero de clases derivadas definidas de forma automtica respecto a la metodologa de [Rund92a]. Esta reduccin se debe al hecho de que las clases derivadas se integran segn el paradigma de orientacin a objetos (mediante la relacin de herencia) exclusivamente en los esquemas externos de los que forman parte, mientras que en el esquema global se integran directamente mediante la relacin de derivacin. La metodologa de [Rund92a] integra mediante la relacin de herencia todas las clases definidas en el esquema conceptual. Dentro de la clasificacin de metodologas realizada anteriormente, esta metodologa se encuadrara en el apartado titulado "Esquema Externo NO Subesquema del Esquema Conceptual". El esquema externo sera subesquema del esquema total, pero incluira clases no necesariamente incluidas en el esquema conceptual.

22

5.3. Relaciones de Derivacin

Se ha definido que la integracin de las clases derivadas en el esquema global se realiza mediante la relacin de derivacin. En este apartado profundizaremos sobre este concepto. Una clase derivada est relacionada mediante una relacin de derivacin con cada una de las clases base a partir de las que est definida. Una clase derivada puede estar definida sobre varias clases base, pero no todas ellas tienen la misma importancia relativa en la definicin. Distinguimos dos tipos de relaciones de derivacin: 1. Derivacin de identidad17: Relacin de derivacin que permite obtener la identidad de los objetos de la clase derivada. 2. Derivacin de valor: Relaciona la clase derivada con las clases a partir de las cuales obtiene el resto de caractersticas de los objetos de la clase, pero no la identidad. La relacin de derivacin de identidad define el subconjunto de las clases base sobre las cuales las instancias de la clase derivada dependen respecto a la identidad. Entre una clase derivada y las clases base pueden existir ninguna, una o varias relaciones de derivacin de identidad: 1. Si existe slo una relacin de derivacin de identidad, la clase derivada estar definida con conservacin de objetos sobre esta clase base. 2. Si existen varias relaciones de derivacin de identidad, la identidad de los objetos de la clase derivada depender de los identificadores de los objetos de todas las clases base relacionadas. Ser un caso de generacin de objetos en funcin de los identificadores de los objetos de estas clases base18. 3. Si no existe ninguna relacin de derivacin de identidad (slo existiran relaciones de derivacin de valor), la identidad de los objetos de la clase derivada se obtendra en funcin de su estado respectivo; por otro lado, el valor de los distintos atributos de los objetos de la clase derivada se obtendra mediante relaciones de derivacin de valor. Es decir, sera un caso de generacin de objetos en funcin de los valores obtenidos a partir de objetos de las clases base. Una clase derivada puede estar relacionada con otras clases al mismo tiempo mediante relaciones de derivacin de identidad y de valor. Es decir, mediante las relaciones de derivacin de identidad obtendra la identidad, mientras que por las relaciones de derivacin de valor obtendra valores de los distintos atributos. Las relaciones de derivacin que se representan en las figuras y a las que se hace referencia, son relaciones de derivacin de identidad. La existencia de una o varias relaciones de derivacin de identidad con clases base, correspondera a la clusula "IdentityFrom" indicada en la definicin de clases derivadas en [Bert92], donde se indican las clases base a partir de las cuales se obtiene la identidad de los nuevos objetos generados.
18 17

23

Las relaciones de derivacin, adems de a nivel clase tal como se ha definido, tambin se definen a nivel instancia [Bert92]. Para cada objeto de la clase derivada que se define tendremos definidas relaciones de derivacin de los tipos indicados que lo relacionan con objetos de las clases base a partir de los que est definido, permitiendo acceder a ellos directamente (de esta forma se facilita la posibilidad de transmitir modificaciones a nivel instancia mediante clases derivadas).

5.4. Obtencin del Esquema Externo a Partir del Esquema Global

Una vez definidas todas las clases necesarias en el esquema global, se procede a la seleccin de las clases que formarn el esquema externo correspondiente. El esquema externo ha de ser cerrado, es decir, todas las clases que se usan en el esquema externo han de formar parte del propio esquema externo. En la metodologa de [Rund92a], todas las clases que formen parte del esquema externo han de estar previamente definidas. Si el esquema externo que se especifica no es cerrado, automticamente se le aaden las clases necesarias para que lo sea; estas clases tambin han de haber sido previamente definidas.
Herencia Agregacin

OBJETOS

CON_POBLACION
Poblacin()

PERSONAS
...

DIRECCIONES
... Poblacin()

PERSONAS PERSONAS CLIENTES

Domiclio()

EMPLEADOS
... Categora()

CLIENTES

EMPLEADOS CLIENTES
Sueldo()

EMPLEADOS

Figura 6. Ejemplo de definicin de un esquema externo integrando las clases derivadas mediante herencia. Consideremos por ejemplo, que se desea tener un esquema externo partiendo del esquema de la figura (1), en el cual tanto para los clientes como para los empleados no se tenga el domicilio, sino que tan solo se disponga de la poblacin donde viven y que adems no est disponible el sueldo de los empleados. La representacin grfica del esquema y de las clases derivadas necesarias, usando la integracin de las clases derivadas mediante herencia, segn la metodologa de [Rund92a], la podemos ver en la figura (6). En este ejemplo, se han definido las clases CLIENTES' y EMPLEADOS' segn las necesidades descritas, y se han integrado usando varias clases derivadas generadas automticamente. En particular, se han generado las distintas combinaciones de la relacin existente entre personas, clientes y empleados (con domicilio - las clases originales; con poblacin PERSONAS', CLIENTES', EMPLEADOS'; y el factor comn de estas, sin

24

ninguno de ellos - PERSONAS'', CLIENTES'', EMPLEADOS''). Posteriormente se han seleccionado exclusivamente las clases necesarias. En el caso de usar la nueva metodologa propuesta, definiramos igualmente las clases derivadas segn las especificaciones; stas se integraran en el esquema global usando la relacin de derivacin, como se muestra en la figura (7). Tambin en la figura (7) se especifican las clases que, en principio, formarn parte del esquema externo a definir. Partiendo de estas clases y de las relaciones de derivacin y herencia (directas o indirectas) entre ellas obtendremos el esquema externo correspondiente. Es en este paso de obtencin del esquema externo donde se realiza la integracin de las clases derivadas mediante la herencia, ya que los esquemas externos no pueden tener otro tipo de relaciones entre sus clases que las de herencia y agregacin.
Herencia Agregacin Derivacin

OBJETOS

PERSONAS
...

DIRECCIONES
... Poblacin()

Domiclio()

EMPLEADOS CLIENTES
... Categora() Sueldo()

CLIENTES
... Poblacin()

EMPLEADOS
... Categora() Poblacin()

Figura 7. Esquema global segn la nueva metodologa. Se seleccionan las clases para obtener el esquema externo. Si se incluyen todas las clases seleccionadas en la figura (7), se habrn de generar e incluir las clases marcadas en el esquema total correspondiente de la figura (8).
Herencia Agregacin Derivacin

OBJETOS CON_POBLACION PERSONAS

...

Poblacin()

PERSONAS
...

DIRECCIONES
...

Domiclio()

PERSONAS EMPLEADOS CLIENTES

... Categora() Sueldo()

CLIENTES

EMPLEADOS

Figura 8. Posible esquema total y esquema externo resultado.

25

Como se puede observar en dicha figura, tratar de incluir directamente la clase PERSONAS nos hace generar nuevas clases para poder integrar mediante herencia las clases derivadas requeridas; adems hemos de incluir la clase DIRECCIONES para que el esquema externo sea cerrado. Las relaciones de derivacin de CLIENTES' y EMPLEADOS' son derivaciones con conservacin de objetos, por tanto, habra que estudiar las relaciones de herencia entre estas clases y la clase PERSONAS como superclase de sus clases base respectivas. De aqu se deducira la necesidad de definir la clase PERSONAS'' que se aadira automticamente en el lugar indicado y dichas clases derivadas seran subclases directas de la nueva clase, al igual que la clase PERSONAS original. Una vez aadidas todas las clases, en un repaso posterior se puede sacar factor comn un tipo ms especfico entre las clases derivadas, aadindose automticamente tambin la clase PERSONAS'. En este caso el nmero de clases derivadas a aadir es menor que en la figura (6), pues slo se consideran las clases sealadas como pertenecientes al esquema externo y las clases que se van generando. De todas formas, ste no es el resultado deseado, ya que resulta un esquema externo demasiado complejo, incluyendo clases que no se necesitaban originalmente. Para solucionar este problema existen distintas alternativas, una posibilidad sera realizar un nuevo proceso de seleccin de clases dentro del esquema obtenido; otra alternativa sera definir todas las clases derivadas necesarias a incluir en el esquema externo, de manera que no hiciera falta generar ninguna clase adicional, esto implicara haber de definir tambin la clase derivada PERSONAS' en el ejemplo anterior. Otra alternativa a este problema consiste en definir distintas categoras en el momento de seleccionar las clases que formarn parte del esquema externo. En particular se distinguira entre clases transformables y clases no transformables. Las clases no transformables han de aadirse directamente en el esquema externo para el cual se seleccionan (hasta ahora todas las clases eran no transformables). Las clases transformables no han de ser necesariamente incluidas directamente en el esquema externo, sino que pueden ser sustituidas por clases derivadas a partir de ellas segn las necesidades de cada caso.

Herencia Agregacin Derivacin

OBJETOS

PERSONAS
...

DIRECCIONES
... Poblacin()

Domiclio()

PERSONAS
...

Poblacin()

EMPLEADOS CLIENTES
... Categora() Sueldo()

CLIENTES

EMPLEADOS
... Categora()

Figura 9. Esquema total y esquema externo resultado, seleccionando la clase PERSONAS como clase transformable.

26

El resultado obtenido en la figura (8) correspondera a la situacin en la que todas las clases sealadas en la figura (7) se califican como no transformables. Sin embargo, sealando la clase PERSONAS como transformable obtendramos el esquema de la figura (9). Internamente se han seguido los mismos pasos descritos antes para obtener el esquema externo pero, por ser la clase PERSONAS transformable, dicha clase es sustituida por la clase derivada PERSONAS' que ha sido obtenida automticamente. En la figura (10) vemos un ejemplo donde se ha definido la clase derivada PERSONAS' como nica clase no transformable, y tambin se ha definido la clase EMPLEADOS' adaptndola a las necesidades especficas (ocultando el sueldo), en este caso como clase transformable. El resultado en este caso es que tanto la clase CLIENTES como EMPLEADOS' se adaptaran automticamente a la nueva definicin de PERSONAS', obtenindose directamente el esquema externo deseado, con las nuevas clases definidas de forma automtica a partir de las clases transformables.
Herencia Agregacin Derivacin

OBJETOS

PERSONAS
...

DIRECCIONES
... Poblacin()

Domiclio()

PERSONAS
Poblacin()

EMPLEADOS
... Categora() Sueldo()

CLIENTES

EMPLEADOS

Figura 10. Esquema global donde sealando la clase PERSONAS' como nica clase no transformable, obtendramos igualmente el esquema externo deseado.

5.5. Caractersticas de la Nueva Metodologa

A diferencia de otras metodologas, en esta metodologa el proceso de integracin de las clases derivadas se realiza en dos fases. En primer lugar las clases derivadas se integran en el esquema global directamente mediante la relacin de derivacin descrita. Posteriormente, se lleva a cabo la integracin de las clases seleccionadas en el esquema externo, esta vez usando la relacin de herencia, a partir de las relaciones de herencia y derivacin expresadas en el esquema global. El resultado obtenido es que resulta necesario generar un menor nmero de clases derivadas, en principio solamente las que se incluyen en el esquema externo. Para ello basta con comparar los esquemas representados en la figura (6) obtenido realizando la integracin exclusivamente mediante herencia, y el de la figura (9), obtenido segn la metodologa. Por tanto, se simplifica el problema que se planteaba de que se obtenan esquemas excesivamente

27

complejos, con clases no significativas semnticamente para el usuario. Se han incluido los conceptos de clase transformable y no transformable, que simplifican el proceso de definicin de esquemas externos, pues basta con definir las clases adecuadas como no transformables y el resto de clases se configuraran de forma automtica para tener un esquema externo correcto respecto a la relacin de herencia. Es decir, estos conceptos hacen que el usuario tenga que definir menos clases para obtener idnticos resultados. Aunque en los ejemplos no se han presentado clases en las cuales se use la semntica de generacin de objetos, estos casos estaran igualmente contemplados dentro de la metodologa. Se han presentado distintos tipos de relaciones de derivacin entre clases, considerando la generacin de nuevos objetos. Se respeta la arquitectura ANSI/X3/SPARC. Los esquemas externos se pueden considerar definidos directamente sobre el esquema conceptual, aunque para ello se basen en el repositorio de definicin de esquemas externos, formado por los esquemas global y total. No se realiza una ampliacin del paradigma orientado a objetos, ya que los esquemas sobre los que pueden trabajar las aplicaciones (esquema conceptual y esquemas externos) siguen totalmente dichos principios. La relacin de derivacin se usa exclusivamente en la definicin de los esquemas externos, pero no es accesible a las aplicaciones o usuarios finales que trabajan sobre dichos esquemas, pues se transforma en relaciones de herencia19. El esquema conceptual contiene slo las clases que se han considerado necesarias para modelar el sistema; puede contener clases derivadas expresamente seleccionadas porque sean necesarias, pero no slo porque se usen en la definicin de esquemas externos. El disponer de un repositorio de definicin de esquemas externos estructurado en forma de los esquemas global y total facilita la reutilizacin de las sucesivas definiciones de clases derivadas y esquemas externos realizadas. Permite distinguir entre las clases derivadas definidas explcitamente y las aadidas de forma automtica.

6. Conclusiones
Dada la utilidad de disponer de un mecanismo de definicin de esquemas externos en BDOO, en este trabajo se ha profundizado sobre dicho tema. Para ello se ha presentado el estado del arte de los distintos mtodos de definicin de esquemas externos, realizando una clasificacin de los mismos no realizada con anterioridad. Uno de los pasos en la definicin de esquemas externos es la definicin de las clases derivadas que se necesiten para el esquema a definir. Por tanto, presentamos el estado del arte sobre la definicin de clases derivadas, clasificando los distintos enfoques que se realizan sobre el tema. Tampoco exista una clasificacin de este tipo anteriormente.
19 Los autores que anteriormente utilizaban la relacin de derivacin en sus esquemas lo hacan con otra finalidad distinta, realizaban una ampliacin del paradigma orientado a objetos como medio de definicin de clases derivadas en los esquemas.

28

Por ltimo y ms importante, se ha presentado una nueva metodologa de definicin de esquemas externos, en la cual, los elementos y conceptos que se utilizan en gran parte no son nuevos, lo que resulta nuevo es la combinacin que de ellos se hace. Esta metodologa resuelve algunos de los problemas de las metodologas anteriores, en particular facilita la reutilizacin de definiciones previas, y adems los esquemas intermedios de definicin no se complican con clases que no se usan directamente en los esquemas definidos. La metodologa definida no se ha particularizado para ningn modelo orientado a objetos concreto, utiliza conceptos comunes a gran parte de los modelos orientados a objetos existentes. Sobre este ltimo punto, sera interesante ampliar la metodologa definida adaptndola para usar conceptos de modelos orientados a objetos ms ricos, como por ejemplo el modelo BLOOM [CaSG92], que permite definir distintos tipos de restricciones en el esquema. En [RaRu95] se presenta un mtodo de transmisin de modificaciones realizadas en los esquemas externos sobre el esquema conceptual, usando el mtodo de definicin de esquemas externos de [Rund92a]; la transmisin de modificaciones sobre el esquema conceptual se simplificara en gran medida usando esta nueva metodologa propuesta.

29

Bibliografa
[AbBo91] S. Abiteboul, A. Bonner "Objects and Views" Proc. ACM SIGMOD (May 1991) R. Alhajj, M.E. Arkun "An Object Algebra for Object-Oriented Database Systems" Database, Vol.24, No.3 (August 1993) ANSI/X3/SPARC Study Group on Database Management Systems Interim report ACM SIGMOD Bulletin 7, n.2, 1975 P.J. Barclay, J.B. Kennedy "Viewing Objects" en [WoGr93] E. Bertino "A View Mechanism for Object-Oriented Databases" en [PiDG92] M. Castellanos, F. Saltor, M. Garca "A Canonical Model for the Interoperatibility among Object Oriented and Relational Models" en [OzDV92] A. Geppert, S. Scherrer, K.R. Dittrich "Derived Types and Subschemas: Towards Better Support for Logical Data Independence in Object-Oriented Data Models" Technical Report 93.27, Institut fr Informatik, Universitt Zrich (June 1, 1993) S. Heuer, P. Sander "The LIVING IN A LATTICE Rule Language" Data & Knowledge Engineering, Vol.9, No.3 (North-Holland 1992/93) W. Kim, W. Kelley "On View Support in Object-Oriented Database Systems" en [Kim95] M. Kifer, W. Kim, Y. Sagiv "Querying Object-Oriented Databases" ACM SIGMOD Record, Vol.21, Iss.2 (June 1992) W. Kim "A Model of Queries for Object-Oriented Databases" VLDB'89 Proc. 15th Inter. Conf. on VLDB (Amsterdam, 1989) W. Kim (Ed) Modern Database Systems: the Object Model, Interoperability, and beyond ACM Press (1995) M.T. zsu, U. Dayal, P. Valduriez (Eds.) Proc. Int. Wor. on Distributed Object Management (Edmonton, Canada, August 1992)

[AlAr93]

[ANSI75]

[BaKe93]

[Bert92]

[CaSG92]

[GeSD93]

[HeSa91]

[KiKe95]

[KiKS92]

[Kim89]

[Kim95]

[OzDV92]

30

[PiDG92]

A. Pirotte, C. Delobel, G. Gottlob (Eds.) Proc. 3rd Int. Conf. on Extending Database Technology (Vienna, Austria, March 1992) Springer-Verlag (1992) Y.-G. Ra, E.A. Rundensteiner "A Transparent Object-Oriented Schema Change Approach Using View Evolution" en [YuCh95] E.A. Rundensteiner "MultiView: A Methodology for Supporting Multiple Views in Object-Oriented Databases" en [Yuan92] E.A. Rundensteiner "A Class Integration Algorithm and Its Application for Supporting Consistent Object Views" Univ. of Cal., Irvine, Tech. Rep #92-50 (May 1992) F. Saltor, M. Garca-Solaco "Diversity with Cooperation in Database Schemata: Semantic Relativism" Proc. of the 14th Int. Conf. on Information Systems (ICIS'93, Orlando 1993) M.H. Scholl, H.-J. Schek "Supporting Views in Object-Oriented Databases" IEEE Data Engineering, Vol.14, No.2 (June 1991) C. Souza, S. Abiteboul, C. Delobel "Virtual Schemas and Bases" Information Systems Vol.19, No.1 (1994) K. Tanaka, M. Yoshikawa, K. Ishihara "Schema Virtualization in Object-Oriented Databases" Proc. 4th Inter. Conf. on Data Engineering IEEE Computer Society Press (Feb. 1988) M. Tresch, M.H. Scholl "Schema Transformation without Database Reorganization" SIGMOD RECORD, Vol.22, No.1 (March 1993) M. Worboys, A.F. Grundy (Eds.) Advances in Databases 11th British National Conference on Databases BNCOD-11 (Keele, UK, July 1993) Springer-Verlag (1993) L.-Y. Yuan (Ed.) VLDB'92 Proc. 18th Inter. Conf. on VLDB Vancouver (Canada), August 1992 P.S. Yu, A.L.P. Chen (Eds.) Proc. 11th Int. Conf. on Data Engineering (Taipei, Taiwan, March 1995)

[RaRu95]

[Rund92a]

[Rund92b]

[SaGa93]

[ScSc91]

[SoAD94]

[TaYI88]

[TrSc93]

[WoGr93]

[Yuan92]

[YuCh95]

31