Viewing Ob jects Peter J Barclay and Jessie B Kennedy Computer Studies Dept., Napier University 219 Colinton Road, Edinburgh EH14 1DJ Abstract. This pap er examines the incorp oration of database views into an ob ject oriented conceptual mo del. An approach is presented where views are themselves ob jects, instances of view classes. These view ob jects provide new ways of interacting with preexisting data; no new ob jects are required to p opulate the view. Although this approach requires no new concepts to b e added to the ob ject oriented data mo del, a large category of views may b e realised. These views allow (parameterisable) sp eci cation of their p op- ulations, and may b e arranged in hierarchies; the ob jects they contain may b e decomp osed or combined, and mayhave prop erties added or hidden. The views presented maintain the integrity of the underlying ob ject mo del, and allow up dating where appropriate. A prototyp e implementation of a data management system supp orting such views is describ ed brie y. 1 Intro duction This pap er presents an approach to database views consistent with a generic ob ject oriented data mo del. Section 2 reviews database views, and their incorp oration in ob ject oriented approaches. Section 3 overviews the ob ject oriented data mo del used. Section 4 shows how a wide category of views can b e realised without need of new mo delling constructs. Section 5 addresses the use and maintenance of views, describ- ing brie y one implementation. Section 6 concludes with a discussion, a comparison with related work, and some directions for future research. 2 Background 2.1 Database Views ANSI/SPARChave de ned a three-level architecture of database description [Jar76] 1 where the topmost `external' level represents a collection of subschemata appropri- ate for particular database users. The central `conceptual' level provides a compre- hensiveoverall description of the enterprise mo delled. Since some users maywork at this conceptual level directly,itmight b e considered a sp ecial case of a view of the data | the most complete view. The views at the external level are abstractions over this base. Views help manage the intellectual complexityofinteracting with the data, by hiding unnecessary detail and presenting information in the most appropriate format; 1 More accurately, these are alternativeschemata whichmay b e derived from the concep- tual schema or some subset of it. further, they mayprovide a level of security where only the information allowable to certain users will b e present in the views which they use. A view is sometimes de ned as a query, but is p erhaps b etter thought of simply as a database schema and its extension. Since for the user of a view, the view schema provides the most comprehensiveoverall description of the data as she knows it, the term `notional (conceptual) schema' will b e used here to mean a schema describing the data as if the view it represents were the central conceptual level. The term `implementing schema' will be used for the schema which shows how the notional view schema is abstracted from the base conceptual schema. This implementing schema corresp onds to the queries in the `view as query' p ersp ective. 2.2 Views in an Ob ject Oriented Context Views have b een well investigated in the relational context (eg [Dat87,chapter 8]). However, developments such as ob ject oriented database systems [Dit88], [Oxb88], + [ABD 89], [GJ89], [Kho90], [ZM90b], [ZM90a] and database programming languages + + [Atk78], [Bun84] (including p ersistent programming languages [ABC 83], [ABC 84], [Co c82], [Co o90]) require development of the concept of a view b eyond that found in the relational mo del. Programming languages have incorp orated various notions of data abstraction [Gut77], [MP88]whichhave b een realised in constructs suchasthepackages of Ada [Bar82], [alr83]. Data abstraction is central in the class concept of ob ject oriented programming languages [SB85], [Sau89]suchasSimula [BDMN79], Smalltalk [GR83] and C++ [Str87], [BG93]. Although some ob ject oriented database systems suchas Postgres have b een based on extensions of the relational mo del [p os90], [Sto87], + others such as Gemstone [BMO 89] and ONTOS [ont90]have b een based closely on such ob ject oriented programming languages. However, the programming language notions of data abstraction are often insucient for database views since the latter requires the notions of p opulation | a subset of preexisting ob jects are to participate in the view. Further, databases frequently require multiple co existing abstractions over the same data. So far, views have b een little supp orted in ob ject oriented database systems (some exceptions are reviewed in section 6.2). Whereas relational views may hide or create attributes in tables, ob jected oriented views must hide or create b ehaviour as well as structure. Further, they should not violate encapsulation, and should interact felicitously with the inheritance graph and the comp osition graph of the underlying mo del. Some approaches to ob ject oriented views (eg [HZ90]) have involved the creation of new ob jects to p opulate the view; this gives rise to various problems in assigning identity[KC86] to these `imaginary' ob jects. 3 NOM | The Napier Ob ject Mo del This section reviews brie y the ob ject oriented mo delling context within which views will b e explored. 3.1 A Conceptual Ob ject Oriented Mo del NOM (the Napier Ob ject Mo del) is an ob ject oriented data mo del based on the mo delling approach describ ed by the authors in [BK91]. The basic aim of NOM is to provide a simple, `vanilla' ob ject data mo del for the investigation of issues in ob ject oriented mo delling. The mo del is more biased towards expressivity for semantics capture than towards ecient implementation. NOM has b een used for the analysis of novel database application areas [BK92a], and for the investigation of sp eci c mo delling issues such as declarative integrity constraints and activeness in ob ject oriented data mo dels [BK92b]. 3.2 NOODL | the Napier Ob ject Oriented Data De nition Language NOODL (Napier Ob ject Oriented Data De nition Language) is a data de nition and manipulation language based on the textual notation used in [BK91]. A brief summary only is given here; further detail will b e intro duced later through examples. A complete description of NOODL may b e found in [Bar93]. A NOODL schema consists of a collection of class de nitions; each de nition p ertains to one particular class of ob ject app earing in the domain mo delled. Each class is named, and its ancestors (sup erclasses) cited. The prop erties of the class are named and de ned, and their sorts given. NOM blurs any distinction b etween `attributes' and `metho ds'; the term `prop erty' is intended to cover b oth. Prop erties declared without de nition represent stored values, those declared with de nition represent computed values. The de nition of a prop ertymay b e an arbitrary query. The names of prop erties may serve as messages to get and set the corresp ond- ing values; such messages are called gettors and settors resp ectively, and are dis- tinguished simply by the absence or presence of the new value. For example, the expression x.name returns the name of the ob ject x,andx.name("Inyan Hoksi") sets the value of the name prop ertyofx to b e \Inyan Hoksi". 2 Op erations whichmay b e su ered by instances of the class, and integrity con- straints to which they are sub ject, are also sp eci ed in each class de nition. A simple example of a NOODL schema is shown in gure 1. 4 Ob ject Oriented Views 4.1 An Approach to Ob ject Oriented Views The basic technique used here to create any desired view is to create a class of ob jects, instances of which represent the view itself. The op erations of this class provide a site for the various queries de ning how the view is derived from the base. No new ob jects are created to p opulate the view; the same p opulations are simply viewed di erently, through the new op erations. This approach circumvents the problems of assigning identity to imaginary view ob jects, and facilitates up datability. 2 Prop erties are simple characteristics of an ob ject, representing a (notionally) stored value; op erations represent the more complex b ehaviour of an ob ject, are parameterisable and represented by arbitrarily long sequences of query expressions. In the following sections, three classes of views are treated separately: selection- 3 views, pro jection-views, and join-views .Any general view may b e a combination of these three categories, which are treated separately for clarity of exp osition. A selection-view do es not change the `shap e' of the data, but hides the existence of those instances which do not meet the selection criterion ; the selection criterion thus sp eci es the population of the view. A pro jection-view reshap es instances of individual classes; ob jects may lose some prop erties they p ossess in the base, and (despite the name `pro jection') may also gain new prop erties not sp eci ed in the base. A join-view may aggregate together ob jects which are separate in the base, or disaggregate single base ob jects into fragments in the view. Such views can b e sp eci ed (and implemented) entirely at the conceptual level, using NOODL.