Object-Oriented Data Model

Object-Oriented Data Model
Table of Contents
Object-Oriented Data Model....................................................................................1 Table of Contents.......................................................................................................1 1 Abstract Data Objects.............................................................................................2 2 Data Classes...........................................................................................................11 3 Dynamic Binding and User nterface...................................................................21 ! "tatic n#eritance...................................................................................................2$ % Dynamic and M&lti'le n#eritance......................................................................3% ( Object dentity and Database )&ery....................................................................!2 $ Metale*el +acilities and Database Arc#itect&re..................................................%,
1
1.1
Abstract Data Objects

Introduction
Object-oriented systems are currently receiving much attention and making great impacts in many areas of computer science. They have their roots in programming, as an alternative approach to procedure-driven programming, and is reflected in the development of such programming languages as Simula, Smalltalk and !!. "t has since been adopted and e#tended, particularly to cover the broader range of soft$are engineering activities including modelling, specifications and design phases of soft$are construction. %ven the field of artificial intelligence, especially kno$ledge engineering, have &some$hat independently and in parallel $ith development in programming' found the object-oriented approach to be particularly effective. Some$hat a later development is the application of the object-oriented paradigm to databases and database management systems. This interest $as perhaps fueled by re(uirements in ne$ areas of database applications - in particular, hypermedia systems. Such applications call for data modelling capabilities not supported by traditional models of databases or current implementations of database management systems &such as relational or net$ork data models and D)MSs based on them'.
+ig&re 1-1 Database *rchitecture onceptually, database systems are based on the idea of separating a database structure from its contents. This $as e#plained in section +., &see also -igure +.. there'. To briefly recapitulate, the database structure is also called a schema &or meta-structure - because it describes the structure of data objects'. * schema describes all possible states of a database, in the sense that no state of the database can contain a data object that is not the result of instantiating an entity schema, and like$ise no state can contain an association &link' bet$een t$o data objects unless such an association $as defined in the schema.
Moreover, data manipulation procedures can be separated from the data as $ell. Thus the architecture of database systems is portrayed as sho$n in -igure + -+. The a#ioms of conventional data modelling are/ +. *ttributes, data objects and relationships belong to predefined types0 1. The schema or metastructure of a database must be specified in advance0 ,. Data manipulation facilities are based on a propositional calculus &allo$ing comparisons of attribute values'
1.2 Abstract Data Objects
The principal idea behind object-oriented approaches is that of encapsulating data in abstract data objects, or *DO for short &the use of this term is practically synonymous $ith that of abstract data types, or *DT, $hich is also commonly used in the literature0 $here no confusion can arise, ho$ever, and $hen it results in better reading, $e $ill simply use 2object3 or 2data object3 to mean an *DO'. *n *DO has the follo$ing properties/ +. "t has a uni(ue identity. 1. "t has a private memory and a number of operations that can be applied to the current state of that memory. ,. The values held in the private memory are themselves *DOs that are referenced from within by means of variable identifiers called instance variables. 4ote the emphasis 5from within6, $hich underlines the idea of encapsulation, ie. such instance variables or objects they denote or any organisation of the objects into any structure in the private memory are not visible from outside the *DO. 7. The only $ay that the internal state of an *DO can be accessed or modified from outside is through the invocation of operations it provides. *n operation can be invoked by sending a message to it. The message must of course contain enough information to decide $hich operation to invoke and provide also any input needed by that operation. The object can respond to the message in a number of $ays, but typically by returning some &other' object back to the message sender and8or causing some observable change &eg. in a graphical user interface'. Operations of an *DO are also referred to as methods. 4ot all methods have to be visible, ho$ever - some methods may be needed only internally and, like the structure and contents of private memory, are hidden from outside vie$. Those methods that are visible e#ternally are called public methods and constitute the public interfaces of the object. 9sers or clients of the object need only be a$are of its uni(ue identity and its public interfaces to be able to use it.
These properties of an ADO may be pictorially depicted as in the figure below:
+ig&re 1-2 Depiction of an *bstract Data Object -or e#ample, the *DO $ith identity 5:erson 4ick6 may be depicted as in -igure + -,. This object represents a particular person and its private memory $ill contain values pertaining to that person. These values are accessed and manipulated only through the public interfaces. Thus, the message 5;et-Salary6 $ill invoke the corresponding method $hich $ill retrieve and return the person3s salary. The 5Set-Salary6 message on the other hand $ill invoke the corresponding method to modify that value in private memory representing the person3s salary.
+ig&re 1-3 Data Object %#ample 4ote that as a user or client of this object, $e have no kno$ledge of, nor do $e need to kno$ or care about, its private memory structure. The salary, for instance, may be a value stored e#plicitly in the object3s memory, or computed dynamically using other values &such as daily rates and number of days $orked', or retrieved from some other object. <hat matters to the client is only the public interface. Much of the po$er of the object-oriented approach lies here in data encapsulation. "t means that the implementor of some *DO is free to choose any implementation structure he8she deems appropriate, or change it later, say, for greater efficiency. *s long as the agreed public interfaces remain the same, clients $ill be assured of the same &perhaps improved' service. hanges may also add ne$ functionality, ie. ne$ public interfaces. *gain, as long as the interfaces used by e#isting clients are maintained, they $ould not be affected. The e#tended object, ho$ever, may take on ne$ clients that e#ploit the ne$ interfaces.
*s implementors of an *DO, ho$ever, $e must kno$ ho$ private memory is structured and organised. "n principle, and in keeping $ith the object-oriented vie$ of values, private memory is simply a collection of other *DOs. More specifically, it is a collection of named memory locations. These names are local to &ie. uni(ue only $ithin' the *DO in (uestion. *t each of these named locations, $e may store the identity of some other data object. These, in contrast, are uni(ue and global to the database. -or this reason, the local names are referred to as instance variable names or simply variable names &2variable3 because the location3s contents may change, and 2instance3, as $e shall see later, is synonymous $ith *DO'. *rbitrarily comple# associations bet$een objects may therefore be constructed through their memories. onsider, for e#ample, the collection of objects in -igure +-7.
+ig&re 1-! Object collection $ith their private memories The schematic on the left depicts the situation $e $ish to represent in object-oriented terms, vi=. there is a department of computer science $ith a collection of employees &t$o are sho$n'. %ach employee has a number of attributes &the 2Name3 attribute is sho$n'. The schematic on the right depicts one possible representation, $hich comprises three data objects. %ach object has a uni(ue identity &2DCS3, 2Alex3 and 2Nick3 respectively' and a private memory $hich contains a collection of instance variable names and their values &eg. in the *DO 2Alex3, the variable 2Affiliation3 has value 2DCS3'. The public methods of these objects are unimportant for no$ and are omitted. 4ote that the value of a variable is in effect a reference to an *DO, using the object identity rather than a copy of the object. This 5reference semantics6 of object containment means that a particular object can be referenced from $ithin many other objects, ie. a form of re-use of data objects. Thus, each of the objects 2Nick3 and 2Alex3 refers to the object 2D S3 as its affiliation. The object 2D S3 in turn has both references to 2Nick3 and 2Alex3 in its private memory. Together, these associations capture the relationship &e#pressed in the left schematic' bet$een a department and its employees. Of course, variable names may be arbitrarily chosen. The names, in themselves, do not constrain the values they may contain and the same data object may be re-used in
different variable names of different objects. So another *DO, say 2University3, may have a variable named 2Departments3 $hose contents are a collection of references to department objects. The data object 2DCS3 can then also be a value in this collection.
1.3 Methods
An ADOs methods are code that operate on its private memory in response to an incoming message. As we have seen above, private memory is a collection of other objects. Thus, a method basically achieves what it needs to do by sending messages in turn to appropriate objects in the private memory. This is illustrated below.
+. Method 1 is activated by an incoming message 1. "t in turn invokes appropriate objects in private
memory by sending each a message it puts together &possibly using values in the incoming message' ,. "nvoked objects eventually return responses 7. Method 1 collects responses and compose a response that is directed back to the sender
+ig&re 1-% Method )ehaviour -or e#ample, suppose the 2DCS3 object responds to a message 2GET_NAME3, responding $ith a te#t string denoting the name of the department. This is sho$n in -igure + ->.
+ig&re 1-( The e#ample object 2D S3 responding to a message Suppose further that the object 2Nick3 has a method called 2WOR S_!OR3, intended to return the name of the department that 4ick $orks for. Of course, this information is contained in the object 2D S3 in 4ick3s private memory. So the method 2WOR S_!OR33 may be implemented by simply sending the message 2GET_NAME3 to 2DCS3, $aiting for
the response and then relaying this back to the sender. This is illustrated in the follo$ing figure.
+ig&re 1-$ ?elegating &part of' the $ork to other objects "f methods achieve their $ork by sending messages to other objects, and these objects in turn send more messages to yet other objects, and so on, $hen $ill any result be generated in response@ The ans$er is that there are system-defined objects $hose internal structure or method definitions are not our concern. <hat is important about these system objects is that they provide a number of public interfaces that guarantee a response if invoked $ith appropriate messages. The simplest type of system objects behave like variables in conventional programming languages, ie. they have only one variable in their memory and provide public interfaces such as 2GET_"A#UE3 and 2SET_"A#UE3 that respectively reads and sets the variable. The 2Name3 variable in -igure + -A could presumably hold such objects. "n applying the object-oriented paradigm to databases, the *DOs are the principal units of data populating the database. *DOs may be created and once created $ill persist until they are e#plicitly deleted. They e#ist independently of particular user sessions, and different sessions may access or modify them.
The following illustration shows a database of three objects on the left. Assuming that the object DCS was sent a DE#ETE message, that object will cease to exist. The outcome is to remove DCS from the database. Note that in this case, the consistency of the database is also maintained by removing any use of DCS in the private memories of other data objects.
+ig&re 1-- %ffect of Data Object Deletion

1.4 Messages
<e have talked about messages above rather loosely. :ublic methods of objects must clearly be formal, ho$ever, and $ill only recognise messages that are appropriately structured and carrying the right sorts of data. Sending a message to an object is not unlike calling a function or procedure in conventional programming languages. So $e may e#pect that the message must specify +. the method name that should respond to the message, also called the 2selector3 component of the message, 1. the object to $hich the message is directed, also called the 2target3 or 2receiver3 of the message, and ,. the actual parameters &of the right sorts' for the method3s code to operate on. :arameters are themselves *DOs. This message structure is illustrated in the figure belo$.
+ig&re 1-. Message Structure *ctual parameters in a message are optional, ie. some methods do not need input parameters and compute their responses only from the internal state of the object. "n these cases the message structure comprise only a selector and a target.
+ig&re 1-1, ?esponding to messages * method may send back some value in response to a message, or it may not. This $ill depend on the problem domain and ho$ $e choose to design our methods. "n the case of the 5Set$Salary6 method above, no return value is necessary - only the effect of setting the 2Salary3 value is important. * method that does respond $ith a value actually returns a data object. This is illustrated in the -igure + -+B. The message 5Get$Salary%Nick&6 retrieves the object in the 2Salary3 variable and passes it back in a return message to the sender. "t is important to notice that since the response to a message &$hen there is one' is itself a data object, it can be the target of another message. "n such cases, $e may treat messages in much the same $ay as $e do functional e#pressions, ie. a message may be vie$ed as a function denoting a data object and can therefore be used $here a data object is a valid e#pression. -or e#ample, assuming that 5'rint6 is a public method of the data object 5()))6 in the above e#ample, then the follo$ing is a valid message/
'rint%$Get*Salary%Nick&$&$
That is, the message 5Get*Salary%Nick&6 evaluates to the value returned, $hich is the data object 5()))6, $hich then becomes the receiver of the message $ith selector 5'rint6.
Object-Oriented Data Model 1. !u""ar#
<e have introduced / +. *DOs as principal components of an object-oriented database. %ach *DO has an identity, its o$n private memory and responds to a number of messages. * message is al$ays directed to a particular *DO and is in effect a re(uest to carry out one of its operations. 1. The public interface of an *DO is the set of operations or methods that may be invoked through sending appropriately structured messages to it. ,. * method is some code that prescribes the processing to be undertaken $hen it is invoked by an incoming message. This processing $ill typically involve sending further messages to data objects in private memory. 7. * system object is a pre-defined *DO. "ts internal memory structure or methods definitions are hidden and unimportant to us. They are other$ise like any user-defined *DO and may be used by application-specific objects. 9nlike relational databases, the data structures of objects in an object-oriented database are encapsulated &hidden' and cannot be manipulated directly by generalised procedures. This is because generalised procedures are only possible if the data structure is kno$n and uniform over all objects, eg. the relation or table in the relational model is a kno$n and uniform structure, allo$ing generalised procedures such as (uery operations to manipulate tabular structures independently of actual contents. "nstead, each *DO presents a public set of methods that operate over its private data structures. This allo$s great fle#ibility in the design and definition of objects $hile at the same time allo$s object capabilities to be shared and re-used amongst persistent objects. *DOs are values, in much the same sense that 2.3 is an integer value or that a particular set is a relational value. They constitute the contents of an object-oriented database. * separation of structure and content may be achieved by describing classes of *DOs, in much the same $ay that a relational schema describes a set of tuples. * particular *DO $ill then be an instance of some class description, $hich $ill define the memory structure and methods common to all *DOs in the class. This $ill be the subject of the ne#t chapter.
2
2.1
Data Classes
Introduction
-rom the discussions of the previous chapter, the basic architecture of an object-oriented database may be illustrated as in -igure 1 -+ belo$. The persistent data of tables in the relational model is replaced by a collection of persistent *DOs, and the generalised data manipulation procedures are replaced by the public interfaces of objects.
+ig&re 2-1 Object-Oriented Database *rchitecture The *DO concept of encapsulating data and operations over them, ho$ever, poses a problem in the database creation. The creation of an *DO, by its nature, re(uires private memory to be defined and methods associated $ith it. )ut typical databases $ill have thousands of objects, and having to define each object individually is clearly impractical.
2.2 Data Classes
To avoid such problems, object-oriented systems introduce the concept of Data Classes. * data class is a description of a number of similar *DOs. "n other $ords, each *DO belongs to a particular data class, or e(uivalently, is said to be an instance of that data class. The *DOs of a class are 2similar3 in the follo$ing sense/ they have in common the same public interfaces and private memory structure &see -igure 1 -1'. They are not the 2same3, ho$ever, because each may have different memory contents and thus behave differently in response to the same message. * data class description is therefore a metastructure description, separating structure from content, in much the same $ay that a relational schema $as a metastructure in the relational data model.
+ig&re 2-2 * Data lass ontent is introduced by creating instances of data classes. -or this purpose, every data class has an implicit method called 2NEW3. "n response to a message $ith selector 2NEW3, a data class $ill return a uni(ue object that has the private memory structure and methods as described by the data class &e#cluding, of course, the method 2NEW3 itself'. Subse(uently, messages may be sent to such objects invoking any of their public methods to manipulate internal data &eg. insert, remove, change, etc'. * data class may thus be vie$ed as a template, or a 2cookie cutter3, or even as a 2factory3 for producing *DOs &ie. the instances'.
+ig&re 2-3 * Data lass and its "nstances -igure 1 -, sho$s this role of a data class. "n response to each 2NEW3 message a uni(ue instance is created. *lso illustrated is the sending of the 2'rint3 message to the instance 2Nick3 and to the instance 2Alex3. )oth instances can respond to this message, since each $as created in the image of the same data class description $hich has the corresponding
method definition. The results they return, ho$ever, may be different since each instance3s private memory is independent of one another. )esides user-defined data classes, an object-oriented system typically includes a number of system classes. "n fact, user-defined classes must in the end build upon system classes. <e may assume that a system class, like any data class, defines a private memory structure and public methods. The private memory structure is of course hidden and inaccessible to user-defined classes and objects. <hat is important, though, is that instances of system classes, or system objects, may be used &through their public interfaces' by other objects. *s an e#ample, a typical system class might be the class called 2N+meric3. "nstances of this class are intended to denote particular numeric values. "ts public methods may include operations like 2'l+s3 &!', 2Min+s3 &-', 2Assi,n3 and 2Get3. This class can then be used, for e#ample, to create instances such as 21.3 and 2,+3 &$hich $e assume $ill carry in their respective private memories representations of the values 1. and ,+'. <e can then form the message/
'l+s%(-.$/0&
$hich is a message directed to the instance 21.3, selecting the method 2'l+s3 and providing the object 2,+3 as a parameter. The method 2'l+s3, as the name suggests, $ill return an object that holds the sum of the values 1. and ,+ &let3s call this object 2.>3'. 4ote that it doesn3t matter, in fact, if the message $as directed to the instance 2,+3 and providing 21.3 as the parameter - the result $ill be the same, ie. 2'l+s3, in this case is associative like the standard arithmetic operator 2!3. Such system objects may of course be re-used by user-defined *DOs or other system objects. So, for e#ample, $e may have another numeric object called 2A,e3, and messages such as the follo$ing can be constructed/
Assi,n%$A,e.$'l+s%(-.$/0&$&
"n an object-oriented database system, there are also system classes to structure data. Such classes are generically referred to as Data Structures. They $ill have other objects in their private memories &members of the structure' and typically provide public interfaces to insert ne$ members, remove e#isting members and also to broadcast messages to all current members. Cet3s say, for e#ample, that there is a data structure class called 2Collection3, $ith methods 21nsert3, 2Remove3 and 22roa3cast3. <e may then create an instance of this class, say 2 ol-+3, and populate its private memory $ith other objects by sending it messages of the form
1nsert%$Col*0.$O45$&
$here 2O453 is some object identity. <e can also remove e#isting objects in 2Col*03 using messages like
Remove%$Col*0.$O45$&
provided 2O453 is a member of 2 ol-+3. *nd since every member of 2Col*03 is an *DO itself, $e may of course direct messages to individual members, or using the 2)roadcast3 method provided, direct a message to all members simultaneously, eg.
2roa3cast%$Col*0.$'l+s%$0$&$&
This particular message assumes that every member is a numeric object. The 22roa3cast3 method $ill, for each member m in the collection, issue the message 5'l+s% $ m .$0& 6. This facility is useful $hen some operation is to be applied to every object in the collection &it can be seen as a special case of repetition constructs in conventional programming languages, such as for loops'. Of course, the message to broadcast can be any message to $hich members can respond. The method 2NEW3, in addition to creating a ne$ instance of a data class, may also initialise the private memory of the instance. The initial values, if any, are themselves *DOs and are included in the message to the data class. Thus, a fuller form of the 2NEW3 message structure is/
NEW%$63ata$class7.$6var78$6val+e7.$9.$6var78$6val+e7$&
$here DvarE is an instance variable name defined in Ddata classE, and DvalueE is an object identifier. There are basically t$o $ays objects may be specified in the 24%<3 message. Suppose, for e#ample, there is a data class called 2:erson3, and that there is already a database of e#isting objects $ith identities as sho$n in -igure 1-,.
+ig&re 2-3 %#ample Data lass Then an object identity may be specified in the DvalueE part of the message, for e#ample/
NEW%$'erson.$Affiliation8$DCS$&
This $ill result in the creation of an instance $ith the variable 2*ffiliation3 set to the object named 2D S3 .
* second method of specifying initial object values comes from noting that the 24%<3 message itself returns an object. Thus, the DvalueE parts of a message can be 24%<3 messagesF -or e#ample/
4%<& :erson, 4ame/ 4%<& String, 54ick6 ', *ge/ 4%<& 4umeric, 57B6 ', *ffiliation/ D S '
<e assume that 2String3 and 24umeric3 are data classes that are already defined. This message $ill thus initialise the 24ame3 variable $ith a ne$ 2String3 object and the 2*ge3 variable $ith a 24umeric3 object. &4ote that the synta# used here is informal. "t is not our intention to describe any particular object-oriented system or its specific language constructions. <e are more concerned $ith describing concepts and features of objectoriented systems in general. <e fre(uently turn therefore to fairly intuitive graphical notations'. The t$o $ays of specifying objects can of course be combined in one message, as illustrated by the last e#ample. Class/ "tate and dentity * class defines a type of objects, distinguished from other types by its particular memory structure and methods. *n object of a class takes on the memory structure it describes, but is other$ise free to set values in its memory independently of other objects. The values of the instance variables of objects therefore constitute the state of the object. Thus t$o objects may be of the same type &instances of the same class' but may possess different states. The 24%<3 method of a class, in addition to creating an object of the class, assigns a uni(ue identity to it &conceptually, there is an infinite set of identities that the system can choose fromF'. This identity is permanent, in contrast to the state of the object $hich can change arbitrarily. Thus, 4ick3s affiliation may change in the above e#ample, but his identity remains unchanged. This formalises the notion of object reference mentioned earlier &similar to the notion of a pointer in conventional languages'. <ithout identity, it $ould not be possible to refer to objects independently of their state, and object re-use $ould be impossible, ie. it $ould not be possible to have the same object as the value of an instance variable in more than one object. The distinction bet$een identity and state, ho$ever, does not apply to objects of socalled )ase lasses. These are system classes of values that are atomic, such as integers, floating-point numbers, characters, etc. Such base objects do not have memory and thus cannot have a state that can vary independently of its identity. Its identity is its valueF Thus an integer 2G3 object denotes both the object3s identity and its value. The state of a user-defined object $ill eventually be constructed from such base objects.
Object-Oriented Data Model 2.3 Definition of $ri%ate Me"or#
To define a data class, $e must define * uni(ue name for the class, * structure for the private memory of the class, and * collection of methods shared by all instances of the class :rivate memory structure is defined as a binding of instance variable names to e#isting data classes. The idea of a 2binding3 here is not unlike the idea of typing in &typed' programming languages. -or e#ample, variables in such languages are declared using constructs such as
6varia4le$name7$8$6type7
eg.
x8$inte,er: y8$real:
9etc
The meaning of such a declaration is that the named variable is constrained to hold only values from the specified type. Cike$ise, a binding is an association of an instance variable name and a data class, using declaration constructs such as
6instance$varia4le$name7$8$63ata$class$name7
*s a class is basically a type, the meaning of such a binding is that the instance variable is constrained to hold only instances from the specified data class. Such a binding is thus also referred to as a Hariable - Domain binding. Suppose that 2String3, 24umeric3 and 2 ollection3 are system classes. Then the follo$ing is a definition of a class and its private memory structure &again, the synta# is notional'/
class$!irm: instance %ariables Name8$Strin,: Employees8$Collection: end !irm:
)lock introducing instance variables "ndividual HariableI Domain binding
The class Firm in turn can be the domain of instance variables in some other class, for example: class$'erson: instance %ariables Name8$Strin,: A,e8$N+meric: Affiliation8$$!irm: end$'erson: 2-irm3 used as a variable3s domain
)indings therefore define associations between data classes $hich can be graphically depicted in Object-Oriented Data Structure Diagrams. The classes and relationships introduced by the above definitions is sho$n in -igure 1 -7.
+ig&re 2-! Object-Oriented Data Structure Diagram

2.4 Definition of Methods
* method is defined by specifying a Message Template, and a Method )ody * Message Template defines the structure of messages to $hich the method $ill respond. "t must include a' a name to match the selector of an incoming message0 b' a specification of a target instance c' a specification of formal parameters in the form of a list of HariableIDomain bindings. The above of course mirrors the structure of messages presented earlier. Hariables in the formal parameters part of the template are names that can be used in the message body &they are different from and should not be confused $ith the instance variables of the class'. The domain parts of the bindings must be names of e#isting classes. Such a formal parameter list $ill match the parameters of an incoming message if each parameter value is from the corresponding domain in the formal parameter list. The corresponding formal variable $ill then be bound to that value during e#ecution of the message body. Suppose for the class 2-irm3 above, $e $ish to define a method to respond to a message to add a ne$ employee. The follo$ing then is a possible template/
Ne;<Employee$$$%$$T8$!irm.$$$$$E8$'erson$$$& 4ame chosen for the message selector This specifies the target, which is an instance of This specifies the input parameter, $hich is an instance of 2:erson3
<ith this template, a message such as

Ne;<Employee$%$=.$>$&
$ill be recognised and accepted by the instance J, if J is an instance of 2-irm3 and if K is an instance of 2:erson3. "n such a case, the formal variables T and % $ill be bound to J and K respectively in the e#ecution of the message body. *ny other message structure $ill be rejected. "f the method also returns a value in response, the template $ill also specify this by $riting a HariableIDomain binding after the formal parameters. -or e#ample/
Ne;<Employee$%$T8$!irm.$E8$'erson$&$R8$#o,ical
The binding 5?/ Cogical6 specifies the response the method $ill generate. <e assume 2Cogical3 is a base system class $ith tr&e and false as its only possible instances. Thus the response ? $ill be either tr&e or false. The body of a method is specified as a number of message e#pressions involving the formal variables in the template and instance variables of the class. "f a result is specified in the template, some e#pression must also cause the result variable to be bound to a value. Thus, for the above e#ample, the follo$ing might be the method body/
Set$$%$R$$.$$1nsert$$%$$T?Employees.$$$E$$$&$$&
This method body may be interpreted as follo$s/

-irst, issue the message 51nsert$%$T?Employees.$$E$&6. The target of this message is
the instance found in the instance variable 2%mployees3 of T, $hich at this time is bound to the very instance that is responding to the original message. The parameter of the message is the formal variable % $hich at this time is bound to the instance of 2:erson3 in the original message. *ssume that the response to the 2"nsert3 message is a logical value. That is, the method body e#pression is reduced to the follo$ing $hen the 2"nsert3 message responds $ith a value, say H/
Set$%$R.$"$&
This is also a message that is sent to the variable ? to set its value to H. The net effect therefore is to generate a response containing H to the sender of the 24e$I %mployee3 message. *s another e#ample, consider the definition of the method 2:rint3 for the class 2-irm3/ Message Template/
'rint$$%$T8$!irm$&$R8$#o,ical
Method )ody/
Object-Oriented Data Model 'rint$%$T?Name$&: 2roa3cast$%$T?Employees.$$'rint$&: Set$%$R.$true$&
This e#ample underlines the object-oriented style of processing, $hich is based on message passing. The intention of this method is to print the name of the 2-irm3 instance and all its employees. )ut as the latter are *DOs themselves, the processing at this level cannot directly print to printer their encapsulated information, since such information is hidden. The options at this point therefore are to collect from the objects the relevant information for printing, or to pass the responsibility of printing to the objects themselves. "n both cases, messages must be sent to the objects, and the objects must of course have corresponding methods to either return re(uested information or to perform the printing themselves. The e#ample above assumes that instances of 2String3 and 2:erson3 can handle printing and thus the 2:rint3 message is passed to them.
2. !u""ar#
* data class is a description of *DOs all having the same private memory structure and public interfaces &methods'. %ach *DO in an object-oriented system belongs to a particular data class and is created as an instance of that class. * data class is defined by specifying its private memory structure and its methods. The definition of its private memory is essentially a set of bindings of instance variables to e#isting data classes. Methods are typically defined by messages that are sent to other objects in the system. The definition of a data class is called a Class Definition Expression. <e distinguish bet$een system data classes on the one hand, and user-defined data classes on the other. The former are a part of a given object-oriented &database management' system. The latter are the results of class definition e#pressions, dra$ing on system classes and other user-defined classes, that collectively describes the behaviour &data structures and operations' of a particular database system.
+ig&re 2-% Object-Oriented Database Schema. * set of data classes therefore defines all possible *DOs that can populate the system. "n the conte#t of a database system, such a set of data classes therefore forms an ObjectOriented Database Schema. This is illustrated in the figure above. 4ote that such a
schema not only defines the data structures but also purpose-oriented behaviour of the system &ie. operations that can be applied to data objects'.
3
3.1
Dynamic Binding and User nterface

Introduction
*DOs combine data structures and procedures operating on them. Messages serve both the purpose of procedure activation and of data passing. *n object-oriented database is a collection of *DOs and a user interacts $ith such a database basically by sending messages to activate processing and receiving data passed back in response. This is depicted in -igure , -+.
+ig&re 3-1 * vie$ of an object-oriented D)MS <e have seen that data classes define the meta-structure of an object-oriented database as $ell as the behaviour of *DOs that instantiate them. Different applications $ill typically call for different data classes to be defined, ie. the data objects and their associated operations are application dependent. "t is not possible, therefore, to have a standard user interface of generalised operations that is application independent. "nstead, the user interface for an application must be defined in the object-oriented database schema itself. To facilitate this definition, there are special system data classes that provide some basic building blocks.
3.2 &ser Interface and !#ste" Data Classes
?ecall that every object-oriented system includes a number of predefined system classes. * system class is one of a )ase lass, such as 2"nteger3, providing base objects upon $hich the states of objects are eventually constructed a primitive Data "tem, such as 2String3 or 24umeric30 unlike base class objects, these have states that can inspected or changed a Data Structure, such as 2 ollection3, 2*rray3, 2Lueue3, 2Stack3, etc, used to combine other data objects into entities $ith predefined properties a 9ser "nterface, used to define application-specific user interfaces &in effect, a data manipulation language'
<e have seen e#amples of the first t$o types earlier and ho$ they are used, and in fact essential, as components of user-defined classes. * user interface system class differs in that they are designed to interact $ith a user, by visualising data objects or by reacting to user actions or both. ;iven today3s sophisticated visual presentation and interactive input devices, user interface system classes typically include a set of templates for constructing graphical, direct-manipulation interfaces that are visualised on computer screens and provide for interactive user actions through various devices such as a keyboard, a mouse, a touch pad, a touch screen, etc. -or e#ample, it is (uite common to find a system class called 5:ush-)uttons6, or something similar. The class represents objects that $hen visualised presents to the user $hat looks like a button on the screen, $hich he8she can then manipulate using interactive input devices like a mouse. <e illustrate this in the figure belo$. *s sho$n, the 24%<3 message brings a number of other objects as parameters. The :ush-)utton class is assumed to respond by first creating for each parameter an on-screen ,D-look button, $ith each button labelled $ith te#t obtained from the input parameter objects. The method then $aits for the user to select one of the buttons, upon $hich the corresponding object $ill be returned as the final response.
+ig&re 3-2 *n e#ample of creating and visualising user interface objects This, of course, is neither a complete nor definitive description of interface classes like :ush-)utton. "t is only intended to outline and highlight that their effects and capability are largely to do $ith human-computer interaction, vi=. visualising information for the user and ac(uiring information from the user.
The user interface objects created, such as the buttons above, are destroyed once a selection is made. This is typical of the nature of interface objects - they are discarded once they have served their purpose. Interface objects, therefore, have a transitory existence compared to the more persistent data objects in the database.
+ig&re 3-3 %ditable fields e#ample
"nterface objects, ho$ever, may cause instances of other data classes to be created in the course of processing. This is illustrated in -igure , -,. Mere $e have an 2"nput--ield3 interface class that, upon receipt of a &parameterless' 24%<3 message, creates an input field object that is visualised on the screen as an edit bo#. The field object $aits for the user to finish typing te#t in the bo#, at $hich point the te#t is returned as an instance of 2String3, say, $hile the field object itself is discarded. 4ote that since the response can be an object, messages to interface objects can be the target of other messages or be passed as parameters in other messages. There are also system classes used principally for their 2side-effects3, ie. their responses to messages are not so much to be found in the objects returned but in changes they cause to the environment, eg. printing information, sending electronic messages, saving information outside the database, etc. -igure , -7 sho$s an interface object designed for printing. The response it generates, an 2ON3 signal in this case, is largely inconse(uential and intended only to inform the message sender of the status of the task.
+ig&re 3-! System objects $ith 2side-effects3 <e should also note at this point that many system classes, not just user interface classes, can cause side-effects. :rinting, especially, is a capability of most system objects, including data structures. That is, their public interfaces include a predefined 2:rint3 method that $hen activated $ill cause information they contain to be printed in some predefined format. -or e#ample, the message
'rint%$Ne;%$Strin,.$@WelcomeA&$&
$ill first create a ne$ string instance containing the te#t string 5<elcome6. This ne$ instance $ill then respond to the 2:rint3 message, causing 5<elcome6 to be printed and passing status data back to the message sender.
3.3 D#na"ic 'inding
"n conventional programming languages, the name of a procedure statically defines the code to be e#ecuted, ie. it is possible to determine at compile time the code to be activated for any procedure call. Suppose for e#ample, the follo$ing procedure $as defined/
Object-Oriented Data Model 'rint_'erson%$Name8$Strin,.$A,e8$N+meric& OP co3e<for<'rint_'erson PQ
The procedure name 2:rintR:erson3 $ill be statically bound to OP co3e<for< 'rint_'erson PQ. * call such as
'rint_'erson%$@NickA.$B)$&
$ill cause a procedure 2jump3 to OP co3e<for<'rint_'erson PQ, after the procedure3s formal parameters 4ame and *ge have been bound to the actual parameters 54ick6 and 7B respectively. *ny call to 2:rintR:erson3 $ill in fact activate the same code, differing only in the actual parameters passed to the formal parameters. This is true even for blockstructured languages that allo$ names to be re-used for procedures defined in inner blocks, since scoping rules in such languages allo$ references to names to be resolved at compile time. "n object-oriented systems, messages play the role of procedure calls and method selectors are analagous to procedure names. "n contrast, ho$ever, it is not possible to determine statically the code to be e#ecuted for a given message. This is because the instance to $hich a message is directed can only be determined dynamically &at run-time' and the code associated $ith the specified selector is likely to be different for objects from different classes.
Suppose for example, there were two classes Employee and Student, each with the method Print defined in its public interface. Suppose further that Nick and Alex are instances of Employee and Student respectively.
The messages/
'rint%$@NickA$&, and 'rint%$@AlexA$& while having the same method selector, will execute different code - that defined in the class Employee for the former, and Student for the latter.
The reader may have noted that the class of an instance e#pression can be statically determined, eg. a message like 24e$& DclassE, P '3 clearly identifies the class and thus any message $ith this e#pression as its target determines the methods &and code' to be activated. -urthermore, instance variables are bound to data classes, and a message template specifies the data class of its response, again suggesting that $e can tell the classes of objects $e are dealing $ith statically. This is true, of course, but objectoriented systems also support inheritance and polymorphism. That is, the actual objects may be instances of derived classes that redefine code for some or all of the methods inherited. "t is not possible therefore to determine the method to invoke until run-time. <e $ill treat inheritance in the ne#t chapter, but for no$, $e $ill simply re-assert that the binding of a method name to e#ecution code is dynamic. The dynamic binding property of object-oriented systems increases their fle#ibility enormously. -or e#ample, the definition of a method in a class does not become overly dependent on the domain bindings of instance variables, as long as the specified domains offer &at least' the same public interfaces used in the method body. This is illustrated in
-igure , -. $hich sho$s the definition of a 2:rint3 method for the class 2)ank-*ccount3. 4ote that the body of the definition sends a 2:rint3 message in turn to the objects in the variables 2O$ner3 and 2SumR*vailable3. *s long as these objects can respond to such a message, it doesn3t matter $hat classes they belong to, ie. $e can change the domain binding of the variables $ithout having to change the method definitionF %g. the domain of 2O$ner3 can be changed from 2Student3 to 2%mployee3, and that of 2SumR*vailable3 from 2Dollar3 to 24umeric3, and the 2:rint3 method $ill still e#ecute correctly provided that 2%mployee3 and 24umeric3 can respond to 2:rint3 messages. Such object transparency, afforded mainly through public interfaces and dynamic binding, plays a very important role in object-oriented systems.
+ig&re 3-% Object transparency through dynamic binding

3.4 !u""ar#
Data associations in object-oriented databases are based on the re-use of objects in the private memory of other objects, ie. on the binding of instance variables to data classes. This is in contrast to the relational data model $hich manifest relationships through foreign keys in relations. The top half of -igure , -> sho$s the familiar e#ample of a relational schema $e have used in earlier chapters. 4ote that the relationship bet$een the entities 2 ustomer3, 2:roduct3 and 2Transaction3 are captured in the latter through the shared attributes 2 S3 and 2:S3. These attributes $ill take on, respectively, values from the corresponding attribute in 2 ustomer3 and 2:roduct3, serving therefore as references &or pointers' to the relevant tuples in those relations. "n contrast, the figure also sho$s in the bottom half a simple and direct translation from relation definitions to data class definitions - each relation corresponds to a data class and the relation3s attributes are represented by instance variables. *n instance of a data class then corresponds to a tuple of the corresponding relation. 4ote, ho$ever, that such instances are directly re-used in the private memory of 2Transaction3 instances instead of being referenced through keys &there is thus no need for the attributes 2 S3 and 2:S3 in the object-oriented model and so $e omit them in our translation from the relational model'.
+ig&re 3-( ?elational vs. Object-Oriented Schema
The object-oriented approach to databases offers the follo$ing advantages/ +. Cevel of granularity of data objects/ Methods may be defined for one data class independently of other data classes and of the overall database structure. Dynamic binding of methods provides capability &such as printing' that is object-transparent and that is resilient to changes in object relationships &such as changing variableIdomain relations'. 1. ?e-use of data objects/ The private memories of instances allo$ the e#pression of arbitrarily comple# associations among them, directly and naturally. The relational model, in contrast, often force the invention of arbitrary key attributes and values to allo$ relationships to be e#pressed through foreign keys. ,. :urpose-oriented behaviour of data objects/ Data classes may be designed to reflect the domain entities and their roles or purposes. "n a real business, for e#ample, transaction records allo$ us to compute the profit8loss of each transaction, or to generate invoices. These purposeorientation is (uite simply modelled by methods. The user interface, in particular, $ill reflect the purpose of the application at hand.
!
4.1
"tatic n#eritance
Introduction
Thus far, $e have seen that data classes define an object-oriented schema. Such data classes are described by users using class definition e#pressions. * user-defined class $ill typically use system-provided classes &and other defined classes' to structure its private memory and define its methods. Memory is structured as a set of variable-domain bindings, allo$ing essentially client-server associations bet$een *DOs, ie. an instance &the client' can call on the services of objects &the servers' that are in its private memory. The resultant database schema, and its instantiations, is therefore a 2flat3 collection of objects in that all objects have e(ual stature and can call on any other object for services published in their public interfaces. Many applications, ho$ever, $ill have entities that have similar private properties, ie. sharing many private memory structures and public methods. "f the only means of structuring available $ere variable-domain bindings, then the description of such entities as data classes $ill see many similar definitions $ith possibly many duplicated parts. -or e#ample, consider the data classes in -igure 7 -+. *ll three classes have in common the instance variables 24ame3 and 2*ffiliation3, and the methods 2;et-4ame3, 2*ffiliation3 and 2:rint3. )ut each also has a uni(ue instance variable and method. ;iven class definition mechanisms discussed so far, these classes $ill have to be defined separately $ith the common components duplicated in each definition. This is $asteful and some means of sharing common definitions $hile still allo$ing for differences is clearly desirable.
+ig&re !-1 Similar classes $ith some common private properties &variables and methods'
4.2 !tatic Inheritance of $ro(erties
Such a means is in fact found in all object-oriented systems and is called static inheritance. The idea is that a ne$ data class can be defined to inherit from an e#isting class all of the latter3s private memory structure and public methods. onsider for e#ample, the situation in -igure +.-1.
+ig&re 1%-2 "nheritance *ssume that the class person has fully defined its instance variables and public methods. <e can e#tend the class definition e#pression introduced earlier to include an inheritance specification, eg.
class$Employee$inherits$'erson:$9
or, e(uivalently, depict such a definition pictorially as sho$n in the figure. Then all properties defined in 2:erson3 becomes also properties of 2%mployee3, even though the latter3s definition makes no e#plicit mention of instance variables or public methods. That is, if $e created an instance of 2%mployee3, that instance can respond to CGet_NameD$ and CGet_AffiliationD messages. <e say in cases like this that 2:erson3 is a superclass and 2%mployee3 is a subclass Of course, there can be many subclasses of a given superclass. -or e#ample, the classes 2Student3 and 2*uthor3 in -igure 7 -+ can also be subclasses of 2:erson3. Subclass definitions therefore achieve the desired sharing of common properties. )ut if this is all $e can do in subclass definitions, a subclass $ould amount to nothing more than a synonym for its superclass. Thus, in addition to inheriting superclass properties, a subclass may additionally define ne$ properties, ie. ne$ instance variables and8or methods. This is illustrated in -igure 7 -1, $hich sho$s the definition of the three classes in -igure 7 -+ as subclasses of the class 2:erson3. 4ote that the inherited properties do not have to be duplicated in the subclasses. "nstead, each subclass need only define properties relevant to itself, thus differentiating itself from the superclass and from sibling subclasses.
+ig&re !-2 "nheritance and Specialisation Subclassing may thus be seen as specialising a superclass to a subset of objects that satisfy added properties. )ut besides adding ne$ properties, specialisation can also involve suppressing and redefining &or overriding' selected properties.
+ig&re !-3 Suppressing properties Suppression discards specified properties. Say, for e#ample, that $e introduce a subclass for people $ho have retired and call it 2?etiredR:erson3 &-igure 7 -,'. * retired person $ill have no affiliation and the method 2;etR*ffiliation3 and the instance variable 2*ffiliation3 are thus irrelevant, ie. $e $ish to inherit all properties e#cept these. "n the subclass definition, therefore, $e e#plicitly suppress these properties. "nstances of 2?etiredR:erson3 $ill conse(uently not have 2*ffiliation3 as a variable nor can they respond to 2;etR*ffiliation3 messages. They other$ise $ould behave like instances of 2:erson3. There are also situations $hen an inherited property is not suppressed but is modified instead, ie. the names of the properties are retained but their attributes are changed. Thus, inherited instance variables may be bound to a different domain, and inherited methods may be assigned different method templates. -igure 7 -7 sho$s a situation $hen overriding the domain binding of inherited variables makes sense. -or e#ample, a student account is a bank account such that the account
o$ner is a student, and a corporate account is also a bank account but the account o$ner must be a firm &company or corporate body'. %ach subclass therefore redefines the domain binding of the 2O$ner3 variable to appropriate domains. 4ote that $hile $e have redefined some variable-domain bindings, the inherited methods remain unchanged, assuming that the public interfaces of the ne$ domains offer at least the same methods as the overridden domains &recall our discussion in the last chapter of object transparency due to dynamic binding'.
+ig&re !-! ?edefining8Overriding inherited variable-domain bindings "f $e $ished, inherited methods can be redefined too. *nd $e may choose to redefine a method in one subclass but not in another. -or e#ample, the 2:rint3 method above may be redefined for the 2 orporateR*ccount3 subclass but not for the 2StudentR*ccount3 subclass &see -igure 7 -.'.
+ig&re !-% ?edefining8Overriding inherited methods *ny class can be the superclass for subclass definitions, including system-provided classes. -urthermore, subclassing can be continued to arbitrary levels, ie. a subclass may itself be the superclass of other classes. -or e#ample, the 2%mployee3 subclass in -igure 7 -1 may be used as the superclass of t$o ne$ subclasses, say, 2:ermanent3 and 2Temporary3. ontinuing in this $ay, an inheritance hierarchy of any depth can be
constructed. Static inheritance therefore introduces a hierachical structure to $hat other$ise $ould be a flat database schema. *n instance of any class in this hierarchy $ill have all the properties of that class, including all ne$ properties it defines and all the unsuppressed and redefined properties it inherits from its superclasses. "t is important to realise that $hile t$o classes may be related through inheritance, their instances are separate *DOs. Thus, if ) is a subclass of *, and ") and "* are their respective instances, the private memories of ") and "* are unrelated. That is, $hile both can have an instance variable named H, the value of H in ") is independent of the value of H in "*. "n other $ords, inheritance is a device for sharing descriptions of properties among data classes - not the sharing of those properties among their instances.
4.3 Abstract Data Classes
<ith inheritance defined, a data class can serve t$o different purposes/ +. *s a template, for the creation of *DOs that $ill populate a database, and 1. *s a superclass describing common properties of a number of subclasses *ny data class may in fact serve both purposes $ithin an application. Mo$ever, there are situations $here a data class is created solely for the second purpose above, $ith no intention of ever creating their instances, or that their instances $ould be incomplete entities and thus meaningless in the application conte#t. "nstead, instances are created only from their subclasses $hich presumably $ill describe additional properties that make them meaningful. Such data classes $ill be referred to as !bstract Data Classes. -or e#ample, an abstract bank account can be described as in -igure 7 ->. "t defines a number of methods and instance variables, but the variables are not as yet bound to any domain. Such incomplete descriptions are allo$ed in the case of abstract data classesT the intention is for subclasses to specialise it and fill in the gaps. *s such, it does not make sense to directly create instances from it.
+ig&re !-( *n *bstract )ank *ccount lass
-rom such an abstract class, $e may derive more complete subclasses, as in/
class$Corporate_Acco+nt$inherits$2ank_Acco+nt:
Object-Oriented Data Model instance %ariables O;ner8$!irm: S+m_Availa4le8$Dollar: end$Corporate_Acco+nt: Domain bindings specified for the variables
The missing domains are filled in by this definition &methods are inherited unchanged'. This then forms a complete class definition and instances can therefore be created from it. ?ecall that a data class represents a set of objects &ie. *DOs' all having the properties and behaviour it describes. * subclass in fact denotes a subset of the objects described by its superclass. "n other $ords, an object that is a member of the subclass is also a member of the superclass. <e should clarify at this point the distinction bet$een being 2an instance of3 and being 2a member of3 a data class. <hen $e say that an object is 2an instance of3 some class, that object $as created by sending a 24e$3 message to that class. Obviously, it is also 2a member of3 that class. *dditionally, ho$ever, if the class has a superclass, the object is also 2a member of3 the superclass, even though it is not 2an instance of3 the superclass. lass membership, rather than instantiation, is the basis for type checking &eg. parameters in messages, values to be assigned to instance variables, etc'. "n the 2:rint3 method definition above, for e#ample, the e#pected parameter is a 2)ankR*ccount3 object. This is actually interpreted to mean any object that is 2a member of3 the 2)ankR*ccount3 data class. Thus, any instance of a class that directly or indirectly inherits from 2)ankR*ccount3 is a valid parameter. This is $hy, $hen $e defined 2 orporateR*ccount3, $e do not need to modify the method template.
+ig&re !-$ ?ole of abstract system classes in object-oriented databases *bstract data classes play a very important role in object-oriented systems. Many system data classes, for e#ample, are really defined as abstract classes. Static inheritance then allo$s users to derive from these abstract classes ne$ application-specific classes. The idea of persistent database objects is in fact abstracted to a special abstract class called 2DatabaseRObject3, and all other classes describing database objects inherit properties from it, such as to store8delete an object into8from the database. This is illustrated in -igure 7 -A.
Object-Oriented Data Model 4.4 Definition of an Object-Oriented D'M!
<e can no$ define more precisely $hat an object-oriented D)MS is. Specifically, it is one that/ +. provides a number of system data classes designed for database creation0 these include classes to define persistent database objects, to create data structures, and to create application-specific user interfaces for data manipulation 1. supports static inheritance and class definition e#pressions to create user-defined application-specific data classes ,. allo$s users to create, modify and access a database through predefined methods of the system data classes
4. !u""ar#
Static inheritance allo$s us to define a ne$ data class 4 &the subclass' from an e#isting data class &the superclass' by/ a' adopting for 4 all the properties of &ie. 3s memory structure and methods', then b' &optionally' suppressing in 4 some of the adopted properties, then c' &optionally' adapting &redefining or overriding' in 4 some of the adopted properties, and finally d' &optionally' adding in 4 ne$ properties not found in Typically, the definition of 4 $ill include some suppression or adaptation or addition of properties &although they are optional' - other$ise 4 $ould only be a synonym for . Static inheritance is basically a descriptive device, allo$ing several classes to share the same property descriptions. Many applications benefit from this since they usually involve many similar entities that can be organised in an inheritance hierarchy. Static inheritance facilitates a concise and natural definition of such entities as data classes. Some data classes are used only as superclasses, ie. no instances are ever created from them. Such classes are termed !bstract Data Classes. They play an important role in object-oriented systems and many system data classes are abstract. "n particular, the abstract class 2DatabaseRObject3 defines many basic properties needed by persistent database objects. 9sers define application-specific data classes by inheriting properties from abstract data classes provided by an object-oriented D)MS. <e have largely used, and $ill continue to use, an informal graphical notation to e#press object-oriented concepts. This is because our focus is more on the general properties of object-oriented database systems rather than any specific formal system. The main notations for static inheritance are summarised in -igure 7 -G.
+ig&re !-- Summary of graphical notation for static inheritance
%
.1
Dynamic and M&lti'le n#eritance

Introduction
Static inheritance & hapter +.' is a descriptive device to define ne$ data classes from e#isting data classes. ?ecall that a data class is defined by describing its private memory structure and methods & hapter +,'. <ith static inheritance, part of this description can be achieved by a combination of adopting, adapting and suppressing the memory structure and methods of an e#isting, similar data class - the superclass. The resultant description may also be e#tended $ith definitions of ne$ memory structures and methods not available in the superclass. Static inheritance e#tends the class definition apparatus and is orthogonal to variabledomain binding specifications of private memory structure. The latter in fact describes a relationship bet$een intances of data classes. That is, if a data class binds a domain S &another data class' to one of its instance variables H, it really says that any member of can take any member of S as the value for H +. Different members of of course have their o$n private copy of H. "n contrast, static inheritance e#presses a relationship bet$een data classes only, not bet$een the private memories of their instances. That is, if $ere the superclass of S, an instance of S does not inherit memory values from an instance of F Their private memories are in fact independent of each other. "n many database applications, ho$ever, inheritance of memory values of one instance by another is a useful feature. onsider, for e#ample, the database of departments and their employees. Cet3s assume there can be an arbitrary number of departments and each department can have an arbitrary number of employees. %ach employee, ho$ever, can belong to only one department. To model this in object-oriented terms, $e define t$o data classes/ 2Department3 and 2%mployee3. 2Department3 has the variables 2Title3 and 2DR:hone3 to hold respectively the name of the department and its general line phone number. 2%mployee3 has the variables 24ame3 and 2:hone3 to hold respectively an employee3s name and personal e#tension, if any. This is illustrated in -igure +>-+ &a', $hich also sho$s some associated methods of each class. The database itself $ill therefore be clusters of instances $herein each cluster $ill have one 2Department3 instance and one or more 2%mployee3 instances that belong to it &-igure +>-+&b''. learly, there is a relationship bet$een an instance of employee and the instance of department. <e should, for e#ample, be able to get the department name given an employee instance. -urthermore, if the department name $ere to change, that change should be reflected in all associated employee instances. That is, $e $ould like employee instances to inherit the value of 2Title3 from the department instance. Static inheritance cannot do this &thus the 2@3 in the relationship dra$n in -igure +>-+'.
4ote that $e use 2member of3 rather than 2instance of3 since this more accurately describes the semantics of variable-domain bindings &in a system that supports static inheritance and abstract data classes'. Of course, the member of , if not also an instance of , must not have suppressed the variable H.
+
+ig&re %-1 * DepartmentI%mployee Database %#ample <e can actually represent the re(uired relationship above using variable-domain bindings, as follo$s. Define in the 2%mployee3 data class a variable called 2Dept3 and bind it to the domain 2Department3 &see -igure . -1'. The idea is that every instance of employee $ill re-use the instance of department they belong to as the value of their 2Dept3 variable. To get the department name from an employee instance, $e must also define a method that relegates the task to the instance held in the 2Dept3 variable. *nother method $ill also be needed to set the 2Dept3 variable, say, 2Set-Dept3 &not sho$n in the figure'. 4ote that in this solution to the problem, adding an employee to a department is a t$o stage process/ first, create a ne$ employee instance, then send it a message to set its department to a selected instance of department &assuming it already e#ists in the database'.
+ig&re %-2 %stablishing instance relationships through variable-domain bindings The solution using variable-domain bindings re(uires e#plicit 2programming3 on the part of the developer. *lternatively, dynamic inheritance provides a $ay of implicitly establishing instance value and method inheritance among data class instances.
Object-Oriented Data Model .2 D#na"ic Inheritance
Dynamic inheritance among instances of data classes are still specified at the level of data class definitions. To distinguish bet$een static and dynamic inheritance, $e $ill use the graphical notation as sho$n in -igure .-, to denote the latter &ie. double lines and borders as opposed to single lines and borders for static inheritance'.
+ig&re %-3 Dynamical "nheritance 4otation <hen a data class S dynamically inherits from a data class / a' %very instance of S $ill be associated $ith one, but not necessarily the same, instance of . %ffectively this describes the cluster organisation as sho$n in -igure .-+ b' *n instance of S $ill inherit all the private memory structure and contents of the instance it associates $ith, unless e#plicitly suppressed or redefined c' *n instance of S $ill inherit all the methods defined in , unless e#plicitly suppressed or redefined &as per static inheritance' Thus, the definition in -igure .-, admits clusters of instances each of $hich contains a department instance and one or more employee instances. %ach employee instance in a cluster $ill inherit the memory structure and contents of the department instance. -urthermore, each also inherits the methods defined in the 2Department3 data class, e#cept for 2Set-:hone3 and 2;et-:hone3 $hich are e#plicitly redefined in the 2%mployee3 data class. "nheritance of the memory structure and content is best interpreted as sharing, rather than copying. Thus, if a department instance is sent a 2Set-Title3 message, the ne$ value of its 2Title3 variable $ill be instantly available to all employee instances associated $ith it. "n a similar fashion, inheritance of methods is best thought of as an indirection, ie. if a message to an inherited method is received, it is resent to the 5super-instance6. Thus $e can send a 2;et-Title3 message to an employee instance and receive in response the value in the 2Title3 variable of the associated department instance. 4ote that $e can also send a 2Set-Title3 message to an employee instance-the effect $ill be e(uivalent to directly sending the message to the associated department instanceF "n effect, the super-instance becomes a server of values and their manipulation &through methods' for the sub-instances $hich constitute its clients. This is similar in principle to the client-server relation established through variable-domain bindings. The difference,
ho$ever, is that relations through variable-domain bindings must be e#plicitly installed and managed, ie. methods must be $ritten to install a server in the client3s memory and to resend messages to it. "n contrast, the client-server relation under dynamic inheritance is established at client creation time. More specifically, creating an instance inheritance hierarchy involves the follo$ing steps/ a' create an instance of the superclass, ie. the server, by the normal mechanism of sending a 24%<3 message to the corresponding data class b' create an instance of a client by sending the 24%<3 message to the serverF Step &b' may be repeated to install as many clients as re(uired for any given server. Maving done this, the system $ill automatically manage all such client-server communication. 4ote that in step &b' above, the 24%<3 message is sent to an instance rather than a data class. This is only defined $hen dynamic inheritance has been specified. That is, the 24%<3 method of a subclass of a dynamic inheritance definition is relegated to instances of the superclass &ho$ever, see ne#t section'. Of course, client-server behaviour does not apply to overridden properties. Thus, the message to 2Set-phone3 sent to an employee instance $ill change that instance3s memory, leaving the server memory unchanged. Cike$ise, 2;et-phone3 sent to an employee instance $ill return the value of 2:hone3 rather than 2DR:hone3. Mo$ever, if ne$ or overridden client methods deal $ith inherited instance variables, messages addressed to such variables $ill be resent to the server.
In object-oriented systems that support both variable-domain bindings and dynamic inheritance, the user of course has a choice over which method to use to address situations exemplified by the department-employee database. Variable-domain bindings are more general, allowing arbitrary configurations or organisations of instances. Dynamic inheritance forces a particular configuration of instances, but where such configurations are intended, it is more convenient and natural.
.3
Multi(le Inheritance
Simply put, multiple inheritance is the inheritance of properties from t$o or more superclasses &see -igure . -,'. "n the case of static inheritance, the effect of multiple inheritance is the union of properties of the superclasses. Thus, in -igure . -,, class $ill have variables J and K and methods + and 1 defined for its instances.
+ig&re %-3 Multiple inheritance There are obviously conditions for this to be a $ell-defined subclass definition. -irst, if a variable name appears in more than one superclass, the domain it is bound to in all its occurrences should be the same. %ven then, different methods that manipulate the variable must be e#amined to see that they $ould not interfere $ith one another, since in the subclass there $ill be only one copy of the variable. On the other hand, if the variable is bound to different domains in different superclasses, it suggests they serve different purposes and often renaming the variables $ill remove the problem &of course, occurrences of the variable in method bodies must also be amended'. Second, if a method name occurs in more than one superclass, their definitions must be e#amined. %ven if their definitions are identical, $e must ascertain that the variables they use serve the same purpose over the different classes. "f not, the variables and the method name should be renamed. On the other hand, if their definitions are different, then renaming the method name may be sufficient. These are (uite comple# conditions and are usually difficult to ascertain. The simplest condition to guarantee $ell-definedness for static multiple inheritance is orthogonality of the superclasses, ie. $hen they do not have common properties. -or these reasons, static multiple inheritance is rarely used in practice. Dynamic multiple inheritance, on the other hand, turns out to be (uite useful and suffers less of the problems mentioned above. *n e#ample is sho$n in -igure . -7. * 2:erson3 dynamically inherits from a 2-irm3 and a 2Soccer Team3. "ntuitively, this models a database of persons and, for each person, the firm he8she is affiliated $ith and the soccer team he8she plays for. %ffectively, such multiple dynamic inheritance sets up multiple servers for a given client, and messages sent to the client $ill be automatically rerouted to the appropriate server. Thus, the message 2;et-Title3 sent to a 2:erson3 instance $ill be rerouted to and serviced by the 2-irm3 server, $hereas the 2;et-Team3 message $ill be rerouted and serviced by the 2Soccer Team3 server.
+ig&re %-! Dynamic Multiple "nheritance %#ample Of course, the server classes above are already orthogonal to one another and no ambiguities arise in handling incoming messages. *mbiguities $ill arise only if the different superclasses have methods of the same name. )ut this is easily circumvented by renaming. ommon variable names in the superclasses do not cause problems since they e#ist in their o$n memory space, so long as methods that operate on them are not redefined and no ne$ methods that refer to them are defined in the subclass. There is a slight problem, though, $ith regard to installing multiple servers. The mechanism of relegating the 24%<3 method of the subclass to superclass instances is not appropriate as there is more than one superclass. Different object-oriented systems may differ in ho$ they handle this, but the essential operation is creating a client object and binding it to one or more server objects. * uniform approach, therefore, is to retain the 24%<3 method $ith the subclass but to include in the message template parameters that represent the servers of the client object to be created.
.4 !u""ar#
Dynamic inheritance allo$s us to describe and establish run-time relationships bet$een instances. The relationship is essentially that of a client &an instance of the subclass' and a server &an instance of the superclass'. "t differs from variable-domain relationships in that it describes a particular organisation of instances - essentially clusters of clients served by a server &or more, in the case of multiple inheritance' - and that client-server communication &through messages' is automatically managed by the system. )ecause it deals $ith instance relationships, it is sometimes also referred to as instance inheritance. Dynamic inheritance and variable-domain specifications of instance relationships may be used in combination. The latter, $hile general enough to describe any configuration of instances, may be a little too cumbersome for situations that dynamic inheritance naturally models. The choice, ho$ever, is $ith the user. Multiple inheritance - inheriting properties from more than one superclass - can be applied to both static and dynamic inheritance. The comple# conditions of $ellformedness for static multiple inheritance, ho$ever, makes its use rare in practice. Dynamic multiple inheritance, on the other hand, is useful, offering a means of setting up multiple servers for a client.
(
).1
Object dentity and Database )&ery

Introduction
"n chapter +., $e characterised an object-oriented D)MS as one that/ a' provides a number of system data classes designed for database creation0 these include classes to define persistent database objects, to create data structures, and to create application-specific user interfaces for data manipulation b' supports inheritance and class definition e#pressions to create user-defined application-specific data classes c' allo$s users to create, modify and access a database through predefined methods of the system data classes These primary functions are depicted in -igure > -+, sho$ing particularly a key system data classT 2Database Object3. *ll database objects derive from it, ie. applicationspecific data classes defined by users inherit directly or indirectly from it, as do all other system classes including the data structure classes. *ll database objects therefore inherit from 2Database Object3 some necessary methods for database manipulation, particularly the 2Store3, 2Delete3 and 2;et3 methods.
+ig&re (-1 Object-oriented database creation and retrieval "t is important to realise that $hen an object is created, it is not automatically inserted into a database. "n other $ords, objects may be created and manipulated during a user session $ithout ever inserting them into a database. Such objects $ill be transient, ho$ever, and are discarded at the end of a session &user interface objects are mainly of this type'. To be part of a database, an object must be e#plicitly inserted. This is the function of the 2Store3 method. Once inserted, objects $ill persist unless e#plicitly removed. *nd this is the role of the 2Delete3 method. The 2;et3 method is for non-destructive retrieval of database objects, and thus central to database processing. "ts message template is/
Object-Oriented Data Model Get$%Tar,et8$O45ect&$Response8$O45ect
2Object3 in the template above is an abstract system class that is the superclass of all classes. "n other $ords, any *DO $e create $ill be a member of 2Object3. Thus, the target of a 2;et3 message can be any *DO $hatsoever. Cike$ise, the response to a 2;et3 message can also be any *DO. The 2;et3 message sent to a database object, returns the target object itself, $hich can then be manipulated in the usual $ay &eg. to print, to update its state, etc', and later restored into the database if necessary. This is illustrated in -igure > -1. "n the illustration, the target object is specified by its identity. )ut if $e must al$ays e#plicitly specify the target object identity, 2;et3 $ould be (uite uninteresting and some$hat limited in use. Database retrieval capabilities should also include implicit specifications of target objects, particularly involving predicates over object states. "n other $ords, $e should also be able to retrieve objects based on their &partial' content.
+ig&re (-2 Database object retrieval using the 2;et3 message ?emember that an object may be a data structure, ie. a collection of other objects. Thus it is also possible for the target and response to 2;et3 to be a collection of objects. <hat $e $ould really like is to send 2;et3 to a collection &perhaps the entire database' and receive a response $hich is a smaller collection satisfying certain predicates over states of the target collection3s objects. "f $e can do this, $e can cascade 2;et3 messages such that the result of one becomes the target of another, until the desired object is retrieved. This more general (uery facility is the focus of this chapter.
).2
Object Identit# and Addressabilit# S$%$T.$'&
Cet us re-e#amine the anatomy of a message. %ach message comprises three components/ $here S is a selector &ie. method name', T is the target object to $hich the message is directed, and : is =ero or more parameters. So far in our discussion, $e have assumed
that T is a name that uni(uely identifies some object. "n most object-oriented systems, ho$ever, T in fact comprises t$o components/
T$E$F6scope7?G$6o45ect$i3entity7
DscopeE is a collection of objects that can potentially receive the message. "t is optional and, if omitted, the implicit scope is the entire database. Dobject identityE specifies an object in the conte#t of the specified DscopeE. T, therefore, is a (ualification e#pression in the dot &2.3' notation that should be familiar to programmers. * (ualification e#pression, in fact, is the general form for specifying objects, and thus applies to the parameters of a message as $ell. More specifically, $e define (ualification e#pressions as/
D(ual-e#prE //U Dobject identityE D(ual-e#prE //U DscopeE.Dobject identityE D(ual-e#prE //U D(ueryE D(ueryE //U DscopeE.DpredicateE DscopeE //U D(ual-e#prE
Dobject identityE specify objects in $ays $e $ill elaborate belo$. D(ueryE $ill be elaborated in the ne#t section. ?ecall that object creation introduces objects and assigns them uni(ue identities. These identities are generally not directly available, ho$ever, to the user. 9sers must $rite, instead, e#pressions that denote object identities. *n Dobject identityE e#pression can be/ a uni(ue global name local variable name a class name a message Uni0&e 1lobal 2ame The identity assigned to an object at the time of creation is an internally generated system identity. Many systems, ho$ever, allo$ users to specify &probably as part of the 24%<3 message' a uni(ue global name8identifier to be associated $ith the object. 9ser $ritten e#pressions can then directly use such names to refer to the objects. <e have in fact been doing this in our e#amples, ie. assuming a global name for objects and using them in e#ample messages &such as 2),>3 in -igure > -1'. 3ocal 4ariable 2ame The use of variable names to denote objects have in fact been illustrated in numerous preceding e#amples, particularly involving method body definitions. )y 2local variables3, $e mean the instance variables and the formal parameter names in message templates of a given class. )oth types of variables hold at run-time particular object identity values. Their appearance as Dobject identityE may therefore be interpreted as evaluating to the object identity they hold.
+ig&re (-3 Cocal variable names as object e#pressions -igure > -, sho$s a class $ith instance variables in its memory and a formal parameter variable in one of its methods. 4ote the target specification 5T.O$ner6 in the method body, $hich uses the formal parameter variable T as DscopeE and instance variable 2O$ner3 as Dobject identityE. The object it denotes is determined as follo$s. -irst, 2T3is evaluated to the object identity value it holds. 4e#t, in the scope of this object, the instance variable 2O$ner3 is resolved. This simply means retrieving the value of 2O$ner3 in that object3s memory, $hich then is the desired object. Class 2ame * data class name of course conceptually denotes all possible objects that fits its description. <hen used as an Dobject identityE, ho$ever, it denotes the collection of e#isting database objects that are its members &ie. only those objects that have been stored in the database'. Thus given the class 2)ank *ccount3 as in -igure > -,, $e can $rite/
Get%$C2ank$Acco+ntD$&
4ote that as the scope is omitted, it defaults to the entire database. This message therefore serves to select from among all database objects only those that are members of 2)ank *ccount3 and returns them as a collection object. 4ote that $e say members rather than instances, ie. instances of subclasses, if any, are included. This means that abstract data class names can be used as Dobject identityE as $ell.
Message <e have already e#plained earlier ho$ messages, because they evaluate to objects, may be used to denote objects. Thus they can be used as Dobject identityE.
).3 *uer# +,(ressions
The previous section tells us ho$ objects may be addressed, and to a certain e#tent $e can achieve object selection through the use of class names and method invocations.
More po$erful selection facilities, ho$ever, must allo$ selection based on object contents. -or e#ample, $e may $ish to select only those 2)ank *ccount3 objects $hose o$ner is 5Smith6. This suggests that $e must provide comparison operators such as 2U3, 2E3, 2D3, etc., to allo$ us to $rite predicates over object states. <e $ill then need a $ay to $rite/ Dthe o$ner of this accountE U 5Smith6 ;iven a 2)ank *ccount3 object, say ), $e cannot of course $rite e#pressions like
2?O;ner?Name
since it presumes kno$ledge of the internal structure of ) &and for that matter the internal structure of the class 2:erson3 as $ell'. Our only recourse is send messages to the object to access its state. Thus, if $e assume that the 2;et-O$ner3 method returns a string object representing the o$ner3s name, $e can $rite/
Get*O;ner%$2$&$E$@SmitHA
This predication applies to one object and denotes a truth value. This is the form that DpredicateE takes. 4o$ $e need to apply predicates such as these to a collection of objects &the scope' to cause the selection of only those objects satisfying the predicate. The scope and the predicate together forms a (uery 5DscopeE.DpredicateE6. The predicate $ill typically involve messages targeted at objects in scope. Since the target objects are implicit in the scope, messages in the predicate omit specifying them. Thus, selecting bank accounts o$ned by 5Smith6 $ould be $ritten as in the follo$ing illustration &note that the 2;et-O$ner3 message does not have to specify a target'/
Get%$C2ank$Acco+ntD&$$.$$$Get*O;ner$E$@SmitHA The query, denoting all objects in scope satisThe predicate The scope: all Bank Account A message targeted to each object in scope
4ote that a D(ueryE also denotes an object, specifically a collection object, and may therefore be the target of a message. -or e#ample/
'rint%$Get%$C2ank$Acco+ntD$&?$Get*O;ner$E$@SmitHA$&
*s further e#amples of (uery construction, assume a database populated $ith objects of classes in -igure > -7. *ssume further that for each class, there is a method 2;et-"3 to retrieve the value of instance variable ".
+ig&re (-! Schema for Luery %#amples &see te#t' #uery/ ;et customers $ho bought a :9. There are several $ays this (uery can be constructed. "n one, $e observe that the re(uired customer objects can be retrieved from transaction objects of :9 sales. * transaction object T is for a :9 if the follo$ing is true/
Get*'name%$Get*'ro3+ct$%T&$&$E$@C'UA
The collection of :9 transactions, therefore, is represented by the (uery/

Get%$Transaction$&?$Get*'name%$Get*'ro3+ct$&$E$@C'UA
<e can no$ use this as the scope to get the desired customers/
%$Get%$Transaction$&?$Get*'name%$Get*'ro3+ct$&$E$@C'UA$&?$Get*C+stomer
*lternatively, $e observe that product objects are associated $ith a collection of transaction objects. Thus, $e can retrieve all the transactions for :9 from the product object for :9. The latter is simply the (uery/
Get%$'ro3+ct$&?$Get*'name$E$@C'UA
*ll the relevant transaction&s', therefore, is given by/

%$Get%$'ro3+ct$&?$Get*'name$E$@C'UA$&?$Get*Transactions
and finally, the desired customer&s' is e#pressed by/

%$%$Get%$'ro3+ct$&?$Get*'name$E$@C'UA$&?$Get*Transactions$&?$Get*C+stomer
#uery/ ;et products purchased by customers from ;ra=. *gain there are several possible constructions, of $hich $e $ill develop one. The reader may attempt other constructions as an e#ercise. <e observe that from a customer object, $e can retrieve all his8her transaction objects, and from each transaction $e can retrieve the product purchased. Of course, $e are only interested in customers from ;ra=, thus $e use the (uery/
Get%$C+stomer$&?$Get*Ccity$E$@GraIA
This then becomes the scope to retrieve transactions/

%$Get%$C+stomer$&?$Get*Ccity$E$@GraIA$&?$Get*Transactions
This, in turn, becomes the scope to retrieve the desired products/

%$%$Get%$C+stomer$&?$Get*Ccity$E$@GraIA$&?$Get*Transactions$&?$Get*'ro3+ct
The notation used here is not that of any particular object-oriented (uery language, nor is it proffered as one. <e use it here only to facilitate description of the principal concepts of object-oriented (ueries. ?eal object-oriented systems fre(uently use more concise notations. -or e#ample, the (ualification e#pression above might be $ritten as/
C+stomer?Get*Ccity$E$@GraIA?Get*Transaction?Get*'ro3+ct
Lualification e#pressions are assumed to be left-associative, so parenthesis may be omitted. 2;et3 may be assumed to be performed on object identities $hose objects have not yet been retrieved from the database. -inally, $e note that a collection of objects is also necessarily a set &no t$o objects can have the same identity in the same collection'. Thus, conventional set operations can be applied to them and, in particular, to (ualification e#pressions that evaluate to collections. This allo$s us to handle (ueries such as 5;et products purchased by customers from ;ra= or Hienna6 simply as a union of products purchased by customers from ;ra= and products purchased by customers from Hienna/
%$C+stomer?Get*Ccity$E$@GraIA?Get*Transaction?Get*'ro3+ct UN1ON C+stomer?Get*Ccity$E$@"iennaA?Get*Transaction?Get*'ro3+ct$& Similarly, queries involving conjunctions can make use of set intersection, negation can make use of set difference, and so on.
).4
!u""ar#
*d-hoc (uery construction is not generally considered a po$erful feature of objectoriented databases. The reader can see from the foregoing that (ueries can be cumbersome to construct and re(uires considerable understanding of object-oriented concepts. More often, therefore, (ueries are anticipated by database developers, built into data classes as methods and provided through easy-to-use interfaces for database users. -or e#ample, the 2 ustomer3 class may have the follo$ing method pre-defined/
Get*'ro3+cts$%$T8C+stomer$&$R8$Collection %$Set$%R.$Get%$T?Transactions?Get*'ro3+ct$&&$&
* user then need only identify a particular customer to see all the products that he8she had purchased. Other similar retrieval methods may be thus embedded into data classes to hide the comple#ities of database retrieval from the end-user. )ecause ad-hoc (uery facilities are poor, greater onus is on the object-oriented database developer to anticipate uses of the database and to predefine them in user interfaces than if database systems $ith more friendly end-user (uery facilities $ere used.
$
-.1
Metale*el +acilities and Database Arc#itect&re

Introduction
"n section +7., $e introduced dynamic binding - the run-time binding of e#ecution code to a message. Static binding is not possible because the e#ecution code for a message selector depends on the target object and the latter is only kno$n at run-time. 2:rint3 messages are good e#amples of the need for dynamic binding/ many objects provide a public method named 2:rint3 but each object may define them differently0 thus the code to e#ecute the message 5:rint& DtargetE, P '6 can only be determined once the class that DtargetE is an instance of is kno$n. This turns out to be an important and vital feature of object-oriented systems. The po$er and economy of static inheritance $ould other$ise be impaired $ithout it. "t allo$s, for e#ample, methods to be inherited unchanged from a superclass $hile changing the domain binding of some instance variable&s'-so long as the ne$ domain can react to at least the same messages that the old domain could. This is illustrated in -igure A -+. 4ote that even though the subclass redefines the domain binding of the variable 2O$ner3, the inherited method 2:rint3 remains unchanged since dynamic binding $ill ensure that the message 5:rint& T.O$ner '6 $ill invoke the right code definition. *bstract data classes, in particular, rely on this property to pass do$n methods to subclasses.
+ig&re $-1 ?ole of dynamic binding in static inheritance <hile methods are dynamically bound to messages, note that instance variables are statically bound to their respective domains $hen a class is defined. There is nothing $rong $ith this and many object-oriented systems provide little beyond this. Such systems are thus characterised by a static schema, ie. a set of data classes that do not change at run-time0 only objects and their states do. <hen there is a need for a ne$ data class, say a ne$ type of account, the schema must be modified &off-line by a database administrator' by adding a ne$ data class.
-or many applications, this suffices. Mo$ever, there are arguably situations that can benefit from an ability to create data classes at run-time. This $ould open up, for e#ample, opportunities to $rite intelligent object-oriented database applications that modify their o$n schema to adapt to a changing environment. Thus, for the banking e#ample above, it is conceivable that the application includes facilities for end-users to interactively define attributes for a ne$ type of account and cause a ne$ data class representing such accounts to be generatedF The reader might $onder at this point $hy $e should bother $ith subclassing at all, if all $e $ant to do is redefine a variable3s domain, such as in -igure A -+. <hy not just make the 2Object3 data class the domain of 2O$ner3 for e#ample@ Then any object $ill be a valid value and there $ould not be any need to subclass 2)ank *ccount3 just to change the domain of 2O$ner3F This is true of course, but it defeats the purpose of typing and of creating different data classes in the first place. Object-oriented data modelling is intended to structure the universe of objects and this means typing objects through data classes &objects $ith similar attributes'.
-.2 Meta%ariables and Metaclasses
One approach to the dynamic creation of data classes is to e#tend the idea of abstraction to data classes themselves. That is, just as a collection of similar *DOs is abstracted or described by a data class, $e abstract or describe a collection of similar data classes. Then, $e can create a data class from its abstract description just as $e can create an *DO from a data class. "n describing things, $e distinguish bet$een the description formalism and the things being described. The latter are said to be at the 2object-level3 &the objects of description' $hile the descriptive constructions are said to be at the 2meta-level3. Thus for e#ample, $e may use Malay sentences to describe the %nglish language, ie. Malay is used as a metalanguage for %nglish. Or, as $e have done in this te#t, $e use )4--like constructions as a metalanguage for various object-level language constructions like relational calculus. "t is possible also that a formalism is used as its o$n metaformalism, eg. using %nglish to talk about %nglish sentences. Making use of this distinction, $e could have called data classes 5metaobjects6-objects that e#ist at the meta-level and $hich describe *DOs. "n like manner, $e $ill call the objects describing data classes 5metaclasses6 &$e could use 5meta-metaobjects6, but this gets a bit a$k$ardF'. The particular form of metaclass $e $ill discuss here looks very much like a data class e#cept that the domain of an instance variable can be an identifier other than an e#isting data class name and interpreted as a variable that can take data class names as its value. 4ote that such an identifier is a variable only at the meta-level and, to avoid confusion $ith object-level variables, $e $ill refer to it as a 5metavariable6. ;iven a metaclass $ith metavariables, the idea then is to derive from it a data class definition by dynamically binding metavariables to data class names. This approach therefore introduces a dynamic binding of instance variables to domains.
The creation of a data class from a metaclass, just like the creation of an *DO from a data class, is an instantiation process. That is, data classes are instances of metaclasses and are created in response to 24%<3 messages sent to metaclasses. Thus, just as data classes are vie$ed as cookie cutters or factories for *DOs, metaclasses are factories for data classes.
+ig&re $-2 Metaclass Definition Defining a metaclass is very similar to defining a data class/ +. Define a uni(ue name for it 1. Define its private memory structure ,. Define its public methods This is illustrated in -igure A -1 &assume that $e have decided to make 2)ank-*ccount3 a metaclass instead'. 4ote t$o points of difference compared to a data class definition. -irst, the use of metavariables-2 lass-Of-O$ner3 and 2 lass-Of-Sum3 are metavariables that can take e#isting data class names as values. Second, such metavariables and metaclass names can also be used in message templates as the type of formal message variables. The 24%<3 message template for a metaclass specifies the binding of metavariables to class names. -or e#ample, the 24%<3 template for the metaclass 2)ank-*ccount3 above $ould be/
CNEWD%$2ank*Acco+nt.$$Class*Of*O;ner8$Class.$$Class*Of*S+m8$Class.$9$&$9
$here 2 lass3 is a system-defined abstract class of classes. * 24%<3 message must therefore provide names of e#isting data classes as parameters. The result $ill be a data class definition $ith all occurrences of metavariables, including those in method definitions, replaced by corresponding class names in the message. -or e#ample, to create the 2Student-*ccount3 data class, issue the message/
CNEWD%$2ank*Acco+nt.$St+3ent.$N+meric.$9$&
The result is illustrated in -igure A -,. 4ote that occurences of metanames are replaced by data class names.
+ig&re $-3 Data class created from the metaclass 2)ank-*ccount3 "n defining metaclasses, $e can use static inheritance. * sub-metaclass $ill inherit the super-metaclass3 memory structure and methods, unless overridden, and can add ne$ instance variables and methods. This is ilustrated in -igure A -7.
+ig&re $-! Static inheritance applied to metaclasses Thus, an object-oriented system supporting static inheritance and metaclasses have t$o parallel inheritance hierarchies/ a metaclass hierarchy and a data class hierarchy, as illustrated in -igure A -.. *ll metaclasses inherit from the super-metaclass 2 lass3. "nstances of metaclasses, ie. data classes, are therefore members of 2 lass3 &thus the use of 2 lass3 as the type of metavariables in 24%<3 message templates'. *nd as $e have seen earlier, all data classes inherit from the superclass 2Object3 and their instances, ie. the *DOs, are thus members of 2Object3.
+ig&re $-% :arallel Static "nheritance Mierarchies "n such systems, users have a choice of either creating a data class e#plicitly using data class e#pressions or creating a data class by sending a 24%<3 message to a metaclass. ;enerally, ho$ever, e#plicit definition of data classes are sufficient for most practical purposes. Metaclasses tend to be used in specialised applications $here meta-level abstractions are re(uired to manipulate classes directly, rather than just their objects. The metaclass as described is, in any case, not $idely supported amongst e#isting objectoriented systems. <hether or not they $ill gain $ide support still remains to be seen.
-.3 Architecture of Object-Oriented Database !#ste"s
Cet us revie$ no$ the principal concepts and components constituting an object-oriented database system. -irst is to note the very important role played by abstract data classes and static inheritance. *n object-oriented D)MS provides a number of system data classes and many of these are defined as abstract classes. The idea of persistent database objects and the general properties governing their creation, manipulation and deletion, is in fact captured as an abstract class called 2DatabaseRObject3. *ll database objects are members of this abstract class. 9sers can also define abstract data classes to organise their description of an application domain. Through the po$er and economy of static inheritance, hierachies of data classes leading to application-specific data classes may be defined. This is illustrated in -igure A ->.
+ig&re $-( The role of *bstract Data lasses in Object-Oriented Databases The architecture of an object-oriented database system is depicted in -igure A -A. The database schema defines data classes and their associations $ith one another. *ssociations may be e#pressed through variable-domain bindings and through inheritance &both static and dynamic'. The database is the set of persistent data objects that are instances of data classes in the schema. Thus, the schema determines all possible objects that can populate the database. 9sers interact $ith the system by sending messages to data objects and receiving their responses. The types and structure of messages and responses are predefined in the database schema, ie. the public interfaces of data classes &and their instances'. The set of public interfaces therefore constitute the Data Manipulation Canguage &DMC' of the system.
+ig&re $-$ *rchitecture of an Object-Oriented Database System The message server is the component of the database system that handles e#ternal and internal messages. %#ternal messages are those that come from or go to the user, such as a (uery and its response. "nternal messages are those generated and passed bet$een database objects, such as those generated in e#ecuting a method body. The message server in both cases is responsible for the proper handling of messages. The database
schema is heavily used in deciding $hat to do $ith messages, as it contains the definition of methods and instance variables. The former is needed to e#ecute an incoming message and the latter is needed to get identities of objects to pass messages to.
-.4 !u""ar# and Conclusion
The follo$ing features of an Object-Oriented Database System distinguish it from Object-Oriented :rogramming Canguages/ +. Data Objects are persistent, e#ist independently of user sessions and can be shared bet$een users &-igure +G-G &a''. 1. Data Objects have states that can change over time and may thus react differently to the same message at different times. -igure +G-G &b' sho$s an object3s response to the same message, returning 2J3 before and 2K3 after a state changing transaction has been applied to it.
+ig&re $-- Object :ersistency oupled $ith dynamic binding, these features have important conse(uences in respect of error detection and database recovery &from interrupted or failed transactions'. "n databases $ith comple# inheritance hierarchies, and particularly $hen those hierarchies evolve over time in response to changing or ne$ user re(uirements, it is e#tremely difficult to fully 2debug3 database behaviour. The most common fault arises from secondary messages. -or e#ample, suppose $e had the follo$ing data class/
class$2ank*Acco+nt: instance %ariables S+m*Availa4le8$N+meric:
Object-Oriented Data Model "ethods Transfer%$To8$2ank*Acco+nt.$S+m8$N+meric.$!rom8$2ank*Acco+nt$&$R8$ #o,ical: F J%$To?S+m*Availa4le.$S+m$&: <%$!rom?S+m*Availa4le.$S+m&: Set%$R.$true$& G end$2ank*Acco+nt:
* primary message such as 5Transfer& *+, .B, *. '6 generates secondary messages as a result of e#ecuting the body - specifically, the 5!6 message directed to the object 5*+.Sum-*vailable6 and the 5I6 message directed to the object 5*..Sum-*vailable6. The problem is that the actual objects receiving them are only kno$n at run-time and there is no guarantee that they can handle the messages. *n object-oriented run-time system, in general, must therefore be able to detect cases $here an object cannot handle a message directed to it and deal $ith the error appropriately. -or general programming systems, it may be sufficient to just flag the error and terminate e#ecution or return an error code for the program to act on. -or a database system, ho$ever, this is not enough. "n the above e#ample, it may have been that the 5!6 message $as successfully e#ecuted but the 5I6 message failed. Vust flagging the error $ill clearly leave the database in a logically inconsistent stateF Thus, the run-time system of an object-oriented database should also have mechanisms to recover from failure and reinstate objects to their states before a failed transaction. The e#act nature of such mechanisms is not $ithin the scope of this book, but suffice it to say here that they $ould be similar in principle to those described for relational databases.

Object-Oriented Data Model

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Object-Oriented Data Model

Enviado por

Direitos autorais:

Formatos disponíveis

Object-Oriented Data Model