1 / 28

Graph Transformation in Relational Databases

Graph Transformation in Relational Databases. Gergely Varró Katalin Friedl Dániel Varró {gervarro,friedl}@cs.bme.hu varro@mit.bme.hu. Introduction. Graph transformation graph query + manipulation at very high abstraction level Relational database management systems

fabian
Download Presentation

Graph Transformation in Relational Databases

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Graph Transformation in Relational Databases Gergely VarróKatalin Friedl Dániel Varró {gervarro,friedl}@cs.bme.huvarro@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. next p1:Process p2:Process Process Resource Graph transformation n1 : next n2 : next Instance model (instance graph) R. Heckel: Compositional verification of reactive systems specified by graph transformation,FASE’98, vol. 1382 of LNCS, pages 138-153 held_by token release Metamodel (type graph) blocked request

  5. p:Process rn:Resource reqn:request hb:held_by r:Resource Rules • A resource that has been held by a process is released. p:Process rn:Resource p:Process rqn:request rel:release hb:held_by Negative application condition Left-hand side r:Resource r:Resource ReleaseR p:Process Precondition Right-hand side

  6. p2:Process p1:Process r1:Resource r2:Resource Pattern matching phase p:Process rn:Resource p:Process rqn:request rel:release hb:held_by r:Resource r:Resource ReleaseR n1 : next rq : request h1 : held_by h2 : held_by n2 : next

  7. r2:Resource p2:Process p1:Process r1:Resource Updating phase p:Process rn:Resource p:Process rqn:request rel:release hb:held_by r:Resource r:Resource ReleaseR n1 : next rq : request h1 : held_by rl : release h2 : held_by n2 : next

  8. SELECT A SELECT * FROM t1 FROM t1, t2 SELECT * FROM t1 WHERE A=1 Database introduction I. • Projection • Selection • Cartesian product

  9. SELECT * FROM t1, t2 WHERE t1.A=t2.C SELECT * FROM t1 LEFT JOIN t2 ON t1.A=t2.C Database introduction II. • Inner join • Left outer join t1.A=t2.C No match for 2 in t2.C No match for 3 in t1.A t1.A=t2.C No match for 2 in t2.C

  10. Process Resource Metamodel representation next Standard mapping • Class  Table • Association  Table + FK • Inheritance Foreign key ... held_by token release Database schema blocked request Metamodel (type graph)

  11. r1:Resource p1:Process p2:Process r2:Resource Instance model representation n1 : next rq : request h1 : held_by h2 : held_by n2 : next Instance model (Instance graph) Data

  12. LHS computation LHS  view Computes the inner join of the corresponding tables p:Process hb:held_by r:Resource CREATE VIEW ReleaseR_lhs AS SELECT p.id AS p, hb.id AS hb, r.id AS r FROM Process AS p, held_by AS hb, Resource AS r WHERE r.id=hb.src AND p.id=hb.trg AND injectivity_constraints

  13. CREATE VIEW ReleaseR_nac AS SELECT p.id AS p, rqn.id AS rqn, rn.id AS rn Process AS p, request AS rqn, Resource AS rn FROM WHERE p.id=rqn.src AND rn.id=rqn.trg NAC computation NAC  view Computes the inner join of the corresponding tables Exactly the same method as for LHS p:Process rn:Resource rqn:request

  14. Precondition computation p:Process rn:Resource Successful matching rqn:request hb:held_by r:Resource Precondition  view CREATE VIEW ReleaseR AS Computes the left outer join of LHS and NAC SELECT lhs.* FROM ReleaseR_lhs AS lhs LEFT JOIN ReleaseR_nac ON lhs.p=nac.p WHERE nac.p IS NULL

  15. DELETE FROM held_by WHERE id=h1 r2:Resource r1:Resource p1:Process p2:Process Updating tables I. p:Process rn:Resource rqn:request hb:held_by r:Resource ReleaseR n1 : next h1 : held_by h2 : held_by n2 : next

  16. INSERT INTO release (id,src,trg) VALUES (rl,r1,p1) r1:Resource p1:Process p2:Process r2:Resource Updating tables II. p:Process rel:release r:Resource 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.

More Related