|Title |Introduction |Integrating App's |Integrity Maintenance |AOODB Model |Backward Propagation |HVC |Constraint Maintenance |Conclusion |References|
2 A Framework for Integrating Engineering Applications
- 2.1 A Framework
- 2.2 Integrity Maintenance Approaches in Engineering Databases
In Section 1.2, we describe difficulties of integrating engineering applications in the existing application-oriented integrity maintenance and present at the centralized constraint maintenance approach with which the heterogeneous applications can be integrated at the semantic level. This chapter presents a framework for the centralized constraint maintenance and its comparisons with other approaches. Based on the framework, we provide an architecture of a design constraint management system in Chapter 7.
This chapter begins by giving a framework of the centralized constraint maintenance in Section 2.1. In Section 2.2, the framework is compared with other approaches for constraint maintenance which can be classified into four groups.
2.1 A Framework
The framework of the centralized integrity maintenance for integrating applications is illustrated in Figure 2-1. The framework consists of four components: the active object-oriented database, the constraint definition and its translator, the constraint management system, and the heterogeneous applications.
Figure 2-1 A framework of centralized constraint maintenance
The active object-oriented database stores engineering objects, associated methods, and rules for constraint maintenance. The objects and the associated methods represent entities and their behavior in engineering domain. A constraint can be defined on objects by verifying the result of the associated method application. The framework provides a special object to represent participating objects and methods in a constraint. The constraint management objects derived from the objects and methods are used for the constraint management.
The constraints defined by the user are translated into rules and related objects in the database by the translator. Integrity constraints are specified by the user with a declarative constructor for constraint maintenance. The user does not have to specify detailed execution procedure for constraint checking and propagation in the database. The translator translates them into the constraint management objects and additional rules, considering the execution and propagation logic of constraint. The backward propagation approach is applied to the translation process for proper constraint propagation.
The constraint management system is a special purpose application to manage constraints. Its operations include creation, deletion, and update of constraints. It also provides operations that resolve conflicts of constraints. All the operations for the management and the resolution are based on the constraint management object in the database.
Various applications can be integrated into the framework. The simplest one is based on the access to only objects in the database. In this case, It is guaranteed that the applications always read consistent data and can not make inconsistent update into the database. Other kind of applications can share objects and methods that can change the state of associated objects. The changes are also checked and confirmed by the rules for constraint maintenance. If an application has interface to the database that embeds the data control language, it can manage the rules as well as objects and methods. It is because that all the constraints and their operations are defined and implemented with resources from the database.
2.2 Integrity Maintenance Approaches in Engineering Databases
In this section, we discuss related works on the constraint enforcement in the context of integration of applications in a heterogeneous CIM environment. As mentioned in Section 1.1, the constraint enforcement in engineering database provides the information resources that automatically maintain engineering semantics so that applications can be integrated at the semantic level. These concepts for the integration have received considerable attention in the ISO STEP standards [ISO92]. This is a fundamental reason for providing the rules in the ISO EXPRESS specification language [ISO91].
We can distinguish four groups of constraint management approaches (including our approach) which employ database oriented approaches (see Figure 2-2).
Approaches in the first group (Group I in Figure 2-2) provide a translator for the engineering data only with the integrity constraints in each application. Since there is no consideration for the integrity constraints of the translated data, the system cannot support the integration of engineering semantics. These approaches were introduced as application-oriented integrity maintenance.
Approaches in the second group (see Group II in Figure 2-2) need additional facilities for constraint management besides their databases. For example, a constraint management system that manages data and associated integrity constraints separately is proposed by Yoo and Cha [Yoo93]. The constraint management system has a special constraint checker to examine the integrity constraints of the data under processing. Separated from an engineering database, the constraint checker reads rules for integrity constraints and evaluates the related data before it is stored in the database. From the integrated constraint management system's view point, this approach is inefficient in that each application must translate its data and associated rules through the constraint checker.
In contrast to the previous groups, our approach (as a member of the Group IV in Figure 2-2) [Do96] allows the user to manage data and the
Figure 2-2 Four groups of integrity maintenance in databases
associated integrity constrains as a tightly coupled object along with its methods. Constraints in our system consist of only database resources such as objects, methods, and triggers. Therefore the constraints can be easily managed in the database environment. Consequently, both building additional constraint checker and translating data for the checker are not necessary in our system.
We can show a constraint management system based on an object-oriented database as another example in the approaches belong to the second group (see Group III in Figure 2-2). The ROSE [Hand91;Liu93] translates constraints specified in EXPRESS specification language into two types of methods in an application. The first is database methods that are always associated with objects, and the second is application methods that exist as database applications. The ROSE uses more tightly coupled methods (to data in the database) than the approaches in Group II. The approach, however, burdens applications with how to check database update events and when to invoke the method to check the integrity constraint of a database state changed by the event. In this system each method or application for the integrity constraints should contain the procedures to check update events and to initiate its procedure for constraint checking.
A major difference between approaches in the above example and ours is that ours accepts the trigger of an active database to account for the event detection and initiation of methods for constraint checking. Since the trigger provides automatic enforcement of integrity constraint, every application can share the information in the database without any additional facilities for the integrity constraint. As a result, each application programmer in this database environment concentrates his/her effort only on the main functionality of the application without any consideration on event detection and method invocation.
The fourth group (Group IV in Figure 2-2) employs active databases for supporting the integrity constraints and automatic verification of them. Urban [Urba94] proposed a heterogeneous engineering database, Shared Design Manager (SDM), which supports integrity constraints using an active DBS. Providing automatic verification of integrity constraint our approach also can be classified into the group. In addition, our approach considers the backward propagation that is a frequently occurred problem in the active object-oriented databases.
Korean Engineering Databases ¨Ï copyright Namchul Do, 1996