8.6 Incremental graph pattern matching in relational databases
8.6.2 Incremental view updates for rule graphs ( LHS and NAC )
Section 6.4.2 already described how views for rule graphs (LHS andNAC) could be generated from tables that stored objects and links of the instance model. Now I present the process that updates these views incrementally by using events being issued when the content of tables is changed.
For each pattern node and edge of each LHS graph, a pair consisting of an insert and a delete operation trigger is specified for the view defined for theLHS. These triggers process events issued by the table representing the pattern node and edge in turn.
Trigger conditions.Conditions of triggers are defined by the following guidelines.
8.6. INCREMENTAL GRAPH PATTERN MATCHING IN RELATIONAL DATABASES 145
• As objects are represented by individual rows in the corresponding tables as shown in Sec. 6.4.1, the addition and the removal of such objects appear as insertion and deletion events issued by these tables, respectively.
To handle these events during incremental operation, an insert and a delete operation trigger have to be declared, respectively, for each pattern node of eachLHS(NAC) graph. These triggers propagate changes in the table representing the type of the pattern node to the view being assigned to theLHS(NAC) graph.
• Each many-to-one link is stored in the table that corresponds to its source object, and represented by the identifier of its target object in the column that has been assigned to the type of the link. In this case, modifications of such links are reported by update events, which inform on changes in the column associated with the link type. However, as link addition and removal are described by setting and clearing the corresponding target object identifiers, respectively, update events have to be filtered accordingly.
In incremental mode, for each many-to-one link of eachLHS(NAC) graph, an insert and a delete operation trigger are defined to process filtered update events, which report on setting and clear-ing values, respectively, in the column representclear-ing the link type.
• A many-to-many link is represented by an individual row in a corresponding table, the addition and the removal of such links are reported by insertion and deletion events, respectively. These events can be handled by a corresponding insert and delete operation trigger, respectively, which are defined for each many-to-many pattern edge of eachLHS(NAC) graph.
Trigger actions. Recall that the non-incremental approach of Sec. 6.4.2 used a separate view for calculating the matchings of each LHS and NAC graph. Each view has been specified by a query consisting of the following sequence of operations. An inner join operation is executed first on tables that represent either a node or an edge of the rule graph. The joined table is then filtered by injectivity and edge constraints, and finally, columns that represent node identifiers are selected by a projection.
In the incremental approach, the above-mentioned overall query structure is preserved for defining trigger actions, only the table, which issues the events processed by the trigger, is replaced with the modified rows of the same event.
Example 35 For exemplifying the incremental operation in RDBMSs, the database equivalent of
ClassRule is monitored, when database representatives of class c1 and EO link connecting class c1
to packagepare added to the model as depicted by Figures 8.4(c), and 8.4(e), respectively.
As theLHSofClassRulehas three nodes and two many-to-one edges, there are five insert and five delete operation triggers defined for viewClassRule_lhs. Each pair of triggers handles events arriving from the table that represents the type of either a pattern node or a pattern edge.
This running example focuses only on those triggers that are actually used during the above-mentioned transformation. In this sense, when class c1 is added to the instance model, the insert operation trigger, which handles insertion events of tableClass is invoked. The trigger action is de-scribed by the query of Listing 8.1.
During the actual query execution, the question mark in Listing 8.1 has to be substituted with the database identifier of the class being inserted, which isc1in this case. This query gives an empty result as the equationc_anc.EO = p.idfails due to the lack ofEOlinks in the model of Fig. 8.4(c). As a consequence, viewClassRule_lhsis not extended now.
When theEOlink connecting classc1to packagepis added to the model as shown by Fig. 8.4(e), tableModelElementis modified in its columnEOby modifyingNULLvalue top. This change is detected
146 CHAPTER 8. INCREMENTAL GRAPH TRANSFORMATION
INSERT INTO ClassRule_lhs (c,p,s) -- Insert operation SELECT c.id AS c, p.id AS p, s.id AS s -- Non-incremental query FROM Class AS c, ModelElement AS c_anc,
Package AS p, ModelElement AS p_anc, Schema AS s
WHERE c.id = c_anc.id AND c_anc.EO = p.id AND p.id = p_anc.id AND p_anc.Ref = s.id AND p.id <> s.id
AND c.id = ? -- Execution restricted to
-- IDs of new classes -- in incremental mode
Listing 8.1: Query handling the insertion of classes
by the insert operation trigger defined for viewClassRule_lhs, which handles such events that signal an update on columnEO, during which aNULLvalue has been replaced by a non-NULLvalue. The action defined by this insert operation trigger is depicted in Listing 8.2.
INSERT INTO ClassRule_lhs (c,p,s) SELECT c.id AS c, p.id AS p, s.id AS s FROM Class AS c, ModelElement AS c_anc,
Package AS p, ModelElement AS p_anc, Schema AS s
WHERE c.id = c_anc.id AND c_anc.EO = p.id AND p.id = p_anc.id AND p_anc.Ref = s.id AND p.id <> s.id
AND c_anc.id = ? -- "c1"
AND c_anc.EO = ? -- "p"
Listing 8.2: Query handling the insertion ofEOlinks
When the query of Listing 8.2 is executed, question marks are replaced with identifiersc1andp
denoting source and target objects of the newEOlink, respectively. As a result, a triple consisting of valuesc1,p, andsis added to viewClassRule_lhs, which corresponds to a new matching for theLHS graph ofClassRule.
Formalization. Recall that notational shorthandsnV = |VLHS|andnE = |ELHS|have been intro-duced for denoting the number of pattern nodes and edges. Additionally, a total order has been defined for the node and edge sets in which nodes precede edges, andxiandznV+jare theith node and thejth edge in this order, respectively.
Recall further that the viewrdLHSfor theLHShas been defined in Sec. 6.4.2 by the following query Q=πP rojColRef s(σInj∧Edge(T1×. . .×Ti×. . .×TnV+nE)),
in which tableTihas been assigned to the type of theith pattern node or edge ofrLHS. Formally,
Ti =
t(xi)d,wheni≤nV andxi ∈VLHS
src(t(zi))d,whennV < i≤nV +nE andui zi
→1 vi∈ELHS
t(zi)d,whennV < i≤nV +nE andui →zi∗ vi∈ELHS
8.6. INCREMENTAL GRAPH PATTERN MATCHING IN RELATIONAL DATABASES 147
Edge constraintsEdge, injectivity constraintsInj, and projection column referencesP rojColRef s are expressed in exactly the same way as in Sec. 6.4.2.
In order to incrementally update viewrdLHSfor rule graphrLHS, insert and delete operation triggers are defined, which handle events arriving from tables representing the types of pattern nodes and edges.
Queries of these triggers always use such versions of queryQ, which restrict calculations only on the set of modified rows reported by arriving events instead of using the complete table.
• Triggers for pattern nodes. For each pattern nodexi, an insert operation trigger is specified by queryQ
t(xi)d→∆(t(xi)d)+
for viewrLHSd on insertion event INSERT,∆(t(xi)d)+ issued by the tablet(xi)drepresenting the typet(xi)of pattern nodexi.
Additionally, for each pattern node xi, a delete operation trigger is specified by query Q
t(xi)d→∆(t(xi)d)−
for the same view rLHSd on deletion event DELETE,∆(t(xi)d)− is-sued by the same tablet(xi)d.
• Triggers for many-to-one pattern edges. In order to avoid complex formulae when specifying triggers for many-to-one pattern edgeui
zi
→1 vi, letSi temporarily denote the tablesrc(t(zi))d, in which many-to-one links of typet(zi)are stored in the database. Since target objects of these links are represented by values in columnt(zi)d, the database trigger monitoring changes in this column can be expressed by update events with modified rows∆(Si)t(znewi)d.
For each many-to-one pattern edge ui →zi1 vi, an insert operation trigger is speci-fied by query Q
hSi →σt(zi)d6=ε
∆(Si)t(znewi)d
i
for view rdLHS on filtered update event
, only those modified rows are kept, in which the value in columnt(zi)dhas been changed from undefined (NULL) to a non-NULLvalue.
Additionally, for each many-to-one pattern edgeui zi
for the same view rLHSd on deletion event
UPDATE, σt(zi)d=ε
∆(Si)t(znewi)d
issued by the same tableSi. In this case, the filtered event identifies such rows, in which the value in columnt(zi)d has been modified from a non-NULL
value to undefined (NULL).
• Triggers for many-to-many pattern edges. For each many-to-many pattern edge ui →zi∗ vi, an insert operation trigger is specified by queryQ
t(zi)d→∆(t(zi)d)+
for viewrdLHSon insertion event INSERT,∆(t(zi)d)+
issued by the tablet(zi)drepresenting the typet(zi)of pattern edge ui
zi
→∗ vi.
Additionally, for each many-to-many pattern edge ui →zi∗ vi, a delete operation trigger is specified by query Q
t(zi)d→∆(t(zi)d)−
for the same view rdLHS on deletion event DELETE,∆(t(zi)d)−
issued by the same tablet(zi)d.
Insertion and deletion triggers for views representing theNACs can be specified in exactly the same way, but using theNACgraphs in the process.