A Conceptual Language for Querying Object Oriented Data

A Conceptual Language for Querying Ob ject Oriented Data Peter J Barclay and Jessie B Kennedy Computer Studies Dept., Napier University 219 Colinton Road, Edinburgh EH14 1DJ Abstract. Avariety of languages have been prop osed for ob ject oriented database systems in order to provide facilities for ad hoc querying. How- ever, in order to mo del at the conceptual level, an ob ject oriented schema de nition language must itself provide facilities for describing the b ehaviour of data. This pap er demonstrates that with only mo dest extensions, sucha schema de nition language mayserve as a query notation. These extensions are concerned solely with supp orting the interactive nature of ad hoc querying, providing facilities for naming and displaying query op erations and their results. 1 Overview Section 2 reviews the background to this work; its ob jectives are outlined in section 3. Section 4 describ es NOODL constructs which are used to de ne behaviour within schemata, and section 5 examines how these may b e extended for interactive use. The resulting query notation is evaluated in section 6. Section 7 outlines some further work and section 8 concludes. 2 Background NOM (the Napier Ob ject Mo del) is a simple data mo del intended to allow ob ject oriented mo delling of data at a conceptual level; it was rst presented in [BK91] and is describ ed fully in [Bar93]. NOM has b een used to mo del [BK92a] and to supp ort the implementation [BFK92] of novel database applications, and also for the investigation of sp eci c mo delling issues such as declarativeintegrity constraints and activeness [BK92b] and the incorp oration of views [BK93] in ob ject oriented data mo dels. The data de nition and manipulation language NOODL (Napier Ob ject Oriented Data Language) may b e used to sp ecify enterprises mo delled using NOM. A NOODL schema contains a list of class de nitions, whichshow the name and ancestors of each class. A class de nition also includes the names, sorts, and de nitions of the prop erties of each class. Prop erty de nitions maycontain simple expressions showing howthe value of the prop erty is derived from those of other prop erties. The ability to sp ecify such derived prop erties allows the capture of data's b ehaviour within the enterprise schema. A class de nition may also contain op erations, constraints, and triggers, which are not discussed in detail here (see [BK91] or [Bar93] for more details). NOM supp orts a principle of context substitutability, demanding that where an instance of some class is required, an instance of one of its descendant classes may always b e substituted; this requires strict inheritance. An example NOODL schema is shown in shown in gure 1; the syntax of NOODL is describ ed in [Bar93]. The GNOME system (Generic Napier Ob ject Mo del Environment) is an implementation of NOM in the p ersistent programming language Napier88 [DCBM89], [MBCD89]. Although the query language describ ed here has b een successfully imple- mented and may b e used to interrogate ob jects managed by GNOME, this exp osition will not address implementation issues. 2.1 NOM's Query Mo del The construction of schemata requires an implicit query mo del for the evaluation of derived prop erties. Here, ob jects exchange messages, in resp onse to which the query expressions enco ded in the de nitions of their prop erties are evaluated; these evaluations mayresult in the sending of further messages to further ob jects. This approachmaintains a strong corresp ondence b etween real world and mo del ob jects. Sp eci cally, and unlikemany other mo dels, NOM do es not allow the creation of new ob jects as the result of a query (although new col lections of existing ob jects may be formed). In addition to adherence to the conceptual mo del, this prevents query results from b eing detached from the class lattice. This disp enses with the need to classify result-ob jects in the preexistent hierarchy (eg, [DD91], [Kim89]). This principle also provides closure in the query mo del; since queries may return only collections of preexisting ob jects, these may certainly be the targets of further, cascaded messages. Since no new ob jects are created, problems of comparing identi ers of ob jects returned by queries do not arise. 3 Ob jectives of This Work A variety of ob ject oriented database query languages exist; some are languages supp orting the logical mo del provided by a particular OODB (eg, [MSOP86]); others are implementations of the query languages of semantic data mo dels (eg, [KA87]); some are attempts to add ob ject oriented extensions to SQL (eg, [ont90], [RS87]). These languages are intended to allow users to p erform ad hoc queries on a database, to embed these in application programs, or b oth. However, Kim has argued that many of these languages are inadequate since they are not based on an underlying ob ject oriented mo del of querying [Kim89], which takes into account the di erent abstraction mechanisms used in the schema de nition against which querying is p erformed. However, since an ob ject oriented data mo del must capture the b ehaviour of the ob jects describ ed, a query notation is necessary simply to describe an enterprise. The only alternatives are either to use natural language comments to describ e the b ehaviour of data ob jects (losing precision), or to describ e this b ehaviour in a host programming language (losing the conceptual level of the data description). As Zicari et al havepointed out, in ob ject oriented database systems, the query language and the metho d de nition language are seldom the same [Zic91]. E orts are underwayto establish a standard ob ject oriented data description language [Atw93], [Hol93]; such ataskwould b e facilitated by establishing a standard data manipulation language. Since a data description language (DDL) must necessarily describ e how ob jects interact with each other, it must contain a data manipulation language (DML); hence it is not p ossible to maintain two separate notations for these functions. 3.1 Integration of the Schema De nition Language and the Query Language In the course of developing NOODL it b ecame apparent that a schema de nition language required considerable b ehavioural capture in order to sp ecify derived properties, as well as constraints and triggers. When desire to supp ort ad hoc querying in GNOME necessitated a query sp eci cation language, it was decided to develop this language by the minimal reasonable extension of NOODL. This approach seemed to o er the b est integration of mo delling and query notations, and would b e easiest to implement since a compiler already existed for NOODL as a schema de nition language. Further, since NOM was designed as a `vanilla' mo del, supp orting only those features agreed up on by the ma jority of ob ject oriented data mo dels, it seemed that this approachmight give some insightinto the ability of any ob ject oriented data mo del notation to supp ort ad hoc querying, provided only that it allows sp eci cation of b ehavioural asp ects of the mo del without resorting to use of a 3GL. The facilities of NOODL as a schema de nition language, and then its adaptation to ad hoc querying, are discussed in subsequent sections. 4 NOODL as a Schema De nition Language This section shows how, in schema de nitions, b ehavioural expressions mayrequire to b e written. The names of prop erties de ned in NOODL schemata can b e used as gettors and settors for those prop erties; this already provides a basis for a navigational query notation. In order to increase b ehavioural expressivity, it is necessary also to have constructs to handle collections of ob jects, and to build up more complex query expressions. These are describ ed in the succeeding sections. The examples are based on the schema shown in gure 1. 4.1 Basic Query Expressions Basic queries are of twotyp es, here called navigational-style and search-style queries. 4.2 Navigational-Style Expressions Anavigational-style query nds some information which is implicit in the enterprise mo del. For example, consider the schema in gure 1 describing p eople with sp ouses, who own coloured cars (assuming one car per p erson). The prop erty sp ousesCar- Colour returns the colour of anyPerson's sp ouse's car. If LEIF is an ob ject of class schema Example domain Colour is ( "crimson", "aquamarine", "puce" ) domain Money is { defined elsewhere } class Person class Employee properties ISA Person { stored properties } properties name : Text ;; salary : Money ;; city : Text ;; company : Company age : Number ;; spouse : Person ;; car : Car ;; children : #Person ;; { derived properties } grandchildren : ##Person is self.children.children ;; spousesCarColour : Text is self.spouse.car.colour ;; likeMindedCarOwners : #Person is Person where its.car.make = self.car.make class Car class Company properties properties make : Text ;; name : Text ;; colour : Colour city : Text { etc } end_schema { Example } Fig. 1. Example NOODL Schema Person, then the expression LEIF.spouse.car.colour is a navigational-style query returning the colour of Leif 's wife's car. The tokens spouse, car and colour are messages which elicit the value of the prop erty of the same name; the de nition of the prop erty, including whether the value is settable or derived, is found in the enterprise schema (strong encapsulation). The dot op erator . sends the message on its right to the ob ject returned byevaluating 1 the expression on its left .

Load more