An ECA Rule Rewriting Mechanism for Peer Data Management Systems Dan Zhao1 , John Mylopoulos1 , Iluju Kiringa2 , and Verena Kantere3 1
3
University of Toronto, Toronto, Canada {dzhao, jm}@cs.toronto.edu 2 University of Ottawa, Ottawa, Canada
[email protected] National Technical University of Athens, Athens, Greece
[email protected]
Abstract. Managing coordination among peer databases is at the core of research in peer data management systems. The Hyperion project addresses peer database coordination through Event-Condition-Action (ECA) rules. However, peer databases are intended for non-technical end users, such as a receptionist at a doctor’s office or an assistant pharmacist. Such users are not expected to know a technically demanding language for expressing ECA rules that are appropriate for coordinating their respective databases. Accordingly, we propose to offer a library of ”standard” rules for coordinating two or more types of peer databases. These rules are defined in terms of assumed standard schemas for the peer databases they coordinate. Once two acquainted peers select such a rule, it can be instantiated so that it can operate for their respective databases. In this paper, we propose a mechanism for rewriting given standard rules into rules expressed in terms of the schemas of the two databases that are being coordinated. The rewriting is supported by Global-AsView mappings that are supposed to pre-exist between specific schemas and standard ones. More specifically, we propose a standard rule rewriting algorithm which we have implemented and evaluated.
1
Introduction
A peer system is an open-ended network of distributed computational peers (nodes), where peers can join or leave the network at any time without central control. Moreover, each peer is acquainted with a number of other peers - its acquaintances. Acquaintance relationships are dynamic and ever-changing. Existing peer systems, such as Napster, Gnutella, Freenet [3], Chord [7], CAN [12], and Pastry [11] were designed specifically for file sharing, and cannot accommodate relational databases. For example, it is difficult to search for some files whose contents satisfy a given predicate, the way one can with relational databases. Thus, along a different path, a few projects are focusing on data semantics by using queries, views, and schema mappings for data sharing and coordination among peer databases [6, 5, 4]. The Hyperion project has proposed a distributed Event-Condition-Action (ECA) rule language as a coordination mechanism for peer databases [15, 13]. This work has been funded by the project PENED 2003 Y. Ioannidis et al. (Eds.): EDBT 2006, LNCS 3896, pp. 1069–1078, 2006. c Springer-Verlag Berlin Heidelberg 2006
1070
D. Zhao et al.
Different peers may, however, have different database schemas. As a result, ECA rules between different peers may also be different according to their respective schemas even when they are intended to capture the same constraint. Moreover, most end-users do not have sufficient professional training to establish ECA rules for their own schemas, and hiring an expert to do the work can be both time consuming and prohibitively expensive. Therefore, it is vital to have a means for generating rules automatically for different schemas. In this paper, we assume that there exist standard database schemas for classes of peers, and standard coordination ECA rules between these schemas. These rules capture common coordination patterns between different classes of peers, e.g., family doctors and pharmacists. When a peer, such as a family doctor, joins a class of peers, that peer establishes a mapping from the standard database schema of the peer group to his or her own schema. When the peer wants to adopt a standard rule to maintain data consistency with another peer, it uses our rule rewriting algorithm to instantiate the rule for his or her schema so that it will offer the same functionality as the standard rule for the standard schemas. The main contribution of this paper is to propose an algorithm to instantiate rules according to the mappings between the standard schemas and the instantiated schemas. That is, given a set of standard database schemas s1, a standard distributed ECA rule rule1 over s1, a set of instantiated database schemas s2, and a mapping m from s2 to s1, the algorithm outputs a new rule, rule2, for s2, which display the same functionality as rule1 for s1. In general, the mapping m from s2 to s1 can relate several relations in s1 to several other relations in s2. In this paper however, we restrict our attention to the special cases where the two schemas s1 and s2 have isomorphic relations or the instantiated schema s2 has more relations than the standard schema s1, whereby one relation in s1 is mapped into several in s2. The algorithm does not support those cases where several relations in s1 map into one schema in s2, neither does it support many-to-many mappings.
2 2.1
Background: ECA Rules and Schema Mappings ECA Rules
An Event-Conditon-Action(ECA) rule is composed of three parts: WHEN< event >, (IF< condition >,) THEN< action >. The ’when’ part describes the event which is meant to trigger the rule. The event can be as simple as an insertion or a deletion of a tuple in table, or a time event triggered at a certain time, or it can be a combination of many simple events. The second part describes the condition of the rule. This is optional, and consists of a Boolean expression. After the rule is triggered, the expression is evaluated. If true, the action in the ’then’ clause is executed. The action of the rule can be a simple database operation, a composite transaction including many simple database operations, or even a user-defined function. Kantere et al. [15] have proposed a distributed ECA rule language for peer Data Management Systems. Their rule language allows that the data accessed
An ECA Rule Rewriting Mechanism for Peer Data Management Systems
1071
and/or updated by a rule reside in different peer databases. They also propose a mechanism to implement efficiently the distributed ECA rule language. The following is an example of an ECA rule. Suppose that our peer network includes peer groups such as a family doctors, pharmacists, and hospitals. Each peer group has a standard - canonical - schema. Here is a fragment of the hospital group standard schema: SDHDB: Admission (AdmID, OHIP#, ...) Patient (H#, OHIP#, FName,LName, Sex, Age, FamilyDr, PatRecord) The following is part of the standard schema for the family doctor group: SDFDDB: Patient
(OHIP#, FName, LName, Phone#, Sex, Age, PatRecord)
A standard rule is defined over one or more standard schemas and is intended to express a generic coordination constraint. For example, when a patient enters a hospital, a record including the OHIP# (a unique patient identification number used in the health care system of Ontario, Canada) of that patient is inserted into the Admission table of the hospital database. This rule involves a single standard schema. Another example rule is triggered when there is an insertion into the Admission relation of the standard hospital schema. Its condition part checks whether the patient with the same OHIP# is a patient of a family doctor who is acquainted with the hospital. If the logical expression in the condition part returns true - that is, the patient is a patient of the acquainted family doctor - then the rule inserts a tuple to the ’Patient’ table in the hospital database with the patient’s information retrieved from the ’Patient’ table of the family doctor. If the logical expression returns false, no action is taken. This rule can be expressed in the rule language of Kantere et al. as follows: Rule 1: WHEN SDHDB.(’insert’, (Admission, ( OHIP#=>OHIP# value1 ))) IF OHIP# value1 = OHIP# value2 where SDFDDB.(’retrieve’, 45, {OHIP# value2, FName value, LName value, Phone# value, Sex value, Age value, PatRecord value}) THEN SDHDB.(’insert’, (Patient, (OHIP#
