Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Extensible Storage Engine wikipedia , lookup
Open Database Connectivity wikipedia , lookup
Microsoft Jet Database Engine wikipedia , lookup
Concurrency control wikipedia , lookup
Entity–attribute–value model wikipedia , lookup
Clusterpoint wikipedia , lookup
Versant Object Database wikipedia , lookup
OBJECT CATEGORY DATA MODEL: A NEW DATA MODEL FOR OBJECT-ORIENTED DATABASE MANAGEMENT SYSTEMS by Adane H.Zygta A thesis submtted to the Faculty of Graduate Studies and Research in partial fulfilment of the requirements for the degee of Master of Computer Science Ottawa-Carleton lnstitute for Computer Science School of Computer Science Carleton University Ottawa, Ontario 2000 8 Copyright 2000, Adane H.Zygta Bibliothbque nationale National Library of Canada du Canada Acquisitions and Bibliogaphic Services Acquisitions et services bibliographiques 395 Wellington Street OttawaON K1AON4 395, nie Wellington Ottawa ON KlAON4 Canada Canada The author has granted a nonexclusive Licence allowing the National Libraxy of Canada to reproduce, loan, distribute or seIl copies of t h s thesis in rnicroform, paper or electronic formats. L'auteur a accordé une licence non exclusive permettant à la Bibliothèque nationale du Canada de reproduire, prêter, distribuer ou vendre des copies de cette thèse sous la forme de rnicrofiche/film, de reproduction sur papier ou sur format électronique. The author retains ownership of the copyright in this thesis. Neither the thesis nor substantial extracts fiom it may be printed or otherwise reproduced without the author's permission. L'auteur conserve la propriété du droit d'auteur qui protège cette thèse. Ni la thèse ni des extraits substantiels de celle-ci ne doivent être imprimés ou autrement reproduits sans son autorisation. Abstract Object-oriented database management systems (OODBMS) attempt to i n t e p t e database and object-oriented (00)technologies. However. a single data model has not emeiged from this approach. Radier several research prototypes and commercial products have been developed using different rnodels. These models reflect the paniculars of their implementarion. the programmin; language used and the set of applications they are targeted for. The thesis defines and illustrates a data mûdel named Object Category (OC) rhat is based on the 00 concepts. The data model is independent of any programming langage. is suited to an' general application. and is easily derived from an EER diagam. OC data model introduces the concept of category. which is a collection of object instances. The use of collections by an OODBMS implies a clear and easy way of manipulating persistent objects that is consistent with the concept of database and resembles the operations of insert, reuieve and remove objects. hcknowledgements Fint of al1 I would like to thank rny wife, Salem Tewelde, for her suppon and understanding. This thesis would not have been finished othenuise. 1 would also like to thank my s u p e ~ i s o rProf. , Ekow Otoo. for his ideas and assistance duing the completion of ths thesis. Finally. 1would like to thank the National Sciences and Enpineenng Research Council for the partial fundin; of the thesis under the NCE: GEOIDE project, and the s t a f f of the School of Cornputer Science for their assistance dunng my graduate career. Contents vii List OF Abbreviations cm CAM CASE CSL DBMS ER E R Y0 OC ODBMS ODM ODMG Oid O0 OODBMS OQL RAMI SQL Un& Xbstract data type American Yational Standards Instinite/Standards Planning and Requirements Commitree Cornputer-aided design Cnmpliter-lided mmvfx ! ~ r i o g Cornputer aided software engineering Category specification language Database management system Entity-Relationship Extended-ER Input/Output Object category Object database management system Object-to-database mappings Object data management group Object identity Object-oriented Object-oriented database management system Object query language Remote method invocation Smictured query languuage Unified modelin5 language List of Figures Figure 2.1 Figure 3.1 Figure 3.2 Figure 3.3 Figure 3.4 Figure 3.5 Figure 1.1 Figure 5.1 Figure 6.1 The ttiree level ANSUSPARC architecture --------------------------26 Different categories defined over the rame class ---------------- 34 Example categones-----------------------------------------------36 Muluple inheritance --------------------------------------- ----------- 36 A relationship wih additional annbute ------------------------------43 OC database schema ----------- 37 Architecture of an OC data mode1 based DBMS -------------------65 LrML - Cla s Dia m -------------------- -------------------------- 77 EER & a p m for a University's database 80 C Chapter 1 1 Introduction Since the earl y dayz of the darahase technnlnpy, the quec!i~ncf ~ Q W rc hest r-posp.n! r e d world objects and their relaùonship has been the dnving force for new data models, hence new database technologies. The purpose of data models 1s to model the reai world as closeiy as possible. The data models on which the database management systems (DBMS) are based upon distinguish hem from each other. The data model used by a DBMS determines the data structures and operators that are available to the user. It also detemnes the features available for storage, retnevd and management of the data independentiy of any particular application. Almost ail database systems that are cornrnercidly available today are based on one of the following data models: hierarchical [11.22. 301, network [M.2230.331, relational [S. 14. 22. 30, 321 and object-oriented [5, 31.35]. Cntil the introduction of object-oriented (00)concepts, the relational approach attracred the vast majority of database research and it represented the dominant trend in the market place. In fact. the relational model is considered. by many. as the single most important developrnent in the history of the database field. However, the introduction of more powerful machines encouraged their use for new and complex applications that required Chapter l - Introduction -7 the services of a DBMS.The use of the relational model to satisfy the database requirernents of these new applications is testing the model's capability to its limits. Object-oriented database management systems (OODBiMS). which are the inregration of concepts from 00 paradi-gm and DBMS, have been proposed as the solution to satisfy the requirements of the "new" applications and hence to overcome the limitations of the relational model. The "new" applications include cornputer-aided design (CAD). compurer-aided manufactunng (CAM),computer-aided software engineering (CASE), geographc information system (GIS),and office automation. However, unlike the relational systems in which the data model preceded their implementation, OODBhlS lacks an official standard data model. The proposed standard [6] published by the Object Database Management Group (ODMG') attempts to fil1 the sap. The following statement in [6] explaîns the lack of a generally agreed standard model better: "With respect to the specificarion of the system, we are taking a Daminian approach. We hope that, out of the set of experimental prototypes k i n g built. a fit model will emerge. We also hope that viable implementation rechnology for that model will evolve simultaneously". Current implementations of OODBMS and data models proposed so far do not include collections as the logical view of the database. Funhemore. 00 programmin; laquages do not support the notion of class extent explicitly. Uniike relational systems, the lack of L ODMG is a consortium of OODBMS vendors. Chapter 1 - introduction 3 a simple collection based conceptuai view makes OODBMSs hard to learn and difficult to apply for many application areas. The thesis defines and illustrates a new data model for OODBMS named Object Category data model, which uses collections as an i n t e p l part of 00 databases. The data model is based on the concept of category [15]. A category is a typed collection of instance objects. The use of collections implies a clear and easy way of making objects persistent that is consistent with the concept of database and resembles the operations of insert. retrieve and remove objects. Unlike current data models. the OC data model makes a clear distinction between the concept of class as a data type and the concept of category as a collection of instance objects in the database. ..\database based on the OC data mode1 is seen as a set of interreiated categories. ï h e objects in the database are oqanized as members of the different categones. A category's definition includes the type of objects it is supposed to maintain, and the set of integnty consuaints its member objects must satisfy. including their relationship to other objects. The OC data model makes a clear distinction between class definitions and integnty constraints. Integnty constraints are properties of categones. and not classes. At least. four kinds of integrity constraints are supported: referential or relationship integnty, keys. NOT N L . constraints and triggen. Relationships are defined between categones. The data model supports binary relationship that may be one-to-one. one-to-man y, man y-toone and rnany-to-many. htegrity constraints are added andor removed from the categories dynarnically. This approach of separating constraints from class definitions Chapter 1 - Introduction 4 makes class design very flexible. It also prevents class definitions from being changed and recompiled due to every rninor change in the business rules, and makes maintenance of business rules much easier. A DBMS based on the OC model maintains the intepty of a database by subjecting the objecrs in the database to different inteb@ty checks depending on their category membenhip. The OC data mode1 also provides a category/subcate_ooryrelationship between categories. The relationship defines the set inclusion semantics for categones. By definirion. a category is a subset of its supercategory. Furthemore. ifs member objects are constrained by the inregrit? consuaints defined over irs supercategory. Csers interact with the DBbIS through the facilities provided by rhe Catejory interface. The interface includes dl the methods that are required for insertion, retrieval and deletion of a singie object as well as a collection of objects. Objects are made persistent and later removed from the database through the various insert and remove methods of the interface. A framework for a DBMS based on the OC data model takes into consideration several issues related to the traditional DBMS aspects like transaction and concurrency conuol, as well as issues related to the complex structure of the objecrs and their organization in the database. DBMSs are based on clienVsenrer mode1 architecture. The server side is Qvided into two big modules, storap manager and object manager, which at the same time is divided into several submodules. Each submodule is responsible for a portion of Chapter 1 - Introduction 5 the object manager's responsibiliry like transaction. concurrency control, caching, etc. Objects in a database are uniquely idenrified by their identity. Object identities could be pointers to physical addresses or logicai identifien that are independent of the objects' storage location. The object manager maps the objects from their intemal representation to their in-memory representation. Furthemore. programming languages provide collection constnicts that are equivalent to categones proposed for the OC data model. Therefore. a seamless intepration of the progamming environrnenr and the DBMS would be one that "ties" the user specified memory resident containers with corresponding persistent containers on secondary storage that are defined as categories. Such mechanism would allow the user to access categones in the database as if they were m extension of the memory resident containers. To allow such functionality a number of issues. including buffenng and transactional access, need to be addressed. Although a user accesses the data as if he/she has an exclusive control of it. objects in the persistent categories are subject to concurrent access by multiple usen. As such a concumncy conuol mechanism thar takes into consideration the complex stmcture of objects and the database's organization as a set of categones ne& to be incorporated. Cornplex objects include attributes that reference other objects. However, propagating a complex object's lock to al1 the objects it references significantly reduces the system's ability to run concurrent processes. Therefore. objects are locked only when the users access them. Chapter I - Introduction 6 1.1 Motivation This thesis g e w out of an interest in currenr database research. mainly OODBMS.and the well-known fact chat their implementaLions were not based on a well-formulated standard data model: ln particular. a data model that i ç defined hased nn the 00 concepts. that is independenr of any programming laquage. and is suited to any application and not just to some. It is our hope that the data model proposed herein would help the ongoing effort to define a standard and pave the way for a new generation of database systems that combine the benefirs of a DBMS in a uuly 00 environment. 1.2 Goals The main objective of the thesis is to define and illustrate a new data model that better inregrates 00 concepts, as defined by 00 programming languages, with database technology concepts. The data model hlly adheres to the concepts of 00 paradiam, is independent of any specific programming lanpuage, and is applicable for any general application. It is also simple to understand and use, and provides data independence of the application from the database. The p a l includes outiining the different issues that need to be considered for an implementation of a DBMS based on the data model. C h a ~ t e r1 - Introduction 7 1.3 Main contributions We have proposed a new data model for OODBMSs that rneets the above stated goals. More specifically we have defined the OC data model. which introduces the concept of category as a collection of obiects. The data model makes a distinction between classes as a data type definition mechanism and categories as collections of objects in the database. It provides class design flexibility and easy rule maintenance mechanisrn by separating class definition from constraint specification. It also provides data independence by establishing a clear distinction between the responsibilities of the DBMS and the applications that use it. The thesis outlines the different problems that are found in current implementauons of OODBMSs and how the OC data model solves them. It also discusses several issues that need to be taken into consideration when implementing a DBMS that is based on the OC data model. We have also proposed a query languaze that c m be used to select objects the same way SQL is used by relational systems. Finally, we have presented an example application that illustrates the various facets of the data model. The example utilizes a prototype implementation package that is based on the OC data model. 1.1 Thesis Organization The thesis is divided into different logcal groups. Fint. it starts by descnbing the concept of data model, followed by a shon review of relational model. its limitations and Chapter I - Introduction 8 approaches taken to solve those problems. It then covers object-orienred concepts and the problems with current implementations of OODBMSs. Next. it defines the OC data model. the Category interface, and the category specification language. It then follows with a description of the architecture for a DBMS that is based on the OC data model. It dsu rcviews [ne VIUMG data model by compmng some aspects of it with the OC data model. Finally. it illustrates the OC data model by using an application that uses an implementation of the data model. and outlines directions for further future works. Chapter 2 2 Background practices of the 00 p a r a d i p and the limitations of the relational model. It is also attributed ro the need of 00 progamming languages to store and handle large volumes of data using a system that is more sophisticated than a simple file management system. The aim of this section is to g v e the background concepts that are important in order to understand the motivation of rhe thesis. the origin and current status of OODBMSs. and the OC data model. Particular attention is @en to the concepts of the 00 paradip and their use by current implernentations of OODBMS. 2.1 Data Mode1 A database is a self-descnbing collection of data elernents that together with the relationships among those elements. presents a uniform service interface [18]. It is a logically organized and stnictured collection of interrelated data stored together. In order to describe the structure of a database, we need to first define the data model that it is based upon. Unfortunately, the notion of data model as it is now used in database technology and progamrning languages has been misused from its original definition [BI. Chapter 2 - Background 10 In general. a data model is defined as a set of conceptuai tools for describing the representation of information in ternis of data [12.3 11. It is comprised of data types and suuctures. operations. and (consistency) consuaints. In other words, it is a pattern according to which data are logcally organized. It consisu of named logicai units of data and expresses the relationships among the data as detemiined by the interpretation of a mode1 of the real world [XI. In order for a DBMS to understand the data model. it is essential that it is farniliar with the concepts used to build that model. This is where the notion of database mode1 emerges. Database models take into consideration the representation of real world objects as well as their organization and interrelationships w i h n a database system. A database model is a specification of the concepts of the real world domain and eiements of a particular application in a form undentandable by a DB-MS. h database model is specific to a particular application. Chapter 2 - Background 2.2 11 The Relational Mode1 Currently, the rnost widely used DBMSs are based on the relational model. The relational model i s hased on a tirnple and u n i f n m data structure, the re!a!ion. a d h s 2 selid mathematical foundation. The relational data structure is based on the mathematical notion of a relation. In relational systems, the user perceives the database as a collection of relations. The SQL standard that defines the relationai database specification uses the term table in place of relation. Each table has columns, and each column has a narne and defined data type. The finr normal form. imposed on the relational model, requires the values of each column to be atomic. The. can not contain sets of any iund. Ironically the concept of what is atomic was never defined, but was pnerally taken relative to the smallest unit of information that can be accessed in a query. Each table contains zero or more rows. The content of each column in each row is represenred as explicit data values. In particular. there are no pointers connecting one row to another. The relational model [8. 14,31, 30.321 is formally and precisely defined usine the following tems: 2.2.1 Relation Schema A relation schema R,denoted by R (.AI, At, ..., A.) is made up of a relation name R and a list of attributes Al. AZ, ..., An. A relation schema is used ro descnbe a relation. It defines what attributes are involved and the roles played by each amibute. For example: Chapter 2 - Background 12 the relation schema Penon (SSN,Name, City) defines a penon as some one with a social security number (SSN). who has a name (Name) and lives in a city (City). A relation schema is also called a relation intention. Each an'bute Ai is associated with a domain. dom (Ai),and it represents the role played by its domain in the relation schema. In the above relation schema, the domain "Narnes" could be associated with the attnbute "Name: dom (Narne)=Narnes".A domain is a set of atomic values. 2.23 Tuple . A tuple t of the relation schema R (Al. Al, . . . An) is a set of (attribute:value) pairs (Ai:vi],where vi is a value from dom (Ai) for l<=ic=n. The tuple (SSN: 111 111 111. Xarne:Joe. CityOttawa) is a niple in the context of the above defined Peson relation schema. There exists a penon with social security number 111 111 111, who has the name Joe, and Iives in a city named Ottawa. Chapter 2 - Background 2.2.4 13 Relation A relation r of a relation schema R (Al, A2, ... , An), r(R), is a set of n tuples of R. In mathematical terms, a relation is defined as a subset of the cartesian product of dom (Ai). dom (A2). .... and dom (A,). Addino a ruple to a relation or deletine- a tuple from a relation results in a new relation. A relation is aiso called relation extension. For database management systerns that are based on the relational model, a database is a collection of relation variables. It describes the compiete state of an information model through its relation variables and c m answer questions about its srate. Sirnilariy, a database has a schema and state. The schema describes the database. The data in the database at a particular moment in time defines the database's state. 2.2.6 Derived Relations Denved relations are calculated from other relations known to the database. They are most comrnonly the result of requests to the database through relational expressions and quenes. The requests can be permanent1y remembered (and recalculated) through views. Chapter 2 - Background 14 Herein after, unless a more precise definition is required. we will be using the rems table. row and coiumn, and relation, tupie and attribue interchangeably. 2.2.7 Advantages and Limitations of the Relational Mode1 The relational model has its own advantags that made it very popular arnong the database communi ty. These are: The underlying concept is based on a strong mathematical foundation. The simple tabular schernes and the uncomplicated relationship representation schema provide an easy to leam and consistent user interface. The comparative1y simple and standard access language (SQL) shonens the leaming curve. It provides data independence. Despite al1 its advantages, the relationai model has its weaknesses. The bizgest problem with relational database systems. at least as they are implemented commercially, is the lack of mechanisms to define new domains or abstract data types (MIT) [9].They are lirnited to data types implemented by the system: char. byte. string, integer. etc., and comparative operaton on these types. These were assurned to be the types of atomic values. Some of the points that have been mentioned as shortcornings of the relational Chapter 2 - Background 15 systems in meeting the requiremenü of the "new" applications are given in [5,7, 12.2 11. A summary of these major shoncomings is: Relational systems deal with a single object type: a relation. Furthemore, the attributes of a relation may corne only from simple and fixed data type domains. Nontraditional applications require more complex object suuctures with nested objects. The relational mode1 captures the factual data about applications, but not the "behavioral knowledge" or "domain-specific generic knowledge". Impedance mismatch between progamming languages and DBMS.Applications that are written in a conventional proCiOJamminglanguage and that use relational systems retrieve data from a database usine SQL. Since SQL is a declarative languap and since data types used by programming languages are different from those used by relational systems. the data needs to be mapped from one data type to another. The above can be sumrnarized as the need for type level extensibility through the addition of new abstract data types to the database. Therefore, what is really needed is a way to extend the data type known to the database. The organization of the database as a set of containers (tables) is not the problem. If the relational mode1 is not good enough to represent complex objects it is because of the limitations imposed on the definition of its relation schema. 00 constructs allow us to define real-world objects, thus the relation schema, similarly but differently. The main problem with relationai systems is not with how the objects are k i n g organized (as members of a table) but how the objects are Chapter 2 - Background 16 defined. It is possible to overcome the problem by introducing a new way of defining objects, w h c h is what classes provide. It is important to note that we are not trying to extend the relational model to solve the above mentioned problems. We just want to ciarify the roles the table-iike organization of the data p l a y in the data management. A table groups together a set of tuples and it defines the relationships and constraints its tuples musr satisfy. 7.3.8 Approaches Taken to Overcome the Limitations Two approaches are being taken to overcorne the problems of relational model and develop OODBMSs [ 5 , 1 1 ] : 1. Evolutionary: Since DBMSs based on relationai model are the dominant product in the market place. this approach extends those systems with 00 like constnicts. It is being pursued by vendon of relational systems and is upward-compatible extension to the relationai approach. They are called object-relational database systems. 2. Revolutionary: The other approach is to introduce database capabilities to already existing 00 progamming languages. or to develop an entirely new 00 database languap and DBMS with 00 capabilities. Cha~ter2 - Backoround 17 The first approach still does not solve the so called "impedance mismatch". ïhe second approach suffers from the lack of standard database model for OODBMSs and mostly neglects the needs of the traditional business database applications. Herein after, we will use the term OODBMS to refer the ones that follow the second approach. Our proposed model. Object Category data mode1 (OC data model) takes a new approach. It is evolutionary in the sense that it retains some of the concepts of the relational model. mainly the Iogical view of the database as a collection of containers. It d s o is revolutionaq. because. although it is independent of any progarnming language's implementation, it fully supports 00 concepts as they are used by progamming langages. By doing so. we satisfy the requirements of both applications. traditional as we!l the new ones. and overcome the limtations of the relauonal model. Chapter 2 - Background 18 2.3 Object-Oriented Concepts Object-orientation was first introduced in the context of programming languages. It provides practical benefits for the prototypinp, modeiing and progamming of advanced applications. including hgh degree of code reuse. Object onentation allows a more natural representation of real world entities as well as abstract concepts. Most of the applications that currently use 00 progamrning languages require the manipulation of complex and highly interrelated objects and most imponantiy b e y need to make use of database management systems. Some of the most fundamental concepts of the 00 paradigm 1131 a.re class. object. inhentance. encapsulation. and polymorphism. hlthough there is no a clear cut and agreed upon definition of those concepts [XI, the next section attempts to give a general account of what those terms mean. 2.3.1 Class Class is the main consuuct used by 00 proCoramming languages to define new types of objects that have the same structure and the same behavior. A class has a name and it defines the structurai (set of propenies or variables) and behavioral (set of methods) Chapter 2 - Background 19 aspects of its instances called objects. The data type of a propeny might be a clasç or a literal. For example: Penon class could be defined. in 1ava2 [17,27], as follows: public Class Person { static String weightMeasurement; lasmame; private S t r h g private String firstName; private Date dateofBirth; ci ty; private City private Double weight; gubiic P e r s o n (String iastName, S t r i r q f i r s t N a r n e , Date dob, City city} { this . iastNane = 1astNarne; this.firstName = firstName; this.dateOfBirth = do^; this-city = city; 1 public String getlasthlme ( ) < r e t u m t h i s .1astName; 1 public void setLastName (String 1astNane) { this . lastName = 1astNarne; 1 public String get?irstNameO { return this.firstName; ) g u ~ l i cString toString() { retürn getLastName ( 1 - " , " + get3irstName ( ) ; The above Penon class has six variables (weigh~Measurement.lasName. fin~Narne, dateofBirth, livesh, and weight). a constructor (Peson()). and four methods (getLastName() and setlastilTame(), setFirsd\lame() and toString()). A constructor is a special method used to create instances of the class. Distinction is made berween instance variables and class variables (weightMeasurement). Changes made to a class variable 'Java is a registered irademark of Sun Microsytems Chapter 3 - Background 20 affect al1 instance objects of the class, while changes made to an instance variable affect only the instance object that is making the changes. 2.3.2 Object A11 objects belonging to the sarne class have the sarne structural and behavioral aspects as defined by rheir class. Objects have states. The values ancilor states of its properties determine the state of an object. 2.3.3 Inheritance The concept of inhentance allows us to specialize and facronze definiuons of classes. Therefore, the class design consists of groupinj the most general information into classes. which are then specialized into subclasses. specifyin; more specific behaviors with each sep. Subclasses could inherit behavior as well as structure. For example, the Penon ciass c m be specialized inro the Employee class as follows: p ~ x b l i cc l a s s Employee extends Person { String mp1oyeeNo ; double sala-q; -. p r i b l i c Persor? (String lasrName, String rirstXame, Date dob, City city, S t r i ~ gemployeeNo, double salary) { super(lastName, firstName, dob, c i t y ) ; this .employeevo = employeeNo ; zhis.salary = salary; Chapter 2 - Background 21 ... 1 public String toString() { r e t u r n super.toString0 + " , " + this.annualIncome(); p h l i c double annualIncorne() { 1 The Employee subclass inherits dl variables and methods of the Person class. 2.3.4 Encapsulation Encapsulation provides a mechanism for objects to hde their implementation details from their usen. Clients interact with an object through its public interfaces. For example, the instance variable name of the Penon class can be read or updared through the public interfaces ge~Vame()and setVarne() only. 23.5 Polymorphism Polynorphism refers to the use of the same message signature to address different methods in different classes. For example, a toSuing() message to a Penon object prints the penon's last name and first nane. When the same message is sent to an Employee objecr, the printout includes the employees salary. Chapter 2 - Background 2.3.6 22 Object Identity Object identity has long, existed in 00 prograrnming languaiages. The concept is even more cntical for OODBMSs. Each object in a database is distinguished from al1 others by its identity. which is independent of the state of the ob!ect. The identity of an object remains the same during the object's lifetime within a database. 2.3.7 Advantages of 00 Modeling The 00 paradiam has many advantages. Some of which are: It provides for more naturalness of the abstract representation of red world information than the relationai mode1. It supports type extensibility through classes. The class structure encapsulates behavior as well as the traditional static attributes. The inhentance mechanism allows us to create new classes by subclassing, and thus reusing existing ones. 2.3.8 Disadvantages of 00 paradigm It lacks a standard data model. The rich and extensible nature of the 00 data model makes implementing OODBMSs more complex and quite challenging. Chapter 2 - Background 23 The dynamic binding that is required by 00 paradigm makes the prograrns slower to run. Data mininp is harder because of the difficulty to discover new relationships between objects. Chapter 2 - Background 24 2.4 Object-Oriented Database Management Systems .A DBMS is a collection of p r o g m s that enables usen to create and maintain a database for various applications. Ir allows users to define and create the database. and populste it with data that is later retrieved and manipulated most probably concurrently by multiple users. A DBMS is usually divided into different software modules that act on the data and perform diiferent functions on different levels of the DBMS architecture. The ANSUSP.UK architecture. illustrated in figure 2.1. dwides database systems into three different levels calied internai level. conceptual level and extemal level. The interna1 levei deals with storing and reuieving data to and from the storage media. The sofiware modules at the conceptual level are responsible for organizing the whole database according to a defined logical data model. They hide the physical charactenstics of the database from higher levels. They ais0 include program for data consistency, sechty. etc. The highest level of the architecture directly cornmunicates with users. It provides the usen with different views of the database that address the specific needs of the user or a group of uses. A DBMS includes software that maps data from the external Ievel to the conceptual level, from conceptual to physical. and vice versa. Chapter 2 - Background 25 The need for 00 pro_oramming langage usen to store their data without suffering from the "impedance rnismatch" and the lack of expressiveness in current data models when applied to the new generation of applications are two of the main factors that motivared development of OODBMSs.OODBMSs try to provide an 00 image of die stored data that c m be modified and used nearly as if it were in transient memory. An early solution to the problem was to extend the programming languages with simple persistence facilities allowing objects to penist between application sessions. Since then. much effon has ;one into developing DBMSs that store objects. and into defining 00 data models. Object-oriented modeling provides constructs for more "naturalness" of the abstract representation of real-world information. However. OODBbISs in their current implementations are application-onented extensions of 00 progamming languages. They do not directly address the problems faced by the integration of the two technoloses: 00 design methodology and DBMS.From the utilization of terms to data organization they have been heavily infiuenced by: The progamrning language used to develop the DBLMS. The parricular application the designers of the DBMS were aiming at. Database management systems are used for managing the repositories of objects that are used in different applications. The database mode1 of a database does not necessarily have to be similar (identical) to the database mode1 of a specific application. 00 data Chapter 3 - Background 26 models proposed so far do not include collections as the logcal view of the database. The use of collections b y a DBMS implies a clear and easy way of making objects persistent 1 Extemal View 1 I Conceptual Level Internal Level ... External View 1 1 Conceptual Schema 1 Internal Schema 1 Stored Database Figure 2.1 : The Three Level ANSi/SPMC Architecture thar is consistent with the concept of database and resembles the operations of insert, retrieve and remove objects. Current OODBMSs provide "roots" as database entry points [6. 14: 231. Other persistent objects are accessed throua navigation that stans from one of the root objects. The question is how many root objects do we need to logically represent the database's scherna In addition. most of them use garbage 1 Chapter 2 - Background 27 collection methods that remove objects that are no longer referenced from one of the root objects. This forces usen to maintain explicit collections. For this reason OODBMSs provide constructors for collections (set, list. etc.). However. the y leave the responsibility of their maintenance to the progarnmer. By doing so they place the burden on the programmer to insure the correct suucturing of the database. This circumvents one of the primary objects of a DBMS, which is to facilitate the management of object repositones. 2.1.1 Advanîages of OODBMSs The integration of 00 concepts and DBMS technology offers the following advantages: Al1 the strenghs of 00 modeiing are available: inheritance. polymorphisrn, encapsulation, etc. Type extensibîlity through classes. which encapsulate behavior as well as the traditional static attributes. A simple relationshp mechanism through logical inclusion (direct object reference). Simplicity of development through aimost direct conespondence between the application's objects and the database's objects. 1.4.2 Prob lems With Current Implementations of OODBMSs What are the probiems with OODBMSs as they are implemented currently? Chapter 2 - Background 28 Unlike the relational model, which has a good theoretical basis and is well defined. OODBMSs lack a comrnon standardized database model and formal foundations. Constnicts used by OODBMSs are direct copies of the consmcts used by the progamming languages that influenced them. However. the notion of 00 data model in database systems is much broader dian that found in programming languages. Progamming languages do not have such notions as relationshp and constraint. In addition, there is no single 00 paradip. and therefore there are varieties of 00 data models ( 5 ) . One of the differences berween the 00 approach and that taken by the relational data model is that the relational model explicitly maintains the collection of tuples. Collections are a natural way of represenung groups of objects from the real world. OODBMS cm not be made to work for the general database case unless the user maintains collections of hisher own. Doing so makes applications more complex, since they have to take some of the responsibilities that previously were under the DBMS. Object-oriented database manasement systems must take into account not only the new applications. but also the traditional business data processing applications. However. existing OODBMSs seem to ignore the needs of the traditional and focus more on the "new" applications. In fact rnost of them are targeted at "new" applications (CADKAM, CASE, Office automation, etc.), and are more application oriented than technology oriented [ 2 ] .In the long nin there is a need for a single Chapter 2 - Background 29 database system that satisfy al1 lunds of database requirements. Few applications fit neatly into just one category [l].In addition. a Company might have al1 hnds of usen, thus would require a database systern that could provide al1 the requirements [j]. .A class is the constnict used by 00 progarnming languages to define absvact data types. Cnfonunately. the influence of 00 programming languages has led to a confusing and contradictory use of the same term [2 11. Does a class represent the set of all possible instances (intention) or just the vanable containing the instances we happen to be interested in at the moment (extension)? Almost al1 OODBMSs treat classes as extensions instead of (or as well as) treating them as data types. Class definitions are used as black boxes that contain aspects of the application progams as well as that of the database. TNsmeans that relationships. constraints. etc. are al1 part of the class defini~on.This idea of putting every thng in one place makes class definitions very susceptible to unforeseen errors or changes in the business rule. Object-oriented data models try to model real world objects. However, adding an additional construct to the database model. namel y catepry, defines bener the logical view of objects in a database and their organization. A database based on the OC data model is seen as a collection of categories as opposed to a collection of objects. Chapter 2 - Background 30 2.4.3 How Does the OC Data Mode1 Solve the Above Problems? The data mode1 is independent of any progaxming language, and it includes the notions that are found only in the context of a DBMS. The use of cateoory adds more expressiveness to the data modei without the additionai burden placed on the programmer. By making collections integral parts of the database the OC data mode1 sarisfies the needs of the uadi tional as well the "new" applications. It makes a distinction between class as a mechanism to define absuact data types (domain) and the structure used to maintain collection of objects. category. A class represents a definition of a real-world object and as a definiuon it "represents" al1 possible occurrences (instances) of the real world object. .A category is a collection of actual instances in the database. The constraints. including relationships, the objects must satisfy are defined at the category level. Objects are checked against those constraints depending on their category membership. This approach provides data independence, and class design flexibility without sacrificing the nearly transparent handling of persistent objects. Chapter 3 3 Object Category Data Mode1 A . ,. ET!?:CC& bd~::, me ûbj:jcSi~c ûf 1hk ù h i k ~ iû i i i i 2 g ~ ~ CÛiIiZpü. rij defincd by 00 programmin; languages, with database technology. The approach followed is to make the database 00 by retaining al1 the concepts of the 00 paradigm, and making collections an integral part of the logical view of the database. The OC data model descnbed is independent of any progamming language implementation. and it can be applied to systems with single inheritance, multiple inheritance. typed or untyped. The data model adheres to the basic properties of 00 paradtgm explained above. The chapter is divided into four sections that describe the different aspects of the data model. Section 3.1 defines the data model and its components. The Category interface and its functionality for object insertion and retrieval are described in section 3.2. Section 3.3 lists the BNF for a category specification language whle section 3.4 explains aspects of a query language for the OC data model. 3.1 The OC Data Mode1 The notion of a collection is very important to the concept of database management. A single design project rnight not need all the hinctionality of a DBMS.However, a Chapter 3 - OC Data Mode1 2 reference to a database implies a reference to a collection of whatever information of an enterpxise we would want to manage, includin; collections of desips. The OC data model is based on the concept of category. A category groups together a collection of objects of the same type hierarchy. A database based on the OC data model is conceived as a collection of categories. The organizaùon of objects in the database through the use of categories allows us to separate most of the situations that arise only on the context of DBMS from class definitions. Categones are to OODBMSs based on the OC data model. what relations are for relationai systems. They form the logical view of the database. Categones are the only enwy poinr to the database. The informauon content in the database. at any given tirne, is perceived in tenns of objects in catesories. Objects do not exist outside the categories. And the operaton available ro the user for deaiing with the database are mainly operators that manipulate objects in categories. 3.1.1 Categories and Classes One of the main functions of a DBMS is to process a large number of interrelated objects. None of the most popular 00 progiiITlTning languages supports the notion of a type or class extent explicitiy. This leads to an interesting contrast between DBMSs and propramming languages with respect to the use of types and classes 1211. The OC data Chapter 3 - OC Data Mode1 33 model makes distinction between a class, which is the set of al1 possible instances, and a category. that is a collection of a finite set of actual instances of a class in the database. A class is a type and not its extension. Gnlike a class. a category is time-variant. Under the OC data model, ciasses define data types. A category is analogous to a relation variable of the relational model. whch is a time varying collection of objects. For example. the above Person class defines the attributes and behaviors that are cornmon to al1 pesons. A category defined over the Person class groups together instances of the Person class that are known to the database. It also defines rheir relationship to other objects in the database. and it captures their collective propenies and atmbutes. or any integnty constraints that need to be satisfied by the collection. A Class addresses generai properties of objects while a category has knowledge of individual instances of objects. The class c m answer requests about the general charactenstics of its instances. The category answers questions about the set of individual objects it contains at a specific time. Classes are defined by the application's progamming language for a modular development of applications, whle categories are defined by the DBMS for an easy oganization and maintenance of the database. Categories are typed. A category maintains a coiIection of instance objects that are of the sarne class or type hierarchy. If class B is a subclass of class A, then objects that are Chapter 3 - OC Data Mode1 34 Emplo yees Figure 3.1 : Three categories (Employees. Managers and Non-Managers) could have been defined over the sarne class (Employee). They are related to the Depmments category, whch is defined over the Department class. through two different relationships: WorksFor and Manages. instances of class B c m be inserted into a category defined over class A. Objects are uouped into categones according to their type and their relationship to other objects. Ci Under the OC data model. objects do not exist outside categones. A persistent object is at least a member of some category. The OC data model provides a large degree of flexibility in its concept of category membenhip. In particular, objects c m be members of more than one category ar the same time. .4 category in a database is uniquely identified by its name. Furthemore, several categories can be defined over the sarne class. For example, we could define three categories for the Employee class: a category of managers, a category for non-managers, and a third one that contains al1 employees. Each one rnight have iü own set of constraints and relationships. Cha~ter3 - OC Data Mode1 3.1.2 35 Inheritance Like the 00 paradigm introduced in chapter 2, the OC data mode1 includes inhentancebased categorylsubcategory or categoryhupercategory relationships between categories. The relationship defines the set inclusion semantics for categories. A category is a subset of its supercategory. Therefore al1 its objects are considered to be members of the supercategory too. In figure 3.1. objects in the Managers and Non-Managers categories are members of the Employees category roo. Therefore. @en figure 3.1 and their contents in figure 3.2. Employees.select(lastName="Mark") would retum al1 the three employees whose lasr?iame equals Mark. A category inherits d l the charactenstics of its supercategory. Characteristics of a category include its relationship with other categories and al1 other constraints. Therefore, objects in the Managers and Non-Managers categones are constrained by constraints defined over the Employees category. Category/supercategory relationships are defined explicitly. That is the system does not infer the categorylsubcategory relationship by Iooking at the signatures of the types or class definitions. The user must declare rhs fact which asserts that the subcategory collection is a subset of the supercategory collection. Chapter 3 - OC Data Mode1 1 r EMPLOYEES Last name First name MA,?JAGERS j, Fint narne NON-MANAGERS , Last name First narne Smuel Georoe Mark 1 1 h t name Mark 1 36 1 Frank Solomon Figure 3.2 -- I Bahta Shows the logical grouping of persistent objects in three categories that are related through the category/subcategory relationshp. The OC data mode1 allows multiple inhentance between categories. A category could be a subcategory of one or more categories. For instance, a category for teaching assistants could be declared as inhenting from the categoq defined for students and another one Studen ts Sections Figure 3.3: A partial EER diajram for a school database with multiple inhentance defined for employees. In addition to the charactenstics inherited from its supercategones a category could also define characreristics that are unique to the instance objects it I Chapter 3 - OC Data Mode1 37 maintains. The category for teaching assistants is complemented with a relationship that reflects the fact that a teaching assistant assists one or more sections. 3.1.3 Intemal Representation The internal representation of a category could be a set. a list. an array. or any other container class. The type of collection to use could be determined by the DBMS depending on the user's need for soning or other characteristics. or the user could explicitly specify it. Methods that conven the internal representation of a category from one type to another could be provided. Objects are selected from a container either by pointer (i teration), or associative retneval (query). 3.1.4 Indexes Collections are usuall y supported by indexes. Indexes [Il improve a collection's ability to find objects given atuibute values for those that form the key. Collections are an integral part of a database based on the OC data model, therefore it is very important b a t indexes are made part of the integral pan of the database too. Indexes understand the category hierarch y. For instance. an index for the Employees category, figure 3.1, would include references to al1 objects in the Employees. Managers and Non-Managers categories. Several indexes can be defined for the same category. Chapter 3 - OC Data Mode1 3.1.5 38 Constraints The choice of appropriate data structures together with the related operations of the data model will often be too coane to exactly represent miniworld sernantics. In this case. additional consnaints (generally called consistency constraints or semantic inregrit' constraints) have ro be specified. and a data model is required to provide appropriate support (111. The OC data model separates constraints from class definitions. The technique of separating design concems into behavior and constram designs makes the design process easier and less prone to unforeseen errors. Because of the flexibility of 00 prograrnming. it is possible to prevent integrity violations by coding the controlling logc as part of the applications. However. the approach does not allow separation of algonthms (application codes) from constraints. and places a heavy burden on the programmer. In a real application environment. support for accommodating changes to type structures is necessary. It is often not feasible to adjust the application code as type definitions evolve [16]. Making changes to design in 00 systems can be expensive. OODBMSs try to create a seamless integration berween the applications and the database. However. one of the main objectives of any DBMS should be to minimize the effects that chanses to the database will have on the applications using it. Therefore, it is very important to achieve the fint objective without neglecting the second one. In OC data model constraints are Cha~ter3 - OC Data Mode1 39 defined over categories. The data model suppons type change transparency by isolating constraint specification from the core definition of the class. Constraints may be added andfor removed dynamicaily. ALthough there are situations in which conversion ûf the existing data and re-compilation of ail the applications is necessary. the approach followed by OC data mode1 minimizes such situations. Key business rules c m be coded as integrity constraints, and if a change takes place in the business rules. a single point of change updates the integnty rules for al1 applications. and ensures that rules are applied unifonnly and consistently for ail applications. Existing constraints c m change and new ones c m be inserted. An object's constrainü have a dynamic nature that changes as the object moves in and out of categories. For emnple. the same employee object mght be subject to different constraint checks depending on its membership to the Managers category or to the Non-Managers category. The separarion of actual objects from the constraints that jovem their participation in a category has the following advantages: Greater application independence: We define application independence as a degree of measuring the irnmunity of application to funue changes in the business d e s . The OC data model separates the actual objects fromthe rules governing their existence in the database. thus avoiding recompilation of al1 applications using the database due to changes in constraints. The constraints are plugged-in or unplugpd dpamically. It captures better the inter-relationship between objects, which is oniy defined by the object's membenhip to one or more categones. Objects can be migated from one Chapter 3 - OC Data Mode1 40 category to another. For example, an employee instance object could be removed from the Non-Managers category and inserted into the Managers category and vice versa. Makes rule maintenance rnuch easier. Consuaints are predicates such that if not satisfied the system automatically raises exceptions for the user to handle. There are a nurnber of integnty constraints that could be enforced on a database. The more integnty niles are enforced automatically, the better the system is. However. ir is alrnost impossible to cover al1 of rhem [l. 211. The integnty constraints discussed in this section include referential intepty constraints or relationships, unique or key constraints, Not Nu11 consuaints and triggen. A category is associated with a set of constraints. 3.1.5.1 Referential Integrity Constraints (Relationships) Referential integnty for the relational mode1 is a consrraint requiring that a foreip key value must either (1) be nul1 or (2) contain a value that actually exists in the referenced table. It implies that a tuple can not be deleted if its pnmary key is a foreign key for another tuple. 00DBMSs should also handle referential integrity checks in a sirnilar manner to avoid dangling pointers. A dangling pointer is one that is referencing a deleted object. Relationships in OC data mode1 define the connection that exists between Chapter 3 - OC Data Mode1 41 categories. For example. the relationship WorksFor in figure 3.1 defines the connection between the Employees category and the Depamnents category. It specifiea the fact that each object in the category Employee works for some object in the Depamnents category. It is important to note that relationships are defined between categones. A relationship defined over a caregory applies only to its member objects. Since it is possible to have different categones defined over the same class. instances of the same class might or not be subject to a specific integnty check, depending on their cstegory membership. For example. employees in the Managers category are related to Departments through the Manages relationship. which is not tme when applied to members of the Son-Manasers category. A relationship defined over the not necessarily distinct categories has propenies that govem the way objects in the category participate in the relationship. We cal1 these properties cardinality ratio of the relationship. The cardinality ratio specifies the minimum and maximum number of objects an object in a category can be related to. The most cornmon types of relationship are one-to-one, one-to-many, many-to-one and manyto-many. The OC data mode1 supports dl four iunds of relationship. The cardinaliry ratio of the relationship defined over the category Ci in its relationship with category Ctcould be more precisely specified by a pair of numben (ij) where Chapter 3 - OC Data Mode1 -42 Oc=ic=j and j>O. It means that objects in category CIcan be related to at least i and at most j number of objects in category C?.The cardinality ratio of the relationship effectively defines referentiai as well as existential constraints on the objects that are members of the panicipatinj categories. The cardinality ratio of the WorksFor relationship between Employees and Departments could be specified as (1,l) and (0,n). The first one (1.1) means thnt an ernployee c m only work for at least one and at most one depanment. while the cardinality for Depanments (0.n) specifies that a department c m have none or maximum of n number of employees working for it. The (1.1) cardinality ratio effectively resmcts the employees that can be members of the Employees catepry to those that work for deparunents in the Depamnents category. It also imposes some constraints on the rernove operation for Depanments. A department cm not be removed from the category as long as there 1s at least one employee working for it. Or. if it is removed, then it should be propagated to the employees working for it. It rneans that removing a department implies the removai of al1 its employees. It is also possible to define relationships between objects in the sarne category. For example, the relationship between an employee and its supervisor can be defined over the same Employees category. Relationships are not objects. Objects in categones are directly linked through their member attributes. For example, employees and departments could be linked through Chapter 3 - OC Data Mode1 43 deparnent and employees attributes respective1y. In [20] relationships are suggested to be objects by rhemselves, and to be maintained in their own category. The advantaje of this approach is that it eliminates the need for a new class when the relationship has 0 Grade Sections Figure 3.1: ' A relationship with an additional attribute additional attnbutes. figure 3.1.The disadvantages of doing so are: It rnakes the system slower. since it would require a join operation even for the simplest select operation. In OC data model. relationships are defined between categones. Objects in categories are directly linked through their member atuibutes. A DBMS based on the OC data model provides mechanism for specifying relationships between categories. Keys are used to uniquely identify an object aven one or more of its atuibute values. They can also be used as a hint to provide faster searches when key values are specified. Chapter 3 - OC Data Model 44 For instance, employee number could be used as a key for employees working for a Company. Keys that consist of more than one amibute are called composite keys. Object identities are intemally defined and used by the DBMS to uniquely identify objects in the database. For a human being, key attributes are what object identities are to the DBMS. Arguments have been made against the need of keys for OODBMSs. The user-defined keys, known from conventional databases. are unnecessary [24]. However more people believe that keys are essentiai ingredients of database query processing [ 6 ] .Without a key it would be very hard. although not impossible. to enforce the nile that specifies the fact that employee numben should be unique within a Company. In addition to object identities, objects in a caregory can be uniquely identified by the values of one or more of their attribues. 4 DBMS based on the OC data mode1 provides a mechanism to define keys. Speciai case of domain integity constraint is the YOT NELL constraint. h % U represents a missing attribute value. In many situations we want the value of an attribute to be neither empty nor W.For exarnple, every person must have a name, therefore name should aiways be different from nul1 and empty. The OC data mode1 supports NOT NLLL constraints. Chapter 3 - OC Data Mode1 45 3.1.5.1 Triggen In practice there are different types of constraints that could be defined over a database. However, it is nor practical to have a special integrity constraint type for each one of them. We need a genenl mechanism whereby usen can express integrity rules and eniorce them. The general mechanism should allow us to define almost al1 possible types of constraints. and should provide the constnicts for the following actions: defining the integrity constra.int and specifying the actions to be taken when an inte-gity rule is violated. The more general the mechanism is the more types of constraints it accommodates. Triggers are special mechanisms for enforcing integrity constraints. In most cases when an integty constraint is violated. the system will raise an exception that will probably end up intempting the process that caused the violation. Tnggen are a way to avoid such situation and correct the situation automatically. They are a combination of two things: a condition and an action. The condition is associated with the operations that a user can invoke on categories: insert object. remove object, modify object, and reuieve object. The condition c m also be more precisely specified as before operation or after operation. For example, if we define that a department's manager saiary should be the sarne or higher than the maximum of the other employees' salary. then modifying an employee's s a l q Chapter 3 - OC Data Model 16 should automatically fire a trigger that checks the managers' sdary appropnately. The OC data model provides a mechanism for specifying triggers that are fired upon the invocation of operations that insert. modify andor remove objecrs. In addition to the above mentioned explicit user defined consuaints. there are other constraints that are implicitly and automatically enforced by the OC data model. For instance, the intemal representation of a category could be a set, a list or an array. The type of collection used irnplicitly defines some constraints on the category. For example, if a set is used ir irnplies that objects can not be duplicated on the s m e category. Chapter 3 - OC Data Mode1 47 3.1.6 Schema For each database created. the DBMS stores and maintains a metadata or schema. The schema describes the database's stmcture and i c uced hy the DBMS !o perf~rrr!ils Z S ~ . The information stored in the schema. figure 3.5, of a database based on the OC data mode1 contains descriptions of the categories defined. the classes whose instances are ç' Keys m Not-Sul1 m A Indexes 1 1 Triggers Fiyre 3.5: 1 + 7 - rr Categoties Relationsttips The Partial EER Diagram for the Schema of a Database Based on the OC Data Model persistent. and the relationships between the categones. It also includes information on keys,constraints, and uiggrs. the indexes defined on the categories as well as other Chapter 3 - OC Data Mode1 48 information used to determine the physical and logical structures of objects. Security and user authorization information is also recorded. The schema can be stored in a collection of categories and maintained using the facilities provided for object manipulation. 3.1.7 Advantages of the OC Data Model The OC data model adheres to the basic properties of the 00 paradiam. Therefore al1 the advantages of OODBMS.as menuoned above. are available in an OODBMS based on the OC data model. The model can be easily derived from the extended entity relationship dia-. Ir provides a framework for unifyîng value-based and identity-based access to objects. Offers a more natural. logical and consistent view of the database. By isolating consuaint specification from the core definition of the class. it provides increased data independence. and flexible design approach. Satisfies the requirements of databases that combine the new applications (C.W/CAM, CASE. GIS,office automation, etc.) with the traditional business data processing applications. Reduces the overhead of worlung with collections, whch are the basic components of any database. Chapter 3 - OC Data Mode1 39 3.2 Object Manipulation using the C a t e g o ~Interface A database based on the OC data mode1 is a collection of interrelated categories with a simple interface. The logical view of the database is composed by the cateoories - it contains. Applications interact with the database through the categories and the operations defined in them. Objects are added to a category by using one of the insen methods. Once inserted they are explicidy removed from the category using the remove operation. The Category interface includes operations that allow usen to insen. revieve and remove objects. These operations c m be divided into single object operations and collection type operations. Collection type operations allow a collection of objects to be inserted. retrieved or removed in a single method call. 3.2.1 Attributes of Categories Categories have two kinds of attributes: attributes defined by the class being maintained and attributes defined by the category itself. For example. the Employee class defines the attributes of each object, like narne, birthday. etc., while the Employees caregory defines azgregate attributes like the number of objects in the category. For the purpose of queryng. a category's attribute set includes only those attributes defined by the class it maintains. Chapter 3 - OC Data Mode1 50 32.2 Making Objects Persistent Instances of a class can be persistent or transient. A DBMS based on the OC data mode1 provides different mechanisms for objects to becorne persistent. Two of the possible mechanisms are explicit insert and object reachabilicy. T h r o u ~ hexplicit insen, an object becomes persistent when it is explicitly insened into a category through one of the different insen methods. .4t least two insert methods are provided: insen (Object O ) , and insert (Collection c ) . 3.23 Retrieving Persistent Objects Access to persistenr objects is done through categones. h y object in the database can be reached through one or more of the categones. The interface provides different ways of retrieving objects from a category. We can ask for a collection of objects that satisfy certain predicate or we can ask for a specific object. The number and type of access operaùons pmvided varies dependmg on the category's interna1 representation. For example, if a list is used, then it is possible to retrieve objects by their position in the list. Another way of retrieving objects is through quenes. Query is an important aspect of any DBMS. Usudly a database stores and manages a large number of interrelated objects organized in a certain way. Quenes are invoked against collections which categories are. Query is a mechanism that allows retrieval of objects by their value. Chapter 3 - OC Data Mode1 51 The Category interface provides operations that accept a predicate as an araoument, like selecr (Predicate p) and get(Predicare p). A predicate is a boolean expression that is evaluated against each object in the category. The result of invoiung these methods on a category could be a collecrion of objects or a singe object. By allowing value-based expressions to select objects. the OC data mode1 provides a framework for unifyng value-based and identity-based access. 3.2.1 Removing Objects The lifeume of a persistent object spans from the moment it is created until it is completely removed from the database. Objects. once inserted into a category, are explicitly removed from the category using the remove operation. The set of remove operations includes operations that remove an object aven iü id. remove (Objecr obj). and operations that remove objects aven a predicate. remove (Predicare p). An object continues being persistent until it is removed from every one of the categories it has been explicitly insened into. Removing an object from the only category it is a member of autornatically removes the object fYom the database. C h a ~ t e3r - OC Data Mode1 52 33.5 Modifying Objects The Category interface does not define an update method. To achieve a nearly transparent manipulation of persistent and transient objects, the preferred way for handling updares of obiects is for the DBMS to automatically propagate the modifications ra the datahase widiout the user havinj to cal1 an update method. 3.2.6 Other Operations In addition to the above-mentioned minimal functionality. the Category interface could be enhanced with operations that dynarnicall y change a catepry 's configuration. Confi_ourationof a category includes its internai representation. i ts relationship with O ther categones. and other constraints defined over the category. Chapter 3 - OC Data Mode1 53 3.3 Category Specification Language From the user's point of view, there are two aspects to the definition of an application's schema for an OODBMS based on the OC data mode1 class d e f i n i t h a d c 2 w g x y specification. Class definition is the declaration of classes whose instance objects will be persistently stored in the database. Class definition cm be written in the progamming language's class definition language. or it can be wntten in an object definition language rhat is independent of any pro-oraniming language. as in [6].Class definitions are subject to the features and limitations of the host progamming language used to write the application. The OC data mode1 does not define a class definition language. The approach to be used is lefi for implementers of OODBHS. Caregory specification languap (CSL) is a language to be used for the declaration of categories. Two different approaches could be used for category declaration: through a specification language. or through low-level calls provided by the DBMS. The use of a specification langage would require the use of a pre-processor that would accept category specifications and add hem to the database's schema. The second approach avoids the need for a specification language and a pre-processor. Chapter 3 - OC Data Mode1 54 The CSL's p t a x includes semantics for the specification of the following aspects: category name, class name, intemal representation. relationships, key consaaints, NOT 1 N L . L constraints, and uiggers. The top-level BW for CSL is as follows: ccategoryheadem .._ ..- category ccategory-name> [extends ecategory-name- lis^] The category-header specifies the category name that is unique within a database and the caregories from w hich it inhents. The body part. w hich stans with ( and ends with ) is composed of five parts. For the complete B N F of CSL see Appendix A. 3.3.1 Extent Declaration .4s mentioned above, different collection types cm be used as an intemal representation of a category. In addition. a category is typed to a specific class. The BNF for extent declaracion is as follows: cextent-declaration> ::= <set-dedaration> 1 ciist-dechration> 1 < a m y-dec larati on> Chapter 3 - OC Data Mode1 55 It specifies the intemal represenration of the category as a set. list or array. The type of collection used detennines the additional functionality of the category. For instance, the list declararion would require the specification of the attributes by which the category will be sorted out and the order of sorting. The BNF for list declaration is as follows: d i st-dechrations ::= list <class-name> [ corder-dedaration> ] corder-declararion> ::= orderedBy corder- lis^ corder-lisu .._ <attribue-name> [ <order> ] [, corder- lis^ ] corder> .._ ASC (DESC 3.3.2 Relationship Declaraüon The specification of a relationship between two categones includes the related categories and the anributes used for the relationship. Ir should aiso include the cardinality of the relationship. X category c m be related to one or more categories. The BNF of relationship is as follows: uelationship-cieclaratiom ::= refationship <cardinalitp crelated-category-name> iink canri bute-name> inverse uelated-atmbute-name> ccardi naiity> 3.33 Key Declaration Objecü in a category are uniquely identified by the values of one or more of their attributes. The BNF of key specification is as follows: Cha~ter3 - OC Data Mode1 56 dey-declaratio~ ::= key <anribute-liso cattribute-lis- ..- cattnbute-name> [, <ambute-lisu] 3.3.4 Yot Nul1 Declaration One or more of the amibutes of the objects in a category mav he cnnstrained rn he 'Q! null. The BlNF for Not Sul1 declaration is as follows: aot-null-dedaration> ...-- notnuii <attribue-lisu 3.3.5 Trigger Declaration A trigger is an action that is fired every time an operation is invoked on a category. A trigger could be fired as a consequence of the insert, remove. modify or retrieve operation. It can also be exactly specified when it should be fired: before the operation or after the operation. The BM: for triggen is as follows: <uiger-decl aration> ..._ - trigger con-dechration> ctrigger-name> [ <when> ] <w hen> ....-- before 1 after Chapter 3 - OC Data Model 3.4 57 Query Laquage Object Category data model organizes objects as memben of categories? which is very cimi lar to rhe way tuplec are orgmized ir! re!zfi~cl! syrtemr. Bec--se of t!is s:~i!i+~ J the query language used for relational systems. SQL [IO], can easily be adapted to fit the OC data model. However. there are one major issue thar needs to be addressed when trying to adapt SQL to the OC data model: retum objects type. When a select query that gets its attributes' values from more than one category is invoked, it retums objects of a specific type that are dynarnically consuucted by the query processor. We use the application described in chapter 5 to illusmte the proposed que. language with examples. 3.4.1 Return Objects Type Relational systems are based on only one data stnicture, i.e. relation. The result of a select query is dways a relation. Cnlike relational systems. 00 systems provide mechanisms to define new data types based on the concept of class. 00 databases, including OC data model, store and manage objects that are instances of classes. Most OODBMSs provide query facilities that span a single class andfor a singie collection of objects [j].As illlustrated in section 3.2. since a catesory is a collection of objects of the same type. a query langage that spans a single category would only require the Chapter 3 - OC Data Mode1 specification of the predicate. However. to achieve the objectives of SQL in relational models, we need to provide a mechanism for the execution of queries that freely combine attxibutes from objects in different categones, andlor different classes. .A select query in 00 databases returns objects that are instances of an existing class. The values for the attributes of the objects rnijht be extracted from one or more classes. However. SQL's select statement does not specify the hnd of objects to be returned. Therefore, the new select statement for 00DBMSs should state the attributes to be retumed as well as the type of objects to be created. For instance. let us Say that @en the Students category and the Professon category we are interested in findin; students whose last name is sorne professor's lasr name. However, we are not interested in retrieving neither student objects nor professor objecü. We only want to retneve some attributes from students (last narne and section) and sorne amibutes from professon namely education and section. SQL-likeselect statement to retneve the information we are interested in would be: Select s.lastVarne. s.sections. psections, peducation From Students S. Professon p Where s.lastName = p.lastName The OC data mode1 and dl 00 data models work at object level. However by readinp the above statement it is not clear what kind of objecü will be returned. We should be able to include in the statement an indication of what kind f objects we want to be created. We Cha~ter3 - OC Data Mode1 59 should d s o be able to specify how the participaring anributes (s.las~Name,s-sections. p.sections and peducation) should be combined to constnict objects. Our proposal is to define a query consmctor that accepts three arguments: the select statement, the object type and the collection type. We define a Query class that is provided with the facilities needed to parse the select statement, execute it and retum the objects in a specific format. Let us first define the Std-Prf class that we use to create the objects ro be returned. p u b l i c class Std-Prf { String IastName ; Sections Sections Scring stdsections; prf Sections ; education; public Std-3rf (String lastKame, Sections stdSections, Sectiozs prfsectiocs, Scring education) { this.lasiName = lastName; this.stdSections = stdsections; this.prfSections = prfsections; education = education; } public String t o S t r h g ( ) { r e t u r n lastName + " , " + stdsections.toString ( ) + " , " + p r f . sections. coScring ( ) + " , " + education; Now we can create a que. constmctor as follows: and pass the above class name as an argument to the que. Chapter 3 - OC Data Model public class TestQuery { ..m S ~ r i n gqry = "Select s.lastName, s.sections s t d S e c t i o r . s , p.sections prfsections, p . e d u c a t i o n Frorn Students s, Professors p Where s.lastName = p.lastNamen Que-ry q = n e w Query(qry, S td-Prf , Queiry.vec tor ) ; Vector r s l t = ( V e c t o r ) q . e x e c u t e ( ) ; f o r (i=l; i<rslt.size(); i-+) ( System. out . p r i n t l n ( ( (StÙ-Prf) (rslt.elementAt(i))).toStri~gO) The query statement (qry) is a statement very close to the SQL's select statement. The space between "s.sectionsWand "stdSectionsWtells the query consmctor that values from "s.sectionsVare to be srored in the anribute "stdSections". If both, the o r i p and destination. attributes have the same narne, then the second amibute name may be omitted. The second argument specifies the type of complex objects to be created. The last argument. "Query.vector". indicates the collection type to be retumed. The Query class could be provided with capabilities to retum any kind of collection or iterator. In conuast to JDBC's SQL mechanism [19], the above query clearly States the amibutes and the type of objects to return. Every retumed tuple forms an object and is manipulated through the interface provided by sorne class, in this case by the Std-Prf class. The class defines the structure and behavior of the objects renimed. Therefore. there is no need for JDBC like getStnng, getlnt. etc. methods to renieve the atmbutes from the result set. Chapter 3 - OC Data Mode1 61 p u b l i c class TestJDSC { -.String qry = "Select s.lastXame, ~ . s e c t i o n sas stdsectlons, p-sections as prfsections, 2.education From Stucents s, P r o f essors p Where s.lastName = p.las=Namen Statement s=m = c o r i n e c t i o n . c r e a t e S t a t e r n e r , t ( ) ; ResultSet r s i t = stm.executeQuery(qry); while (rs7t.next()) ( String str += rslt.getString(\*lastNmel')+ *' *' + r s l t . getObject (\'stdSectio~sJ*) i " t rslc.get0bject ("prfSectiozsn) + " + r s k .getstring ( "educa"iiontr) ; System.out . p r i r i t l n ( s t r ) ; \* \* Str = 1'" . t It is obvious from the above JDBC example that the returned attributes are treated as independent and not as pan of an object. Furthemore. using JDBC we c m not specify the behavior of the retumed objects. nor the collection type. Therefore, whatever we want to do with the result (the behavior) has to be hard coded as part of the application. defeating the notion of encapsulation and 00. The only requirement for the proposed query mechanism would be that dl attnbures and methods that participate in the que. must be publiciy accessible. In addition. the remm type class, in this case Std-Prf, must provide either a zero argument constructor. or a consmictor whose arguments are similar to the one specified in the altribute list. Following SQL's select-from-where foxmat, the general syntau for select statement codd be defined as follows: Chaprer 3 - OC Data Model 62 Select <expression> [<amibuteparne>] [{ ,<expression> <anribute-name> }] From ccategorp [( ccategorp } ] [Where <predicate>] . <expression> could be any expression that yields a value of type that is compatible wi th the tw - - of <amibuteaname>,In particular. it could be an amibuteTcname or a methnd d l . The Where part might be omiaed in which case al1 objects will be reuieved. 4 Framework for a DBMS Based on the OC Data Mode1 A DBMS that is based on the OC data model is used to manage datahases rhat are collections of interrelated caregories. which at the same time are collections of objects that are concurrently accessed by multiple users. To allow an efficient and concurrent use of the database, and at the same time maintain the consistency of the database, several issues need to be addressed. This section discusses the issues that aise when implemenring the conceptual level of a DBMS based on the OC data model. The impiementation takes into consideration aspects related to the traditional DBMS functionality like transaction and concurrency control, and others that are unique to the OC data model and its 00 nature. 4.1 Architecture The architecture. illus~atedin figure 4.1. is based on cliendserver model and is divided into three levels according to the AVSVSPARC standard: storage level, object level and application level. The storage level software is responsible for low level disk VO operations. while the application level deais with a single user's requests. In between is the object manager: which at the same time is divided into different submodules related to transaction. concurrent y control, recovery, security, caching, clustering, object Chapter 4 - Framework for a DBMS Based on the OC Data Model 64 manipulation and schema management. Since each submodule could by itself be a subject of a thesis, it is not possible to cover d l issues and implementation alternatives available for the different components. 1.2 Implementation Issues As mentioned in the OC data mode1 definition. objects in a database are uniquely identified by their identities. Because of this, persistent objects have two lunds of representation: in memory and in disk storage. The object manager handles users' request by transparent1y trançforming the object's representation from in-memory to oid or vice versa. A table hashed by oid can be used to access an object in memory given its identity. Object identifiers can be pointers to physical addresses or logcal ones. Using physical pointers makes object access much faster since the systern aiready knows the physical address. However, the system has to be provided with additional funcrionality to allow object relocation. Using logical pointers has the addirional overhead of maintaining a table that maps the logicd pointers to physical addresses. Therefore, reading an object might imply two readings. one to j e t the object's physical address and the second one to retrieve the object itself. Chapter 4 - Framework for a DBMS Based on the OC Data Model 65 Objects in a database based on the OC data mode1 are orgnited as members of persistent categories. Furthemore. categones are the on1y entry points to the database, and an objecr in the database cm be accessed through at least one of the categories. This fact c m be exploited by the DBMS by fint caching the categories into the usen' main memory, Applications I i Object manager 1 1 Storage manager Figure 4.1: Objcct manager Clustering 1 Cache 1 1 I c Disk Manager Cache A Three Level Architecture for a DBMS Based on the OC Data Model and then transparently redirecting object requests through them. Such rnechanism would provide an easy and transparent way of moving objects from and to the database. Chapter 4 - Framework for a DBMS Based on the OC Data Mode1 66 Furthemore progamrning langages provide container classes that are similar to the persistent categories used by the OC data model. What is required and to be provided by a DBYS is a mechanism that extends the memory resident containers in a way that allows them to span the structures of persistent categories. This mechanism of "tying" a memory resident container class with a penistent category would dlow the user to traverse the data in the database as if it were in memory. To allow this seamless inteqation of memory resident container classes and persistent categories, issues like buffenng rnechanism and transactional access need to be addressed. Databases are used to manase a huge number of interrelated objects. It is almost impossible to Ioad a database's content into the main memory. Therefore we need a buffering mechanism that transparently sends and brings data to and from the secondary storage. Such buffenng mechanism would use a cache to control the flow of data from and to the penistent categories. The first tirne a category is accessed the user is given a handle to the category. Alternatively. the category could be "tied" with an existing memory resident container object. The container object is then used to traverse the persistent catepory it is "tied" with as though the categoq was in memory. To achieve the transparent traversai of persistent categories, a buffering mechanism process c m be running that manages the cache and controls the flow of data. sending data from and to the semer as required. The other important issue that needs to be addressed is a mechanism for a transactional access of the objects in the persistent categories. It shouid Chapter 4 - Framework for a DBMS Based on the OC Data Mode1 67 be recognized that while an individual progamming environment accesses the data as if it has exclusive access to the data, the persistent collection of objects in the categories are shared resources and are subject to concurrent access (reading and writing) by multiple users. When uncontrolled this could create consistency problems to the database. Thus a concurrency control mechanism that prevents such problems from happening needs to be included. Such mechanism would need to take into consideration several issues. Categories are collections of objects with complex nature. As such. an objecr c m have attnbutes that reference other objects. Ropagating an object's lock request to al1 the other objecü that can navigationally be reached from it would significantly reduce the system's ability to handie concurrent requests. A rnechanism that locks objecrs only when the user accesses them is difficult to implement and is prone ro deadlocks. However. it significantly increases the number of processes that can run concurrently. Furdiemore. concurrency control mechanisms require a constant request-reply interaction between the user and the server. Dependmg on the way users interact with the server, the mechanism could create a network traffk overhead. One solution proposed in [3] uses a "semioprimistic" technique and attempts to reduce the overhead by rninimizing the number of messases that are exchanged between the two processes. In a "semi-optimistic" interaction, the user sends a lock request to the server. However, the server does not send a reply to the user unless the request cm not be satisfied. Chapter 4 - Framework for a DBMS Based on the OC Data Mode1 68 Related to the buffering mechanism and transactional access discussed above is the problem of obsolete cache. As mentioned above objects in persistent categories are subject to concurrent access by multiple users. This means that an object in a user's cache can be modified by another concurrently mnning user making the object in the fint user's cache obsolete. The solution io this problem requires a callback mechanism that allows the system to notify the user of the changes to the object so that the cache is updated. Chapter 5 5 Related Work 5.1 ODMG 2.0 Standard ODMG 1.0 is a srandard for object database management systems (ODBMS)proposed by Object Data Management Group (ODMG). The p u p is composed of representatives of the major vendors of ODBMS/ODM products. The standard [6] defines fiom the simplest aspects. object and literal. to the most complicated aspect of a DBMS that m u t be satisfied by products that comply with the standard. The major components of the standard are: Objecr model Object specification language Object query language C t t binding Smalltalk binding Java binding The object model defines the common data model, including the metadata, to be supponed by d l implementations. The object specification language includes an object definition language (ODL)and object interchange format (OF).Object query language is Chapter 5 - Related Work 70 a declarative language that is used for queryin; and updating database objects. The last three components define the object model's binding to three prograrnming languages: C u , Smalltalk, and Java- A data model for DBMSs should be characterized by organization structure. valid operations and constraints that must be enforced by the DBMS. The anempt by ODMG to define a standard for ODBMSs is a big step towards the fast development and acceptability of the technology. However, as important as it is, the standard is plagued by the same problems that are found in curent implementations of OODBMSs. The documenr States that "We have picked and combined the best features of irnplementations we had available to us". Current OODBMS'implementations are application oriented. As such, they address only aspects that are relevant in the context of the specific set of applications they are targeted for. Instead of attempting to integrate the different implementations, a better approach would have been to corne up with a new database model that bener inte-gates 00 concepts into the DBMS technology. A new data mode1 for new jeneration of OODBMSs that cm be used for any kind of application. The OC data mode1 does not define what an object is. It adheres to the generally agreed use of 00 tems by proCgamminglanguages. In this section. we describe some aspects of the ODMG data rnodel and their counterpart in the OC data model. The standard by ODMG is still a continuing work and as such it will be revised and enhanced. Chapter 5 - Related Work 5.1.1 71 Logical View The OC data model includes collections as the logicd view of a database. A database based on the OC data model is seen as a collection of cateeories. which are the oril y entry points to the database. The ODMG 1.0 states that "the application's object model is the database's (lo@cal)schema". 5.1.2 Categories vs. Implicit Extents The ODMG document states that "Many people believe that extents are essential ingredient of database query processing. Implicit extents and keys would be preferable to explicit mechanisms involving narned collections. yet there are challenging engineering issues that must be faced to rationalize these capabilities with the notions of transitive persistence and dynamic storage management herein presented. It first completely agrees with Our belief that collections are essential part of a DBMS. However, it diffen from our use of categories. There are, of coune. challenging issues that must be faced by OODBMS implementen. However, this is not a reason to shy away fiom their use. The use of categories, as descnbed in rhis document, has advantaps over the implicit extents. Some of the advantages are: Chapter 5 - Related Work 72 Categories are more than a collection of objects. They define the relationshps between member objects, and offer operations for object manipulation and intercategory communication. Implicit extents do not give the user the freedom to organize the database as he/she sees i t fit. OC data model allows objects to be memben of more than one category. which allows h e m ro be subject to different consuaint checks. Ths approach offen some support for object mi-gation. which is not availahle if we use implicit extents. 5.1.3 Attribute or Relationships According to the standard 'Two kinds of propenies are defined in the ODMG Object Model: atuibute and relationship. An atmbute is of one type. X relationship is defined between two types. each of which must have instances that are referenceable by object identifiers". It also States that "Relationships are not directly supponed by C++. Instead. they are supponed in ODMG by including instances of specific template classes that provide maintenance of the relationship. The relation iüelf is implemented as a reference (one-to-one relation) or as a collection (one-to-rnany) embedded in the objects." An attnbute might be used by the DBMS to enforce referential inte-gity, but it is still a normal attribue. The OC data model defines relationshps as properties of categones and not objects. As such. an application's data definition does not have to change to Chapter 5 - Related Work 73 accommodate the DBMS's requirements. Furthemore, embedding the relationship in the class definition prevents the user from using that particular attribute the same way as hejshe uses any other amibute. Relationships are more than direct references between objects. They are integnty constraints that must be enforced by the DBMS. Progamming languages do not support the notion of relationship. 4 standard for persistency of 00 progamming 1angua;e objects in databases should accept an application's objects as they are defined by the progamming language used. and complement them with the minimum possible extension without alterin; the way they are usually used. 5.1.3 Constraints The document says nothing about constraints that are neither relationship nor keys. It is the class designer's responsibility to include every constraint check as part of the class definition. This means that every simple rule change would require the recoding of the class definition, recompiling the application, and chanpng the schema in the database. Doing so is a very hi& pnce to pay because of the fact that changes to 00 systems, in fact to any sptem by that matter. are very expensive. A data model for OODBMS should make a clear distinction between the static and volatile parts of object definition. The OC data model associates constraints widi categones and not class definitions. Chanter 5 - Related Work 73 The ODMG 2.0 standard defines an object query language. In general quenes are rnainly used to select objects from collections, which categories are. Relational systems use SQL to access any object in a database. The language is relatively easv because of the uniform orgnization of the database. Tables are the only entry points to a relational darabase. Similarly. the OC data mode1 defines a database as a collection of categories, w h c h are collections of objects. Therefore. it lends itself perfectly to the use of a query laquage in the manner SQL is used by the relational mode]. The same can not be said about ODBMSs based on the ODMG 2.0. .-ln 00 select statement has five parts and is of the following form: (collecrionType<class>) (CI, C2,C3,.... C,).select (atmbuteList. predicate) The "collectionType" and "class" specify the type of collection used as a container and the type of objects to be r e m e d respectively. C, , l<=i<=n, indicate the categories that participate in the query. The "attributeList" is a list of attribütes that togeiher will f o m objects of type "class". The "predicate" is used to filter the objects to be retumed. ODMG's OQL is defined to "query denotable objects starting from their narnes, w h c h act as entry points into a database. A name may denote any kind of object, Le., atornic, structure. collection. or literal". The lack of uniformity of input objects makes the use of OQL in ODMG 2.0 Iess intuitive. Chapter 5 - Related Work 75 5.1.6 Keys Keys are used to uniquely identify objects from a collection of objects. In the OC data mode1 keys are declared against categones, which by definition are collections of objects. The ODMG standard States that 'The scope of uniqueness is the extent of the t type must have an extent to have a key". Unlike ODMG 2.0. in OC data mode1 collections and keys are an integral part of the database. p . thus a Cha~ter5 - Related Work 76 5.2 Unified Modeling Language (UML) UML[16] is a modeling language to express the results of an 00 analysis and design. It Inc!-des dbgrzxs t~ rtpresmr c!sses, ;sr cases, actP.5:~ diapïïs, ... ce.Li c s i i r r ~1t6 the OC data model and the ODMG 2.0 standard. UML is not concemed on how to design and develop an OODBMS.However. as a general purpose 00 modeling language, it can be used to draw the dtagams of an 00 database model. Specifically class diagrams. which are used to illustrate class models, are cornfortably similar to database models. In this section we will illustrate how UML notations. instead of EER diagram, could have been used to express the design of most of our examples. A class d i a C mdescribes a system in terms of objects and the relationships among them. As mentioned before, a database is a logically organized and stnicnired collection of intenelated data objects stored together. The class d i a a m modeling technique includes notations to express the objects design (atuibutes and operations) and the relationships arnong them. The two principal h n d s of relationships that can be established between objects are associations and subtypes. Associations are used to express referential integnty constraints, including cardinafity ratio (multiplicity), between participating objects. Subtypes specify the IS-A relationship between objects. For example, the one to many worksFor relationship (figure 3.1) between employees and departments c m be Cha~ter5 - Related Work 77 represented as an association between objecu of type Employee and Department. (figure Multipiicity Depanment - id - name - description - name - daceOtBirth - totalEmployees(j Subrype Operations 1 Manager 1 1 on- Manager - bonus - mnuaiBudget performance { if 3lanager.performancc is "poor", then Manager-bonus m u t be zero 1 Constraint The above example also illustrates the notations to express subrype relationships and consaaints. As with EER,the OC data mode1 cm also be easily denved from a database's class dia_=. Chapter 6 6 Illustration of an Example Application using OCS T k iilfûrrîlâüûii in L?S xctiùn prcseriü exaïpie àppEcatiun ihit iiiustrates Liic vuious facets of the OC data model. and describes the implementation aspects of the OCS.OCS is a package based on the OC data model that provides higher level abstractions for manipulation of typed persistent categones. and for stable storage of objects. It uses Java as the progamrning langage and 0bjectstore3 as the persistent store. Since the objective of the thesis is rather to define a data model and prove that it is realizable, we used ObjectStore as the repository manager. The public interface of OCS consists of a set of operations rnostly oriented towards inserting and reuieving of objecü from categories. The basic operations are operations that add. select, and rernove a single object. In addition. we have included collection-oriented operations that do the sarne. It also includes operations needed for creation and removal of categones. The system has also implemented operations to dynamicaily add and/or remove relationships and other consuaints from catepries. The nvo main classes of the OCS package are ObjectCategory and Category. The ObjectCategory class is used to create and manipulate categones, while the Category class is basicaily used to insert, retrieve and remove objects. The system maintains references to al1 categones that are created. - - - ObjectStore is a registmd nademark of ObjstDerign Inc. 78 Chapter 6 - illustration with Example 79 6.1 The Application Let us imagine we are developing a database for a University. The main players in a University are the snidentr, ~ h profersors. e o k s t ~ f memhers f znd the cclAnles cffe:eC by the University. Usuaily courses have requirements. and they are divided into sections and taught by different professors. Funhermore, some of the students work as teaching assistants helping students and marking p d e s . The EER diagram for the database. illustrated in figure 6.1. is composed of seven entities (Course, Section, Student. TA. Staff. Professor and Employee). The relationships defined between the entities are: a course has one or more required courses a section belongs to a course. and a coune has many sections a student takes one or more sections a TA assists in only one section. and a section may have many TAS a TA is a student as well as a staff a professor teaches one or more sections a professor is an employee a staff is an employee staff and professor are disjoint (not overlapping) Chapter 6 - illustration with Example 80 requires c Course Figure 6.1: Partiai EER Diagram for a University Database Ones we define the EER dia*-, we need to decide and define the classes and categories to be created and maintained by the database. For this application. we define a class (Course. Section, Student, TA, Professor, Staff, Employee) per entity. The Professor class and the Staff class would be defined as subtypes of the Employee class. The TA class would inherit from the Student class and the Employee class. For instance, using the Java Chapter 6 - IlIusuation with Examde progarnming language the definitions for Empioyee and Professor classes would look like the following: public class Employee Scring String String String double { firstName; las tNa,.ne ; no ; phone ; salary; Ehnployee (String no, String firstName, S t r i n g lastName) { tnis .no = no; this.firstName = firstName; this.7astNarne = 1astName; p i b l i c void setphone (String phone) { this.phone = phone; ) public String getPhone O { return phone; ) public void setsala-ry (StrLng salary) { this.salary = salary; } aublic double getsalary O { return salary; a. public class String String Vector Professor extends Employee education; tenure ; sections ; 3rofessor (String no, String IastName, String firstName) { super (no, lasrName, f irstxane) ; this-section = aew VectorO ; { } Chapter 6 - Dlustration with Example 82 public void setEducation (String education) { this-education= education; } public String getEducation ( ) { return education; gublic void setTenure (String tenure) { this.tenure = tenure; ) public String getTenure ( ) { return tenure; } public boolean addsection (Section section) { sections.add (section); ) public boolean removeSectio3 (Secion section) { sections.remove ( section) 1 } The next step is to define the categones that will contain the objects. For this application. we create one catepry (Courses,Sections. Students, TAS, Professors, Staff. Employees) for every class defined. The category hierarchy would resemble the subtyping hierarchy between the classes. Therefore. the category for teactung assistants will be a subcategory of the Studenü category and the Staffs category. In addition. the categories for staff and professon will be subcategories of the Employees category. Using the category specification langage listed in appendix A. for instance, the Employees category and the Rofesson category are specified as follows: category Employees { extent s e t Ernpioyee indexekey employeeNo; ernp loyeeNo; category Prof e s s o r s extends m l o y e e s : extent s e t Professor; relationshig one2Many Sections link sections inverse professor; 1 Chapter 6 - nlustration with Example 83 The Employees category is defined as the container for objects of type Employee. The collection will be indexed by employeeNo, which should be unique within the category. The Professors category is defined as extending the Employees category. Therefore, al1 objects in the Professors category will automatically be members of the Employees catepry, and the key constraint, employeeNo. defined on Employees category would also apply to Professors category. Furthermore, the Professors category defines a relationship with the Sections category through the sections and professor attributes found in the Section and Rofessor class respective1y. 6.2 Defining Categories Using ObjectCategory Class The OCS package provides the ObjectCategory class. which defines operations that are not specific to any category. The operations are used to manage categories. They include methods that add. get and remove categories. All the methods are s t a ~ cThe . class provides creureCategory(), getCarego-l) and removeCaregory() operations to create, get and remove a category respectively. Since a Category instance is an object by itself it can be stored in the database like any other object. The createCaregory operation requires two arguments: category name and class type. An overloaded createCaregory operation requires a third argument, an array of category names, that specifies the category's supercategones. The operation raises a Catego~NumeAZrea&Exisrsexception if there exists a category with the same name. The other two operations only require the Chapter 6 - Dlustration with Example 84 category's name as ar-miment. They both raise the CategoryNameNatFound exception if a carepry by that name could not be located. The class aiso defines static constants that are used by the system. The removal of a category implies two rhings: removal of al1 objects from the category and iü subcategories. and removal of the category and its subcategories from the database's schema. For instance, using the ObjectCategory class we c m easily define Employees. Sections and Professors categories as follows: F u b l i c class Tes;CreateCacegory { ..i / create zhe Empioyees category C a t e g o r y ec = ObjectCategory.createCatego~(db, "FmpIoyeesn, "Em-ployee") ; create the P r o f e s s o r s category Category pe = ObjectCategory.createCatego~(db, "Professors", nProfessorn, "Emplyees"); /i ;/ create the Courses category Category cc = ObjectCategory.createCategory(db, "Coursesn, "Course"); The createCategoq(db. categor\;Name. className) method and its overloaded version createCatego~(db.caregoryNnme, className. superCaregorieshiame create a persistent category namzd caregoryName in the db database. The category is typed to c1acsNume and inherits from the categories specified in superCategoriesName. Only instances of the cl~ssiiiarneclass or its subclasses may be inserted into the category. A category groups Chapter 6 - Illustration with Exarn~le 85 objecü of the same type (in the sense of the isInstanceOf() method of java.lang). The method throws a Carego~NameAlreadyEristsErceprionif a category by the narne categoryNmne already exists in the database. The argument db is a reference to the database where the category is ro be created. The signatures of the methods crearelalegory gel Caregory and deleteCategoy are as follow s: : public static Category createCategory(Database db, String categoryName, String className) throws CotegoryNarneAlreadyExistsException public static Category createCategory(Database db, String categoryName, String classNarne, String superCategoriesName) throws CategoryNameAlreadyExistsExceptFon public static Category getCategorv(Database &, String categoryName) throws CategoryNotfou,??dException public static void deleteCategory(Database db, String categoryName) throws CategoryNotFoundExcepcion, ConstraintViolationException 6.3 Data Manipulation The Category class is the most important class of the sytem. It provides most of the functionality required for &ta manipulation, including maintenance of the integnty Chapter 6 - ïllustrauon with Example 6.3.1 86 Inserthg Objects The Category class implements operations that are used to add objects to a category. Two rnerhods are implemented: add (Object obj). which inserts a single object to the category. and add(C01lecrion c) that adds a collection of objects. public void add (Object obj ) tiirows WrongObjectTypeException, ConstraintVio~a~ionException public void add (Collection c ) throws WrongObjectTypeException, ConstraintVio~ationExceptioc Both methods check whether the object or objects in question are instances of an acceptable class, and raise WrongObjectTypeExceprion if not. For instance. to insen a new Rofessor object to the database we first get a reference to the category and cd1 the add metfiod as follows: public c l a s s TestAdd { *. / / Get a Catego-T handle to the %ofessors category pc = ObjectCategory.getCategory(db, "Professors"); / / C r e a t e a new Professor object 2 r o f e s s o r prf = new Profes~or(~Mark","Rider",~Phd"); / / P.dd t h e o b j e c t to t h e Professors c a t e g o r y pc .ad6 ( p r f 1 ; Chapter 6 - Illustration with Example 87 63.2 Retrieving Object. The system provides a mechanism for reuieving objects through queries or iterators. Query is performed by passing a predicate expression as an argument to the selecr operation of a category object. p h l i c Set select (String predicate) A category applies the predicate expression (an expression that evaluates to a boolean result) to ail elements it contains. including objects in its subcategones. and returns a collection of al1 objects for which the expression results m e . For instance. the following example retrieves d l employees whose lasr narne is "Mark". Since Staff and Rofesson are subcategories of Employees. the query would search in al1 three categories. public class Testselect { a.. Category e m p = Ob j ectcategory . g e t c a t e g o r y (a, "Employees") ; Set marks = emp.select ("lastName == \"Mark\"") ; If the sarne method were sent to the Professors category, it would search in the Professors category only. The only requirement is that the attribue lasrName must be public. Ail attributes and rnethods refened to in a predicate's expression must be public. If a method is specified, then it rnust r e m something. The select rnethod returns a Ser thar contains the objects that satisfy the predicate. If the category does not find any matchmg object, it Chapter 6 - Illustration with Example 88 r e m s an empty Set. An equivalent get operation retrieves the first object thar satisfies the predicate expression. If no object in the category satisfies the predicate. the method returns null. p u b l i c Object get (String predicate) Objects can also be retrieved through the search operation. Search allows die user to find an object without pnor knowledge of the its caregory membenhip. Cnlike the selecr and ger operations, which retneve objects from the category receiving the message, the result of search operation is the union of al1 objects of type classType that satisfy the predicate. Al1 categories that store objects of type classType are searched. public Set search (Class classType, String predicate) The clussType pararnerer provides the context in which the predicate should be evahated. The message c m be sent to any one of the categones in the database. For instance. the following instruction retrieves al1 employees in the database whose last name is "Mark". Public c l a s s TestSearch { ... Category std = Objec=Category.getCategory(db, 'Studencs" ) ; Sec narks = siC.s e a r c h ( c l a s s . for?Jane ( "Enployee" ) , "lastName == \"Mark\""); Chapter 6 - Illustration with E x m l e 89 It gets the sarne result as the above select instruction. However, it is not as fast as the above one since it has to f i t determine the search strategy. To eliminate duplicates and minimize processing, the progam first srarts anaiyzing the most specialized categories. An alternative way of accessing objects in a category is dirough the Iterator ciass, which helps navigate through the category's objects. The iteratorf)method of the Category ciass retums a hande to an Iterator instance. The retumed Iterator object is an instance of the OCIterator class thar is an irnplementation of the java.uti1.Iterator interface. Iteraton can be used ro traverse categories as well as to remove objects from categories. The signature is as follows: For instance, the following code retrieves ail objects in the Employees category and prints them to the standard output. public class TestIterator < p & l i c s t a t i c void main{String argv[j) { *.. Iterator i t r = 0bjectCategory.getCatego-~(db, "Employees") . iterator ( ) ; w h i l e (itr.hasNext()){ Employee emp = (Employee) itr.nexc(); Syscem.out.println(emp.toString()) ; 1 Chapter 6 - Illustration with Example 90 6.3.3 Removing Objects Removing objects is done through the operations of remove and removeA11. In both cases, if the object being removed is not a member of any other category, it will automatically be removed from the database. The operation removeAlU l removes al1 elements from the category. However, it does not remove the category from the database. It only removes the objects from the category. If the removal of an object violates a consrra.int. the rnethods throw a ConstraintViolarionErceprionexception. The signatures of the remove and removeAl1 methods are: p u ~ l i c~ o o l e a nremove (Object obj) throws ConstraintViolationException public nooiean remove (Coliection c ) throws Cons t r a i n W i o l a t i o n E x c e p t l o n public 'Doolean removeAl1 ( ) throws ConstraintViolationException 6.3.1 Modifying Objects The system maintains the database's integrïty automatically as objects are added andfor removed from categories. However, it is the user's responsibility to cal1 the update method when a persistent object's memben are modified. The update method is needed because OCS being a Library has no way to automatically detect when changes are made ro an object. Furthemore, objects c m be members of more then one category. This Chapter 6 - Illustration with E x m l e 91 means, whenever an object is modified, dl consuainü defined on al1 categories the object is member of must be checked. OCS handles thîs by keeping. with each persistent object, a list of the categories the object is member of. Whenever an object is inserted, modified or deleted the list is consulted to make sure that al1 constraints are enforced. For example, suppose professor Mark adds "~~95.501" ro its list of courses. To make sure that the database's consistency is rnaintained the application should cail the updare method as follows: P ~ b l i cclass Test'Jpdate { ..a P r o f e s s o r p r f = ( P r o f essor) Obj e c t c a t e g o r y . g e t c a t e g o r y (db,n?rofessors'' ) .get ( last Name == \ " M a r k i , " " ); Course crs = (Course) ObjectCategory.getCategory(db, n C o u r ~ e ~ *get l ' ) ("courseN O == \"cs95.101\""); p r f .addCourse ( c r s ); / /cal1 update on the rnodif ied oDject prf .update(); The updare method is defined in the OCPenistent class descnbed in section 6.5. There are different mechanisms to enforce integrity constraints on a database. Some special integrity consaaints could be supported automaticaily by the system whereas Chapter 6 - Illustration with Example 92 othen can be added to the database through a mechanism that dlows users to express and enforce new integnty rules. Constraints could be violated only by operations that modify the state of the database (updates, inserts and deletes). An object's operation is said to satisfy its constraints if its insertion, modification or removal does not violate the integnty of the database. Such operation is said to be le& OCS provides facilities to specify and enforce referential integnties. keys. domain integnty constraints and tri,,ouers. 6.4.1 Defining Relationships Relationships are a special case of constraints cdled referential integnty constraints. Referential integnty constraints are one of the most imponant and most frequently used rnechanisms for maintaining a database's integnty. The purpose of referential integnty constraints is to indicate that a reference to an objecr is legai only if the referenced object exists in a particular collection. For example, a referential integnty constra.int between the Sections category and the Professon category could be that, the professor attribute for a coune object should be limited to one of the professors in Professors catepry. The inverse is, that any section in the S ~ C ~ attribute U ~ S of a professor object must be a member of the Sections category. Referentiai integrity constraints are enforced by the system with a liale input from the user. The user's responsibility is limited to specify the nlated categories and the Chapter 6 - Illustration with Exam~le 93 attributes through which they are related. Relationships are defined between categories. Only binary relationships are supponed. The amibute on the many side of a relationship should always be of type Collection or one of its subclasses. Four classes that represent the four types of relationships that are commonly used are implemented: one-to-one, one to-many. many-to-one. and many-to-many. The following is a panial listing of the Relationship class. public class Relationshig { orivate String name; grivate int type; private String attribuceName; private string relatedCategoryName; private String inverseAttributeName; Relationshio (String nm, i n t type, String atrrun, String rcn, Strlng i n v - a t m ) { this.name = nm; A category can be related to more than one category. One instance of the Relationship class is maintained for each of the relationships the category is involved in. The relationship type is consuained to be OneIOne, OneZMany, ManyîOne or iMany2Many. The constants are defined in the ObjectCategory class. The components are passed as arguments to the addRelationship method. public void addRelatioaship (String relationshipName, i n t relationshipType, String ~ t t r i b u t ~ a m eString , Chapter 6 - Illusmtion with Example 94 relatedCategoryName, String inverseAttributeName) throws, RelationshipNameAlreadyExistsException, RelationshipAlreadyExistsException For instance, the following statement declares a one-to-many relationshp named R S e c between the Professors category and the Sections category through the inverse atrributes of sections and professor. public c l a s s Tes tRelationship { a.. / / Get a handle to tne Professors category Category pc = ObjectCategory.gecCategory(db, " Prof essors.') ; / / EstanLisi., relationship with the Seccions catego-ry pc . addPeLationship ( " Pr-Sec" , Objectcateçory .OrieSMany, "seczions", "Sections", "professor"); Relationships need to be specified only once. The system inserts and/or removes die inverse pan of the relationshp autornatically. For instance, the relationship between Sections and Professors categories need be specified only once. either through the Sections category or the Professon category. Relationships are uniquely identified by their names, which is used as the only argument to the removeRelarionship method. public void removeRelationship (String relationshipName) throws RelationshipNotFouridException The above inserted relationship is removed from the database with the following staternent: Chapter 6 - Illustration with Example 95 ... 0bjectCategory.getCatego-ry (db, " P r o f essors " ) . removeRelationship ( " Pr-Crs ) There are other four relahonship-related classes irnplemented by the system: Relationship 131, Relationshipl2M. RelationshipMZ 1 and RelationshipM2M. Thev correspond to the four types of relationship the system supports. They ail implement the Relationshiphterface interface. Whenever required, the system dynarnically creates an instance object of the right relationship class and calls the object's validate method. 6.42 Defining Keys Keys are relevant for any DBMS that uses collections. They allow objects to be uniqueiy identified given the values andor States of one or more of their attributes. OODBMSs use object identities to uniquely identify objects. However. those identities are usually hidden from the user. OCS offen a mechanism to add and remove keys From categones. Keys in a category are uniquely identified by their narnes. They can consist of one or more attributes. The addKey method is used to add a key consuaint to a category. public void addKey (String keyName, String[] atrributrnames chrows KeyNarneAlreadyExistsException The method takes as arguments the narne of the key, which shouid be unique within a category, and an array of attribute names. Only attributes that are defined by the Chapter 6 - Illustration with Example 96 contained class are accepted. Attributes that are part of the key should al1 be publicly accessible. The removeKey method is used to remove a key from a category. public v o l 6 removeKey (Stricg keyName) zhrows KeyNo tCouncIExc ep tion For instance. to make sure that the ernployees' no is unique through the database we define a key on the Employees category with the attribue employeeNo thar is defined in the Employee class. public c l a s s T e s t K e y { .* String!] keyAttributes = {"employeeNou}; 0bjectCategory.getCategory (db, " b ~ l o y e e s ".acdKey("BnployeeNumber", ) keyAttributes); From now on. the system makes sure thar that the employeehio is always unique when an employee is inserted to Employees, Staff or Professors categories. or when an employee object is updated. The system uses Java's reflection API to dynarnically retrieve amibute values. 6.4.3 Generai Purpose Constraint Definition Keeping faith with the objective of the thesis, a new and general mechanism of defining constraints has k e n implemented. A consaaint is implemented as a class definition that implements the Constrainhterface interface. The interface defines the only method that Cha~ter6 - Uustration with E x a m ~ k 97 has to be implemented by conscra.int classes, validare (object, when). The parameter objecr is a reference to the object in question. The parameter when contains a value that specifies the current phase in the object's processing. The current phase could be Before-Insen, rifre-sen, Before-Remove, etc. The constants are defined in the ObjectCatgory class. public void validate (Obj ect ob j ect, i n t when) throws ConstraintViolationException. X consuaint is a predicate that has to be complied with by di objects in the category. A constraint could range from a simple domain check. like the fact that an employee's salary has to be above or equd to some minimum salary, to a more complicated one, like conditional constraint. Because a constraint is a full-fledged object by itself, its definition is not lirnited by the expression construction rules of the DBMS.The special case of NOT hWLL consuaint cm easily be enforced using dus general mechanism.For each consuaint. a class that implements the Constrainthterface interface should be defined. Once it is defined. the oddConsrrainr method should be invoked against the category where the constraint is to be enforced. p a b l i c void addCons traint ( S t r h g constName, S t r i n g className, i n t when) throws Cor,strainiNameAlreadyExistsExceptior, The parameten are the constraint's name, the name of the class that defines the constraint and timing. The method raises a ConsnaintNameAlre~EristsErcep~n exception if die Chapter 6 - Illustration with Example 98 constraint set of the category aiready includes a constraint by the name specified. Every tirne an object is added to the category, or whenever an object that is already in the category is modified or removed, the system, at run time, creates a new instance of the consuaint class and calls its validate method. The validate rnethod of a consuaint object should raise a ConstrainfViolarionExceptionto notify the system that a constraint has been violated. For instance, to enforce the constraint that an employee's salary should not be less than the minimum salary. let us say $7.00 an hour, we first define a class that implements the ConstraintIncerface interface. public ciass MinSalaryConstraint implemenis ConstraintInterface { S. i,/ implement the validate rnethod tnat will / / autonatical& be calieo by the system p u ~ l i cvalidate (Object obj , int timing) throws ConstraintViolationException { . - (((Emp1oyee)obj) ï .getSalary() < 7 . 0 ) throw n e w ConstraintViolaïionE~cep~ion(~~Salary can n o t 'De less than sevenn) 1 .%€ter compiling the above class. we register the b i n q file with a specific category by calling the addconsuaint. For instance, if we want to apply the consuaint to ail employees then we send the message to the Employees category as follows: Chapter 6 - Illustration with Example 99 The system stores the constraint's name, the constraint's class name and the timing information only. Ones the constraint is added to the category. whenever needed the system dynamically creates an instance of the class MinSalaryConstraint and calls its validare method passing the object to be checked as an argument.It also traps the ConstraintViolationE~ceptzonthrown by the MinSalaryConsuaint object, which it passes to the user's process. The sarne constraint can be insened into different categories. or added to the same category with different name and timing.The only restriction is that the constraint's narne within a category should be unique. The rernoveConsrrainr method removes a constraint from a category. if the constraint in question is not found. the method raises a ConstraintNotFoundException exceprion. p b l i c void removeConstraint (String consrname) throws ConstraintNotFoundException Triggen. like constraints. are objects by themseives. Therefore, they allow us to enforce integrity rules that are not automatically enforced by the system. A trigger is always associated with a constraint in a category, and it is fired whenever the constraint evaiuates to tme. A constraint is said to evaiuate to true if it raises a Chapter 6 - illustration with E x m l e 100 ConstraintVioZarionLrception exception. The TriggerInterface defines the only method that has to be implemented by trigger classes: p u b l i c void fire (Object o b j ) throws ObjectCategoryExcepcio~ The operations addTrigger and removelrigger are used to add and remove a trigger respectively. A tngger can be associared with a constraint that has already been added to a category. Xltematively, the tngger and the consuaint can be inserted to a category at the same tirne. The uigger execution mechanism is basically the same to the one used for constraints. However. before the tngger is fired the system makes sure that the constraint anached to it raises a ConstraintVioiationException.Triggers within a category are uniquely identified by heir name. Assuming that we have already defined a uigger class called SetMinimumSaIary, the following instruction attaches the above-definedconstraint MinSalaryConsaaint with the SetMmimumSalary uigger, and registers it with the Ernployees categoq. O b j ecrcategory .getcategory (db, "Zmployees") .addTrigger ( " R e c t i f y M i n i m m % h r y n "SetMi,?imumSalaryN, "MinSalary", 0bjectCategory.Before-t'pdate) Chapter 6 - illustration with Exam~le 6.5 101 - Defining Persistent Classes OCPersistent Class As rnentioned above, OCS has no way to automatically detect when changes are made to an object. The OCPenistent class defines the annbutes and methods that are required by the system for penistent objecr manipulation. Ai1 penistent classes must inherit from the OCPersistent class. The class defines an atuibute. mernbershp. and a set of methods. From the user's point of view the two important methods are the no-argument consmictor and the updare method. The updare method is used by the user to notsfy the system of modifications made to persistent objects. The following is a partid listing of the OCPersistent class. public abstzacc class OC?ersisten= private OSVector x ~ ~ b e r s h i p public OCPersistent() rhis.menbership = new OSVectox(); 1 public final void update ) throws ConstraintViolationException ( Chapter 7 7 Conclusion OODBMSs have corne a long way fwni a simple mechlnism fer ~ h estrr-gt r e ~ ~ c ~ d of penistenr objects to a DBMS with many of the facilities that are required by an OODBMS. However, their development and acceptance have been hindered by many factors. The lack of a standard data model which makes them harder to leam and use. and the fact that they are targeted towards a specific set of applications have been two of the major limitations of OODBMSs.Their target area. the "new" applications. excludes the larpst usen of databases: traditionai business applicauons. However. in the long mn there is a need for single database systems that satisfy al1 kinds of a company's database requirements. Few applications fit neatly into just one category [l]. Current implementations of OODBMS are based on the concept of the 00 data model. The 00 data model is not characterized by niles that define the structure, vdid operations and constraints on the context of databases. Therefore. curent OODBMSs are rather characterized by the underlying 00 progamming langage upon which their implementation is based and by the target application. A new data model is required for new kind of DBMS: A DBMS that is not application-oriented, and inregrates the best features of DBMS technology with the 00 concepts. Cha~ter7 - Conclusion 103 This thesis attempted to achieve the above objectives by defining a new data model, Object Category data rnodel. that is independent of progamming languages and adheres to the 00 concepts alrnost al1 OODBMSs agee on. The main characteristics of the data model are: It introduces a new concept, category, and it distinguishes it from the concept of class. A class represents the set of al1 possible instances. while a category is a collection of actual instances of a class in a database. It also defines operations on categories. It is fully 00. because it suppons the 00 concepts as they are used by 00 progarnrning ianguaps. It can easily be denved from the EER data model. Ir makes a clear distinction between class definition and integnty constraints. Integrity consuaints, including relationships, are defined against categories. This layered approach, separation of application aspects from database aspects, provides increased data independence and flexible design approach. The seamless integration of pro,oramming languages with DBMSs. as preferable as it is, should not corne at the expense of core advantaps that are usudly expected from a DBMS:data independence. progamming language independence, etc. Different programming languaps support àifferent type construction facilities. Therefore. the tighter a DBMS is to a progamming Chapter 7 - Conclusion 104 language the further it is from the other propmming languages. Databases based on the same data model should provide the same interface independently of their implementation programming language and independendy of the programming language used to develop the application. Objects in a database that is based on the OC data model are organized as memben of categories. The use of category by the OC data model provides the usen with a clear and consistent view of the databases. It also lends itself to the use of a query language much similar to the way SQL is used by relational systems. Categories are the only entry points to the darabase. Funhermore, the Category interface is provided with operations that are used for insertion. retrievai and removal of objects as well as inte-gity consuaints. The thesis defined a new way of executing queries that is in sink with the 00 nature of the data modei. It also outlined a framework for a DBMS that is based on the OC data mode1 and addressed the issues that need to be taken into consideration for its impiementation. The architecture uses the client/server paradigm. and it divides the server side of the system into two major parts: object manager and storag manager. The storage manager deals with low Ievel disk Il0 operations. The object manager is composed of different submodules that perfom specific tasks iike transaction, concurrency control, etc. Objects in a dalabase based on the OC data model are uniquely identified by their identities. The object manager translates the objects' representation fiom in-memory address to oid and vice versa. A mechanism for a transparent access of Chapter 7 - Conclusion 105 penistent categories as if they were in the main memory was also addressed. Two major issues were discussed: buffering mechanism and transactional access of objects in the database. The buffenng mechanism deals with the uansparent flow of data from persistent categories to memory based container classes and vice versa. It was also noted that although usen access objects in penistent categories as if they were the only uses and as if rhey have an exclusive access to it, objects in categories are subject to concurrent access by multiple usen. As such, a concurrency conml mechanism is required to prevent consistency probiems. The mechanisrn takes into consideration the complex nature of objects and the problem of obsolete cache. We also discussed some aspects of the ODMG data mode1 in contrast to the OC data model. Finally we illusuated the OC data model by describing an example application that uses the OCS package. OCS is a Java implementation package of the OC data model. The package includes the ObjectCategory class that provides facilities to create, get and remove categones from databases. A Category class rhat implements the Categoryhrerface interface is also provided. The interface defines the operations that allow usen to insen, retrieve and delete objects. It also provides methods that are used to specify constraints. whch are automatically maintained by the system. Four kinds of constraints are supported by the system. Constraints and triggen are defined as classes allowing the user to specify and enforce almost dl kinds of constrainü. The system aiso Chapter 7 - Conclusion 106 suppons the four kinds of relaûonshps: one-to-one, one-to-many-, many-to-one. and many-to-man y, and key constraints. 7.1 Future Work OODBMS technology is a relatively new entrant to the DBMS field. As a new area, it is almost impossible ro list d l aspects of OODBMS that need further research. There is not even a univenally agreed and uniform use of the term OODBMS. In fact. there is very little m e consensus and much disagreement. even at the most basic level [8].Therefore, we will list only those aspects that are very important to the completeness and improvement of the OC data model. 7.1.1 Query Optîmization Because of the way relationships between objects in categones are maintained, dirough direct pointers, andor because different users rnay have different points of view when looking at a database's schema, queries can be specified in different ways. For example, to retrieve employees who work for a certain depamnent we could send the request to: 1. Employees category. This would require a traversal through al1 the employees. unless the Employees category maintains an index on depamnent attnbute. 2. Departments category. This would require fint locating the depamnent, which is faster, then retrieving the employees following its links. Chapter 7 - Conclusion The question is how could a que. 107 optimizer rransform the inefficient form of a query into the correspondmg efficient one. Unlike the relational model. in which relationships are rnaintained dirough key and foreign key attribue values. relationships between objects are established and maintained through direct pointers between participating objects. The user or the DBMS can exploit t h s aspect of the relationships for query optimization. It is Our belief that, because of the organization of objects through categones (as tables are used in relational systerns) query optimization methods used by relational systems could easily be adapted and used by DBMSs based on the OC data model. In addition. pnor knowledge of the schema and the way the database is organized can be used to optimize queries. 7.12 Object Migration An object in OODBMSs is an instance of a certain ciass that is defined by the application program. .-Zn object has identity that stays the same through the object's lifeùrne. However. in the real-world applications, objects do noi always belong to the sarne goup of objects. For instance, in a company's organirational hierarchy a secretary could, in the future. becorne a manager. 00 d a ~ amodel does not allow such change of type. The mikgration of an object from one group to another without changing its identity, is an important aspect that should be supported by OODBMSs. The OC data mode1 inherently Chapter 7 - Conclusion 108 supports some level of object migration by virtue of separaion of object definition from constraints. Most of the times object migration is required to accommodate changes on constraints that must be enforced to one goup but not to others. For instance. a distinction between an employee object and a manager object might be, that the manager object should be related to a department through the attribute manages. The OC data model supports a Iimited object migration capability without type change. However, because of its importance. there is a need for an in-depth research on this area. The research could focus on object migration in p e r d and in particular in the context of OC data model. 7.1.3 Views Views are a very essential part of DBMSs based on relational model. Views. in addition to data independence, 'provide different applications with different views of the same database. The tight integration of programming languages and DBMSs,as useful and attractive as it is, raises some important questions. In particular. an application program (by definition) is intended to solve some specific problem, whereas a database (by definition) is intended to solve a variety of different problems, some of w h c h rnight not even be known at the time the database is established [8]. Views are the result of requesü to the database ihrough predicate expressions and quefies that are permanently remembered. îhey allow us to define different extemal views for different usen, and Chapter 7 - Conclusion 109 lirnit their access to the database. An enhancement to the application level interface could be to complement it with a view definition and manipulation mechanism. Category Specification Language (CSL) category <category_name> extends ecategory-narne- lis^ set cclass-name> [ eaccess-mode> ] the name of one of the indexing methods provided by the DBMS Annex A - CSL 111 the oame of one of the hashing functions provided by the DB-MS dist-declaration> <clas-name> corder-decl aration> corder-lis<attri bute-name> corder> ASC ) DESC array-dec laration> array eclass-name> cattri bute-list> uelationship-declaration~ relationship aelationship-type> aelated-category-name> link <atmbute-name> inverse erelated-attri bute-nanie> < relationship-type > key cattribute-lis> Annex A - CSL dgger-name> aarne> cwhen> before 1 after <name> <alpha> [ <string> ] <string> Ccharacten [ smng ] cc haracter> c a i p h ~1 <&@D 1 csymbols> <alpha> apper-case-lettep 1 clowe-case-letten cupper-case-letter, upper case leeter from A to Z dower-case-letters> lower case letters frorn a to z <di@ decimal digits from O to 9 <sysmbol> my other symbol rhat could be part of a name OCS Code Source i ne LC1 ûbjec tCacegory impiemencs [ne s w i c meriiocis thar creare, remeve and remove categories from a database. It also defines some constants that are used throughout the package. package ocs .oc ; corn. odi.*; static static static static güjlic static public static sublic sublic public public public public puhiic public static static static static final rn: Jefore-Izsert = I; f 3 a l ixc Afser-fnsert = 2; fizal in= Before-Xodify = 3; finai iat After-Modify = 4; final int Jefore-Reiove = 5; final ia= Afcer-3emove = 6 ; fical fical fical fxal i2= One20ne = I; 13= One2Mafiy = 2 ; i3= Many20ne = 3 ; int Many2Many = 4; i : tke variable tka= contaics al: stacic Cacegories ca=eçcries; the categories in the dacabase / / creates ~ h root e ectry to the database s t a c i c Caïegoriss InitiaLite (DataDase db) < E gets =Re r o o c o ~ j e c tof al1 :Be categorles categories = (Cacegories) db.get3oot("Category0fCa=e~oriesn); retc,r, cazegories; 1 catch (Databasei3ootNo~Fo~dZxception e) { / / creates the root a b j e c c if it doesn't exisc :'/ Annex B - Code Source 114 categories = new Categories ( ) ; db.createRoot(nCategoryOfCategories". categories); retu-m caregories; ," roiUrEs a l 1 ca=egories Ln =he database scaric Categories getcacegories (3atabase db) { try ! categories = {Categor~es) cb.get300t("Ca:egoryOfCategoriesn); retz-Tn cateçories; 1 cacck ( 3 a c a ~ a s e R o o t ~ o t ~ o ~ ~ d E x c ee p) t{i o ~ ret2rn initialize( & ) ; : / creaces a new category and returns i : public scaiic Category createCa~egory(Da=aDase 65, StrLxg categoryNarte, String ciassName1 throws CategoryNarneAlreadyExistsExceptioc ( Category ct = new Cacegory (categoryName, className); getca~ecories(db).add(ct); recurr, cc; i public static Carego-y createCatego,-y(3a:ajase db, Strizg catego-zyXane, Stricg className , Stricg s~~erCa=egoriesNaiie) ïhrows CategoryNam~~lreadyExistsExcep=ion [ Caiego-y ct = new Cateçory (ca=egoryName,className, superCacegoriesName ; geccategories ( d 3 ).ado(c=); retrrrr. ct; a category Dy zarie ar.a retwms a hacàle to it Category geicategory (Database Stri2g categoryNm.e) zhrows Ca~egoryNocSoundExce~ion( r e t x r c getcazeçories (db). get (cacego~yName) ; *, . / / rernoves a catego-y from t h e &tabase public static voiâ âeleceCategory(Database db, String categoryName) tkrows ConstraintViola~ionZxcegtion~ ~eferentialIr,tegri~yVi01ationExceptior,,Catego-ryNotFom&Bcception { getCateçories(33).deIete(categoryName); 1 Annex B - Code Source 115 The Categoryhterface interface specifies the methods that are to be implemented by the Category class. package public interface CategoryI~terface / / Accessory netnoàs Scring getName ( ; v o i d setName(Sïring name) ; S -, V, ;,ng getClassEame ( ) ; C l a s s getClassType ( ) chrows :! acXs é a o b j e c c O : ~ h ecategory gublic 3ooleaiz add (Objecz o8j ) EYrows WrongODjectTypeSxception, C o n s ~ r a i n t V i o l a z i o n & c e p t i o n ; :!, acCs a collecclon of objects = O :he categorf gcblic boolean ad6 (Collecrior. c) throws W r o ~ g Q b j e c t ? ~ ~ e Z ~ c e p c i o c , ConstraintViolatio~Zxception; / / re3oves ar o ~ j e c t from :ne category guDlic 3oolean rkqove (08j e c t on3 ) throws Co~szraiztViolationException; / i renoves :rom the category, 211 objeczs in c (airference) 9ublic joolean renove (Coilection c ) = k o w s Cocs~raictVio7atio~Exception; :/ removes a l 1 objeccs from :ne category public void removeAl10 throws CozstraintVioiation%ceptioc; / / r e t a i ~ so n l y elenents i n c ( I n t e r s e c t i o n ) public joolean retairrAll (Collection c chrows Constzai~tViolatioc~ception; ;/ retrieves the f i r s t o ~ j e c tchat s a t ~ s f i e stke precicate gunlic Object geï(String predicate); :.' retrieves al1 the oDiects tkat sacisfy tke preCicate gublic Set select ( S t r i c g greaicate); / / retu--ns ar, iterator for t3e ~~~~~~~zy gxbiic Iteraîor irerator0 ; Annex B - Code Source // /! s&lic wnen ) methods to add and remove incegrity constraints aads a coascraict void addconstraict (String cozstName, String className, t h r o w s Cons t r a i n t N a m e i S 1 r e a d y 3 I s i s E x c e p ioc ~ ; /: adds a k e y public vois adciKey (String keySame, Stricg[: aztrikctesj throws KeyNameAlreaay~istsExceptiorr; puDlic void rm.oveXey ( Stricg KeyName ) chrows XeyNorFo~~dZxcept io3; / / adas a relacionsnip between two categories public void aC?dRelationship (String relationskipName, int r e l m e , String attzName, String caïNaiie, Strizg irxAcrNa,~ce) Ehrows 3elatiocshipN~~~ireadyExistçExcepcio~, RelationshipAlreaàyFxistsException; , t removes a catego-ry * / / relationship from a c a t e g o r y a2B f r o ~cke zeiazoc ~ Ü S l i cvoid rernoveReiationshlp (Scrirg reiaiiocskipNme) throws 3elatiocs~ipNot?ou1:~Fxceptior:; / / addç a new trigger and a zew assoc~atedconstrainc gublic voie acdTrigger (Srring criggerWasne, String trClossName, S ~ r i z g cClassNane, int whez) =hrows Tri~gerNmeAlreaay~istsZxcsption; ! * adds a new trigger and associates it with a_r? exisiizg cmstraint * / p ~ i i cvoid a4dTrigger (String x i g g e r N m e , String trClassName, S t r m g c o n s c r a i ~ ~ X a m ethrows C o ~ s t r a i ~ ~ N u t ~ o ~ ~ ~ d E x ,c e p t i o z TriggerNmeAireacyFxistsException; / rerncves a t r i g g e r public void removeTrigger (String triggerNaine) tkrowç Tr l g g e r N o ~ F o u n ~ c e p t i o n ; / cnecks if the categorf incluCes the o ~ j e c t public boolear, contains(0bject o b j ) ; !/ r e t u m s the nümbsr 05 o ~ j e c t sin the category gublic int s l z e 0 ; hnex B - Code Source 117 The Key class specifies the amibutes that make up a key object. It uses the methods of java.1ang.reflect to dynamically mate the predicate WC! evaluate the query. package ocs.oc; import pablic class K e y { :: t h e c o n s c r x t o r acce9:s Che s e y ' s n m e acc izs a = = r i ~ c t e s Key (String name, S = r l n g [ ; ai:ribütes) ( this.name = zane; t h i s . a ~ t r i 8 ~ ~=e sattri8uces; / / u t i l i t y rne~hoas String getNa.ne0 E r e t u r n =kis.mme; i String: 1 ç e t A t t r i ~ ~ t (e) s { retu-zn zhis. attri5utes; } / : checks f o r d ~ p l i c a s ekey void checkKey ( C a t e g o q c l Object o ~ ,j irx w h e ~ i t h r o w s ConstraFntViolarionExceptior?, OnjectCategoryExceptior? { String predicate = java.lmg. ref l e c t .F i e l d fld; O b j e c t atrvalue; FreeVariables vars = new ? r e e V a r i a D l e s ( ) ; ; FreeVariaDleBindings 5inùicgs = new FreeVariableBindiags(); for ( i n t i = O ; i<attributes.length-1; i-+) { greâicate = predicate "(* a t t r i ~ u t e s [ i ] " == " fv-* +atrr; ,,,butes Li] + " ) && " ; - - - 7 'cry I E l 6 = ( c . getClassType ( ) 1 . g e t ? i e l d ( a t t r i b u ~ eCi] s ) vars . p u t ( " fv-" -at=ziDutes;ij, f ld.geïType ( ) ) ; ; , catch (NoS~chFieldZxceptio~ e) { Enrow new ObjectCatego,-y%cepti~n(~Unexpectea e x c e p t i o n i n key: toString( + + e. t o S t r F c g 0 ) ; 1 tw - Annex B - Code Source atrValue = f ld. gec (obj ) ; Sindings.putInfv-"tattribctes[il, atrvalue) ; 1 catch (IllegaiAccessException el i + zhrow new Objec~Catego~y~ception(~Unexpecteci exceprio2 ic key: roString0 + " \ r i n + e . z o S t r i z q 0 ) ; 1 1 precicate = predicate " (" attribu:es[at=ribute~.1engtf=-1I " == n n,~to f a *-* --; -----k~itac ' e - r r - à - ' -. ' m i n . -R , a- t-r--r i '-----c .- -***a , , =-Y C -.. = l a = (c.getClass~eO).getFie1d(attributes~aztrib~tes.~eng~h-~~!; vars.put("fv-"-actri5utes~atzribute~.lengt-,fld.getrype0); - 7 "fy7 - -*- - - P c a x h (XoSxhFieldException e ) { throw zew ObjectCatego~~Fxception~"Ur?expec~ec exception I n Key: =zy ': aczValue = flS.get(obj); bindi~g~.put(*fv-~-at~ri5~tes~tributes.~e~gth-~~, 1 catch (IllegalAccesslxception el C t h r o w r s w Objec~CategoryExceptlon(~'Jnexpec=ed exception ix key: i / / check if there is a duplicate Guery q = new Q u e r y ( c . g e ï C l a s s m e 0 , precicate, vars Set resclc = q.select(c.ge~lli),b i n d i n g s ) ; Dooleon rsunique = t r - ~ e ; switch(whea) 1 case ObjectCatego-y.3efore-Insert: if (result.size(! > O ) isUniwe = f a i s e ; 3reak; ; case Obj e c t c a t e g o r .~A f ter-XoCify : if ( r e ç u l ï .size ( ) >l) isUnique = false; break; 1 if ( ! i s u n i q d e l I String nsg = "Key violaziox Excepcion 13 k e y : vicïazed by: * o~j.toS=ringO) ; z k o w xew C o r i s t r a i n = V L o i a t i o r , ~ c e p t i o n ( m s q ) ; 1 1 : - coStrlcg0 Annex B - Code Source 119 A Constraint objects specifies the constraint's narne, the name of the class that defines it, and when to check. The Constraint class dynarnically instantiates an object of type "constClassName", w h c h implements the Constrainthterface interface, and invokes the object's validnre method. package ocs.oc; import com.odi.*; gcblic class Constraint { private String 2arr.e; private Stri2g co~stClassName; private int whec; .', the conscxczor Constzaiac (String cane, S t r i n s className, i n = wnen) E =his.name = nane: this.constClassName = classNarr,e; ç r .when = wker.; r. b i / rzility mechoas Striag getNalie ( ) { returr? zhis .name; ) ict get*.en( ) ( retu,~. this.wnes; ) String gecClassName ( ) C recurn z h i s .constClassKa.lie; i* icstaztiates d'? object of cype "constClassNameR and invokes its v a i i d a t e nethoci * / vois check(0bject obj, i n t when) throws ConstraintViolationException, O5jec tCaïego,yExcep t ~ O I I { Class cc; ConstraintInterface ci; cc = Class.forName(t3is.getClassNameO ) ; J catck (ClassNotFou,r:dZxceptior, e ) { String msg = "Unexpeccec5 exception in c o n s c r a i z t : " "\zn+ e . ïoString(1 ; t k r o w zew 38jectCategorry~ceptio~(msgi; toStrinç0 + Annex B - Code Source 120 catch ( I l l e g a U c c e s s ~ c e p t i o ne) { String m g = "Unexpecced exception in cocstraint: " " \ n n + e.ïoString0; tkirow new Ob jectCategoryException(nsg) ; catch ( C ~ s t m t i a t i o n ~ c e p t i oel~ .{ Siring m g = "Unexpected exception in conscraint: " " \ n w + e. toString ( 1 ; throw new Obj ectCacego,ryExcep'cio~~ ( m g ); + - ioString0 + :oString() + t ci.vali&ate(obj, when); 1 The Consuainthterface defines the only method that is to be impiemented by user defined Constra.int classes. gac kage ocs .oc ; public i z t e r f a c e Cons=raint:nterface { / / the netnod accepts and validates =he oDjec: p u l i c void validate(0bjec: obj, int when) throws ConstraintViola~ionException; 1 A Relationship object defines the attributes through whch two catejones are! related. It also indicates the type of the relationship ro be created. irnport cor.. odi . * ; pzblic ciass Rela~ionsnis { private private pzrvate prlvate prlvate S ~ r i n g= m e ; ict type; Scring attriButeName; Szring reiatedCategoryNane; String FnverseAtsrFbute!Ya,me; :/ i~verserelat i o n s h i p tyge Annex B - Code Source 121 static I n t inverseTyps(inc type) { swicch (type) { case ObjeccCatego-ry.One2One: return ObjectCaîegory.O~e20ne; case ObjecKacegory.One2Many: return Objectcaiegory .Muy20r.e; case ObjectCategory .Many20ne: r e t u r n Objectcatego-y. One2Maqy; case ObjeccCaïego,ry.Na,ny2Many: return O b j e c t C a c e a o ~ . X a ~ y 2 M a ~ y : ;'/ the constrictor !telationship(Stringname, rnï type, String atrNa,-elString catNa,?r.e, String invAtrXame) C this.mme = name; this-tyye = t m e ; this .relatedCategoryNaiie = catNarne ; this .lnverseActribiteName = icvAtrNane; 1 ;/ x t i l i ~ yrnethods Strizg getNme( 1 { returc this .name; i in= getType( : recürn tkis.=ype; : String gecAccributeNaie0 iretu? chis.ac=ribuceName; 1 Stricg getReiatedCategoryName0 : r e t q x n tkis.rela~eàCa:egoryName; 1 Strixg getI~vers~~:trLbuteNmeO{returc this.ir,verseAttributeNm.e; =he aecnod chec~sthe :me of relatior-ship, instantla=es a2 o~jectof the XelationshipInterface type, aza icvokes i t s v a l i d a c s metnod. void validateInverse (Objecc obj , i n t * k e n ) :hrows C o n s t r a i n t V i o l a t i o n ~ c e p t i o ci Relationshi?Interface ri; s w i ~ c h (type) { case 0BjectCacegory.OneSOne: ri = new 3elatFonsniplSl(oOj, whec, break; case ObjectCategory.3ne2Many: ri = new XelationshiplSM (onj, wnec, 1' *./ break; case ObjeccCatego-zy.Yany20ce: ri = new 3elationshipM2l(o~j, wnec, 8reak; case Ob j ec Kacego-ry .Macy2Yany: ri = new Xelacior~hipM2MIobj, when, break; 1 } Annex B - Code Source 122 The Relationshiphterface interface defines the only method that is implemented by the different implementations. package ocs.oc; i n c e r f ace RelationshipIr-ter face E : zhe nethod checks =ne zef erencial integrity voi6 validaze0 t h o w s Constraiz=ViolationExcepcio~; :' 1 A Trigger object specifies the txigger's name, the user-defined class that implements it and the Constraint object it is associared with. The class dynamically creates an instance of "classhne" and invokes its fire method. sackage ocs .oc ; public ciass Trigger { private String name; private Strinç classN&,lie; grlvate ConstraLz= constraint; / / cke c o n s t - ~ c = o r Trigçer(Str2ng name, S t r i ~ gclassName, Constraint constraint) this.name = came; tkis.className = className; this.coastrainz = constraint ; : /! utilizy nethods String getName0 { r e c u r n this-3arr.e; ) S t r l c g getClassName0 ( r e t a - n this-classNme; ) Constraiat getConstrair,tO { returr. =his.constrair,t; { Annex B - Code Source /* -. 123 the method instantiates an object of type "classNamem and rires it * / void fize(0b:ect oDj) t k r o w s 0Bjec:Catego-ryExcepcion Class cc; TriggerInterface trigger; < tl?/ ( cc = C ~ ~ S forNa,ne S. (getCIassName( 1 1 ; 1 c a t c h iClassNn+=nl~ridZ~coprinr? o! throw ziew ObjectCategoryCxceptior. lV5zexpected exceptloc: 21ass getClassName0 + " not f o t m d n ) ; " 1 try E trigger = (TriggerInterface) ? catch (Z~~egalAccessException String nsg = "?nexpected exception ic zrigger: e.=oString(); t h r o w new ObjeccCatego-zyExceptio~!(nsg); ?P catcn ( I n s ~ ~ t i a = i o n ~ c e p t ie o) ni String msg = "Jnexpected exceptio~ i?. x i g g e r : e . =oStriz.ç ( 1 ; chrow new Obj ec~Catego~ryExcep~ioz (rnsç); The TriggerInterface interface defines the only method that is implemented by userdefined uiggen. package ocs .oc; pünlic i~terface /,J' an erit,'y metnod public void tire(0bject i O) throws - Annex B - Code Source 124 The OCPersistent class defines the attributes and methods the system needs for manaping persistent objects. import import import impor: java.utFl.*; corn-odi.+ ; corn.odi.l~til..~; .. corn.odi . ztl-.que-? ; gublic absxact class OCPersis~enc( !* the artribute coctains r e f e r e n c e s ae-rnher of *! =O zhe categories the onjecz 2s ;/ initializes ~ h OSVector e public OCPerslstent ( 1 { chis.rriexrbership = aew OSVeczor(); OSVector çetMembership ( ) retu,?. tthis .membership; 1 { vo19 adâYembership (Category c = ) { geîMembership ( ) .aC&1eme,?z ( c c ) ; voici zernoveMemberskip (Catego-zy c t ) getXm4ezsnip ( 1 . removeElenect ( c t ) ; { i int membershipWLimi3er ( ) { return getMembership ( .size ( 1 ; I !* the >se= caLls this mechoz afzer the 09ject1s contencs are nodifiee. 1 : allows OCS = O check f o r i==egrity c o n s x a i n t s c h a t are eeficeà over the categories the oDject is nemjer of * / pwlic final voici updace0 t h r o w s Constraln=ViolatiocExceptio~:E OSVector rn = qetMenbership ( 1 ; for ( k t i = O ; I<r,.sizeO ; i-+) { Catego-y c = (Categozyi n.elenen0At (il ; c.checkObjec~(this,0bjectCa~egory.Sefore~MoCify) ; 1 1 ) References [il hdleigh. P. R. and Gretzinger. R. M. Distributed Object-Orienred Data- Systems Design. PTR Prentice-Hall. hc., 1997. 14 Athnson. M., DeWitt. D.. klaier, D.. Bancilhon, F.. Dituich, K. and Zdoni k. S . The Objecr-Oriented Database System Mon ifesto. In proceedings to the Fint International Conference on Deductive and Object-Oriented Databases (DOOS89). Kim. W., Nicolas, J.-M. and Nishio S. (Editon). Kyoto, Japan, 1989. Pl Bancilhon. F. Delobel C. and Kanellaius P . (Eds.). Building an Object- Morgan Kaufmann Oriented Dutubase Syrems. The Story of 02. Publishers. Inc. San Mateo. CA, 1992. 141 Bertino, E.. Catania. B. and Shdovsky, B. Inde-ring Techniques for Advanced Database Sytems. Kluwer Academic Publishen, L997. Pl Canell, R. G. G. Object Dora Management. Object-Onented and Eirended Relational Database $stems. Addison-Wesley, 1994. References El 126 Canell, R. G.G.and Barry, K . D. (Eds.) The Object Darubase Standard: ODMG 2.0. Morgan Kaufmann Publishen, Inc., San Francisco, California, USA, 1997. 171 Claude, D., Christopher. L. and Philipps R. Darabases: From Relarional ro Object-Oriented Systems. International Thomson Cornputer Press, 1995. Pl Date. C . J. An Introduction tu Database Sytems. 6" edirion. hddisonWesley. 1995. [91 Date. C. J. and Danven H. Foundations for Objecr Relarionnl Databases. The Third Manifesro. Addison-Wesley Loqman. Inc., 1991. [ 101 Date. C. J. and Danven, H. A Guide To The SQL Standard. Inird Edition. Addison-Wesley Publishiq Company, 1991. Dittrich. R. K. Object-Orienred Dala Model Concepts. Univenitat Zurich. Institut fur Informatik, Zurich. Switzerland. in proceedings to Advances in Object-Oriented Database S ystems. NASO Ansi Series, Spring-Verlag. 1992. References [ 121 127 Dogac, A. Advances in Object-Oriented Darabme Sysrems. NASO Ansi Senes, S pring-Verlag, 1992. Lw Ellis, A. M. and Suoustrup. B. AT&T Laboratories. 7'he Annotated C++ Reference lktanual. .WSI Base Document, Addison-Wesley Publishing Company, 1990. [ 141 Elmasri, R. and Navathe, S . B. Fundamentals of Database Systems. second edirion. The BenjaminICummings Publishing Company, Inc.. Redwood City, CA, USA. 1994. [15] Elmasri. R., Weeldreyer. J. and Hevner, A. The Category Concept: An Eaension ro the Entiy-Relationship Model. Data and Knowledge Engineering 1. 1983. [ w Fowler, M. and Scott. K . UML Distilled Second Edirion. A Brief Guide to the Standard Objecr Modeling Lunguage: Object Technology Series, Addison-Wesley,2000. [171 Jawonki, J. lova 1.2 Unleashed, T7ze Comprehensive Solution. S A M S , USA, 1998. References [la 128 Johnson, J. L. Dotabase. Models. Languuges. Design. Oxford University Press, Oxford, NY, 1997. [19] Joshi, 1. D..Runoifson. R. and Chandak. R. The Comprehensive Guide ro the JDBC SQL MI. Ventana Communications Group. Inc. 1997 Po] Khanna. L. EER-Schema Mupping Toolsfor lnreroperable Database Represenratzons. 1997. [w Khoshafian. S . Object-OnentedDarabases. Wiley Professional Computing, 1993. f 221 Korth. F. H.and Silbenchau, A. Cniversity of Texas at Austin. Dambase S w e m Concepts. McGraw-Hill Book Company, 1986. [23 1 ObjecrSrore Java MI User Guide. Release 6.0. ObjectDesign Inc.. March, 1999. [W Peuos, J. Modeling and lmplementation in an Object-Onented Database Management System. 1993. References 129 Rao, R. B. Objecr-Oriented Databases. Technology, Applications and Products. McGraw-Hill, Inc., 1994. Skarra. A. H.and Zdonik, B . S . Type Evolution in Objecr-Onented Darabase. In Research Foundations in Object-Oriented and Semantic Database Systems. Cardenas. A. F. and McLeod. D. (Eds.), Prentice Hall. 1990. Sndharan. P. Advanced Java ivenvorking. Prentice Hall PTR. Upper Sadle River. New Jersey, 1997. Tsichntzis. C. D. and Lochovsky. H.F. University of Toronto. Databuse Managernenr Sytems. Academic Press. New York, New York. 1977. Tsichritzis. D. and Lochovsky. F. Dara Models. Prentice-Hall. 1982. L'llman. J. Stanford Univenity. Principles of Darabase Systems. Cornputer Science Press. Rockville, Maryland. 1982. References 1311 130 Lllrnan.J. Stanford University. Principles of Database and Knowledgebase Sytems, Volume 1. Computer Science Press, Rockville, Maryland, 1988. 1321 Yang, C. C.Relational Databases. Prenuce-Hall. Englewood Cliffs. NJ. USA, 1986. [33] Yannakoudakis, J. E. and Chang, P . C . Standard Relational and Network Database Languages. Springer-Verlag, 1988.