North-Holland Microprocessing and Microprogra mming 27 (1989) 127-132 127

A New Approach Towards an Object-Oriented Database System.

S, Goutas, P. Soupos, D. Christodoulakis

Computer Engineering Dept. and

Computer Technology Institute University of Patras, 26500, Patras, Greece

In this paper we describe an object-oriented (O-O) database system that supports databases consisting of an extensible set of self-sufficient modules loosely coupled with each other. The object-oriented model used provides semantic constructs that enhance its expressive power and ensure consistency of data. Retrieval is accommodated by a query language based on Horn Clauses. These properties make our system suitable for storage of data in areas such as CAD/CAM, office information systems and artificial intelligence.

1. Introduction

The object-oriented paradigm has proved itself a very suitable concept in database management systems in- tended to meet the needs of new database applications such as CAD/CAM, office information, knowledge- bases etc. So far it has led to the development of a number of systems that either use it at the conceptual level and rely on relational DBMS's for storage or build complete database systems on it.

The object-oriented approach in databases has emerged from semantic data models and object-orien- ted programming languages. The differences between the two areas has led to a variety of interpretations and applications of the basic concepts and it seems that a lot of work can be done in this direction.

We have designed an object-oriented database sys- tem from scratch based on principles from semantic data models, logic databases and expert systems. The basic idea is to express relationships between objects in a simple, declarative manner as part of the behaviour of objects, include conditions in their definition to as- sure consistency of interrelation and maintain them by the system kernel so as to provide trancpareney. For these reasons, following the expert system approach, we express relationships by rules, placed in the defi- nition part of interrelated objects. At a lower level, relationships between object instances are maintained by direct links that speed up retrieval.

The role of relationships has been broadened to in- elude interactions between objects belonging to differ- ent schemas. So the overall schema of an application can consist of separate subschemas connected with rela- tionships modelling interactions between subschemas.

In that sence modular design can be applied since log- ically independent parts of an application can be mod- elled separately and then linked with relationships rep- resenting their interactions.

Emphasis is also placed on relationships as far as retrieval is concerned. The query language is based on logic programming where relationships between ob- jects are also expressed. The disadvantages of evaluat- ing recursive logic queries are overcome by the object- oriented organization of facts and the direct links be- tween related instances.

The strueture of this paper is as follows. First, we describe the structure of objects and their hierarchi- cal organisation. We then describe relationships ex- pressing interactions between objects as well as their application. Next, we describe how the constructs of the data model can be combined to form schemas and in turn how schemas viewed as database modules can be interrelated. Finally we discuss data manipulation focussing on the query language, views and recursion.

2. Objects

The object oriented approach in the Database world fits well with our conception of the world as numer- ous abstractions and classifications over concrete ob- jects. Nevetheless there is no unique way to apply this approach as can be seen from the various O-O data models developed so far [1, 3, 5, 8, 10, 11, 14].

Our notion of the O-O approach focuses on elabo- rate type classification that defines multiple abstrac- tion levels on data which serve as views on the

128 S. Goutas eta/. / A New Approach Towards an Object-Oriented Database

database. Classification leads to abstract data types that are either abstractions or collections. Abstrac- tions are referred to as type-objects and their purpose is to define abstraction levels on data. Collections are called collection-objects and represent data types along with their instances. The overall type structure is a type lattice. This approach is advantageous compared to simple inheritance since it simplifies data modeling. The conflicts arrising between types are resolved via renaming as in EXTRA [5].

Objects as type definitions apart from specifying data also specify knowledge about the data, in the form of rules, which are monitored by the database system at all times. This ensures that schema semantics are followed and concistency is kept. We have isolated two types of information to be expressed with rules, namely, disciplined relationships and aggregations. Disciplined relationships axe binary links between an object and the world under constraints. Aggregations on the other hand form groups of instances of an object according to predicates. Their purpose is to organize instances within a certain collection-object according to changing retrieval requirements.

Furthermore objects provide database views to users. As we know a view is a subset of the data held in the database visible to a specific end-user for a specific purpose. Views are very important in terms of security and data independence. An object in itself is a prim- itive view on the data it describes as a type [21]. But an object can have a view to more data according to the relatioships it keeps with the rest of the objects in the database. It is therefore possible to have a view of the database through queries issued from an object, in other words to have a view, in the form of a query set, from that object. This view is attached to the object and provides a template to the user.

3. I n h e r i t a n c e

As can be seen in various existing systems the IS-A relationship [16] is not enough to cover every hierar- chical scheme required in applications where not "tra- ditional" data are involved. So the IS-PART-OF re- lationship has been introduced. Furthermore it is of- ten useful when creating a new object to use proper- ties defined for another object without the implications of IS-A and IS-PART-OF. Having taken that into ac- count we have adopted two types of hierarchical re- lationships, the IS-A hierarchy which accommodates the principle of generalization/specialization [4] and a partial inheritance hierarchy where an object inherits some properties from one or more than one objects, this is referred to as subtype/supertype hierarchy. In case no properties are inherited, this type of hierar- chy simply expresses taxonomy of objects. The IS- PART-OF relationship can be expressed by combining the subtype/supertype hierarchy and a disciplined re- lationship as will be shown in section 4.

An example [13] demostrating the IS-A hierar- chy can be seen in figure 1 where the savings_account and checking_account collection-objects inherit the ac- count_number and balance attributes from the account type-object. Savings_account and checking_account in- herit all the attributes of account and each has one more attribute of its own, namely interest_rate and overdraft_ammount so they are specializations. As al- ready mentioned type-objects do not actually carry in- tances of their own. But since according to our in- terpretation the IS-A hierarchy expresses generaliza- tion as well, account has virtual instances. Virtual in- stance of an object 0 is any instance of the set of its attributes T belonging to an other object that has in- herited T from O through IS-A. For example the values of account_number and balance in the instances of sav- ings_account and checking_account make up the virtual instances of account.

ISA ~ I S A

TYPE account: (.account_number: string, .balance: real).

COLLECTION savings_account IS_A account:

(.interest_rate: real). COLLECTION checking_account

IS_A account: (.overdraft_ammount: real).

Figure 1.

The example in figure 2 demonstrates multiple- inheritance along with the IS-A and subtype/supertype hierarchies where the amphibious_vehicle collection- object inherits the number_of_tyres and horse_power at- tributes, that is all the attributes from the land_vehicle collection-object and the propeller from the boat collec- tion-object. The hierarchy between land_vehicle and amphibious_vehicle is IS-A and concequently the in- stances of amphibious_vehicle are virtual instances for land_vehicle. The amphibious_vehicle is also a subtype of boat since it inherits just the propeller attribute from it.

S. Goutas et aL / A New Approach Towards an Object-Oriented Database 129

ISA N ~ ~ Subtype

p h i b i o u s _ ~

COLLECTION land_vehicle: (.number_of_tyres: integer, .horse_power: integer).

COLLECTION boat: (.propeller: string .sea-horse_power: real).

COLLECTION amphibious_vehicle IS_A land_vehicle SUBTYPE boat:

(.propeller: boat.propeller).

Figure 2.

tion followed by the invocation of the primitive method that implements relationships. Consider for example the D R I V E S disciplined relationship between person and car. The rule D R I V E S in person reads:

DRIVES : ((.age > 18)(RELATE car))

here the predicate is that the value of attribute age of person should be greater than eighteen. The action (RELATE car), that follows, invokes method RELATE, which implements disciplined relationships, with argu- ment car, ie. the name of the object with which person is related. The corresponding rule in car reads:

D R I V E S : (OWN(person, car) (RELATE person))

here the predicate is that a person that drives a car must also own it. 0 W N i s a disciplined relationship be- tween person and car and (OWN) returns true if there is an 0 W N relationship between an instance of per- son and an instance of car. An example of an insert operation that causes an assertion is:

D R I Y E S(person(.name = john), car(.make = f errari_208 ) )

This causes the creation of links between instances of person and ear that fulfill all the predicates, namely person(.name = john), person(.age > 18), car(.make = f errari_208) a n d OWN(person, car).

4. Disc ip l ined Re l a t i onsh ip s

Relationships between hierarchically structured ob- jects are widely recognized semantic constructs in O-O data models [6, 9, 11, 17, 18, 22]. They serve to ex- press interactions between objects in a natural way. As far as we know interactions are dealt with in two ways. Either as instance variables and methods of classes or as concrete objects with fixed description and reference to other objects. The second approach is rather static since it contributes to the object schema but it also pro- vides transparency whereas the first approach is flexi- ble because it is dynamic but increases the complexity of representation. Furthermore in both approaches re- lationships between objects are not part of the object kernel in the same way as hierarchical relationships are.

As already mentioned in section 2., relationships between objects according to our view are expressed by rules which are included into the properties of objects and have common implementation code which is part of the object kernel. This approach provides the flexi- bility of instance variables and methods because rules are part of the behaviour of an object as well as simple representation and trancparency since rules constitute an effective representational form for declarative de- scriptions of domain-dependent behavioural knowledge [7].

A disciplined relationship is behavioural knowledge common to a pair of objects, represented by a rule in each participating object. Such a rule consists of a predicate that preserves the integrity of object interac-

4.1 The I S - P A R T - O F R e l a t i o n s h i p

The IS-PART-OF relationship expresses, in a declara- tive manner, that every instance of an aggregated class has associated with it instances of its components [20]. In other words it expresses two things between a class and its components, firstly taxonomy through hierar- chy and secondly reference between instances. Refer- ence between an instance of a class and the instmlces of its components is much more a relationship than a mere constraint through inheritance rules since it must be clearly specified at any moment which instances are components of which instance. This type of special be- haviour of the IS-PART-OF can be better expressed in a declarative form as a disciplined relationship which is referred to as the P A R T _ O F disciplined relationship.

The P A R T _ O F disciplined relationship can not be treated as any other ordinary disciplined relationship because it has standard semantics [12, 15, 19] and it is likely to be used more than once in a database schema. For that purpose it has become a primitive function- ality of the object kernel. Nevertheless it is treated exactly as any other disciplined relationship.

As already mentioned the complete representation of the IS-PART-OF relationship is the disciplined re- lationship P A R T _ O F along subtype/supertype hierar- chies. The example depicted in figure 3, shows the description of a forest as an object which is made up of trees. The object tree is subtype of the object for- est and there is the P A R T _ O F disciplined relationship,

130 S. Goutas et aL / A New Approach Towards an Object.Oriented Database

depicted as a two-way edge, between them to show the trees that compose a specific forest. It must be noted that it is not necessary to include the rules for the PART_OF in the objects' behaviour since they are in the object kernel.

PART_OF ~ t y p e

COLLECTION forest: (.location: string, .type: string).

COLLECTION tree SUBTYPE forest PART_OF forest:

(.height: real, .age: integer, .type: string).

Figure 3.

bidirectional edges because each pair corresponds to one disciplined relationship.

Finally a schema s is an object graph with the following properties:

1. there is one and only one type node in N, called root node, such that at least one path of hierarchical edges from every other node in N leads to it,

2. there is no cyclic path of hierarchical edges. A schema is a self-sufficient module that can serve

as a component for modular design. That is, an ap- plication can be partitioned into interacting, logically independent parts and then each part can be inde- pendently represented by a schema. These separate schemas can then be interconnected via disciplined re- lationships to form the environment of the application. In such an environment the tight hierarchical organiza- tion of objects is not followed between schemas but in- stead the more loose disciplined relationships approach is adopted for flexibility without loss of consistency.

This modular design approach, ie. with loosely coupled modules, enables the formation of distributed environments in a variety of configurations. For exam- ple a possible configuration is an environment consist- ing of schemas on different sites on a LAN. Another alternative is an environment distributed over different users of a multi-user system. Any combination of the previous two configurations is also possible.

To give a more formal definition, an environment E is a directed graph (v, D), V and D being the set of schemas and the set relationship edges respectively. A relationship edge in D is between any two nodes of any two schemas in v. A schema S is uniquely specified by its root node.

5. Schemas and Environments

To define a schema the following definitions must be given. Assume a directed graph G = (N, E) where N and E are the sets of nodes and edges respectively. The set N is the union of the set of type node8 NT and the set of collection nodes Ns. Collection and type nodes are represented graphically as semicircles and circles respectively. The set E is the union of two sets E/~ and ER. The set of relationship edges ER consists of pairs of opposite edges between pairs of nodes in N, while EH, the set of hierarchical edges, consist of single edges between nodes in N. Furthermore Ex is the union of E1SA, the set of IS-A edges, and EsuB, the set of subtype edges.

An object graph Go is a directed graph G where each type node corresponds to one type object, each collection node corresponds to one collection object and there is one-to-one correspondence between rela- tionship, IS-A and subtype edges and disciplined re- lationships, IS-A and subtype/supertype hierarchical relationships. Relationship edge pairs are depicted as

6. Data Manipulation

As one may have concluded so far key feature of our data model is relationships between objects. This should also be the case for the query language in order to make use of this capability of the data model. As we know this can be found in logic programming where re- lationships between objects are Mso expressed. In view of that similarity we have chosen a logical query lan- guage where base predicates are disciplined relation- ships and objects. In other words, from the retrieval point of view, an environment is a logic database where the base predicates are structured according to the object-oriented data model presented in the previous sections.

The underlying object-oriented organization of facts simplifies the evaluation of logic queries, which in an ordinary logic database deal with unstructured base relations. More specifically, the existence of di- rect double links between object instances (assertions), sets of object instances of a certain type (collection ob- jects) and aggregations of uniform data that satisfy a certain predicate (aggregations) directs query eval- uation and gives hints about optimization. For ex-

S. Goutas et aL / A New Approach Towards an Object-Oriented Database 131

ample direct links between two types of objects re- place a join. The price tha t one pays here, is in no- tat ion, tha t is, variables and constants always refer to a certain a t t r ibu te of a certain object, for exam- ple to express that j o h n likes m a r y one must write: i l K E( woman( .name = mary), man(.name = john)), since it must be stated that m a r y a n d j o h n are the values of the a t t r ibu te .name of objects m a n a n d w o m a n .

Let us consider the environment depicted in fig- ure 4 where m a n I S A per son , w o m a n I S A p e r s o n and the disciplined relationships L I K E ( p e r s o n , p e r s o n ) a n d L IKE(person , game), (note here that L I K E is polymor- phic). Furthermore, because of the I S A , L I K E is inher- ited by m a n and w o m a n . A query to find a game that both mary and john like, is:

? L I K E ( m a n ( . n a m e =john), z),

L I K E( woman( .name = mary), x ).

To find the z's that answer this query one has to find any instance that is linked both with the instance of object m a n where .name = j o h n and with the instance of object w o m a n where .name = m a r y .

Insertion, modification and deletion axe opera- tions available for both object instances and assertions. Modifications and deletions of instances that axe in- volved in assertions axe the ones that require special t rea tment in order to preserve consistency. In case of modification of instances involved in assertions the conditions of the per t inent rules axe checked for consis- tency. If conditions axe not satisfied the affected asser- tions are deleted. Similarly when an instance is deleted all the assertions in which it is involved are also deleted. Since assertions axe double links the garbage collection mechanism removes any loose links.

6.1 V i e w s

As already said a view of an object is a set of stored queries that facilitates access to the instances of the ob- ject directly and the intances of other objects through disciplined relationships. Access to instances of other objects is possible if there is a sequence of relationship edges to these objects. A p o t e n t i a l v i e w of an object o is the union of the instances of O and the instances of all the objects which axe reachable from o via any sequence of relationship edges. Thus a potent ial view is the set of potent ial ly relevant facts [2] for the answer of any query of O.

Stored queries axe analogous to rules in logic pro- gramming. For example the following stored query of the object p e r s o n expresses that men admire any woman that plays football:

A D M I R E ( m a n ( . n a m e = x), y) : -

L I K E( woman(.name = y), game(.name = f ootbaU) ).

To find the women that john admires one has to write: ? A D M I R E ( j o h n , x)

LIKE

TYPE person: LIKE: (true (RELATE game)); LIKE: (true (RELATE self));

(.name: string, .age: integer, .address: string).

COLLECTION man IS_A person:

(.height: real, .weight: real).

COLLECTION woman IS_A person:

(.height: real, .weight: real).

COLLECTION game: LIKE: (true (RELATE person));

(.name: string, .players_no: integer, .referee_no: integer).

Figure 4.

The heads of stored queries are derived predicates that can be used in building other queries.

6.2 R e c u r s i o n

The evaluation of recursive logic queries is t radit ionally a source of inefficiency. Our query language, as it is based on disciplined relationships, produces queries the relevant facts of which axe assertions in the form of double links. Let us consider the A N C E S T O R stored query which is defined recursively using the disciplined relationship PARENT(per son ,per son )

A N C E S T O R(person(.name = x), person(.name = y ) ) : - P A R E N T ( p e r s o n ( . n a m e = x), person(.name -- z)),

A N C E S T O R(person(.name -- z ), person(.name = y) ).

A N C E S T O R ( p e r s o n ( . n a m e = z) ,person( .name = y)) : -

P ARENT(per son ( .name = x), person(.name = y)).

132 S. Goutas et al. / A New Approach Towards an Object-Oriented Database

Since P A R E N T is a disciplined relationship for every virtual instance of p e r s o n involved in P A R E N T there is a tree of double links with nodes other instances of p e r s o n also involved in P A R E N T . Now, the answer to the query

? A N C E S T O R(person(.name = john), person(.name = y) ).

is simply the traversal of such a tree of double links caused by P A R E N T with root an instance of p e r s o n where .name = john. This tree has all the ancestors of j o h n as nodes.

7. C o n c l u s i o n s

The database system we presented in this paper incor- porates ideas from semantic databases, logic databases and expert systems. The basic concept is that of rela- tionships under constraints firstly between objects and secondly between schemas where they serve as loose links between them. Relationships are binary and are expressed by rules that contain conditions that ensure their validity at all times. Retrieval is also based on relationships and is accommodated by a logical query language. Furthermore the existence of direct dou- ble links between object instances greatly simplifies the evaluation of recursive queries. Another important point is that of rules which apart from relationships can express other types of events that may take place only when certain conditions are met, such an example is aggregations.

References [1] S. Abiteboul and R. Hull, IFO: A formal semantic

database model, ACM Transactions on Database Systems 12 (4) (1987) pp. 525-565.

[2] F. Bancilhon and R. Ramakrishnan, An amateur's introduction to recursive query processing strate- gies, Proc. ACM SIGMOD Conf., Washington, D.C., 1986, pp. 16-52.

[3] J. Banerjee, W. Kim, H.J. Kim and H. Korth, Se- mantics and implementation of schema evolution in object-oriented databases, Proc. ACM SIGMOD Conf., San Francisco, Cal., 1987, pp. 311-322.

[4] R. Brachman, What IS-A is and isn't: An analy- sis of taxonomic links in semantic networks, IEEE Computer 16 (10) (1983) pp. 37-41.

[5] M. Carey, D. DeWitt and S. Vandenberg, A data model and query language for EXODUS, Proc. ACM SIGMOD Conf., Chicago, Illinois, 1988, pp. 413-423.

[6] O. De Troyer, J. Keustermans and R. Meersman, How helpful is an object-oriented language for an object-oriented database model?, Proc. 1st Intern. Workshop on Object-Oriented Databases, Pacific Grove, Cal., 1986, pp. 124-132.

[7] R. Fikes and T. Kehler, The role of frame-based representation in reasoning, Communications of the ACM 28 (9) (1985) pp. 904-920.

[8] D. Fishman, D. Beech et al., Iris: An object- oriented database management system, ACM Tra- ns. on Office Information Syst. 5 (1) (1987) pp. 48- 69.

[9] S. Goutas, P. Soupos et al., The use of the object- oriented approach in the GRASPIN DB, Proe. 4th ESPRIT Conf., Brussels, 1987, pp. 361-374.

[10] S.E. Hudson and R. King, Object-oriented databa- se support for software environments, Proc. ACM SIGMOD Conf., San Francisco, Cal., 1987, pp. 491- 503.

[11] D. Jagannathan, R.L. Guck et al., SIM: A database system based on the semantic data model, Proc. ACM SIGMOD Conf., Chicago, Illinois, 1988, pp. 46-55.

[12] W. Kim, J. Banerjee et al., Composite object sup- port in an object-oriented database system, Proc. ACM OOPSLA Conf., Orlando, Florida 1986, pp. 118-125.

[13] H. Korth and A. Silberschatz, Database System Concepts, McGraw-Hill, New York (1986).

[14] F. Manola and U. Dayal, PDM: An object-oriented data model, Proc. 1st Intern. Workshop on Object- Oriented Databases, Pacific Grove, Cal., 1986 , pp. 18-25.

[15] F. Maryanski, J. Bedell et al., The data model compiler: A tool for generating object-oriented database systems, Proc. 1st Intern. Workshop on Object-Oriented Databases, Pacific Grove, Cal., 1986, pp. 73-84.

[16] J. Mylopoulos, P. Bernstein, and H.K.T. Wong, A language facility for designing database-intensive applications, ACM Trans. on Database Syst. 5 (2) (1980) pp. 185-207.

[17] G.M. Nijsen, A gross architecture for the next gen- eration database management systems, in: G.M. Nijsen (Ed.), Modelling in Data Base Management Systems, North-Holland, Amsterdam, 1976.

[18] J. Rumbangh, Relations as Semantic Constructs in an Object-Oriented Language, Proc. ACM OOP- SLA Conf., Orlando, Florida, 1986, pp. 466-481.

[19] P. Schwarz, W. Chang et al., Extensibility in the Starbust Database System, Proc. 1st Intern. Work- shop on Object-Oriented Databases, Pacific Grove, Cal., 1986, pp. 85-92.

[20] D. Tsichritzis and F. Lochovsky, Data Models, Prentice Hall, Englewood Cliffs, New Jersey (1982).

[21] G. Wiederhold, Views, Objects, and Databases, distr, during 1st Intern. Workshop on Object- Oriented Databases, Pacific Grove, Cal., 1986.

[22] C. Zaroliagis, P. Soupos, S. Goutas, D. Christodou- lakis, The GRASPIN DB - A Syntax Directed Lan- guage Independent Software Engineering Environ- ment, Position Statement, Proc. 1st Intern. Work- shop on Object-Oriented Databases, Pacific Grove, Cal., 1986, pp. 235.