A Comparison Analysis of Graphical Models of Object-Oriented Databases and the GOQL Model

Transcription

1 A Coparison Analysis of Graphical Models of Object-Oriented Databases and the GOQL Model EUCLID KERAMOPOULOS School of Coputer Science Westinster University 5 New Cavendish Street, London WM 8JS, UK PHILIPPOS POUYIOUTAS School of Coputing Intercollege 46 Makedonitissas Ave., Nicosia 700, CYPRUS TASOS PTOHOS School of Coputer Science Westinster University 5 New Cavendish Street, London WM 8JS, UK Abstract: - In this paper we present a coparison analysis of the ost iportant graphical odels of objectoriented databases. These odels are also copared with the graphical odel (User s View UV) of GOQL - our graphical query langu for object-oriented databases. The coparison is based on an exaple of an object-oriented database schea whose graphical representation is given in the ost iportant graphical odels that exist in the literature including GOQL. The coparison illustrates the liitations of these odels as copared with the UV of GOQL. The paper presents the basic characteristics/concepts of an object-oriented database schea. Each graphical representation of the running exaple illustrates how each graphical odel supports these characteristics in ters of graphical constructs. These graphical constructs of each graphical odel are therefore evaluated within the context of the running exaple. Having evaluated these odels, the paper continues and illustrates the graphical constructs of GOQL. The design of these constructs has been based on the concept of desktop etaphors. The paper presents an overview of this concept and explains the way they have been utilized in the design of the graphical constructs of the UV of GOQL. The ephasis on the design was to provide a graphical odel that does not contain any of the perplexing details of an object-oriented database schea and therefore provide end-users with a user-friendly query environent for ad-hoc queries. The UV of the langu GOQL was first presented in []. The query echanis of GOQL was presented in [2], whereas a ore coprehensive part of the langu is to appear in [3]. The work in [, 2, 3] includes a survey of the various graphical odels, an evaluation ethodology of the features supported by these odels and the design of the UV and query constructs of GOQL. The purpose of this paper is to substantiate our decision for proceeding with the ipleentation of GOQL. The coparison presented illustrates the advants of the UV of GOQL over the rest of the graphical odels. The UV of GOQL therefore provides the basis for building the query echanis of a graphical query langu for object-oriented databases. The conclusions of course, presented herein, are based on our own views and perspective. Our near future work involves the evaluation of the graphical odels presented in this paper, by a group of users of object-oriented databases so as to get a ore independent set of conclusions. Key-Words: Graphical Query Langus, Object-Oriented Databases, Desktop Metaphors. Introduction A graphical representation of an object is used to provide a visual and better picture of the object, ephasizing on its ost iportant/interesting characteristics. Graphical representations are being used in our every day life as well as in any scientific and research applications. In this paper, we exaine one such application of graphical representations, naely the graphical database scheas. A graphical database schea is a graphical representation of a database schea. It can be derived either for an external database schea (addressed for naive users and being free of soe perplexing technical details), or for a conceptual schea (addressed for database designers and developers). More particularly, this paper concentrates on graphical database odels for object-oriented databases and shows the design of the GOQL graphical odel, which utilizes the concept of etaphors. The use of etaphors is one of the ost successful types of teaching and is often used for children learning. Most of the ties, in our attept to explain soething, we use exaples fro other subjects that we (or our audience) know better and feel ore cofortable with, thus introducing etaphors. The ost faous application of etaphors in software applications is the turtle in LOGO [4]. The illustration of painting by the oveent of the turtle tail in the dust was very successful and helped especially the children to use LOGO ore effectively. In a siilar way, etaphors can be used for database applications to ake the friendlier to naive users. An office is probably the ost suitable

2 area to look for the best etaphor for database applications. Database applications substitute the office records that are kept in folders and docuents. Thus, it sees logical for an office eployee to work ore effectively using a database application whose environent consists of pictures fro his/her working environent. However, the use of etaphors needs careful consideration. An inappropriate etaphor can confuse users. For exaple, the ejecting of a disk has been illustrated in soe coputer systes by throwing a disk icon into a wastebasket. This etaphor is totally wrong and confuses users, since norally we throw garb into the wastebasket and not a useful disk. 2. Different graphical odels In this section, eight different odels for representing graphically a database schea are critically represented. A picture of the graphical schea is given for the exaple database (given in Appendix) for every odel presented. Our evaluation exaines nine basic characteristics that a graphical schea should represent, which are:. classes or entities (depending on the database odel) 2. attributes (properties) of classes/entities 3. ethods (properties) of classes 4. relationships between classes/entities 5. class/entities hierarchies 6. recursion (type of property (attribute/ethod) of a class/entity type is the sae class/entity) 7. coplex properties (type of a property is a coposite property of ore than one other properties) 8. collection properties (type of a property is of set or bag or list or array type) 9. etaphors (pictures/icons are used to represent the schea characteristics in a ore natural way, hiding their technicality without losing their eaning). Two are the basic categories of the graphical schea odels, the condensed and the detailed odels. A condensed odel represents only classes/entities, relationships and hierarchies. A detailed odel represents all the eleents of the database external schea. The detailed odel is better than the condensed because it presents a ore coplete picture of the database schea. 2. THE O.D.M.G. 2.0 MODEL The graphical representation of the schea in the O.D.M.G. 2.0 odel [5] is given in Fig.. Only the classes and the relationships between the are represented. Attributes, ethods, coplex properties and collection types are not shown. Directed arrows are used for the representation of the relationships between the classes. A thick directed arrow represents class hierarchy which starts fro the child and finish to the father. Recursion is shown as a relationship that has as source and target the sae class (e.g..is_referenced). Finally, there is no attept for using etaphors to represent the parts of the graphical schea. We believe that the O.D.M.G. 2.0 attept to represent graphically the schea is targeted to expert users and not to naïve users. s s s s s s Fig. : The O.D.M.G. 2.0 Graphical Representation 2.2 THE COAD/YOURDON MODEL The graphical schea of the COAD/YOURDON odel [6] represents the class as a rounded box which has as a heading the nae of the class, as iddle part the naes of the attributes without their types and in the botto part the class ethods. The relationships between classes are given as undirected lines of which on the two edges are written a), b) or c), depending on the type of the relationship. The hierarchy of the schea is given by lines between the classes using the sybol ( ). A coplex attribute (such as place or Con_date in ) is given by another box (linked to the coplex attribute of the class), which has as heading the nae of the coplex attribute. Collection attributes are not represented and etaphors are not used. We believe again that this odel does not fully satisfy end-users. Volue Nuber Con_ Start_date End_date Con_ City Country Key words _of_birth Fig. 2: The COAD/YOURDON Graphical Representation

3 2.3 The Extended Entity Relationship odel The graphical representation of the Extended Entity Relationship (EER) odel [7] is very detailed (Fig. 3). It has two representations for classes; a rectangle with the nae of the class and a doubleline rectangle for a class appearing again in the diagra. Attributes are represented by ovals and are linked to the class they belong. There is no representation for ethods. A relationship is represented by a line with a naed rhobus - the type of the relationship is written on the edges of the line. A special sybol (a double line ending in a D in circle) is used in the hierarchy representation (e.g., and ). A relationship of an entity to itself represents recursion. Coplex attributes are linked to the attributes (given by ovals) they consist of. Collection types are not represented and etaphors are not used. difficult for both end-users and database experts to understand the underlying database schea since any database eleents are represented with the sae geoetrical shape. Coplex attributes are represented as classes. Finally, collection types are not represented and no etaphors are used. s s s s s s _of_birth Fig. 4: The AMAZE Graphical Representation d Con_ d Edited Writes ed s float s s Volue Nuber date _of_birth Con_ s Con_ Start_date End_date date date City Country Con_ Volue Nuber Start_date End_date City Country Fig. 3: The EER Graphical Representation s s 2.4 The AMAZE odel The AMAZE graphical odel [8] represents the classes as 3D boxes, the relationships as directed lines and recursion as relationships, which have as source and target the sae class (e.g..is_referenced). Class Hierarchy is represented by a thick arrow fro the child to the father. In the AMAZE graphical schea, there is no representation for attributes, ethods, coplex attributes and collection types. Also etaphors are not used thus. We believe that the 3D representation does not give any advant to the schea representation and that the lack of etaphors akes this odel usable only by expert database developers and not by end users. 2.5 The G-LOG Model The G-Log odel [9] is detailed but confusing. In this odel classes are represented by rectangles. Properties, class hierarchy, relationships and recursion are all represented with arrows, thus leading to confusion and not distinctive representation constructs. This akes it very Fig. 5: The G-Log Graphical Representation 2.6 The GOMI Model In the GOMI odel [0] the root OBJECT (Fig. 6) represents the top superclass of the schea hierarchy. That OBJECT is linked to the iediate subclasses by thick arrows (i.e. class hierarchy is represented by a thick arrow fro the superclass to the subclass). Tables are used to represent classes. Attributes are listed in the tables together with their types. Methods are not supported. Two different types of arrows represent relationships. A dotted arc represents the one to any relationship and a dashed arrow represents the any to any relationship. Finally, recursion is represented as a relationship fro a class attribute to the sae class itself (e.g..is_referenced). GOMI s odel gives a nice feel for the class hierarchy but uses too any lines and arcs that ake the schea confusing and soeties look like a aze. This odel again does not use

4 etaphors and ethods. We believe that it is very difficult for the naive user to understand this odel. set City Country Con_ Con_ Start_ End_ s float s s int int int Volue int Nuber OBJECT s Fig. 6: The GOMI Graphical Representation _of_birth s s s int int set 2.7 The KHOSHAFIAN odel Another graphical odel is the Khoshafian odel [] (Fig 7). In this odel, rectangles represent classes and arrows represent properties. A dashedoval gives the type of an attribute and a double-line oval the type of a ethod. Arrows represent relationships with the relationship nae labelling the arrow and thick-white arrows represent hierarchies that start fro the children and conclude to the parent classes. An arrow starting fro a class and returning back to the class represents recursion. Dashed-rectangles represent coplex attributes. A circle with star represents a set type whereas a circle with an L represents a collection type. Metaphors are not used. This odel provides a lot of useful inforation to the expert database person but a naive user will have probles to understand and work using such a graphical schea. Float Float Con_ Con_ Con_ s Country City Start_date End_date Volue s s L Nuber s s _of_birth L s Fig. 7: The Khoshafian Graphical Representation 3. THE GOQL MODEL The GOQL odel [,2,3] has utilized the concept of desktop etaphors in representing graphical constructs. With the end-users in ind, GOQL hides any perplexing details and presents to users database scheas that are easy to understand. The GOQL graphical representation of the schea of the running exaple of the paper is given in Fig. 8. A coparison table suarizing the supporting features of each of the odels presented herein is given in Fig. 9. _of_birth _of_birth s _of_birth s s s s s s s Volue Nuber s Proceeding s s s Con_ Web_P Fig. 8: The GOQL Graphical Representation GQLs Features ODMG 2 COAD/YOURDON EER AMAZE G-Log GOMI Khoshafian User s View class/entities attributes ethods relationships hierarchy recursion? copex properties collection properties etaphors Fig. 9: Coparison of the 8 Models In the GOQL odel, etaphors have been used to represent the database schea features. More specifically the database schea constructs have been represented as follows:. classes are represented by tables 2. attributes are represented by cells in tables 3. ethods are also represented by cells in tables (users do not distinguish between attributes and ethods; they know these as properties) 4. relationships are represented by folders/briefcases (the class related to an attribute is represented by a folder/briefcase and is linked with a line to the attribute). 5. class hierarchy is incorporated into the folders/briefcases; a folder/briefcase can be opened to reveal any subclasses

5 6. recursion is represented by a relationship fro a class to itself 7. a coplex property is shown by an envelope which is placed in the right edge inside the cell of the property; a user can open the envelope to reveal the properties that constitute the coplex property 8. a collection property (set, bag, list or array) is shown by a paper clip that is placed in the top right edge inside the property cell. The design of the graphical representation of GOQL that lead to the decision to incorporate a condensed graphical representation (Fig. 0), has taken into consideration the following ethods that deal with database scheas consisting of too any classes: Top-Down: With this ethod data are grouped into interesting levels. The ost well known ethod is the hierarchical where in the first level the ost general data are represented and in the other levels the ore detailed data are represented. For exaple, for the object-oriented odel, the classes and the class hierarchy are shown in the top level and the other details of the database (properties, relationships, etc.) in the next levels. Fig 0: The Condensed GOQL Graphical Representation Browsing: With this ethod a user can have as a starting point an eleent in the database schea and then travel to the next relative by a relationship. This ethod is ore successful when the user has knowledge of the database structure because the change fro a level of detail to another is developed slowly. In the condensed GOQL graphical representation, all the classes are represented by closed folders. The user can select one of the folders to open it in order to exaine all the features of the class. By this selection the schea is oving one level down (top down ethod) for the class under consideration. By browsing through relationships, the user can open a related folder. Using the relationship browsing a user can therefore develop the part of the schea that is needed for a query (Fig. ). 4. Conclusions In this paper we have illustrated through an objectoriented database schea the various graphical odels that support a graphical environent for databases, including our GOQL odel. Through this illustration, a coparison of these odels has been ade based on the various features of objectoriented databases. The paper has also presented the design of the GOQL odel based on the concept of desktop etaphors. The advants of the GOQL odel have also been addressed. We believe that the conclusions drawn fro this coparison reinforce our decision to proceed with the full design and ipleentation of the GOQL odel. Our near future work involves the evaluation of the graphical odels presented in this paper, by a group of users of object-oriented databases. This will give us a ore independent set of conclusions. _of_birth s _of_birth s s Fig. : Schea Developing in the GOQL Model

6 : [] Keraopoulos, E., Pouyioutas P. & Ptohos T. The User s View Level of the GOQL Graphical Query Langu. International Conference on Inforation Visualtion 99, London, July, 999, pp [2] Keraopoulos, E. Ptohos, T. & Pouyioutas P. GOQL - A Graphical Query Langu for Object-Oriented Databases. IASTED AI2000 International Conference (Applied Inforatics), Innsbruck, February 2000, pp [3] Keraopoulos, E., Pouyioutas P. & Ptohos T. The GOQL Graphical Query Langu. To appear, International of Coputers and Applications, Vol. 24, No. 3, [4] Slack J.. Turbo Pascal With Turtle Graphics. West ing Copany, 990. [5] Cattell R.G.G. & Barry D.K. (Eds.): The Object Database Standard: ODMG 2.0. Morgan Kaufann s, 997. APPENDIX The Running Database Exaple : alphanueric, : alphanueric, Pubs_ : alphanueric, : nueric, s_ : alphanueric, s_ : alphanueric, : nueric, : nueric, PRIMARY KEY (), FOREIGN KEY (Pubs_) REFERENCES, FOREIGN KEY (s_) REFERENCES, FOREIGN KEY (s_) REFERENCES. : alphanueric, : alphanueric, Pubs_ : alphanueric, : nueric, s_ : alphanueric, s_ : alphanueric, : nueric, : nueric, Volue : nueric, Nuber : nueric, PRIMARY KEY (), FOREIGN KEY (Pubs_) REFERENCES, FOREIGN KEY (s_) REFERENCES, FOREIGN KEY (s_) REFERENCES. : alphanueric, : alphanueric, Pubs_ : alphanueric, : nueric, s_ : alphanueric, s_ : alphanueric, : nueric, : nueric. Con_ : alphanueric : alphanueric, PRIMARY KEY () FOREIGN KEY (Pubs_) REFERENCES, FOREIGN KEY (s_) REFERENCES, FOREIGN KEY (s_) REFERENCES, FOREIGN KEY (Con_) REFERENCES Con_, FOREIGN KEY () REFERENCES. : alphanueric, : alphanueric, _of_birth : date, : alphanueric, : alphanueric. [6] Coad P. & Yourdon E. Object-Oriented Analysis. Prentice Hall, 2 nd Edition, 99 [7] Elarsi R. & Navathe S.B. Fundaentals of Database Systes. Addison-Wesley, 2 nd Edition, 994. [8] Boyle J., Leishan S. & Gray M.D. Fro WIMPS to 3D: The Developent of AMAZE. In Visual Langus and Coputing, No. 7, 996, pp [9] Paredaens J., Peelan P. & Tanca L. G-Log: a graph-based query langu. In IEEE Transactions on Knowledge and Data Engineering, Vol. 7, 995, pp [0] Jun Y.S. & Yoo S.I. GOMI: A Graphical User Interface for Object-Oriented Databases. In of International Conference on Object-Oriented Interface Systes (OOIS), 995, pp [] Khoshafian S. Object-Oriented Databases. John Wiley & Sons Inc, 995. : alphanueric, : alphanueric, : alphanueric, : alphanueric, : alphanueric, _ISDN : alphanueric PRIMARY KEY (), FOREIGN KEY (_ISDN) REFERENCES. : alphanueric, : alphanueric, _of_birth : date, : alphanueric, : alphanueric, Docs_ISDN : alphanueric, PRIMARY KEY (), FOREIGN KEY (Docs_ISDN) REFERENCES. : alphanueric, : alphanueric, _of_birth : date, : alphanueric, : alphanueric, s_title : alphanueric, PRIMARY KEY (), FOREIGN KEY (s_) REFERENCES. : alphanueric, s_ : alphanueric, Pub_ISDN : alphanueric : nueric, : nueric, : alphanueric, Ref_ : alphanueric, Is_ref_title : alphanueric. PRIMARY KEY (), FOREIGN KEY (s_) REFERENCES, FOREIGN KEY (Pub_ISDN) REFERENCES, FOREIGN KEY (Ref_) REFERENCES, FOREIGN KEY (Is_ref_title) REFERENCES. Con_ Start_date :, End_date :, PRIMARY KEY (Start_, End_date). City : alphanueric, Country : alphanueric, PRIMARY KEY (City).

7