Graph Transformation in Relational Databases

1
Graph Transformation in Relational Databases

• Gergely VarróKatalin Friedl Dániel Varró
• gervarro,friedl_at_cs.bme.huvarro_at_mit.bme.hu

2
Introduction

• Graph transformation
• graph query manipulation
• at very high abstraction level
• Relational database management systems
• storage medium for business critical data
• the most successful field of SW engineering
• close synergy between theory and practice SQL
• manipulation on a low level of abstraction

3
Motivation

• GT for databases
• hybrid (visual textual) query language based
  upon GT Andries, Engels
• Varlet framework Jahnke, Zündorf TGGs for
  database re-engineering
• GRAS (graph-oriented DBMS, underlying database
  for PROGRES) Kiesel, Schürr, Westfechtel
• Databases for GT
• How to do? (Mapping)
• How fast? (Performance)

4
Graph transformation
n1 next
n2 next
Instance model (instance graph)
R. Heckel Compositional verification of reactive
systems specified by graph transformation,FASE98
, vol. 1382 of LNCS, pages 138-153
release
token
held_by
Metamodel (type graph)
blocked
request
5
Rules

• A resource that has been held by a process is
  released.

pProcess
pProcess
rnResource
rqnrequest
relrelease
hbheld_by
Negative application condition
Left-hand side
rResource
rResource
ReleaseR
pProcess
Precondition
Right-hand side
6
Pattern matching phase

pProcess
rnResource
pProcess
rqnrequest
relrelease
hbheld_by
rResource
rResource
ReleaseR
n1 next
rq request
h1 held_by
h2 held_by
n2 next
7
Updating phase

pProcess
rnResource
pProcess
rqnrequest
relrelease
hbheld_by
rResource
rResource
ReleaseR
n1 next
rq request
h1 held_by
h2 held_by
rl release
n2 next
8
Database introduction I.

• Projection
• Selection
• Cartesian product

t1 t1
A B
?A(t1)
A
1 a
2 b
1
2
t1 t1
A B
sA1(t1) sA1(t1)
A B
1 a
2 b
1 a
t1t2 t1t2 t1t2 t1t2
A B C D
t1 t1
A B
t2 t2
C D
1 a 1 a
2 b 1 a
1 a 3 c
2 b 3 c
1 a
2 b
1 a
3 c
9
Database introduction II.

• Inner join
• Left outer join

t1 t1
A B
t2 t2
C D
t1 INNER JOIN t2 t1 INNER JOIN t2 t1 INNER JOIN t2 t1 INNER JOIN t2
A B C D
t1.At2.C
1 a
2 b
1 a
3 c
1 a 1 a
t1 t1
A B
t2 t2
C D
t1 LEFT JOIN t2 t1 LEFT JOIN t2 t1 LEFT JOIN t2 t1 LEFT JOIN t2
A B C D
No match for 2 in t2.C
No match for 3 in t1.A
t1.At2.C
1 a
2 b
1 a
3 c
1 a 1 a
2 b N N
No match for 2 in t2.C
10
Metamodel representation
next
Resource
id
Process
id
...
next next next
id src trg
held_by held_by held_by
id src trg
release
token
held_by
Database schema

• Standard mapping
• Class ? Table
• Association ? Table FK
• Inheritance ? Foreign key

blocked
request
Metamodel (type graph)
11
Instance model representation
n1 next
rq request
h1 held_by
h2 held_by
n2 next
Instance model (Instance graph)
Resource
id
next next next
id src trg
release release release
id src trg
held_by held_by held_by
id src trg
Process
id
r1
r2
n1 p1 p2
n2 p2 p1
h1 r1 p1
h2 r2 p2
p1
p2
Data
12
LHS computation
LHS ? view
Computes the inner join of the corresponding
tables
pProcess
ReleaseR_lhs ReleaseR_lhs ReleaseR_lhs
p hb r
hbheld_by
p1 h1 r1
p2 h2 r2
rResource
CREATE VIEW ReleaseR_lhs AS
SELECT
p.id AS p,
hb.id AS hb,
r.id AS r
Process AS p,
held_by AS hb,
Resource AS r
FROM
WHERE
r.idhb.src
AND
p.idhb.trg
AND injectivity_constraints
13
NAC computation
NAC ? view
Computes the inner join of the corresponding
tables
Exactly the same method as for LHS
ReleaseR_nac ReleaseR_nac ReleaseR_nac
p rqn rn
rnResource
pProcess
rqnrequest
p2 rq r2
14
Precondition computation
lhs lhs lhs
p hb r
lhs LEFT JOIN nac lhs LEFT JOIN nac lhs LEFT JOIN nac lhs LEFT JOIN nac lhs LEFT JOIN nac lhs LEFT JOIN nac
p hb r p rqn rn
nac nac nac
p rqn rn
p1 h1 r1
p2 h2 r2
p1 h1 r1 N N N
p2 h2 r2 p2 rq r2
p2 rq r2
ReleaseR ReleaseR ReleaseR
p hb r
pProcess
rnResource
Successful matching
rqnrequest
p1 h1 r1
p2 h2 r2
hbheld_by
rResource
Precondition ? view
Computes the left outer join of LHS and NAC
CREATE VIEW ReleaseR AS
SELECT lhs.
ReleaseR_lhs AS lhs
LEFT JOIN
ReleaseR_nac
FROM
ON lhs.pnac.p
WHERE
nac.p IS NULL
15
Updating tables I.
held_by held_by held_by
id src trg
pProcess
rnResource
rqnrequest
h1 r1 p1
h2 r2 p2
hbheld_by
rResource
ReleaseR
n1 next
h1 held_by
h2 held_by
n2 next
16
Updating tables II.
release release release
id src trg

pProcess
rl r1 p1
relrelease
rResource
ReleaseR
n1 next
h2 held_by
rl release
n2 next
17
Categorization

• Style
• interpreted AGG, Progres
• compiled Fujaba, DB based approach
• Base algorithm
• constraint satisfaction AGG, VIATRA, DB based
  approach
• variables constraints
• local searches Fujaba, Progres
• step-by-step extension of the matching
• Single pushout approach with injective matchings

18
Tool comparison I.

• Same set of test cases
• Short transformation sequences
• deterministic execution order
• length between 25 and 5000
• Long transformation sequences
• deterministic execution order (no matchings in
  some cases)
• up to 60000 rule applications
• Few matches on large models
• as long as possible rule application

19
Tool comparison II.

• Tool specific issues
• AGG
• Without GUI, controlled by a Java program
• Progres
• Interpreted version with GRAS
• Prolog-style cuts (determinism)
• Measurements on a second scale
• Fujaba
• Always (Many-)To-Many associations
• Without DOBS
• Additional node for storing processes and
  resources
• Our approach
• PostgreSQL No additional optimization

20
Quantitative comparison I.
21
Quantitative comparison II.
22
Evaluation I.

• AGG
• good PM strategy even for large models
• update strategy linear in model size (!!!) due
  to compilation into categories
• Progres
• good, if relatively large number of matches
  compared to the model size
• worst execution results (especially if large
  models few matches)

23
Evaluation II.

• Fujaba
• extremely good for small models
• performance problems with large models
• could be much better if DFS graph traversal is
  supported
• DB
• runs on all test cases
• relatively large overhead for as long as possible
  rule applications (always from scratch)
• BUT STILL THE BEST FOR LARGE MODELS

24
Future work

• Interface definition
• to enable the integration of the engine to
  several GT tools
• Comparison to other tools
• VIATRA
• GReAT
• Comparison on other test cases
• Incremental transformations
• Now in Darmstadt (Segravis)

25
Before saying thank you for your kind
attention...

• I have some additional surprise if you are
  interested.

26
AGG (match vs. update)
27
Fujaba extra I.
28
Fujaba extra II.
29
Results of tool comparison I.
Proc Mod. TS AGG AGG Progres Progres Fujaba Fujaba DB DB
size length avg sum avg sum avg sum avg sum
ms ms ms ms ms ms ms ms
5 17 24 105 2512 125 3000 2 38 48 1150
100 302 499 110 55047 1042 520000 45 22379 35 17459
1000 3002 4999 409 TO TO TO 260 TO 140 700419

4 21 2500 145 362811 97 242000 1 2926 34 84951
1000 5001 60001 1952 TO 920 TO 7794 TO 257 1544621

10 50 40 78 3111 100 4000 13 519 18 723
30 150 120 74 8926 225 27000 145 17421 33 3909
50 250 200 83 16680 345 69000 639 127874 37 7332
100 500 400 128 51047 657 263000 5061 2024589 38 15000
200 1000 800 315 251706 1294 1035000 6918 TO 51 40581
30
Conclusion

• Outperformed GT engines based on interpreted
  approaches
• Fujaba comparison
• better in case of large models
• worse in case of small models
• Worst-case assessment method
• More simple rules
• join of few tables
• independent of the number of rules