Definition of External Schemas in Object Oriented Databases José Samos Departament de Llenguatges i Sistemes Informàtics Universitat Politècnica de Catalunya Pau Gargallo 5, 08028 Barcelona, Spain
Winterthur Seguros División Informática Numància 164, 08029 Barcelona, Spain E-mail:
[email protected] Fax: +34-3-2901551
ABSTRACT: In this work, a new external schema definition methodology for object oriented databases (OODB) that solves some of the problems of existing methodologies is presented. In particular, this new methodology avoids the need for generating derived classes that are not directly used in the defined external schema. Also, it offers a way of integrating and reusing different external schema definitions. KEY WORDS: Object oriented databases, views, external schemas, class integration.
1. Introduction The three-level schema architecture (ANSI/X3/SPARC, 1975) represented in figure (1) has been widely applied in relational databases. In OODB the conceptual and internal schemas have also been studied deeply; this is not the case for external schemas. External Schema 1
External Schema 2
External Schema N
Conceptual Schema Internal Schema
DB Figure 1. The ANSI/X3/SPARC Three-Level Schema Architecture. In this paper, the study of external schemas in OODB will be broadened, in particular, external schema definition. A new external schema definition methodology that simplifies considerably the process of definition and the results obtained will be presented. The concepts presented here don't refer to any particular object oriented model; they are general concepts applicable to most existing object oriented models.
1.1 External Schemas and Views A "view" is a simplifying abstraction of a complex structure. Some authors identify the term view with the concept of external schema; others, consider it just as a derived class. In order to avoid confusion, in this work the term view will not be used; instead the terms external schema or derived class will be used appropriately. The three-level schema architecture is adopted as a guide; so, our terminology and concepts, and also the terminology used in other referenced works are adapted to it. 2. External Schema Definition Methodologies Three kinds of external schema definition methodologies are distinguished, just considering the relation between the conceptual schema and the different external schemas defined: • External schemas are subschemas of the conceptual schema (Rundensteiner, 1992;
Geppert et al., 1993; Tresch et al., 1993): In this case, the conceptual schema has to contain all the classes of the defined external schemas. If an external schema containing a class that is not previously included in the conceptual schema is wanted to be defined, this class has to be defined and integrated in the conceptual schema. • External schemas are not necessarily subschemas of the conceptual schema (Tanaka et al.,
1988; Abiteboul et al., 1991; Souza et al., 1994): External schemas can contain classes not included in the conceptual schema. These new classes are derived from conceptual schema classes but not necessarily included in it. • External schema as a class of the conceptual schema (Barclay et al., 1993): This is a
unique case, where each external schema is implemented defining a new class with just an object that simulates the behaviour of all the classes of the new external schema. In the first group of methodologies, the conceptual schema plays the role of the external schema definition repository: new derived classes are integrated by inheritance in the conceptual schema. Class integration assures the consistency of all external schemas with the conceptual schema and with one another. The main problem here is that the conceptual schema becomes more complex each time a new derived class is defined, as will be seen later with more detail. The main problem of existing methodologies of the second group is that external schemas are defined independently, using modification operations on an existing schema (conceptual or external); an external schema definition repository doesn't exist, so it is difficult to reuse previous definitions. Therefore, the conceptual schema is not affected by external schema definitions. In the methodology of the last group, external schemas are simulated by just an object of a new defined class. This means a change in the schema nature and also in the way of working with it. The most representative of the first group of methodologies is MultiView (Rundensteiner, 1992a). Some examples developed according to this methodology will be presented in detail,
in order to show the problems that, as far as we can see, it has; a solution to them will be proposed in section number three. 2.1 An Example Figure (2) shows the initial example conceptual schema. An external schema like the conceptual schema is wanted to be defined, but with a new class EMPLOYEES' replacing class EMPLOYEES, defined from it hiding the Salary() method and selecting objects that are not manager employees. According to this methodology, the new class has to be integrated in the conceptual schema using the inheritance relationship1. Class integration is useful for sharing methods and object instances consistently among classes without unnecessary duplication (Rundensteiner, 1992a; Rundensteiner, 1992b). Inheritance Aggregation OBJECTS
PEOPLE
ADDRESSES
...
...
Address()
City()
CLIENTS
EMPLOYEES Category() Salary() ...
Figure 2. OODB Example Schema. In (Rundensteiner, 1992a; Rundensteiner, 1992b) an algorithm is defined that integrates a derived class in a schema using inheritance; if necessary, it automatically generates intermediate derived classes, in order to properly obtain all the existing inheritance relationships among classes in the schema. In the object model defined there, a property is defined in just one class and, if it is used in another class, both of them shall be related by an inheritance relationship. As can be seen in figure (3), class EMPLOYEES'' is generated; the reason is that EMPLOYEES' is neither a subclass, nor a superclass of EMPLOYEES (its type is a supertype, but its object set is a subset of corresponding of EMPLOYEES); both classes share properties that could not be inherited from an already existing class.
1 In (Rundensteiner, 1992a) a different terminology is used: The base schema only contains base classes with stored rather than derived instances; the global schema is an extension of the base schema that also contains the derived classes defined during the lifetime of the database. We consider that the conceptual schema can also contain derived classes, so it would correspond to the global schema rather than to the base schema.
Base Class OBJECTS
Defined Derived Class Generated Derived Class PEOPLE
ADDRESSES
...
...
Address()
City()
EMPLOYEES’’ CLIENTS
...
Category()
EMPLOYEES
EMPLOYEES’
Salary()
Figure 3. Automatic Class Integration by Inheritance. Subset Incompatibility Problem. Another additional example of integration can be found in figure (4). Class EMPLOYEES' is defined hiding Salary() and adding a new method City() which returns the city where the employee lives, already defined in class ADDRESSES. Now, the inheritance problem between EMPLOYEES and EMPLOYEES' is just in their respective type; anyway, a new class EMPLOYEES'' is generated (different from the previous example class in the set of objects it contains). In this case, another additional class has to be generated, WITH_CITY, that defines the common method between ADDRESSES and EMPLOYEES'; so, this method can be inherited by both of them. OBJECTS WITH_CITY PEOPLE
City()
...
Address() ADDRESSES ...
CLIENTS
EMPLOYEES’’ ...
Category()
EMPLOYEES Salary()
EMPLOYEES’
Figure 4. Automatic Class Integration by Inheritance. Subtype Incompatibility Problem. Lastly, figure (5) shows the selection of the set of classes that will compose the external schema, corresponding to figure (3). If a class in the set references another class in the conceptual schema, this class is added automatically to the original set; this defines the closure criterion of an external schema (Rundensteiner, 1992a). In the example, the schema was already closed.
External Schema OBJECTS
PEOPLE
ADDRESSES
...
...
Address()
City()
EMPLOYEES’’ CLIENTS
...
Category()
EMPLOYEES Salary()
EMPLOYEES’
Figure 5. External Schema Class Selection. Figure (5) also shows what, in our opinion, is one of the main problems of this methodology, which will be solved in the rest of this work: In order to define the external schema, a class (EMPLOYEES'') has been defined automatically and added to the conceptual schema, but this class is not included in the external schema. This class lets the original base class (EMPLOYEES), and the defined class (EMPLOYEES') be in the same schema without inheritance conflicts; however, the external schema only includes one of them. In most cases, the only schema to contain both of them will be the conceptual schema, and it would be useful only for defining more external schemas; even for this operation it will be problematic, because complex schemas not meaningful to the external schema definer may be obtained. 3. A New External Schema Definition Methodology The objective of defining this new methodology is to have the advantages of methodologies that use a definition repository, but make the repository simpler than the one of (Rundensteiner, 1992a), with only meaningful classes for the external schema definer. The problem described happens because the methodology uses inheritance for derived class integration in the repository (or conceptual schema in this case); this would make sense if this schema was to be used for some other operation, besides the external schema definition one. If this is not the case, a different method of class integration can be used. A new relationship between classes is proposed: Derivation relationship (Bertino, 1992), that relates a new derived class to the schema classes from which it is derived. Results for the external schema defined previously can be seen in figure (6); there, the only class added is the one defined by the external schema definer. This new class can be directly integrated in an object schema by means of derivation relationship. The schema that contains derived classes integrated by derivation relationship is called the global schema2.
2 The name is the same used in (Rundensteiner, 1992a), but the meaning is different.
Inheritance Aggregation Derivation
OBJECTS
PEOPLE
ADDRESSES
...
...
Address()
City()
CLIENTS
EMPLOYEES Category() Salary() ...
EMPLOYEES’ ...
Category()
Figure 6. External Schema Definition Using the New Methodology. The external schema can be generated in a way quite similar to the one of (Rundensteiner, 1992a), but considering the derivation relationship and its implications to be transformed in inheritance relationships. This kind of relationship just appears in the global schema (not in the conceptual schema); it is transformed into inheritance relationships in any external schema that include the derived class. One can argue that the derivation relationship and the global schema do not belong to the object oriented paradigm; this is not a real problem, because this kind of relationship is only included in the global schema, and this schema is only used to define external schemas; so, the object oriented paradigm does not need to be extended for end users. The global schema is only a first approximation to the external schema definition repository, and not an object schema for end users. In this example, the derived class is directly integrated in the external schema defined; but, in some cases, derived class integration by inheritance into external schemas or, which means the same, transformation of derived and inheritance relationship combinations into inheritance relationships in external schemas, is not so easy. Next, a more representative example will be shown. 3.1 External Schema Calculation from the Global Schema Starting from figure (2) example object schema, an external schema with similar structure is wanted to be defined, but without address information, just having the city, and also hiding the salary for employees. A possible definition of this external schema according to (Rundensteiner, 1992a) methodology can be seen in figure (7). First, CLIENTS' and EMPLOYEES' classes are defined according to requirements; then, they are integrated into the conceptual schema, generating in this operation some intermediate classes; lastly, some classes are selected to get the defined external schema.
OBJECTS WITH_CITY City()
PEOPLE ’’ ...
ADDRESSES ...
CLIENTS’’
CLIENTS’
PEOPLE ’
EMPLOYEES’
EMPLOYEES’’
PEOPLE
Category()
Address()
EMPLOYEES CLIENTS Salary()
Figure 7. External Schema Definition. Figure (8) shows the external schema definition using the new methodology. In this case, derived classes are directly integrated into the global schema by derivation relationships; also, proposed classes to compose the external schema are selected. Selected classes can not be integrated directly using inheritance; so, some new derived classes have to be generated. The global schema and these generated classes constitute what is called the total schema. The global schema contains the conceptual schema and explicitly defined derived classes; the total schema besides contains generated classes.
OBJECTS
PEOPLE
ADDRESSES
...
...
Address()
City()
CLIENTS
CLIENTS’ ...
City()
EMPLOYEES Category() Salary() ...
EMPLOYEES’ Category() City()...
Figure 8. Global Schema. External Schema Definition. Moreover, the external schema has to be closed, for this reason some other existing classes are automatically added to it. Thus, the resultant external schema is shown in figure (9); this is not the desired result, because this schema contains some classes not initially desired. One alternative to this problem is to define different class categories initially, when global schema classes are selected.
Two kinds of classes are distinguished: transformable and non-transformable classes. Nontransformable classes have to be added to the external schema directly (until now, all classes were non-transformable); transformable classes can be replaced by another new derived class in the external schema if necessary.
OBJECTS WITH_CITY City()
PEOPLE ’’ ...
PEOPLE
ADDRESSES
Address()
...
PEOPLE’ CLIENTS
CLIENTS’
EMPLOYEES Category() Salary() ...
EMPLOYEES’
Figure 9. Total Schema. A Possible Resultant External Schema. The external schema shown in figure (9) corresponds to the case in which all classes were qualified as not transformable. If the PEOPLE class is qualified as transformable, the corresponding external and total schema obtained are shown in figure (10); there can be seen that the PEOPLE class is replaced by the generated PEOPLE' class in the external schema. This new class is defined according to the structure of not transformable classes belonging to the external schema specified. Now, only strictly necessary classes for the external schema are generated.
OBJECTS
PEOPLE PEOPLE’
ADDRESSES
...
...
Address()
City()
...
City() CLIENTS
CLIENTS’
EMPLOYEES Category() Salary() ...
EMPLOYEES’ ...
Category()
Figure 10. Total Schema. Correct Resultant External Schema. Figure (11) shows a representation of the different schemas that take part in the definition of this external schema.
AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA A AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA Conceptual Schema AAAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA A AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA A AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA Global Schema AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA A AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAAAAAAAAAAAAAAA AAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAA AA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA OBJECTS AAAA AAAAAAAAAAAAAAAAAAAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA A AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA Total Schema AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA A AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA External Schema AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA A AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA A AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA PEOPLE ADDRESSES AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAA AA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA ... ... AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA A AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA A AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA Address() City() AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAA AAAA AAAA AA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAPEOPLE AAAAAAAA AAAAAAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA ’ AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA A AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA ... AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA A AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA A AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA City() AAAA EMPLOYEES AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAA AAAA AA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA A AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA Category() AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA A AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA CLIENTS AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAA AAAA AAAA AAAA AAAA AAAA AA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA Salary() ... AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA A AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA EMPLOYEES ’ AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA CLIENTS ’ AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA ... AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA Category() AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA
Figure 11. Schemas to Define External Schemas.
OBJECTS
PEOPLE
ADDRESSES
...
...
Address()
City()
PEOPLE’ ...
EMPLOYEES Category() Salary() ...
City() CLIENTS
EMPLOYEES’ ...
Category()
Figure 12. Alternative External Schema Definition. Global Schema.
OBJECTS
PEOPLE
ADDRESSES
...
...
Address()
City()
PEOPLE’ EMPLOYEES Category() Salary() ...
...
City()
CLIENTS
EMPLOYEES’ CLIENTS’
EMPLOYEES’’
...
Category()
...
Category()
Figure 13. Alternative External Schema Definition. Total Schema.
There are other ways of defining the same external schema; figure (12) shows the global schema obtained from definition of this external schema in a different way. In this case, the derived class PEOPLE' is defined as non-transformable, classes CLIENTS and EMPLOYEES' as transformable (EMPLOYEES' class is defined just hiding the Salary() method). With these conditions the external schema generated is equal to the one of figure (11), but a different total schema is obtained, that of figure (13), because the generated classes are different in this case. 3.2 New Methodology Main Characteristics • The process of integration of derived classes has two phases in this methodology: Firstly,
derived classes are integrated directly into the global schema by derivation relationships. Then, they are integrated into the external schema, but this time considering only the set of selected classes and using inheritance relationships. Thus, the amount of auxiliary classes to generate in order to integrate derived classes by inheritance is less than in previous methodologies; the reason is that, in this case, the set of classes to integrate by inheritance is also less than before, because now only the classes that participate in the composition of the external schema instead of the whole conceptual schema are used. This can be clearly seen in the schema obtained in figure (7) versus the one of figure (10) with the new methodology, both of them for the same example. • External schema definers can now work directly on a schema that contains only classes
explicitly defined by them (in addition to conceptual schema classes): generation of complex and not meaningful schemas is avoided. • The new concepts of transformable and non-transformable classes simplify the external
schema definition process, because they permit the direct generation of the classes needed in the external schema, avoiding more complex definitions. • This methodology respects the ANSI/X3/SPARC three-level schema architecture: External
schemas are defined directly on the conceptual schema, even though an external schema definition repository is used in this process (the global and total schemas). • With the definition of this methodology, in particular using the derivation relationship to
integrate derived classes, the object oriented paradigm is not changed: the derivation relationship does not appear in object schemas for end users, it is only used in the external schema definition repository. • A repository as the one defined here, structured in form of the global and total schemas,
provides a mean of reusing previous external schema definitions and integrate them in a coherent way. • According to the classification of external schema definition methodologies made before,
the new methodology belongs to the second group: defined external schemas are not necessarily subschemas of the conceptual schema. On the contrary to existing methodologies belonging to this group, this methodology uses an external schema definition repository, avoiding in this way previous disadvantages.
• In the examples presented, derived classes were always defined according to object
preserving semantics. This is not a limitation of the new methodology: derived classes defined according to object generating semantics can also be handled in the same way. 4. Related Work In OODB only a few works treat explicitly obout the definition of external schemas referencing the ANSI/X3/SPARC three-level schema architecture (Barclay et al., 1993; Souza et al., 1994; Kim et al., 1995), but the respective proposed models do not fulfil it completely. In the case of (Barclay et al., 1993), as presented before, they just make a simulation of the defined external schema using the sole object of a specially defined class. In the model proposed in (Souza et al., 1994) (continuation of Abiteboul et al., 1991), an external schema is defined from the conceptual schema using operations that permit the definition of derived classes, and modify or hide existing ones. Derived classes are integrated in the external schema by a new relationship: "may_be" relationship, using the concept of non-strict inheritance. Since external schemas are offered to end users, this means a modification of the object oriented paradigm. They do not use any external schema definition repository to integrate the definitions made before. (Kim et al., 1995) references the ANSI/X3/SPARC three-level schema architecture too. At the beginning of their paper, they define the concept of view as an external schema; secondly, they treat and define a view as a derived class. The derivation relationship is also used to relate derived classes with base or derived classes. They propose to have two separate inheritance hierarchies in the same schema: one for base classes, and another for derived classes; the link between these hierarchies is the derivation relationship. At the end of their paper, the external schema definition problem is presented as an extension of their view concept seen up to now; it is defined as a dynamic window into the schema of a database, but without considering the previous definitions made. In their second definition of view, inheritance relationships in external schemas have to be explicitly defined. So, this work can be classified as a methodology of the second group: defined external schemas are not necessarily subschemas of the conceptual schema. They do not use any external schema definition repository either. The derived relationship concept appears in previous works about the derived class integration in an object schema problem (Bertino, 1992; Souza et al., 1994; Kim et al., 1995). We use this concept without involving a change of the object oriented paradigm, because it is not offered to end users; they always will work with compliant object oriented schemas. As was earlier mentioned, this new external schema definition methodology has been defined in order to solve some of the problems that the MultiView methodology (Rundensteiner, 1992a) has. 5. Conclusions and Future Work Given the importance and usefulness of having an external schema definition mechanism in OODB, this work has gone deeply into this subject. A new external schema definition methodology has been presented that fulfil the ANSI/X3/SPARC three-level schema
architecture; most of the concepts used in this methodology are not new, what is new is the defined combination of them and also the obtained results. The transformable and non-transformable class concepts have been defined and how they simplify the external schema definition process has been shown. Also, the global and total schema concepts have been defined; they implement the external schema definition repository, and relate external schemas with the conceptual schema. Defined derived classes are integrated by derivation into the repository, and by inheritance into end user object schemas. Moreover, this methodology copes with object generating and preserving semantics. The defined methodology is not particular to any object oriented model: it uses common concepts to most of the existing object oriented models. It would be interesting to extend the defined methodology in order to adapt it to use the concepts of richer object oriented models as BLOOM (Castellanos et al., 1992), in particular to give the possibility of defining constraints into the existing schemas. In (Ra et al., 1995) a method to translate schema evolution operations on external schemas to the conceptual schema, using the external schema definition methodology of (Rundensteiner, 1992a), is presented; this problem can be considerably simplified using the new external schema definition methodology. Acknowledgments I would like to thank Prof. Fèlix Saltor, and the anonymous reviewers for their helpful comments on earlier versions of this paper. References (Abiteboul et al., 1991):
S. Abiteboul, A. Bonner. Objects and Views. In Proceedings of ACM SIGMOD, pages 238-247, May 1991.
(ANSI/X3/SPARC, 1975):
ANSI/X3/SPARC Study Group on Database Management Systems. Interim report. ACM SIGMOD Bulletin 7, n.2, 1975.
(Barclay et al., 1993):
P.J. Barclay, J.B. Kennedy. Viewing Objects. In M. Worboys, A.F. Grundy (Eds.). Advances in Databases. 11th British National Conference on Databases, BNCOD-11, Keele, UK, July, 1993, pages 93-109, Springer-Verlag, 1993.
(Bertino, 1992):
E. Bertino. A View Mechanism for Object-Oriented Databases. In A. Pirotte, C. Delobel, G. Gottlob (Eds.). Proceedings of the 3rd International Conference on Extending Database Technology, pages 136-151, Springer-Verlag, 1992.
(Castellanos et al., 1992):
M. Castellanos, F. Saltor, M. García. A Canonical Model for the Interoperatibility among Object Oriented and Relational Models. In M.T. Özsu, U. Dayal, P. Valduriez (Eds.), Proceedings of the International Workshop on Distributed Object Management, Edmonton, Canada, 1992.
(Geppert et al., 1993):
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 für Informatik, Universität Zürich, June, 1993.
(Kim et al, 1995):
W. Kim, W. Kelley. On View Support in Object-Oriented Database Systems. In W. Kim (Ed). Modern Database Systems: the Object Model, Interoperability, and Beyond. Chapter 6, pages 108-129, ACM Press, 1995.
(Ra et al., 1995):
Y.-G. Ra, E.A. Rundensteiner. A Transparent Object-Oriented Schema Change Approach Using View Evolution. In P.S. Yu, A.L.P. Chen (Eds.). Proceedings of the 11th International Conference on Data Engineering, pages 165-172, Taipei, Taiwan, March, 1995.
(Rundensteiner, 1992a):
E.A. Rundensteiner. MultiView: A Methodology for Supporting Multiple Views in Object-Oriented Databases. In L.-Y. Yuan (Ed.), VLDB'92 Proceedings of the 18th International Conference on VLDB, pages 187-198, Vancouver, Canada, August, 1992.
(Rundensteiner, 1992b):
E.A. Rundensteiner. A Class Integration Algorithm and Its Application for Supporting Consistent Object Views. University of Calalifornia, Irvine, Technical Rep #92-50, May, 1992.
(Souza et al., 1994):
C. Souza, S. Abiteboul, C. Delobel. Virtual Schemas and Bases. Information Systems Vol.19, No.1, pages 81-94, 1994.
(Tanaka et al., 1988):
K. Tanaka, M. Yoshikawa, K. Ishihara. Schema Virtualization in Object-Oriented Databases. Proceedings of the 4th International Conference on Data Engineering, IEEE Computer Society Press, pages 23-30, February, 1988.
(Tresch et al., 1993):
M. Tresch, M.H. Scholl. Schema Transformation without Database Reorganization. SIGMOD RECORD, Vol.22, No.1, pages 21-27, March, 1993.
