|Title |Introduction |Integrating App's |Integrity Maintenance |AOODB Model |Backward Propagation |HVC |Constraint Maintenance |Conclusion |References|
4 An Active Object-Oriented Data Model
The database in our framework has an active object relational data model that includes core concepts of the object-oriented paradigm [Kim90]: objects, attributes, methods, classes and their hierarchies. The model also contains a simplified trigger that considers only its application to integrity maintenance. It has a fixed action clause, so that it can not provide automatic execution of reserved procedures. A virtual class, a direct parallel to the view specification in relational databases, is another component of the model. It will be used in a backward propagation approach. To allow the backward references of objects against class composition hierarchy, the associative reference is also introduced into the model.
In this chapter, we will present the data model and related concepts that are used in the subsequent chapters. To present the model, three constructors are used: the class, trigger, and virtual class constructors. The syntax of each constructor is also introduced. The relationship between the elements of the model is also presented using the entity relationship diagram [Your89].
This chapter is organized as follows. In Section 4.1, the core object-oriented concepts along with a class constructor are introduced. The virtual class is described with its constructor in Section 4.2. Section 4.3 presents the trigger in the model which provides active rules for constraint enforcement. In Section 4.4, the associative reference for the backward reference is described.
4.1 An Object-Oriented Data Model
Objects
An object is a real-world entity that has unique identifier (object identifier) in a certain domain. The state of the object can be represented by the value of its attributes (see the 'has' relationship in Figure 4-1). The domain of an attribute is the class to which the values of the attribute belong (see the 'has_domain' relationship in Figure 4-1), and the attribute may have a single value or an aggregation (set, sequence, or bag) of values from its domain. The domain may be primitive types (for example, integer, real number or character) or other user defined types.
To describe objects and their attributes, we use object identifiers and attribute names. The 'has' relationship between them is denoted by the dot notation. The following expression denotes that the 'p' object has attribute 'volume' that has value, 100.
p.volume = 100
The domain of attribute and the class will be described in the following sub sections.
Figure 4-1 Object, attribute and their relation ship
References
The reference is the value of the attribute of an object. It is implemented as the object identifiers in the domain of the attribute [Kim89b,90]. A reference from an object to other objects indicates that the object identifiers of the referenced objects are the value of an attribute of the referencing object. We can describe the reference with a directed graph (a path), and get the state of the referenced objects (the attribute value of the objects) through the path. The relationship between the object and the attribute, along with the 'has' relationship is depicted in Figure 4-2.
Figure 4-2 The reference relationship
For example, we show the following expression that denotes the 'p' object references the 'm' object through the 'material_type' attribute, and the referenced object 'm' has the 'density' attribute whose value is 50.
material_type = m m.density = 50
material_type.density = 50
Classes
A class is an object that is used to define the state variables and operations (e.g., the class attributes and the class methods) for a set of similar objects. Each of these similar objects is said to be an instance of the class [Kim90] (see Figure 4-3). The class also represents a type of instances. In the view of authorization, the model provides the read, write, and execution authorities for each class (it means the unit of authority is a class).
Figure 4-3 Instance relationship
The 'is_instance_of' relationship is denoted by ':' between object identifier and class name. For example,
p : Part
denotes that object 'p' is an instance of the 'Part' class.
For more detailed specification of the class, we use a class constructor. It specifies the class name, attributes including their name and domain, and methods. The syntax of the constructor is as follows:
<class_constructor> ::= CREATE <class_name>
[AS SUBCLASS OF <super_class_name>] '('
<attribute_list> ')'
[<method_specification>] ';'
<super_class_name> ::= <class_name>
<attribute_list> ::=<attribute_decl>|
<attribute_list>','<attribute_decl>
<attribute_decl>::=<attribute_name>
[SETOF]<attribute_domain>
<attribute_domain> ::=<class_name>|
<primitive_type>
In the syntax, the 'attribute_decl' denotes the name and the domain of an attribute. The 'super_class_name' and 'method_specification'clauses for the super class and methods will be described in the subsequent sections.'
Methods
Methods are a representation of object's behavior in the form of procedural code. They are uniformly treated as any other conventional objects in database such as string, number, or date, and defined as a component of the associated class (see Figure 4-4). Further, they can be associated with rules for checking integrity constraints. Hence, a rule for integrity enforcement with method can present complex constraints on an object. In the active databases, the methods are a candidate for representing procedural rules in expressing complex situations of the object [Mojt89].
Figure 4-4 Class and method relationship
The 'method_specification' in the syntax of the class constructor in the previous section shows the structure of the method. The following is the syntax of the method specification.
<method_specification> ::=
<return_type><method_name>
'('<input_parameter>')'
[<method_body>]
<return_type>::=<attribute_domain>|<void>
The detailed syntax of the 'method_specification' such as the 'input_parameter' or the 'method_body' follows that of the conventional C programming language.
For example, the 'PartWeight()' method of the 'Part' class is specified as the follows.
Float PartWeight(Part obj)
{return(obj.volume * obj.material_type.density)}
The method returns the weight of a 'Part' instance by multiplying its volume and the density of its material object which are denoted by the 'obj.volume' and 'obj.material_type.density', respectively. The 'obj' in the example is a 'Part' object to which the method applied.
Class Hierarchies
There are two types of relationship between classes in the object-oriented data model: the class inheritance hierarchy and the class composition hierarchy. The class inheritance hierarchy is a relationship between a super class and sub class(s). The super class may have any number of the sub classes. The sub classes inherit attributes and methods of the super class. This means that all the attributes and methods in the super class also exist in the sub classes. The sub class may have additional attributes and methods.
Corresponding to the references along the composite relationship among objects, the class composition hierarchy arises from the aggregation relationship between a class and its attributes [Kim90]. When an attribute of a class has a class as its domain, we say that there is a class composition hierarchy between the two classes. Instances of a class may have composite references with the objects in the domain class (see Figure 4-5).
The 'AS SUBCLASS OF' and the 'attribute_domain' classes in the syntax of the class constructor show the class inheritance hierarchy and the class composition hierarchy, respectively. In the syntax, the 'super_class_name' denotes the super class of the class whose name is the 'class_name'. According to the syntax, the model does not support the multiple inheritance [Kim90].
Figure 4-5 Class composition and inheritance hierarchies
For example, the following definition shows that the 'atomic_part' is the sub class of the 'Part' class, and it has class composition hierarchy with the 'Material' class through the 'material_type' attribute.
CREATE CLASS Atomic_Part
AS SUBCLASS OF Part
(material_type Material);
4.2 Virtual Classes
In relational databases, the view is a logical table derived from one or more base tables that are physically stored in the databases [Prat87;Ullm88;Ceri91]. It helps the user to represent different levels of abstraction or different portions of a database to different users [Ceri91]. Conventionally the view is specified with a select expression of SQL of the relational database. The user can specify a retrieval query over the view as if the view is a physical table.
In our data model, the virtual class corresponds to the view in relational databases. The definition of the virtual class is specified using object-oriented queries [Rund92]. Like the view, the virtual class is defined during the life time of database using query statements, and uses instance of base classes (see Figure 4-6). Like the base table in the relational databases, instances of the base classes are explicitly stored as base objects. The virtual class allows update in the base classes that changes its corresponding instances.
Figure 4-6 Virtual class and base class relationship
We make use of a constructor to specify the virtual class. Syntax of the constructor is similar to that of the class constructor in the 'class_name', 'attribute_list', and 'method_spec'.
<virtual_class_constructor>::=CREATE VCLASS
<class_name>
'('<attribute_list>')'
[<method_specification>]
AS <query_specification> ';'
The 'query_specification' denotes the query that logically retrieves the virtual class from the base classes. We employ the query language of the UniSQL/X [UniS93a] as the object-oriented query. See [UniS93a] for more information about the language.
4.3 Triggers
We use triggers in the model for defining and checking integrity constraints. When a data operation declared in its event clause occurs, the trigger evaluates its condition clause. Then it initiates an operation (e.g., invalidation of the transaction) specified in its action clause, if the evaluated condition clause returns true value. The user defines a logical expression in the condition clause of the trigger to specify an integrity constraint. It may include a method defined in a general programming language (e.g., C or C++) which enables the user to overcome the limitation of the trigger definition language. The action clause may contain various operations such as query definition, update, insert, or method invocation.
The most popular uses of the trigger include integrity constraint maintenance, maintenance of materialized views, and security enforcement [Diaz92]. The trigger in the data model concerns the integrity maintenance among the uses. The following is an example of how to define a user-defined integrity constraint using the trigger constructor.
CREATE TRIGGER WeightConstraint
AFTER UPDATE ON Part
IF PartWeight() ON obj > 1000
EXECUTE INVALIDATE TRANSACTION;
The trigger states that if the weight returned from 'PartWeight()' method on the updated 'Part' object (in the example, it is represented by 'obj') is larger than 1000, the database system should invalidate the update transaction. Because the 'WeightConstraint' trigger checks every update on the 'Part' class and invalidates inconsistent database updates, the integrity constraint (e.g., the weight of object is less than 1000) defined using the trigger will be automatically enforced.
We use a simplified trigger model that has fixed event and action clauses. Supposing initial state of database considered has instances that satisfy integrity constraint (that means the initial state of the database is consistent), we fix the event clause to contain only the update transaction. The action clause is also limited to the roll back operation that recovers the database when the it counters inconsistent state. The condition clause supports logical expressions that may contain methods or references of participating objects in constraint checking (see Figure 4-7).
We also import a constructor into the model to present the trigger and associated operations for its management.
<trigger_constructor>::=
CREATE TRIGGER <trigger_name>
AFTER UPDATE ON <class_name>
IF <logical_expression>
EXECUTE INVALIDATE TRANSACTION ';'
Figure 4-7 The simplified trigger
The constructor is a simplified version of the trigger in UniSQL/X [UniS93]. We specialize the constructor to support integrity constraint, eliminating facilities for automatic procedure invocation. The 'logical_expression' for checking integrity constraint may contain a method or references to participating objects. The 'obj' variable that denotes the object to which the update operation is applied also can be used in the expression.
4.4 Associative References
Researchers report that the navigational access in class hierarchies alone is not adequate for applications that must deal with a large number of objects [Bert93]. Associative queries like join operations in relational databases are therefore introduced into the object-oriented model [Bert89;Kim89a;Bert93;Bert95]. These also can be used for the references of objects in the backward direction along the class composition hierarchy. An example of the research area is the index system on the composition hierarchy proposed by [Kim89a;Bert93]. This system allows the indexes for forward traversal, reverse traversal and mixed traversal along the class composition hierarchy.
Our data model allows navigational access to objects through composite references (see the dot notation in Section 4.1). The class composition hierarchy (or reference) used for the access is directional path, so that the backward reference against the hierarchy is impossible. We, therefore, extend the model to allow join operations between classes [UniS93;LAGU95]. This provides associative queries that allow backward references in the class composition hierarchy.
Integrating these three paradigms: the object-oriented data model, the active data model, and the relational data model for associative query capabilities, we prepare an object-oriented data model that supports active facilities for the backward propagation (see Figure 4-8). We describe the issues of the backward propagation based on the model in the rest of this thesis.
Figure 4-8 Model elements and their overall relationship
Korean Engineering Databases ¨Ï copyright Namchul Do, 1996