|Title |Introduction |Integrating App's |Integrity Maintenance |AOODB Model |Backward Propagation |HVC |Constraint Maintenance |Conclusion |References|
6 Horizontal Virtual Class
In the previous section, three backward propagation approaches were proposed to properly support integrity constraints on the classes that form a class composition hierarchy. In this chapter we propose a constructor with which the user can specify the constraints. Since the constructor specializes in constraints that cause the backward propagation problem, constraints on participating classes in a class composition hierarchy can be specified with it.
In Section 6.1, we develop the constructor based on a selected backward propagation approach, the backward propagation with virtual class, from approaches proposed in Section 5.3 through comparisons on several futures. In Section 6.2 , we names the virtual class used in the approach, the Horizontal Virtual Class (HVC), and describes several characteristics of the HVC in the view of constraint management. Section 6.3 includes a procedure for generating a virtual class and triggers for constrains from the constructor, which support the backward propagation with virtual class.
6.1 Comparisons of Three Backward Propagation Approaches
For the comparisons of the backward propagation approaches, we consider two goals [Aho83]. The first goal is to select an approach that is easy to implement with currently available resources. The second goal is to select an approach that makes efficient use of the resources, especially, one that runs as fast as possible. We consider three features for the comparison: the code redundancy, the authority control, and the referential complexity.
Comparisons of these backward propagation approaches exhibit that the backward propagation with virtual class is superior to the other two approaches in terms of code redundancy and authority control. The results of the comparison are summarized in Table 6-1.
The backward propagation with method duplication approach needs functionally redundant methods for all participating classes. On the other hand, the backward propagation with method call and the backward propagation with virtual class approaches use only the initial method. Since multi-level class composition hierarchies and the shared objects make duplicating the initial method difficult, these two approaches are preferable to the backward propagation with method duplication, if a DBS is to support the backward propagation automatically.
Table 6-1 Comparisons of three backward propagation approaches
| Method Duplication | Method Call | Virtual Class | ||
| Code Redundancy | each of participating classes has a functionally duplicated method | no code redundancy (reuse initial method) | no code redundancy (reuse initial method) | |
| Authority control | read authority for participating classes | read authority for participating classes, execution authority for initial method | read authority for virtual class, execution authority for initial method | |
|
Complexity |
Total |
N-1 |
(the best N-1, the worst 2N-2) |
N (consider the cost for initialization of HVC ) |
|
Backward |
|
|
1 |
|
|
Forward |
|
(N-1) |
(N-1) |
|
Since the backward propagation with virtual class approach can hide classified attributes in participating classes from unauthorized users, it can achieve required constraint checking without compromising security. On the other hand, the other approaches, the backward propagation with method duplication and backward propagation with method call approaches, require the user to have read authority for all participating classes to check an integrity constraint. Therefore, if there is a classified attribute from the user in a participating class, he/she cannot check the integrity constraint using these two backward propagation approaches.
In the comparison of referential complexity, we make a number of assumptions in order to simplify the comparison. That is because the aim of the comparison is to select an approach that can be easily implemented rather than being exhaustive in terms of the algorithmic efficiency of each approach.
- The participating objects are uniformly distributed so the access cost to each object is identical.
- All attributes are single valued.
- No shared objects exist.
- If there are Ci.. Cn classes in a class composition hierarchy, and C1 is the root class of the hierarchy, Each instance of a class Ci is referenced by instances of class Ci-1 (1 < i
N). This implies that there are no partial instantiations in the hierarchy.
In referencing participating classes in a class composition hierarchy, the backward propagation with method call approach needs 2N-2 references in the worst case and N-1 in the best case for N participating classes with no set-valued attributes or shared objects. The backward propagation with method duplication and the backward propagation with virtual class approaches (their complexities are N and N-1 accesses respectively) are superior to the backward propagation with method call approach (the average cost is 3/2 (N-1)). Furthermore, if the backward references are to be implemented with join operation, the backward propagation with virtual class approach is better for multi-level class composition hierarchies than the backward propagation with method call approach, since it requires only one backward reference (e.g., from a base class to a virtual class). This means that the expensive join operation is saved, and the referential path for backward propagation through the multi-level class composition hierarchy is maintained by the query statement of the virtual class.
As a result, the backward propagation with virtual class has advantages in code reuse and authority control. The referential complexity, in the simplified comparison, shows the approach is better than the backward propagation with method call. So, we decide to develop a constructor for the backward propagation based on the backward propagation approach with virtual class.
6.2 Characteristics of HVC
We call the virtual class which is used in the backward propagation with virtual class approach the horizontal virtual class (HVC). Although a HVC is a kind of virtual class, it has several characteristics which differentiate itself from the other kinds of virtual classes. The following are the characteristics of HVCs:
First, the base classes of a HVC form a class composition hierarchy. While a virtual class in general may include base classes which are its subclasses in terms of attributes (especially, in the programming language context) or independent classes, HVCs have base classes all of which are related in a class composition hierarchy. 'H(orizontal)' in 'HVC' means that the base classes of a HVC have a horizontal composition relationship in contrast to the vertical inheritance relationship.
Second, all the attributes of a HVC have base classes as their domains (e.g., the 'material' attribute of the 'HVC' class has the 'Material' class as its domain in the example in Section 5.1). This means that HVCs in turn form class composition hierarchies with its base classes. This also contrasts to the case where a virtual class is a super class of its base classes in terms of attributes.
Third, the sole purpose of a HVC is to invoke the initial method which checks an integrity constraint defined by the user not to access each base class. This is the reason why the backward propagation with virtual class is better than the other two approaches in terms of authority control. It only references object identifies of base classes without access to each attribute.
6.3 CONSTRAINTCCH
In Section 5.3, we showed that HVCs and triggers on base classes (participating classes) can support the backward propagation effectively. In this section, a constructor for integrity constraints that support the backward propagation is proposed. We will define the syntax of the constructor and describe how to generate a HVC and triggers for the backward propagation from an integrity constraint specified by the constructor.
The following is the syntax of the proposed constructor:
<constraint_constructor>::=
CONSTRAINTCCH ON <initial_class>,
<participating_classes> WITH <condition>;
<initial_class> ::= <class_name>
<participating_classes> ::= <class_name>
|<participatingclasses>, <class_name>
<condition> ::= <logical_expressioin>
The 'initial_class' is the root class of the class composition hierarchy which includes the 'participating_classes' that participate in the integrity constraint except for the root class. The 'condition' is the integrity constraint which the participating classes (i.e., 'initial_class' and 'participating_classes') should satisfy. In this paper, we limit the 'condition' to be a logical expression including the 'inital_method' on the 'initial_class'.
The following procedure is how to define a HVC and triggers for the backward propagation from the constructor with an assumption that there are no shared objects in the class composition hierarchy. We will use the example from the weight constraint in Figure 5-3 to illustrate the procedure:
CONSTRAINTCCH ON Machine,Assy_Part,Part,Material
WITH MachineWeight() ON Machine <= 1000;
(1) Create a HVC whose base classes are the 'initial_class' and the 'participating_classes'. Its attributes have the 'initial_class' and the' participating_classes' as their domains. If there is a base class which has a set-valued attribute in the class composition hierarchy, the corresponding attribute and the subsequent attributes (in the class composition hierarchy order) of the HVC should have the sets of the corresponding base classes as their domains.
For example, the domains of attributes of the HVC are the 'Machine' class (the 'initial_class'), and the 'Part', 'Assy_Part,' and 'Material' classes (the 'Participating_classes'), respectivly. Since the 'Machine' class has attribute 'components' that has a set of the 'Assy_Part' class as its domain, the corresponding attribute, 'assy_part' attribute, and the subsequent attributes, the 'part' and 'material' attributes of the 'HVC', have sets of the corresponding classes (e.g., 'SETOF(Assy_Part), SETOF(Part)', and 'SETOF(Material)) as their domains. The following is the specification for the HVC:
CREATE VIRTUAL CLASS HVC
{ machine Machine,
assy_part SETOF(Assy_Part),
part SETOF(Part),
material SETOF(Material)}
(2) The query part of the HVC has the 'initial_class' in its range clause. The target clause of the query consists of object variables representing the 'initial_class' and references from the 'initial_class' to the 'participating_classes'.
For example, the next query should be attached to specify proper instance of the HVC:
AS SELECT m, m.components,m.components.sub_part,
m.components.sub_part.material_type
FROM Machine m
(3) Attach triggers with the 'Backward()' method to the 'participating_classes'. The 'Backward()' method is used to reference the object of the HVC whose attribute value is the updated object. Through the object of the HVC the object of the root class to which the initial method should be applied can be referenced. It is achieved by attaching the dot and the attribute name of the HVC whose domain is the 'initial_class. The triggers have the condition clause that is the complement to the 'condition clause of 'CONSTRAINTCCH.
For example, triggers for the backward propagation should be specified on the 'Assy_Part,' 'Part', and 'Material' classes. The following specification is the trigger definition for the 'Material' class (we skip the triggers for the 'Assy_Part' and 'Part' classes):
TRIGGER machine_weight_material
AFTER UPDATE ON Material
IF NOT(MachineWeight() ON
Backward(HVC,material,obj).machine <= 1000)
EXECUTE INVALIDATE TRANSACTION;
Korean Engineering Databases ¨Ï copyright Namchul Do, 1996