DATABASE MANAGEMENT SYSTEM
Active databases support the specification of business rules in the form of ECA rules.The business knowledge that was dispersed in many applications in the form of programming code is now represented in the form of rules and managed in a separatedway.Thisfacilitates the adaptation to new requirements and improves the maintainability of systems.
DBMS is software that is designed to be able to manage the collection anf utilization of data in large numbers.before the database,data is stored in its general form file.software used to manage and query a database call is called the database management system and conduct operations against the requested data users.
2.Management System Database Active
`(Zimmer & Unland, 1999) that allows the definition of socalled composite or complex events. By means of a rule definition language (RDL), ECA rules are specified. This language provides constructors for the definition of rules, events, conditions and actions.Once rules are specified with an RDL, the rule base should be checked according to the following properties: termination, confluence and observably deterministic behavior
(Aiken, Widom, & Hellerstein, 1992). For instance, termination analysis ensures that the current rule base is safe and correct with respect to the intended reactive behavior. In general, these properties cannot be provenautomatically, but an analyzer might assist in detecting inconsistencies. After this verification step, rules are ready to be processed.
3.Eca rule Procesing
Rule execution semantics prescribe how an active system behaves once a set of rules has been defined. Rule execution behavior can be quite complex, but we restrict
ourselves to describing only essential aspects here. For a more detailed description, see Act-Net Consortium(1996) and Widom and Ceri (1996).All begins with event instances signaled by event sources that feed the complex event detector, which
selects and consumes these events. Consumption modes (Chakravarthy, Krishnaprasad, Anwar, & Kim, 1994) determine which of these event instances are considered for
firing rules. The two most common modes are recent and chronicle. In the former, the most recent event occurrences are used, while in the latter, the oldest event
occurrences are consumed. Notice that in both cases a temporal order of event occurrences is required. Different consumption modes may be required by different application classes.Usually there are specific points in time at which rulesmay be processed during the execution of an active system. The rule processing granularity specifies how often these points occur. For example, the finest granularityis “always,”which means that rules are processed assoon as any rule’s triggering event occurs. If we consider the database context, rules may be processed after the
occurrence of database operations (small), data manipulation statements (medium), or transactions.(coarse). At granularity cycles and only if rules were triggered, the rule processing algorithm is invoked. If more than one rule was triggered, it may be necessary to select one after the other from this set. This process of rule selection is
known as conflict resolution, where basically three strategies can be applied: (a) one rule is selected from the fireable pool, and after rule execution, the set is determined
again; (b) sequential execution of all rules in an evaluation cycle; and (c) parallel execution of all rules in an evaluation cycle.
To sum up, an ECA-rule-processing mechanism can be formulated as a sequence of four steps (as illustrated in Figure 1):
1. Complex event detection: It selects instances of interest where various event occurrencesmay be involved. As a result, these picked instances are bound together and signaled as a (single) complex event.
2. Rule selection: According to the triggering events, fireable rules are selected. If the selection is multiple,a conflict resolution policy must be applied.
3. Condition evaluation: Selected rules receive the triggering event as a parameter, thus allowing the condition evaluation code to access event content. Transaction dependencies between event detection and the evaluation of a rule’s condition are specified using Event-Condition coupling modes.
4. Action execution: If the rule’s condition evaluates to true, the corresponding action is executed taking the triggering event as a parameter. Condition-action dependencies are specified similarly to Step 3. It should be noticed that Step 1 (complex event detection) can be skipped if rules involve primitive events only.
Several tools are required in order to adequately support the active functionality paradigm (Act-Net Consortium,1996). For instance, a rule browser makes possible the inspection of the rule base; a rule design assistance supports the process of creation of new rules and is complemented with a rule analyzer that checks for a consistent rule base; and a rule debugger monitors the execution of rules.
Modern large-scale applications, such as e-commerce,enterprise application integration (EAI), Internet or intranet applications, and pervasive and ubiquitous computing, can benefit from this technology, but they impose new requirements. In these applications,integration of different subsystems, collaboration with partners’ applications or interaction with sensor devices is of particular interest. It must be noticed that in this context, events and data are coming from diverse sources, and the execution of actions and evaluation of conditions may be performed on different systems. Furthermore, events, conditions and actions may not be necessarily directly related to database operations. This leads to the question of why a full-fledged database system is required when only active functionality and some services of a DBMS are needed.The current trend in the application space is movingaway from tightly coupled systems and towards systems of loosely coupled, dynamically bound components. In such a context, it seems reasonable to move required active functionality out of the active database system by offering a flexible service that runs decoupled from the database. It can be combined in many different ways and used in a variety of environments. For this, a component-based architecture seems to be appropriate (Collet, Vargas- Solar, & Grazziotin-Ribeiro, 1998; Gatziu, Koschel, von
Buetzingsloewen, & Fritschi, 1998;), in which an active functionality service can be seen as a combination of other components, like complex event detection, condition evaluation and action execution. Thus, components can be combined and configured according to the required functionality, as proposed by the unbundling approach in the context of aDBMSs (Gatziu et al.) or by using a service-oriented architecture (SOA) as described in Cilia, Bornhövd, and Buchmann (2001).
Business Rules: They are precise statements that
describe, constrain and control the structure, operations
and strategy of a business. They may be thought of as
small pieces of knowledge about a business domain.
Consumption Mode: It determines which of these
event instances are considered for firing rules. The two
most common modes are recent and chronicle.
Coupling Mode: It specifies the transactional relationship
between a rule’s triggering event, the evaluation of
its condition and the execution of its action.
ECA Rule: It is a (business) rule expressed by means
of an event, a condition and an action.
Event: It is an occurrence of a happening of interest
(also known as primitive event). If the event involves
correlation or aggregation of happenings then it is called
a complex or composite event.
Event Algebra: Composite events are expressed using
an event algebra. Such algebras require an order function
between events to apply event operators (e.g., sequence)
or to consume events.
Rule Base: It is a set of ECA rules. Once this set is
defined, the aDBMS monitors for relevant events. The
rule base can be modified (new rules can be added, or
existent rules can be modified or deleted) over time.
Rule Definition Language (RDL): Set of constructs
for the definition of rules, events, conditions and actions.