budapest university of technology and economics department of computer science and information...

Budapest University of Technology and EconomicsDepartment of Computer Science and Information Theory 1

Graph Transformation in Relational Databases

Gergely VarróKatalin Friedl Dániel Varró

{gervarro,friedl}@[email protected]


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


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)


Graph transformation

blocked

releasetokenheld_by

next

R. Heckel: Compositional verification of reactive systems specified by graph transformation,FASE’98, vol. 1382 of LNCS, pages 138-153

Metamodel(type graph)

n1 : next

n2 : next

p1:Process p2:Process

Instance model(instance graph)

Process

Resource

request


r:Resource

hb:held_by

p:Process

reqn:request

rn:Resource

Rules• A resource that has been held by a process is

released.

r:Resource

p:Process

r:Resource

hb:held_byrel:release

p:Process

rqn:request

rn:Resource

ReleaseR

p:ProcessPrecondition Right-hand

side

Left-hand side

Negative application condition


Pattern matching phase

n1 : next

n2 : next

r:Resource

p:Process

r:Resource


p:Process

rqn:request

rn:Resource

ReleaseR

h1 : held_by h2 : held_by

r1:Resource p1:Process p2:Process r2:Resource

rq : request


Updating phase

r:Resource

p:Process

r:Resource


p:Process

rqn:request

rn:Resource

ReleaseR

n1 : next

n2 : next



rl : release

rq : request


Database introduction I.• Projection

• Selection

• Cartesian product

1 a

2 b

1

2

t1

A B

1 a

2 b

1 a

t1

A B

1 a 1 a’

2 b 1 a’

1 a 3 c

2 b 3 c

FROM t1

SELECT A

FROM t1

SELECT *

WHERE A=1

1 a

2 b

1 a’

3 c

t1

A B

t2

C D

FROM t1, t2

SELECT *

σA=1(t1)

A B

t1×t2

A B C D

ΠA(t1)

A


Database introduction II.• Inner join

• Left outer join

1 a

2 b

1 a’

3 c

t1

A B

t2

C D

1 a 1 a’

t1 INNER JOIN t2

A B C D

1 a

2 b

1 a’

3 c

t1

A B

t2

C D

t1 LEFT JOIN t2

A B C D

1 a 1 a’

2 b N N

FROM t1, t2

SELECT *

WHERE t1.A=t2.C

FROM t1 LEFT JOIN t2

SELECT *

ON t1.A=t2.C

t1.A=t2.C

No match for 2 in t2.CNo match for 3 in t1.At1.A=t2.C

No match for 2 in t2.C


Standard mapping

• Class Table

• Association Table + FK

• Inheritance Foreign key

Metamodel representation

Resource

id

next

id src trg

held_by

id src trg

blocked

releasetokenheld_by

next

Process

Resource

request

Metamodel(type graph)

Process

id

Database schema

...


Instance model representation

r1

r2

n1 p1 p2

n2 p2 p1

h1 r1 p1

h2 r2 p2

Data

Resource

id

next

id src trg

release

id src trg

held_by

id src trg

n1 : next

n2 : next



Instance model(Instance graph)

p1

p2

Process

id

rq : request


LHS computation

p1 h1 r1

p2 h2 r2

Computes the inner join of the corresponding tables

r:Resource

hb:held_by

p:Process

LHS view

SELECT

Process AS p, held_by AS hb, Resource AS rFROM

CREATE VIEW ReleaseR_lhs AS

WHERE r.id=hb.src AND p.id=hb.trg

ReleaseR_lhs

p hb r

p.id AS p, hb.id AS hb, r.id AS r

AND injectivity_constraints


NAC computation

Computes the inner join of the corresponding tables

rqn:request

rn:Resource

NAC view

p:Process

SELECT p.id AS p, rqn.id AS rqn, rn.id AS rn

Process AS p, request AS rqn, Resource AS rnFROM

CREATE VIEW ReleaseR_nac AS

WHERE p.id=rqn.src AND rn.id=rqn.trg

ReleaseR_nac

p rqn rn

Exactly the same method as for LHS

p2 rq r2


Precondition computationlhs

p hb r

p1 h1 r1

p2 h2 r2

p1 h1 r1 N N N

p2 h2 r2 p2 rq r2

Computes the left outer join of LHS and NACSELECT lhs.*

ReleaseR_lhs AS lhs LEFT JOIN ReleaseR_nacFROM

CREATE VIEW ReleaseR AS

WHERE nac.p IS NULL

ON lhs.p=nac.p

ReleaseR

p hb r

lhs LEFT JOIN nac

p hb r p rqn rn

p1 h1 r1

p2 h2 r2

nac

p rqn rn

r:Resource

hb:held_by

p:Process

rqn:request

rn:Resource

Successful matching

Precondition view

p2 rq r2


n1 : next

n2 : next



Updating tables I.

h2 r2 p2

held_by

id src trg

r:Resource

hb:held_by

p:Process

rqn:request

rn:Resource

ReleaseR

DELETE FROM held_by

WHERE id=h1

h1 r1 p1


Updating tables II.

n1 : next

n2 : next

h2 : held_by


rl : release

release

id src trg

rl r1 p1

INSERT INTO

VALUES (rl,r1,p1)

release (id,src,trg)

p:Process

r:Resource

rel:release

ReleaseR


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


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


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


Quantitative comparison I.

0

100

200

300

400

500

600

small medium large

AGG

Progres

Fujaba

DB


Quantitative comparison II.

0

200

400

600

800

1000

1200

1400E

xecu

tio

n t

ime

(ms)

50 150 250 500 1000Model size

AGG

Progres

Fujaba

DB


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)


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


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)


Before saying thank you for your kind attention...

I have some additional surprise if you are interested.


AGG (match vs. update)

0

200

400

600

800

1000

1200

1400

1600

0 200 400 600 800 1000 1200

Rule application sequence

Exe

cuti

on

tim

es (

ms)

match

update


Fujaba extra I.

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

0 20 40 60 80 100 120 140 160 180

Rule application sequence

Lo

gar

ith

m o

f ex

ecu

tio

n t

ime

newR

reqR

takeR

relR

giveR


Fujaba extra II.

0

5000

10000

15000

20000

25000

30000

35000

40000

45000

100 97 94 91 88 85 82 79 76 73 70 67 64 61 58 55 52 49 46 43 40 37 34 31 28 25 22 19 16 13 10 7 4 1

No. of matchings

Ex

ec

uti

on

tim

e (

ms

)

budapest university of technology and economics department of computer science and information...

Documents