OHQL: a hypertext approach for manipulating object-oriented databases

Informcmon ~rocessrng & Management Vol. 28. No. 5, pp. 567-579, 1992 Pruned m Great Bnta~n.

CopyrIght

0

03OfP4573/92 SS.00 + .Ml 1992 Pergamon Press Ltd.

OHQL: A HYPERTEXT APPROACH FOR MANIPULATING OBJECT-ORIENTED DATABASES ERIC ANDONOFF, MICHEL CANILLAC, CATHERINE MENDIBOURE, and GILLES ZURFLUH C.E.R.I.S.S., (Received

University Toulouse I and I.R.I.T., University Toulouse III, Toulouse Cedex, France 15 July 1991; accepted in final form 2 January 1992)

object-oriented database management systems (OODBMS) provide powerful end-user interfaces. The manipulation at the object level is graphical and navigational, whereas the manipulation at the class level is based on a query language close to SQL. This way of interrogating classes is an impediment for users who are not specialized in computer science as SQL is in the relational database management systems (RDBMS). In this article, we describe an interface for an OODBMS. This interface, called OHQL (Object Hypertext Query Language), implements some concepts from the Hypertext Systems and is intended for nonspecialist users (managers, decision-makers, . . .). The latter visualize the scheme of the object-oriented database (OODB) in the shape of a hypergraph. They express queries graphically from the nodes and the links of the hypergraph. They handle the complex and multimedia objects and the classes of the OODB in an unified way. Abstract -The

I. INTRODUCTION

of the relational database management systems (DBMS) are widely accepted (Gardarin & Valduriez, 1990) and several systems have been developed to answer to this weakness. Those systems emphasize the structural, operational, or behavioural aspect of the objects they handle (Dittrich, 1986). The systems which emphasize the behavioural aspect of the objects are based on concepts from the object-oriented programmation (Goldberg & Robson, 1983; Meyer, 1988). They are called object-oriented database management systems (OODBMS). They design the structure and behaviour of the objects and they preserve the acquired knowledge of the extended relational DBMS, at the structural level. Moreover, those systems are fit to the new fields of database applications (office automation, CAD/CAM, technical documentation, . . .) because they facilitate the handling of voluminous, complex, and multimedia objects (Woelk, Kim, & Luther, 1986; Gardarin & Valduriez, 1990). The OODBMS on the market offer declarative and powerful query languages. Those languages are SQL extensions [as in IRIS (Beech, 1988); 02 (Cluet, Delobel, Lecluse, & Richard, 1989), or ONTOS (Andrew, Harris, & Duhl, 1990)] or are new languages strongly inspired from SQL [as in GBASE (Graphael, 1988), GEMSTONE (Copeland & Maier, 1984) or ORION (Kim, 1989)]. User-friendly graphic interfaces were developed especially in GBASE, 02, or ONTOS. The user manipulates the objects and the classes of an OODB. Objects are consulted one by one and the user goes through the references of objects. Classes are consulted with the query language proposed by the system. This manipulation of classes requires a theoretical knowledge about the used model and the learning of a language whose structure is often strict. This is an impediment for users who are not specialized in computer science. The Hypertext Systems (Conklin, 1987) are the subject of numerous works in various fields of studies. They offer powerful and friendly interfaces for the handling of voluminous and complex documents (Halasz, 1988; Yankelovich, Haan, Meyrowitz, & Drucker, 1988).

The limits

A version of this paper was presented at the RIA091 conference, Barcelona, Spain, 2-5 April 1991. Correspondence should be sent to Dr. Andonoff, I.R.I.T., UniversitC Paul Sabatier, 118, Route de Narbonne, 31062 Toulouse Cedex, France. 567

E. ANDONOFF et al.

568

Those systems visualize documents in the shape of hypergraphs composed of nodes connected by links. The nodes correspond to documentary units and the links express semantic or structural binds between those nodes. The main interest of the hypertext approach is that it facilitates the consultation of the data. This way of functioning is particularly interesting for nonspecialist users. In this article, we propose a graphic interface for the manipulation of complex and multimedia objects in an OODB. This interface is based on some concepts from the hypertext systems and is intended for users who are not specialized in computer science. It enables the user to manage the objects and the classes in a unified way which is more natural and easier than in most present interfaces (Andonoff, Canillac, Mendiboure, & Zurfluh, 1991). This paper is organized as follows. The section 1 describes the object-oriented data model used in OHQL (we only speak about the concepts useful for this paper). In section 2, we propose an example of an OODB which is a support for section 3 in which we present the main functionalities of the interface. Finally, OHQL is evaluated in conclusion.

2. THE OBJECT-ORIENTED

DATA MODEL

2.1 Object and class An object is a collection of structured components; it is identified by a unique reference (Gardarin & Valduriez, 1990). It has a state and a behaviour. The state of an object is a pair (identifier, value). Its identifier is unique; it is the object identity (noted id_) (Khoshafian & Copeland, 1986). The structure of an object is described by a collection of attributes. The value of the object corresponds to the values of its attributes. The behaviour of an object is defined by a set of operations called methods. They manipulate and return the state of an object. Objects can communicate with one another through messages. A message has the following syntax which is like the syntax of the Eiffel language (Meyer, 1988): Receiver.Selector

(Arguments)

The Receiver is the object which receives the message. The Selector is the name of the method which must be executed, and Arguments are the possible parameters. An object reacts to a message by executing the corresponding method. The attributes and methods are modeled in an object at the same time, owing to the notion of encapsulation. The structure of an object is hidden to the user, who can only manipulate it with the methods which are visible from outside the object. Those methods are public and constitute the public interface of an object. The objects described by the same structure and the same behaviour are grouped together into the same conceptual entity, the class. A class is designated by a name and owns an intention and an extension. l

l

The intention of a class describes the common properties (attributes and methods) of its objects. The methods of these objects constitute the interface of the class. The extension of a class is the set of instances of the class. An instance corresponds to the state of an object at a given moment.

A class is an object factory; the class is used to generate new objects. A new object is created by performing a method of object creation on the class. The model provides atomic classes: INTEGER, REAL, STRING, PICTURE, and TEXT. It also offers the structural classes SET and LIST which perform the role of constructors (they are noted { ) and ( )) (Gardarin & Valduriez, 1990). Atomic objects or collection objects (set or list) can be defined. 2.1.1 Inheritance and inheritance graph. Inheritance comes from the concept of generalization in semantic models. The classes are hierarchically organized. The generalization

A hypertext approach for manipulating databases

569

gathers the common properties of several classes (called subclasses) in a more general class (called superclass). The transmission of properties from a class to a subclass is made by inheritance. The intention of a subclass is described by the set of properties owned and inherited. The interface of the class is described by the public methods, owned and inherited. The generalization expresses the “is-a” relationship between a subclass and a superclass. Therefore, every instance of a subclass is also an instance of its superclass. The extension of a subclass is included in the extension of its superclass. This inheritance is an inheritance by inclusion (Atkinson et al., 1989). The model provides multiple inheritance: a class can have several direct superclasses. The clashes between the names of inherited properties are solved by renaming the properties (Meyer, 1988). The inheritance relationship between different classes is represented by a graph called class lattice. This graph owns a root called OBJECT. It is the class which shares the common behaviour of all the objects. 2.1.2 Domain and integrity constraints. Each attribute of a class is defined on a class called domain of the attribute. The value of an attribute is an object owned by its domain or by one of the subclasses of the domain. This value is the identity of the object if the domain is complex or it is the value of the object itself if the domain is atomic. EXAMPLE ChSS

COURSE

att~but~

title official

: string : teacher

class attributes

TEACHER : integer degree room : string

The attribute title of the class COURSE is defined on the class STRING which is its domain, called atomic domain. The value of this attribute is the string corresponding to the title of the course. The attribute official of the class COURSE is defined on the class TEACHER which is its domain, called complex domain. The value of this attribute is the object identifier of an object teacher. A set of semantic integrity constraints, inherent to the model, supports the consistency of the OODB. We distinguish the inheritance constraints and the domain constraints. The latter are: l

l

Simple domain constraints, when the attribute is defined on an atomic domain (it is equivalent to the domain constraints in the relational model). Complex domain constraints when the attribute is defined on a complex domain; they are identity constraints.

3. THE EXAMPLE

This example describes a university database with courses, students, degrees, and researchers (PhD students and teachers) who are members of university’s laboratories. The designer’s view of the classes is the following:

class Superclass

LAB0

class Super&w Attributes

DEGREE OBJECT

STRING

title credits exams

Methods Ipn 28:5-c

class

: string : set(course) : list(string) : teacher

official nb_course(credits):integer;

Superclass Attributes

Methods

COURSE OBJECT : string title nb_hours : integer teachers : set(teacher) room : integer timetable(room):list(course);

570

E. ANDONOFF et Q/.

class Superclass Attributes

PERSON OBJECT name

first-name

ChSS

: string : integer

:integer photo : picture agefss#):integer;

Superclass Attributes

SS#

Methods class Superclass Attributes

STUDENT PERSON NO-card : integer prepare-for : degree CV : text

hlethods class Superclass Attributes Methods

TEACHER PERSON grade : integer laboratory :labo room : string wag~(grade):real;

PhD_STUDENT STUDENT laboratory : labo reader : teacher team(laboratory):set(PhD_student)

The class LAB0 illustrates the semantic of an atomic domain; it is a specialization of the class STRING. The others classes are subclasses of the superclass OBJECT. They have attributes whose domains are simple (e.g., title:string) or complex [e.g. official:teacher, credits:set(course)~. 4. THE OHQL INTERFACE OHQL recovers several concepts from the hypertext systems. It supports the data model introduced in Section 2. The user can consult and handle a OODB without knowing the structure of the handled objects. 4.1 The hypergraph The scheme of an object-oriented database is displayed on a hypergraph (Canillac, 1991). The nodes correspond to the classes, the links are sets of classes gathered according to inheritance and domain constraints. This hypergraph is not very easy to read by the users so it is linearized: a link (named inheritance link or domain link) joins only two nodes. The characteristics of the hypergraph follow: 0 The nodes correspond to the class OBJECT, which is the root of the inheritance graph, and to the nonatomic classes defined by the user (in our example, classes DEGREE, COURSE, PERSON, STUDENT, TEACHER and PhD_STUDENT). The other classes which are predefined or atomic non-predefined (like the class LABO) are not represented in order to simplify the user’s view. l The links correspond to the inheritance constraints and domain constraints. They graphically illustrate the methods in which the linked classes intervene. When a link is selected, the system sends messages which execute the corresponding methods. The user manipulates a OODB in handling (a) nodes which group objects with common properties; and (b) links which are actions on the linked nodes and on the hold objects. For the user, a link is like a button which can be clicked (so the link is in inverse video). Figure 1 corresponds to the example of Section 3. The links of the hypergraph correspond to the several constraints existing between classes. We distinguish the inheritance links and the domain links. The inheritance links represent the transmission of properties between a superclass and its subclasses. When an inheritance link is selected, the attributes and the methods are transferred from the superclass to the subclasses (e.g. from STUDENT to PhD_STUDENT). Then, the user sees the interface of the subclass completed by the superclass one (Fig. 2). The domain links correspond to simple domain and complex domain constraints. We distinguish composition domain and compatible domain links. Composition domain links express composition relationships between objects of the base. The link “prepare-for” expresses that an attribute of the class STUDENT is defined on a domain DEGREE. A student object has a component which is an object degree (Fig. 3).

A hypertext approach for manipuIating databases

I

ODJECT

571

I

Fig. 1. Hypergraph of the university database

The link “teachers” expresses that an attribute of COURSE is defined on a structured domain with a SET or a LIST constructor. An object course has a component which is a collection of objects teacher. The link “prepare-for” is monovalued, whereas the link “teachers” is multivalued (Fig. 4). These links display the composition of complex objects and the possibilities of moving through objects. The orientation of a link shows the direction of the composition. When a link is selected, the components are accessible; they correspond to the implicit joins between classes described in Kim (1989). Compatible domain links show the possibilities of explicit joins between classes. The link “official, reader” expresses that these attributes are defined on compatible domains (Fig. 5). REMARK.The simple domain constraints which correspond to predefined atomic domains (INTEGER, STRING, . . .) are not represented by links. The user can only see the possibilities of joins between semantic domains. So, the consistency of his queries is assured.

1

STUDENT

1

Fig. 2. Inheritance link.

Fig. 3. Monovalued composition domain link.

512

E.

ANDONOFFet al.

Fig. 4. Multivalued composltion domain link.

Fig. 5. Compatible domain link.

4.2 Handling object and classes 4.2.1 The objects. An object has an identifier which is either a name given during the

creation of the object, or an identifier generated by the system. The system represents the objects by icons (rectangle and object identifier). The interface of an object is a menu composed of public methods of the object. The menu is handled by the mouse and its buttons. The concept of encapsulation requires hiding the structure of the objects. For each attribute of the class, the system automatically generates a corresponding method which has the same name [the approach is the same in (Banerjee, Kim, & Kim, 1988)]. When it is applied to an object, this method returns the value of the corresponding attribute. The methods title( ), credits( j, exams( ) and official( ) are automatically generated and are part of the interface of objects degree. It is important because these methods are used as arguments in the main methods of class handling. Beside these methods, public methods are defined in the scheme base. Standard methods like Display_object( ), which displays the contents of the object, Delete_object( ), and Edit_object( ) are also defined. For example, let the object be the degree “MSc”. Its icon and interface are shown in Figure 6. When the method official( ) is applied to the object “MS?‘, the system gives the official of the degree “MSc”. This is an object of the class TEACHER. The user can navigate through the objects by way of the composition domain links. When a link is not selected, the components of the objects are not accessible; only their identifiers can be seen. In this case, the icon of the object is shaded and its interface is not accessible. For example,

This possibility of navigation through the objects exists in the interfaces of the present OODB (e.g. O2 or ONTOS). 4.2.2 The classes. The identifier of a class is its name. The nodes of the hypergraph represent the classes by icons. The interface of a class is a menu with the public methods of the class. It is handled with the mouse and its buttons.

c hphy_obJeCI() Delele_obJect() &+il_obJecr nb_cowcredlu0) IlIk() cdl@ ex-0 ofticial()

Fig. 6. Interface of the object degree, MSc.

513

A hypertext approach for manipulating databases

I DEGREE

Display_icon() Create_objectO Visualize_objeetsO Display_objectsO Projection0 SelectionO Deletion0 Edition0

Fig. 7. Interface of the class DEGREE.

The interface of each class is composed of the set of predefined methods which notably enables the user to express a query bearing on one or several classes. With the methods, the user can handle sets of objects (for the user, a class is a set of objects). The methods are the following ones: Visualize_objects( ) and Display_objects( ) to represent a set of objects, Projection( ) to calculate the components of the object to display, Selection( ) to select a set of objects, Edition( ) and Deletion( ) to update a set of objects. There is no join method is proposed to the user in the interface of the classes: joins are graphically represented on the hypergraph by the domain links (composition domain link for implicit joins and compatible domain links for explicit joins). The method Create_object( ) creates a new object and Display_icon( ) represents the class as an icon. For example, let the class DEGREE. Its icon and interface are shown in Figure 7. The method Visualize_objects( ) enables the user to access to the contents of the node. It represents the objects by icons (Fig. 8). The method Display_objects( ) enables the user to access to the contents of the node with every object displayed (Fig. 9).

I

DEGREE

Fig. 8. Iconic representation of the objects degree.

I

DEGREE object

title

I exams

credits

-1

Degree of Science

m

Master of Science-

vi

-4

Doctorate

. ..

m

Fig. 9. Developed representation of the objects degree.

official

17

E. ANDONOFF et al.

574

Fig. 10. ProJection

arguments

for the class DEGREE.

4.3 Queries A query is a sequence of messages sent by the user to the classes of the OODB; it is activated and stopped explicitly by the user. The activation of a query sets off the activation of the methods corresponding to the messages. On the hypergraph, a query is a set of nodes and links in inverse video. The result of the query is a new class automatically generated by the system. This new class replaces a class already in the graph or it is integrated automatically as a subclass of the root. 4.3.1 Single class queries. 4.3.1.1 The projection. In order to perform a projection, the user chooses the method Projection( ) in the interface of the node. This produces the apparition of a window in which the user selects the several methods he wants to apply to the objects of the class. These methods correspond to the methods associated to the attributes of the class. The projection reduces the considered class just keeping, for each object, the values corresponding to the activated methods. For example, for the class DEGREE, the window is shown in Figure 10. To obtain the title and the official of the degrees, the user selects the title( ) and official( ) methods. The result is a new class which puts together the objects degree on which the methods title( ) and official( ) were applied. The node DEGREE of the hypergraph represents this temporary class. The method Display_objects( ) gives the result in Figure 11. The application of the method projection( ) can lead to a dynamic removal of links in the hypergraph when the constraints are on deleted attributes. 4.3.1.2 The selection. In order to perform a selection, the user chooses the method selection in the interface of a node. Then a window appears in which the user can construct a predicate which must be satisfied by the objects of the class. The selection restricts the extension of the class to the objects satisfying the predicate. For example, let the query: “What are the degrees whose official is Lewis?” The predicate window is shown in Figure 12. Here, it is a comparison of objects; the system verifies that the two objects are identical. The result is a new temporary class which holds all the objects DEGREE satisfying the predicate. The node DEGREE of the hypergraph represents the result class. To sate a predicate, the left operand is chosen among the proposed methods, the operator among the proposed operators. The right operand may be an atomic value, the ob-

DEGREE object

Fig.

11. Developed

representation

after

the projection.

A hype1text approach for manipulating databases

575

Fig. 12. Selection predicate for the class DEGREE.

ject name or the object icon selected graphically, a list or a set of objects, or a method. When it is a set or a list case, the user points out a sequence of objects specifying their values (for atomics objects), their names and their icons. For example, let the query be: “What are the degrees in which “UVI” and “UV2” are taught?” The predicate is the following: credits0 >= ( m

m

1

4.3.1.3 The deletion and the edition. They delete or update objects of a class in accordance with a predicate expressed in the same way. 4.3.2 Multiple-class queries 4.3.2.1 Selection of composition domain links. The selection of those links enables the user to reach the object components. A navigation can be made through the complex objects. Let us consider the complex objects degrees. For the following example, the user selected the links “credits” and “official” (Fig. 13). The system makes the implicit joins between the classes DEGREE, COURSE, and TEACHER. Every degree object is associated to the corresponding teacher object and to the corresponding course objects.

Fig. 13. Query using composition domain links.

E.

576

I

ANDONOFF

al.

et

DEGREE object m

piziq

credits

title Degree of Science

Doctorate

exams

pi

official

Ei

I

- - .

Fig. 14. Consultation

of the degree objects.

The query result is a set of complex objects represented by a subgraph in inverse video. DEGREE is the root of the subgraph, whereas the other classes are component ones. The node COURSE contains the courses which are credits in the graph of the node DEGREE. The node TEACHER contains the teachers which are responsible (official) of these degrees. The manipulation of the class DEGREE using the method Display_object( ) has the result shown in Figure 14. The icons of the objects course and teacher are no longer shaded; the objects are accessible. For example, the user can consult the official of the object “MSc” (the object “Lewis”) with the interface methods. The method Display_object( ) returns the result shown in Figure 15. The selection of the inheritance link between the classes TEACHER and PERSON realizes the transmission of the properties between those classes. The objects teacher have an interface which contains attributes and methods of the corresponding objects person. When the user assesses to the object “Lewis”, the result is shown in Figure 16. The user can go on with his consultation and access to the Lewis’s photography activating the button “photo Lewis”; the picture is displayed on the screen (see Fig. 17). In a similar way, the user can reach the objects course which are in the objects degree. To perform selections on a set of complex objects, the user makes selection queries on the subgraph classes. To make a selection on COURSE or TEACHER is equivalent putting conditions on the component objects. For example, the user activates the method selection( ) in TEACHER and reduces the set of its objects to “Lewis” and “Smith”. DEGREE will only contain the degrees whose official are “Lewis” and “Smith” and COURSE will only contain the courses which are credits of those degrees. 4.3.2.2 Selection of compatible domain links. The selection of compatible domain links enables the user to perform explicit joins between two classes. The result of that join

grade

TEACHER

1 m

1 245

Fig. 15. Consultation

maiER

name

first-name

lm

Lewis

John

IRIT

410

of the object,

ss# 1540431172274

Fig. 16. Consultation

room

laboratory

of the object

photo (pLewi3

I

Lewis.

grade

laboratory

245

Lewis after inheritance.

IRIT

room 410

A hypertext approach for manipulating databases

577

Fig. 17. Displaying Lewis’ photography.

is a set of objects obtained by concatenation of the objects of each class satisfying the join predicate. A temporary class is generated by the system. Its intention is made up of the attributes and methods of the two joined classes. Its interface is made up of the methods described in the interfaces of the two joined classes. Let us consider the example in which the user has selected the link “official, reader” between the classes DEGREE and PhD_STUDENT. This selection produces the apparition of an operator window in which the user specifies the join operator (Fig. 18). The user sees the join result in the classes DEGREE and PhD_STUDENT. They are obtained by projection of the methods associated to their respective attributes on the result class. 4.3.2.3 Handling set of complex objects. The selection of composition domain links and compatible domain links makes joins between sets of complex objects. Let us consider the following example: the user has selected the composition domains links “credits” and “reader” and the compatible domain link “official,reader”. This latter corresponds to an explicit join between two sets of complex objects represented by the classes DEGREE, COURSE, and the link “credits” on one hand, and the classes PhD_STUDENT, TEACHER, and the link “reader” on the other hand. The user sees the query result in the classes DEGREE, PhD_STUDENT, COURSE, and TEACHER (see Fig. 19). The query result is a set of complex objects; it is described by a graph. The composition domain links are the same as those of the query graph, that is, the links “credits” and

Fig. 18. Query using compatible domain link.

578

E.

ANDONOFF et ul.

Fig. 19. Query using compatible and composition domain links.

“reader”. The graph classes are those of the query graph, except for the two classes which directly intervene in the explicit join. Those classes were replaced by the class result of the join, Here, we have the classes COURSE, TEACHER and a class R which is the resuit of the join between DEGREE and PhD_STUDENT. The result is presented in Figure 20. 5. CONCLIJSION The present object-oriented database management systems usually handle classes with a language close to SQL. This handling is not very easy for people who are not specialized in computer science. OHQL offers an interesting solution: it enables these users (a) to work from the hypergraph, which gives a simplified view of the OODB. This hypergraph shows all the consistent operations which can be done on the OODB. The user does researches in the OODB by association of ideas. He formulates queries by selection of nodes and links on the hypergraph. Those queries are expressed gradually, step-by-step, and the user doesn’t need to express the queries totally before submitting them to the system; (b) to handle complex and multimedia objects by making choices of the components on which he wants to work; and (c) to express operations in an original way, which correspond to the algebraic operations of the data models for complex objects. Every graphic manipulation sets off the sending of messages to the OODB; those messages perform the corresponding methods. This way of handling classes is no longer associated to a formal query language but to a graphic query language which is easy to use, powerful, and uniform. This language is navigational, as the consultation at the level objects in the interfaces of the present

Fig. 20. Generated class after the join.

A hypertext

approach

for manipulating

databases

579

OODBMS. In favour of the hypertext approach, OHQL extends the navigational consultation at the class level. Today, OHQL is being developed at the Institut de Recherche en Informatique de Toulouse (IRIT-SIG). It is implemented above the 02 object-oriented DBMS (Bancilhon, 1988) on a Sun workstation. REFERENCES M., Mendiboure, C., & Zurfluh, G. (1991). Hypertext interface for an object-oriented at the RIAO International Conference, Barcelona. Andrew, T., Harris, C., & Duhl, J. (1990). The ONTOS object-ortented database. Ontologic Incorporation. Atkinson, M., Bancilhon, F., Dewitt, D., Dittrich, K., Maier, D., & Zdonik, S. (1989). The object-oriented database system manrfesto. Presented at the first International Conference on Deductive and Object-Oriented Databases. Kvoto. Bancilhon, F. (1988). The design and implementation of 02, an object-oriented database system. Presented at the second Object-Oriented Databases Systems Workshou. Bad Munster. Banerjee, J., Kim, W., & Kim, K.C. (1988). Queries in object-orrented databases. Presented at the fourth International Conference on Data Engineering, Los Angeles. Beech, D. (1988). A foundation for evolution from relational to object databases. Presented at the Extended Databases Technology, Venice. Canillac, M. (1991). (In modele et we interface hypertexte pour bases de don&es orientees-objet. PhD thesis, University Toulouse III, France. Cluet, S., Delobel, C., Lecluse, C., & Richard, P. (1989). Reloop, an algebra based query language for an object-oriented database system. Presented at the first International Conference on Deductive and Object-Oriented Databases, Kyoto. Conklin, J. (1987). Hypertext: an introduction and survey. IEEE Computer, 20(9), 17-41. Copeland, G., & Maier, D. (1984). Making smalltalk a database system. Presented at the International Conference on SIGMOD, Boston. Dittrich, K. (1986). Object-oriented database systems: the notions and the issues. Paper presented at the International Workshop on Object-Oriented Database Systems. Gardarin, G., & Valduriez, P. (1990). SGBD avances: bases de don&es orientees objets, deductives et &parties. Paris: Eyrolles Publishing Company. Goldberg, A., & Robson, D. (1983). Smalltalk-80: the language and rts implementatron. Reading, MA: AddisonWesley Publishing Company. Graphael, S.A. (1988). GBASE 3.2 manual, 2nd version. Presented by S.A. Graphael m Compiegne. Halasz, F.G. (1988). Reflexions on notecards: seven Issues for the next generation of Hypermedta systems. ComAndonoff,

E., Canillac,

database. Paper presented

munication of the ACM, 31, 836-852. KhoshaLian, S., & Copeland, G. (1986). Object rdenttty. Presented at the first ObJect-Oriented Programming, Systems, Languages and Applications International Conference, Portland. Kim, W. (1989). A model of queries for object-orrented databases. Presented at the fifth international Conference on Very Large Databases, Amsterdam. Meyer, B. (1988). Object-Oriented Software Construction. Englewood Cliffs, NJ: Prentice-Hall. Woelk, D., Kim, W., & Luther, W. (1986). An object-oriented approach to multimedia databases. Communicatron of the ACM, 31 l-325. Yankelovich, N., Haan, B., Meyrowitz, N., & Drucker, S. (1988). Intermedia: theconcept and theconstructron of a seamless information environment. IEEE Computer, 21 81-96.