We will be discussing the architecture, fundamental
characteristics/features, application, strength as well as the
weaknesses of an Active Database Management System.
TOPIC: ACTIVE DATABASE
INTRODUCTION
Active database are database systems that supports mechanisms that enable them to respond automatically to events that
are taking place either inside or outside the database system itself by supporting the specification and implementation of
reactive behaviour.
The reactive behaviour resides on rules which integrates cause with an expected effect [Montesi and Torlone 1995]. This
functionality is commonly defined in terms of event-condition-action rules (ECA-rules). These rules (mainly active rules),
allow the system to monitor and react to specific events.
ACTIVE RULES/PRODUCTION RULES:
These are stored programs, which are automatically executed or fired when some event occur. Triggers can be written to
respond to Data Manipulation Language DML (Insert, Update, and Delete), Data Definition Language DDL (Create, Alter,
and Drop) and Database Operation (Log-on, Log-off, Start-up, and Shutdown). Triggers can be defined on table, view or
database with which the event is associated.
INTRODUCTION
The desired reactive behavior is expressed in production rules (also called event-condition-action rules), which are designed
and stored in the database. This has the benefit that the rules can be shared by many application programs, and the database
system can optimize their implementation.
Important database concepts, such as scenarios, constraints and methods can be expressed in a natural way using the active
rules.
 The event part specifies the signal that triggers the invocation of the rule
 The condition part is a logical test that, if satisfied or evaluates to true, causes the action to be carried out
 The action part consists of updates or invocations on the local data
Active rules applications support conventional DBMSs within different contexts, such as relational integrity, data maintenance,
replication, monitoring data updates, etc. [Zaniolo et al. 1997].
ARCHITECTURE OF AN ACTIVE DATABASE
The architecture depends on the knowledge model (a description mechanism) and the execution
model (a runtime strategy) of the system which are the two components required for providing
reactive capabilities in an active database.
1. A Knowledge Model must be provided for triggers: This will specify what kinds of rules can be
supported, what can be said about these rules, and how the rules can be classified into
security levels.
2. An Execution Model must be provided for the triggers. This will specify the runtime strategies
for rule execution, ensures no illegal information flow occurs because of the triggers
execution.
The two approaches to designing the Architecture of an Active Database are;
1. Built-In Architecture: Active database components becomes a part of the database (e.g.
Postgres, Sentinel, and Starburst).
 Implementation from scratch: Here the Active Database components is implemented
from scratch.
 Integrated architecture: This involves modifying and extending an existing passive
DBMS internally.
2. Layered Architecture: Active database component are built on top of an existing passive
database system, (e.g. ACOOD, RDL, and TRIGS).
ARCHITECTURE OF AN ACTIVE DATABASE.
This is a layered architecture for an active database; here the rules that triggers the
reactive behaviour in the Active Database are built on top of an already existing
database i.e. active functionalities are added on top of the base system.
This approach is beneficial for active object-oriented databases when the base
system is also an object-oriented database such that functionality to be rewritten can
be easily modified or wrapped.
Built-In Architecture for a Multi-Level Secure (MLS) Active Database.
The principal components are depicted by rectangles and the data stores are depicted by ellipses. The built-in approach is preferred in a multilevel
secure active database due to
1. Performance.
2. Unavailability of efficient multilevel secure database that can serve as an underlying database for the layered approach.
ARCHITECTURE OF AN ACTIVE DATABASE
 A multilevel secure database is characterized by having a partially ordered set of security levels (the ordering relation is referred
to as the dominance relation);
 All the database objects and the operations (transactions) on the database objects have security levels associated with them.
 Mandatory access control policies determine which transactions can access which objects. The idea is that information can flow
from the dominated level to the dominating level but not in the other direction.
 Security levels are assigned to events in an MLS databases using rules.
 An MLS rule is associated with a security level.
 Events in an MLS database are also associated with security levels.
 An MLS rule can be triggered by an event that is at a different security level than the rule, the algorithms used for detecting
events in a non-MLS database cannot be employed in MLS Active Database. Using such algorithms causes illegal information
flow.
ARCHITECTURE OF AN ACTIVE DATABASE
FEATURES OF AN ACTIVE DATABASE
1. It possesses all the concepts of a conventional database i.e. data modelling
facilities, query language, multi-user access, recovery, etc.
2. It supports all the functions of a traditional database, including data definition, data
manipulation, storage management, transaction management, concurrency
control, and crash recovery.
3. An active database supports definition and management of ECA-rules.
4. An active database must detect event occurrences.
5. An active database must be able to evaluate conditions and to execute actions.
6. An active database includes an event driven architecture (often in the form of ECA
rules)
7. An active database should support a programming environment and should be
tunable.
8. An active database must be able to evaluate conditions and to execute actions.
This requirement means that it has to implement rule execution.
APPLICATION OF ACTIVE DATABASE
1. Applications which depend on data monitoring activities such as CIM,
Telecommunications Network Management, Program trading, Medical and
Financial Decision Support Systems can greatly benefit from integration with active
database.
2. Production control, e.g., power plants.
3. Maintenance tasks, e.g., inventory control.
4. Financial applications, e.g., stock & bond trading.
5. Telecommunication and network management.
6. Air traffic control.
7. Computer Integrated Manufacturing (CIM)
8. Statistics gathering and authorization tools.
STRENGTH/BENEFIT OF AN ACTIVE DATABASE.
1. Active database systems enhances traditional database functionalities with powerful
rule processing (or trigger) capabilities
2. Triggers in active database enable a uniform and centralized description of the
business rules relevant to the information system.
3. The use of triggers in an active database facilitates the maintenance of business
rules.
4. Triggers are expected to improve the performance of applications. Better
optimization techniques can be applied by using triggers to centralize the application
semantics while also avoiding redundancy of checking and repair operations.
5. The layered approach is beneficial for active object-oriented databases if the base
system is in turn implemented in an object-oriented way such that functionality to be
rewritten can be easily modified or wrapped.
STRENGTH/BENEFIT OF AN ACTIVE DATABASE.
6. The ECA rules in active database are a powerful and uniform mechanism for a
number of useful database tasks;
 Enforce integrity constraints.
 Implement triggers and alerters.
 Maintain view and derived data,
 Enforce access constraints,
 Implement version control policies,
 Gathering statistics for query optimization or database reorganization,
7. In addition the inference power of ECA rules makes active database systems a
suitable platform for building large and efficient knowledge base and expert systems.
WEAKNESSES OF ACTIVE DATABASE.
1. Insufficient methodological support in design and analysis.
2. Lack of standardization.
3. Missing development and administration tools for triggers.
4. Weak performance: This is one the main reasons that makes users reluctant to use
active rules in the development of large applications.
5. Optimizing large applications is rendered difficult by the separation of transactions
and triggers and the misunderstanding of their subtle interactions.
6. Lack of Support for application development in many active database management
system prototypes.
7. Distribution and Parallelism has not been widely treated as active databases have
been considered primarily in centralized database environments.
8. The layered approach is beneficial in terms of construction cost, but the entire system
cannot be optimized comprehensively and this can cause runtime performance to be
worse than in an integrated architecture which is also very costly to construct.
Active database has brought a lot of improvement to the way database are currently accessed. The database we have today are
intelligent and they can react to event and transactions carried out by users. Database can now react and relate with application
software in real time. The theory and technology of active database systems is still maturing. There are several areas that
researchers and practitioners will likely address in the future, particularly as active databases emerge in the commercial arena.
These include the following:
 Support for application development.
 Increasing the expressive power of rules: Methods for increasing the expressiveness of database rule language while
maintaining an efficient implementation deserve further study.
 Improved algorithms.
 Distribution and Parallelism.
 In addition, considerable work is needed on increasing the communication capability between database rules and
applications.
CONCLUSION
1. Huang, K., Chen, P., Chen, Y., Song, W., and Chen, X. (2009). The research for embedded active database based on eca rule and
implementation in sqlite database. In Database Technology and Applications, 2009 First International Workshop on, pages 476–479.
REFERENCES.

Active database system

  • 1.
    We will bediscussing the architecture, fundamental characteristics/features, application, strength as well as the weaknesses of an Active Database Management System. TOPIC: ACTIVE DATABASE
  • 2.
    INTRODUCTION Active database aredatabase systems that supports mechanisms that enable them to respond automatically to events that are taking place either inside or outside the database system itself by supporting the specification and implementation of reactive behaviour. The reactive behaviour resides on rules which integrates cause with an expected effect [Montesi and Torlone 1995]. This functionality is commonly defined in terms of event-condition-action rules (ECA-rules). These rules (mainly active rules), allow the system to monitor and react to specific events. ACTIVE RULES/PRODUCTION RULES: These are stored programs, which are automatically executed or fired when some event occur. Triggers can be written to respond to Data Manipulation Language DML (Insert, Update, and Delete), Data Definition Language DDL (Create, Alter, and Drop) and Database Operation (Log-on, Log-off, Start-up, and Shutdown). Triggers can be defined on table, view or database with which the event is associated.
  • 3.
    INTRODUCTION The desired reactivebehavior is expressed in production rules (also called event-condition-action rules), which are designed and stored in the database. This has the benefit that the rules can be shared by many application programs, and the database system can optimize their implementation. Important database concepts, such as scenarios, constraints and methods can be expressed in a natural way using the active rules.  The event part specifies the signal that triggers the invocation of the rule  The condition part is a logical test that, if satisfied or evaluates to true, causes the action to be carried out  The action part consists of updates or invocations on the local data Active rules applications support conventional DBMSs within different contexts, such as relational integrity, data maintenance, replication, monitoring data updates, etc. [Zaniolo et al. 1997].
  • 4.
    ARCHITECTURE OF ANACTIVE DATABASE The architecture depends on the knowledge model (a description mechanism) and the execution model (a runtime strategy) of the system which are the two components required for providing reactive capabilities in an active database. 1. A Knowledge Model must be provided for triggers: This will specify what kinds of rules can be supported, what can be said about these rules, and how the rules can be classified into security levels. 2. An Execution Model must be provided for the triggers. This will specify the runtime strategies for rule execution, ensures no illegal information flow occurs because of the triggers execution. The two approaches to designing the Architecture of an Active Database are; 1. Built-In Architecture: Active database components becomes a part of the database (e.g. Postgres, Sentinel, and Starburst).  Implementation from scratch: Here the Active Database components is implemented from scratch.  Integrated architecture: This involves modifying and extending an existing passive DBMS internally. 2. Layered Architecture: Active database component are built on top of an existing passive database system, (e.g. ACOOD, RDL, and TRIGS).
  • 5.
    ARCHITECTURE OF ANACTIVE DATABASE. This is a layered architecture for an active database; here the rules that triggers the reactive behaviour in the Active Database are built on top of an already existing database i.e. active functionalities are added on top of the base system. This approach is beneficial for active object-oriented databases when the base system is also an object-oriented database such that functionality to be rewritten can be easily modified or wrapped.
  • 6.
    Built-In Architecture fora Multi-Level Secure (MLS) Active Database. The principal components are depicted by rectangles and the data stores are depicted by ellipses. The built-in approach is preferred in a multilevel secure active database due to 1. Performance. 2. Unavailability of efficient multilevel secure database that can serve as an underlying database for the layered approach. ARCHITECTURE OF AN ACTIVE DATABASE
  • 7.
     A multilevelsecure database is characterized by having a partially ordered set of security levels (the ordering relation is referred to as the dominance relation);  All the database objects and the operations (transactions) on the database objects have security levels associated with them.  Mandatory access control policies determine which transactions can access which objects. The idea is that information can flow from the dominated level to the dominating level but not in the other direction.  Security levels are assigned to events in an MLS databases using rules.  An MLS rule is associated with a security level.  Events in an MLS database are also associated with security levels.  An MLS rule can be triggered by an event that is at a different security level than the rule, the algorithms used for detecting events in a non-MLS database cannot be employed in MLS Active Database. Using such algorithms causes illegal information flow. ARCHITECTURE OF AN ACTIVE DATABASE
  • 8.
    FEATURES OF ANACTIVE DATABASE 1. It possesses all the concepts of a conventional database i.e. data modelling facilities, query language, multi-user access, recovery, etc. 2. It supports all the functions of a traditional database, including data definition, data manipulation, storage management, transaction management, concurrency control, and crash recovery. 3. An active database supports definition and management of ECA-rules. 4. An active database must detect event occurrences. 5. An active database must be able to evaluate conditions and to execute actions. 6. An active database includes an event driven architecture (often in the form of ECA rules) 7. An active database should support a programming environment and should be tunable. 8. An active database must be able to evaluate conditions and to execute actions. This requirement means that it has to implement rule execution.
  • 9.
    APPLICATION OF ACTIVEDATABASE 1. Applications which depend on data monitoring activities such as CIM, Telecommunications Network Management, Program trading, Medical and Financial Decision Support Systems can greatly benefit from integration with active database. 2. Production control, e.g., power plants. 3. Maintenance tasks, e.g., inventory control. 4. Financial applications, e.g., stock & bond trading. 5. Telecommunication and network management. 6. Air traffic control. 7. Computer Integrated Manufacturing (CIM) 8. Statistics gathering and authorization tools.
  • 10.
    STRENGTH/BENEFIT OF ANACTIVE DATABASE. 1. Active database systems enhances traditional database functionalities with powerful rule processing (or trigger) capabilities 2. Triggers in active database enable a uniform and centralized description of the business rules relevant to the information system. 3. The use of triggers in an active database facilitates the maintenance of business rules. 4. Triggers are expected to improve the performance of applications. Better optimization techniques can be applied by using triggers to centralize the application semantics while also avoiding redundancy of checking and repair operations. 5. The layered approach is beneficial for active object-oriented databases if the base system is in turn implemented in an object-oriented way such that functionality to be rewritten can be easily modified or wrapped.
  • 11.
    STRENGTH/BENEFIT OF ANACTIVE DATABASE. 6. The ECA rules in active database are a powerful and uniform mechanism for a number of useful database tasks;  Enforce integrity constraints.  Implement triggers and alerters.  Maintain view and derived data,  Enforce access constraints,  Implement version control policies,  Gathering statistics for query optimization or database reorganization, 7. In addition the inference power of ECA rules makes active database systems a suitable platform for building large and efficient knowledge base and expert systems.
  • 12.
    WEAKNESSES OF ACTIVEDATABASE. 1. Insufficient methodological support in design and analysis. 2. Lack of standardization. 3. Missing development and administration tools for triggers. 4. Weak performance: This is one the main reasons that makes users reluctant to use active rules in the development of large applications. 5. Optimizing large applications is rendered difficult by the separation of transactions and triggers and the misunderstanding of their subtle interactions. 6. Lack of Support for application development in many active database management system prototypes. 7. Distribution and Parallelism has not been widely treated as active databases have been considered primarily in centralized database environments. 8. The layered approach is beneficial in terms of construction cost, but the entire system cannot be optimized comprehensively and this can cause runtime performance to be worse than in an integrated architecture which is also very costly to construct.
  • 13.
    Active database hasbrought a lot of improvement to the way database are currently accessed. The database we have today are intelligent and they can react to event and transactions carried out by users. Database can now react and relate with application software in real time. The theory and technology of active database systems is still maturing. There are several areas that researchers and practitioners will likely address in the future, particularly as active databases emerge in the commercial arena. These include the following:  Support for application development.  Increasing the expressive power of rules: Methods for increasing the expressiveness of database rule language while maintaining an efficient implementation deserve further study.  Improved algorithms.  Distribution and Parallelism.  In addition, considerable work is needed on increasing the communication capability between database rules and applications. CONCLUSION
  • 14.
    1. Huang, K.,Chen, P., Chen, Y., Song, W., and Chen, X. (2009). The research for embedded active database based on eca rule and implementation in sqlite database. In Database Technology and Applications, 2009 First International Workshop on, pages 476–479. REFERENCES.