Visual query language for object-oriented databases: OQD

Microprocessing and Microprogramming 38 (1993) 369-376 369 North-Holland

Visual Query Language for Object-Oriented Databases: OQD

Jae Cheol Kwak and Songchun Moon

Computer Engineering Division Department of Information and Communications Engineering, KAIST 207-43 Cheongryang, Dongdaemun, Seoul 130-012, Korea

Abstract. We propose a visual query language object query diagram (OQD) for object-oriented databases (OODBs). Unlike other approaches for OODBs, in which a class is used as a primitive entity for query specification, in OQD we specialize a class as a number of object sets, each of which is a domain of an attribute in the class. An object set is the primitive entity of designation in a query. OQD helps make queries simple by specifying a query without a complex path expression and give a better support for query optimization by removing the repetitive use of path expression and grouping the conditions which apply to a single class. Moreover, the basic structure of OQD derived from a schema graph can be easily extended to express a complex query because the entities of designation in a class, i.e. object sets, are isolated from each other.

Keywords: visual query language, object-oriented database, object query diagram, object set, query graph.

I. Introduction

During the past decade, advanced database applications such as computer-aided software engineering (CASE), computer-aided design (CAD), computer-aided manufacturing (CAM), and multimedia databases that require powerful modelling ability for complex data which are not easy to be supported by relational database systems have been emerged. Object-oriented database (OODB) systems will, most probably, be the next generation of commercial database systems in response to the requirement of complex data modelling. They are currently the focus of great deal of experiments and researches I Hur93].

One of the most important factors that determine the success of a database system is the performance from the viewpoint of end-users. Although declarative textual query languages like SQL and QUEL achieve major improvement over procedural programming languages like COBOL, they still enforce users to formulate complex specifications to describe data that they wish to access. Moreover, OODB systems are based on object-oriented data model, which is considered to be more complex than relational one. Given the underlying richness of object-oriented data model, query languages for them tend to be even more complex than relational SQL. In addition to these, the community of potential users of database systems has grown well

beyond the traditional administrative business professionals, and now includes people that are even less familiar with the standard ways to formulate their requests. So there is a strong demand for more intuitive and easy-to-use database user interface. Visual queries with the important concepts of the explicit presentation and direct manipulation provide users clear and powerful means of interaction. Moreover, considering the recently attracted multimedia workstations equipped with bit- map display units and mouses, visual queries are promising user interface for a database with great importance.

In formulating visual queries, a schema graph of a database plays an important role. A schema graph is a user-friendly diagram to represent the schema of a database. A schema graph offers users to grasp the logical structure of a database visually, which includes entities, their attributes, and associations between entities in a database. Some visual queries can be formulated by restructuring the schema graph [Aud91, Lar86]. A query graph which can be used as a model for query language [Kim89] or as a language to specify queries visually [Wha92] utilizes the schema graph to full extent. Even novice users are able to derive a query graph from the schema graph easily. In addition, a query graph gives a better support for query optimization by grouping intra-entity conditions which apply to a

370 J.C. Kwak, S. Moon

single entity around that entity, which ensures that, once the entity is retrieved, the conditions on the retrieved entity applied immediately to that entity. In spite of the benefits of query formulation based on schema graph, the direct employment of schema graph for OODBs, as is the case for relational databases, is not desirable due to the deficiency in describing an entity of designation.

In visual queries based on schema graphs for OODBs, a primitive entity of designation may not be described in the specification of a query. Unlike relational databases, in which an entity of designation is always a set of all tuple instances of the cos'responding relation, in OODBs not only a class as a set of object instances but also a portion of the class can be an operand in a query. For example, consider movies playing on theaters. All movies cannot be opened at theaters. Some movies could be made just for home-videos or for practicing. That is, only a portion of class MOVIE is associated with class THEATER. But in visual queries based on schema graphs like query graph, since only a class is used as a basic entity for query specification, the repetitive use of complex path expression to designate a part of a class is necessary, which increases complexity of a query and gives a poor support for query optimization. Moreover, use of a class as a compound of several entities of designation prevents the basic structures of visual query languages from being extended to express complex queries since the change on a part of a class could influence on the other part of the class.

In this paper, to remove the drawbacks of query formulation based on schema graph in OODBs and to support the features of object-oriented data model like object identity, we propose a visual query language object query diagram (OQD) which is an extension of an AND/OR graph version of a query graph. In OQD, a primitive entity of designation in an object-oriented query, i.e. a part of a class, is also described explicitly in the specification of a query. The philosophy underlying OQD aims to allow users, first, to derive a query graph of interest from a schema graph, second, to present parts of classes explicitly to which conditions in a query apply, and finally, to associate the conditions with them.

The remainder of this paper is organized as

follows. Section 2 introduces two major approaches for visual queries and their problems. In section 3, we explain the basic idea of our approach to overcome the problems of the query graph for OODBs. Section 4 describes the OQD syntax and semantics with the illustrative examples. Finally, conclusions appear in section 5.

II. RELATED WORK

A number of approaches for visual queries have been proposed [Aud91, Dat81, Lar86, Kim89, Kun89, Wha92]. They are divided into two major categories: the query interfaces by examples and visual queries based on schema graphs.

2.1 The Query Interfaces By Examples The query interfaces by examples have the

characteristics that users can manipulate the database by inputting the database query examples in a full-screen mode. The representative work is Query-By-Example (QBE) for relational database [DatS1]. QBE provides easy-to-use interface by filling example values into templates of relations. But QBE cannot present the global view of the logical structure of a database, which brings serious burden to novice users as follows.

1. Users may have to browse relations of a database one by one to select the relations which include attributes appeared in a query.

2. The selected relations should be joined properly. Users may supplement the relations to join those selected relations.

Visual queries based on schema graphs [Lar86, Wha92] would solve this problem since a schema graph visualizes the logical structure of a database including the names of all relations, their attributes, and the connections between the relations. Example 1 shows the drawbacks of QBE and effectiveness of query graph, one of the classical approaches of visual queries based on schema graphs.

Example 1. Suppose there is a relational database which includes at least 3 relations - relation EMPLOYEE (eno, ename, salary), relation OFFICE_USE (eno, room, floor), relation OFFICE (room, floor, capacity). Then, consider the query "Print the names of employees who make less than $40,000 and capacity of whose room is more than 10." in QBE in Figure 2.1.

OQD 371

EMPLOYEE eno ename salary

10 P. <40000

OFFICE_USE eno room floor

10 2.__00 3___00

OFFICE room floor capacity

2_9.0 30 > 1 0

Figure 2.1 The Query of Example 1 in QBE

Users can obtain the information about the relations and their attributes of a database by entering "P." and "<relation name> P." in NAME field of the empty table, respectively. For example, users can get the attributes of relation EMPLOYEE by entering "EMI~LOYEE P." in NAME field of the table. Through this time-consuming and tedious work reviewing some or all relations one by one, users may choose 2 relations - EMPLOYEE and OFFICE - which include the attributes appeared in the query - ename, salary, and capacity.

Another problem in choice of relations is that relations should be joined properly. The same attributes could be appeared in different relations like attribute capacity of relation OFFICE which could be those of another relations like HOTEL, THEATER, etc. In occasion, joins may be accomplished indirectly like join of relation EMPLOYEE and relation O F F I C E through relation OFFICE USE.

Query graph based on entity-relationship diagram would overcome the drawbacks of QBE. The query in Figure 2.1 is represented in query graph in Figure 2.2.

EMPLOYEE OFFICE_USE OFFICE

project ename capacity>l 0 salary < 40000

Figure 2.2 The Query of Example 1 in Query Graph

From the schema graph, in which the relationships between relations are represented explicitly, users can easily derive the query graph including two entities, EMPLOYEE and OFFICE to which attributes appeared in the query belong and the relationship, OFFICE USF on the paths connecting them. END

2.2 Visual Queries Based on Schema Graphs Visual queries based on schema graphs utilizes a

schema graph well. Especially, a query graph (QG) [Wha92] makes the best of a schema graph. Queries in QG consist in portions of the underlying schemas, which are qualifying using restrictions. But use of

QG for OODBs [Kim89] is not desirable because the direct adoption of QG for OODBs brings some

serious drawbacks. Example 2 shows the drawbacks inherent in QG for OODBs as follows.

1. Lack of the expressiveness of a query.

2. Increase of the complexity of a query graph.

3. Poor support for query optimization.

Example 2. The following classes show a portion of the OODB schema for the query, "Print the titles of movies, and the names of theaters in which two movies of the same director aged 40 or less, made by company, whose running times are less than 2 hours and more than 3 hours respectively, have been played." in QG in Figure 2.3. - class THEATER [ name: string, play: MOVIE ] - class MOVIE [ title: string, directed_by: DIRECTOR,

runtime: integer ] - class COMPANY [ make: MOVIE ] - class DIRECTOR [ age: integer].

COMPANY MOVIE1 DIRECTOR1 makel ~ , ~ directed_by ~L f - ' ~

itle theater.playl. lay 1. directed_by. me<2 age<40

E2 DIRECTOR2 directed by ~_ ~ ' - ~

v ~ j project name project title theater.play2.

theater.play2, directedby. runtime>3 age<40

theater.playl = company.makel theater.play2 = company.make2

theater.playl .directed by= theater.play2.directed_by

Figure 2.3 The Query of Example 2 in QG

Without allowing duplication of classes and attributes, QG is not able to express this query since it cannot distinguish two different sets of instances with the same path. Consider two exclusive conditions runtime<2 and runtime>3 with the same path theater.play.runtime. To specify these conditions, it is necessary to duplicate


attribute play of class THEATER and its domain class MOVIE, which increases the complexity of a query. Moreover, as the case may be, the duplication of a class accompanies with unnecessary duplication of another attribute like attributes make l and m a k e 2 of class COMPANY. Furthermore, it also brings duplication of conditions on classes like age<40 of class DIRECTOR1 and class DIRECTOR2.

Even if the duplication is allowed, the query in Figure 2.3 is semantically wrong since it requires the different interpretation of attributes. A pair of attributes playl and play2 of class THEATER is AND-grouped which means that class THEATER should be associated with both of their domain classes, MOVIE1 and MOVIE2. On the contrary, another pair of attributes makel and make2 of class COMPANY is OR-grouped which implies that class COMPANY should be associated with at least one of their domain classes, MOVIE1 and MOVIE2. QG only supports the former interpretation.

In the case that duplication is not employed, QG for OODBs is even more complex than that for relational databases due to use of complex path expression. Even for conditions which apply to a single class, complex path expressions are often required. Consider two conditions for class MOVIE1, runtime<2 and theater.playl. runtime<2. While the former constrains all instances of class MOVIE1, the latter constrains only the object instances associated with class THEATER.

The repetitive specification of path expression is even worse for query optimization. For example, to enable the optimization of the attributes theater .playl , theater. playl.dlrected_by, and theater.playl.runtime with the same path theater.playl simultaneously, query rewriting transformation in the form of tree-structure is needed. This repetitive path expression and the duplication of classes and conditions give serious burden to optimization process. END

I I I . Drawbacks Exposed in QG fiw OODBs

For OODBs, an entity of designation in a query is a set of object instances. So the concept of class as a set of object instances provides the basis on which a query may be formulated laud91, Kim89]. Actually, however, a class cannot stand for all entities which designate operands in a query. In occasion, a class is considered as compound of a number of sets of object instances, each of which may be a domain of an attribute of another class and to which a condition in a query may apply; we call this object set. Figure 3.1 shows two object sets

O m l and Om2 in class MOVIE. Object set O m l is a domain of attribute m a k e of class COMPANY and the other object set Om2 is a domain of attribute p lay of class T H E A T E R . Object sets Om I and Ore2 may have common instances. Since class C O M P A N Y and class T H E A T E R are the roots of the attribute-domain hierarchy, each of them is considered as single object set Oc l and Ot l , respectively. Those object sets are the primitive entities of designation in a object-oriented query. So use of a class as a primitive entity for query formulation causes several problems. The argument for this is three-fold. Let us in detail.

COMPANY

°vIE 1 Otl I

Figure 3.1 Object Sets in a Class

First, since an object set is defined as a part of a class, it is inevitable to use a complex path expression to designate an object set, which makes a query complicated. Consider class M O V I E 1 in Figure 2.3, which includes two object sets. One is a domain of attribute p layl of class THEATER and the other is a domain of attribute m a k e 1 of class C O M P A N Y . To designate the former object set, path expression theater, play1 should be affixed as condition theater .playl . runt ime<2. To remove the need of path expression, we present object sets explicitly in a query. As a result, two object sets for two attributes p l a y l and m a k e l are described explicitly and condition runt ime<2 can be specified by associating it with the object set for attribute playl without a complex path expression.

Second, since an association between two classes may. consist of a number of associations between

OQD 373

object sets, repetitive path expression is required to specify an association between object sets. It gives a poor support for query optimization. Consider association between class DIRECTOR1 and class MOVIE1 which includes two object sets - one is a domain of attribute playl and the other is a domain of attribute m a k e l . To designate an object set in class DIRECTOR1 associated with one of object sets in class M O V I E 1 , path expression for the object set in M O V I E 1 is repetitively used as condition theater.playl.directed_by.age<40. By specializing an association between classes as associations between object sets and presenting them explicitly, we can designate the object set in class DIRECTOR1 associated with one of object sets in class MOVIEI without repetitive path expression.

Third, the concept of a class as a compound of domain object sets of multiple attributes keeps a query graph from being extended to express a complex query because change of an object set in a class may have an effect on the other object sets in the same class. Consider the duplication of attribute p l a y of class THEATER and domain class MOVIE in Figure 2.3. It brings the duplication of attribute make of class COMPANY, whose domain class is also class MOVIE. That is, the duplication of domain object set in class MOVIE for attribute p lay causes the duplication of another domain object set in class M O V I E for attribute m a k e , which requires unnecessary change, i.e., the duplication of attribute make. Moreover, those two duplicated attribute pairs even have the different meanings from each other. While a pair of duplicated attributes p lay l and play2 of class THEATER is AND-grouped, the other pair of duplicated attribute m a k e l and m a k e 2 of class C O M P A N Y is OR-grouped. This can be worked out by isolating an object set in a class, that is, by presenting explicitly an object set which is a domain of a single attribute. Then, the duplication of an object set due to the duplication of attribute play makes no influence to attribute make whose domain is a different object set.

The heart of OQD in overcoming the drawbacks of QG is the explicit presentation of the object sets and the associations between them in the extended

query graph. Classes and associations between classes are specialized as a number of object sets and associations between object sets, respectively. Explicit description of object sets in the specification of a query makes users formulate a query without a complex path expression and its repetitive use, which greatly reduces the complexity of a query and gives a better support for query optimization. In addition, an object set is defined as a domain of a single attribute, which keeps the duplication of an attribute from influencing other attributes. It makes OQD simple and expressive. Example 3 explains the basic idea of OQD by showing how to work out the drawbacks of QG shown in Example 2.

Example 3. The same query in Example 2 is represented in OQD in Figure 3.2.

Query Window

project title "~ runtime(Oml) < 2 J runtime(Om2) > 3 / /

I COMPANY [ MOVIE

make ] ~ . . ~

¼;oo a_uy

I I ( project name ) ( age<40 )

Figure 3.2 The Query of Example 3 in OQD

Attribute play of class THEATER is specialized as two duplicated attributes, playl and play2. Class MOVIE is specialized as three object sets: object sets Oral and Om2 which are the domains of duplicated attributes, playl and play2 of class THEATER, and object set Om3 which is that of attribute make of class COMPANY. So users are able to formulate the query without the


duplication of the classes, which brings unnecessary duplication of attributes and conditions as shown in Figure 2.3.

Since each object set in OQD is defined as a domain of a single attribute of an object set, explicit presentation of associations between the object sets replace a complex path expression and its repetitive use in a query. For example, condition runtime(Oml)<2 implies that theater.playl.runtime<2 because object set Om I is a domain of attribute playl of class THEATER. END

IV. Object Query Diagram

We first define a schema graph for OODBs and present a sample schema graph used as the basis for OQD. The basic structure of OQD is derived from the schema graph as the query graph is.

PERSON]

~ ~ C T O R

COMPANYname ~ ~ / / ~ t e d _ b y

f MOVIE title

THEATER runtime

name class/subclass link

• .,. attribute/domain link

Figure 4.1 Example Schema Graph

A schema of a OODB is represented by a schema graph. A schema graph is a directed graph consisting of classes N and a set of edges E between pairs of classes. E has two types of edges. One is between a pair of classes CI and C2, such that C2 is the domain of one of attributes of C1. Another is between a pair of classes C and S, such that S is an immediate subclass of C. The direction of an edge is from a class to the domain of its attribute, anti from a class to its superclass. Figure 4.1 shows the sample OODB schema served as a basis for the example queries of the paper.

OQD is an extension of an AND/OR graph version of a query graph. OQD consists of class C, Object set O, and associations between object sets E. A class is represented by a class box. An object set is represented by an object circle in the class box standing for the class to which the object set belongs. An association between object sets is represented by an edge between object sets. For example, the query in Figure 3.2 includes four class boxes, T H E A T E R , COMPANY, MOVIE, and DIRECTOR. Class T H E A T E R and class C O M P A N Y are the roots of attribute-domain hierarchy, so instances of them are considered as single object set, O t l and Ocl , respectively. Class MOVIE consists of three object sets. One is domain object set Ore3 of attribute m a k e of class COMPANY. The other object sets O m l and Ore2 are domains of duplicated attributes p lay l and p lay2 of class T H E A T E R . Class DIRECTOR includes two object sets O d l and Od2 which are domains of attribute d i rec ted_by of duplicated object sets O r a l and O m 2 in class MOVIE. Attributes of an object set are grouped by an AND or an OR operator, which helps users formulate complex queries in a simple way. In addition, each class in OQD can have logical conditions and projection information associated with it. They are specified in a special area called condition box. Object sets in a single class have no relationships unless a certain condition to relate those object sets is given.

A. Condition Specification For object-oriented query languages, two

different types of equality based on two notions of object equivalence in object-oriented data model are defined as follows [Kho90].

1. Identity equality of objects: Two objects are identity equal if they are the same object, i.e., they have the same object identifier (OID).

2. Value equality of objects: a. Two primitive objects are value equal if they

have the same value. b. Two non-primitive objects are value equal if

they have the same set of attributes and their attributes are value equal.

Therefore, in OQD two types of condition

OQD 375

specification schemes are defined - one for a condition based on value equality and the other for a condition based on identity equality. A condition based on value equality is specified in a condition box associated with a class including object sets to which the condition applies.

A condition based on identity equality is used to test the equality of referenced objects. So operands of a condition can be designated by object sets in a single class to which referenced object sets belong. A condition can be specified by the relationships between object sets in a class. We represent the relationships between object sets in a class by using the well-known Venn diagram which is simple and easy-to-use tool to represent set operations visually. Venn diagram consists of a rectangle and a number of circles in the rectangle. These circles may be overlapped. A rectangle represents a universe of set operations, i.e., a set of all elements, and a circle represents a set to which set operations apply. Then we can specify set operations by designating one or more areas distinguished by circles.

CLASS CLASS

(a) Ocl = Oc2 (b) Ocl ~ Oc2 Figure 4.2 Conditions Based on Identity Equality

In OQD, a class is considered as an independent universe and object sets in the class stand for operands of conditions. We define two operators: = and ¢. Figure 4.2 shows two conditions based on identity equality between object sets Ocl and Oc2 specified by Venn diagram. The overlapped area of the object circles for two object sets, Ocl and Oc2 in Figure 4.2(a) implies that object instances which belong to both of object sets are selected. Fig,,: 4.2(b) implies that we select object instances which belong not to object set Oc2 but to object set Ocl. For example, consider condition theater.playl. directed_by = theater .play2.directed_by in the query in Figure 3.2. Class D I R E C T O R includes two object sets Odl and Od2. Objects referenced by operand thea ter .p layl .d i rec ted_by belong to

object set Od 1 and objects referenced by the other operand thea te r , p lay2 .d i rec ted_by belong to object set Od2. Then, the condition is specified by the overlapped area of the object circles for two object set Odl and Od2 in class DIRECTOR.

B. Joins between Classes Join is used to correlate two or more classes. Join

between classes is divided into two categories: an implicit join which is defined between an attribute of a class and the domain of the attribute in the schema graph and an explicit join, similar to the relational join, where two objects explicitly compared by using either the value or identity equality. Since implicit join is restricted to the attribute-domain relationship specified in schema, it can be specified by associations between object sets. That is, it is essentially the materialization of the values of the attribute. For example, in Figure 3.2, object set O m l in class MOVIE is associated with object set Otl in class THEATER as the domain of attribute p l a y l . So class THEATER and class MOVIE are implicitly joined.

Explicit join based on value equality is specified in a global condition box same to relational join. Explicit join based on identity equality can be specified by the relationship between object sets in a domain class common to attributes of classes to be joined. For example, in Figure 3.2, object set Ore3 that is the domain of attribute m a k e of class COMPANY alid object set O m l that is the domain of attribute playl of class THEATER is explicitly compared in common domain class MOVIE . So class C O M P A N Y and class T H E A T E R are explicitly joined.

C. Extension to Class Hierarchy The concept of object set as a primitive entity of

designauon in attribute-domain hierarchy is simply extended to class-subclass hierarchy. That is, similar to the case in attribute-domain hierarchy, in class- subclass hierarchy a class may consist of a number of object sets, each of which is a parent set of one of its subclasses. Example 4 shows the query which needs joins between a class and its subclasses.

Example 4. Consider query, "Print the titles of movies whose directors 'also act on the movies." in Figure 4.3.


Query Window

MOVIE

p . | roject title

Figure 4.3 The Query of Example 4 in OQD

Class PERSON consists of two object sets Opl and Op2. These object sets are associated with object set Odl in class DIRECTOR and object set Oal in class ACTOR, respectively. By selecting the overlapped area of two object sets Opl and Op2, condition movie.acted_by = movie.directed_by is specified. END

V. Conclusions

In this paper, we have proposed a visual query language OQD as an easy and expressive front-end of OODB systems. OQD facilitates to formulate queries by employing a query graph for OODBs, which in basis utilizes the schema graph of a database. OQD allows to support some features of object-oriented data models. First, the navigation through the object structures can be simply specified by associations between object sets in classes. Second, simple and easy-to-use specification scheme based on well-known Venn diagram is provided for conditions based on identity equality.

The further work planned is to develop a query editor for OQD. The query editor for OQD will offer users direct and visual manipulation facilities for specification of queries. The features of our query editor for OQD are as follows.

1. Provide multiple windows in order for users to get always information needed to formulate a query, for instance, a window for a schema graph

2. Let users perform intuitive physical actions like selecting and dragging objects to modify the visual representation of queries, or activate dedicated functions through menus, labelled buttons, dialog boxes to manipulate objects like object circles and class boxes in OQD.

REFERENCES

[Ala89] A. M. Alashqur, S. Y. W. Su, and H. Lain, "OQL: A Query Language for Manipulating Object-Oriented Databases," Proc. 15th Int'l Conf. Very Large Data Bases, 1989, pp. 433-442.

[Aud91] A. Auddino, E. Amiel, and B. Bhargava, "Experiences with SUPER, a Database Visual Environment," Proc. Int'l Conf. Database and Expert Systems Applications, 1991, pp. 172-178.

[Dat81] C. J. Date, An Introduction to Database Systems, 3rd Eds., Addison-Wesley Publishing Co., 1981.

[Hur93] A. R. Hurson, S. H. Pakzad, and J. Cheng, "Object-Oriented Database Management Systems: Evolution and Performance Issues," IEEE Computer Mag~ine, Vol. 26, No. 2, 1993, pp. 48-60.

[Kho90] S. Khoshafian and G. Copeland, "Object Identity," in Readings in Object-Oriented Database Systems (eds.) S. B. Zdonik and D. Maier, 1990, pp. 37-46.

[Kim89] W. Kim, "A Model of Queries for Object- Oriented Databases," Proc. 15th Int'l Conf. Very Large Data Bases, 1989, pp. 423-432.

[Kun89] M. Kuntz and R. Melchert, "Pasta-3's Graphical Query Language: Direct Manipulation, Cooperative Queries, Full Expressive Power," Proc. 15th Int'l Conf. Very Large Data Bases, 1989, pp. 97-105.

[Lar86] J. A. Larson, "A Visual Approach to Browsing in a Database Environment," IEEE Computer Magazine, Vol. 19, No. 6, June 1986, pp. 62-71.

[Wha92] K.Y. Whang, A. Malhotra, G. Sockut, L. Burns, and K. S. Choi, "Two-Dimensional Specification of Universal Quantification in a Graphical Database Query Language," IEEE Trans. Software Engineering, Vol. 18, No. 3, March 1992, pp. 216-224.

Documents

Visual query language for object-oriented databases: OQD