Presentation is loading. Please wait.

Presentation is loading. Please wait.

PReCISE LIBD 1st International Workshop on Bidirectional Transformations - Bx 2012 Tallin, March 25, 2012 Bidirectional Transformations in Database Engineering.

Similar presentations


Presentation on theme: "PReCISE LIBD 1st International Workshop on Bidirectional Transformations - Bx 2012 Tallin, March 25, 2012 Bidirectional Transformations in Database Engineering."— Presentation transcript:

1 PReCISE LIBD 1st International Workshop on Bidirectional Transformations - Bx 2012 Tallin, March 25, 2012 Bidirectional Transformations in Database Engineering Jean-Luc Hainaut, Anthony Cleve

2 2 Reference Objectives of the conference  short  practical  intuitive  introduction  to the (x) transformational paradigm,  applied to the DB domain. Based on:  Hainaut, J-L., Cleve, A., Transformational Approach to Database Engineering and Evolution, tutorial, Dagstuhl seminar on "Bx", January 2011  Hainaut, J-L, The Transformational Approach to Database Engineering, in Lämmel, R., Saraiva, J., Visser, V., (Eds), Generative and Transformational Techniques in Software Engineering, pp , LNCS 4143, Springer, 2006)

3 3 1. Introduction 2. Transformational engineering 3. Modeling data structures 4. Schema transformations 5. Bidirectional transformations 6. Typology of practical elementary transformations 7. Typology of practical complex transformations 8. Transformational modeling of database engineering processes 9. Conclusions and perspectives (A. Schema transformations in CASE tools) Contents

4 4 1. Introduction

5 5 Goal: to introduce the conference (what else would you have expected?)

6 6 1. Introduction "Bidirectional transformations (bx) are a mechanism for maintaining the consistency of at least two related sources of information." "Such sources can be databases, software models, documents, graphs, and trees." bx appear in many aspects of the data & DB realm:  Model-Driven Software/DB Development: to compute and synchronize views of software/DB models.  Relational Databases: to construct updatable views.  Data Transformation, Integration, and Exchange: to map data across paradigms, merge it from multiple sources, and exchange it between sources.  Data Synchronizers: to bridge the gap between replicas in different formats.  Serializers: to mediate between external data (binary or sequential data representations on the wire or the le system) and structured objects in memory. source: GRACE Report, 2008

7 7 1. Introduction Focus of this conference:  Model-Driven Software Development: to compute and synchronize views of software models.  Model-Driven Database Engineering: to compute and synchronize views of database schemas. 

8 8 1. Introduction DB Engineering = {domain analysis, logical design, physical design, view derivation, optimisation, code generation, reverse engineering, maintenance, evolution, migration, integration, etc.}

9 9 1. Introduction Two directions of synchronization: Vertical synchronization: in the design abstraction artifact hierarchy, how to ensure that there is no information loss? conceptual schema logical schema physical schema DDL code horizontal synchronization: when an artifact changes, how to resynchronize the other artifacts?

10 10 1. Introduction Two directions of synchronization: conceptual schema logical schema physical schema DDL code Client program conceptual schema' Client program' logical schema' physical schema' DDL code' horizontal synchronization: when an artifact changes, how to resynchronize the other artifacts? Vertical synchronization: in the design abstraction artifact hierarchy, how to ensure that there is no information loss?

11 11 2. Transformational engineering

12 12 Goal: to show a practical application of schema transformations or how to motivate participants at 9 o'clock, summer time?

13 13 l through translation rules l through transformations How to derive a target schema from a source schema? 2. Transformational engineering

14 14 l Rule-based engineering the target specification is produced following a set of translation rules. l Transformation-based engineering the target specification is produced by application of a chain of substitution operators to the source specifications. Rule-based vs Transformation-based engineering 2. Transformational engineering

15 15 Rule-based view of Database Engineering Example: producing a relational schema from a conceptual schema  Conceptual schema (ER) Physical schema (MS Access) 2. Transformational engineering

16 16 Rule-based view of Database Engineering Natural procedure: through translation rules 2. Transformational engineering

17 17 Rule-based view of Database Engineering OK, but what if:  attribute A is at level 2, 3, …?  attribute A is not atomic?  relationship type R is many-to-many, or one-to-one, or N-ary?  etc.  Combinatorial explosion and complexity of the set of rules. 2. Transformational engineering

18 18 Transformation-based view of Database Engineering Transforming the multivalued attribute Author  2. Transformational engineering

19 19 Transformation-based view of Database Engineering Transforming the many-to-many relationship type write  2. Transformational engineering

20 20 Transformation-based view of Database Engineering Transforming the one-to-many relationship type aw (and the others)  2. Transformational engineering

21 21 Transformation-based view of Database Engineering Coding (generally simple; rule-based or transformational)  No more than 5 WRITE rows per BOOK row. 2. Transformational engineering

22 22 Transformation-based view of Database Engineering What if the attribute is multivalued, compound and comprises other multivalued components ?  rule? 2. Transformational engineering

23 23 Transformation-based view of Database Engineering  Note: slightly different variant of the transformation of an attribute into an entity type 2. Transformational engineering

24 24 Transformation-based view of Database Engineering  2. Transformational engineering

25 25 Transformation-based view of Database Engineering  2. Transformational engineering

26 26 Transformation-based view of Database Engineering Observations l no new operators l iterative application of known operators l compositional property of transformations (the composition of two transformations still is a transformation) l no combinatorial explosion, just the right (small) set of operators l need for meta-rules for applying the operators (a transformation plan) 2. Transformational engineering

27 27 What now? 2. Transformational engineering

28 28 Questions l We need to represent schemas in a great variety of models (GER = Generic ER model) l What is a transformation and how to specify it? l Does a transformation preserve the information contents of a schema? l Let us be more concrete: what about PRACTICAL transformations? l How do transformations help in REAL database engineering processes? 1. Introduction

29 29 3. Modeling data structures

30 30 Goal: to define a common formalism to specify data structures in different data models or how to tidy the data model Babel tower?

31 31 Dealing with multiple models A typical organization uses N different data models. E.g., it  commonly uses DB2 databases,  also uses a legacy IDMS database,  writes its conceptual schemas in the ER model,  quite often transfers data between databases,  exchanges data with its environment,  standardizes on XML format,  plans to migrate some databases to other platforms,  prepares the development of a datawarehouse,  study the feasibility to merge several departments (and their information systems),  etc. 3. Modeling Data Structures

32 32 Dealing with multiple models ETL data warehouse application program operational data environment design conceptual schema migrate XML extract & export XML import organization 3. Modeling Data Structures

33 33 Dealing with multiple models Considering all the inter-model and intra-model conversions, the organization requires N x N different mappings (= 16). Relational Model CODASYL Model XML Model ER Model  rel>rel  cod>cod  er>er  xml>xml  rel>er  rer>rel  cod>xml  xml>cod  er>xml  xml>er  rel>cod  cod>rel  xml>rel  rel>xml  cod>er  er>cod 3. Modeling Data Structures

34 34 Dealing with multiple models The usual answer: introducing a pivot model. Considering all the inter-model and intra-model conversions, the organization requires 2 x N + 1 different mappings (= 9). Pivot Model p>pp>p Relational Model CODASYL Model XML Model  rel>p  p>rel  p>cod  cod>p  er>p  p>er  p>xml  xml>p ER Model 3. Modeling Data Structures

35 35 Dealing with multiple models Example: relational logical design. Pivot Model p>pp>p Relational Model  p>rel  er>p ER Model logical schemaconceptual schema Logical design 3. Modeling Data Structures very simple complex

36 36 GER: the Generic Entity-Relationship model A large spectrum data structure model l Encompasses several paradigms: ER, UML, SQL, CODASYL, IMS, file structures, XML, etc. l Encompasses several levels of abstraction: conceptual, logical, physical, external Chosen as the pivot model in this tutorial Pivot Model GER Model  3. Modeling Data Structures

37 37 GER: the Generic Entity-Relationship model Conceptual schema fragment (1) entity type Is-a attribute all-attribute ID hybrid ID relationship type role (with cardinality) 3. Modeling Data Structures

38 38 GER: the Generic Entity-Relationship model Conceptual schema fragment (2) multivalued attribute compound attribute optional attribute N-ary relationship type 3. Modeling Data Structures

39 39 GER: the Generic Entity-Relationship model Logical schema fragment record set / table foreign key array multivalued field 3. Modeling Data Structures

40 40 GER: the Generic Entity-Relationship model Physical schema fragment: RDB unique index storage space index 3. Modeling Data Structures

41 41 4. Schema transformations

42 42 Goal: to define more precisely the nature of schema transformation or actually, what is a transformation?

43 43 A transformation T replaces a construct C in a schema S1 with another construct C', leading to schema S2 T schemas S1 S2 C C' 4. Schema transformations

44 44 If the schema describes actual data, the transformation should also tell how to convert the data (t)... t data T schemas S1 S2 C C' c c' 4. Schema transformations

45 45 A transformation  is defined by two mappings T and t  = T: structural mapping = syntax of  t: instance mapping = semantics of  C' = T(C) c' = t(c)c C T t inst_of 4. Schema transformations

46 46 Mapping T can be specified with two predicates: P: minimal pre-condition Q: maximal post-condition  = = 4. Schema transformations

47 47 Expressing structural predicates through any logic-based language entity-type(E)there exists an entity type with name E entity-type(e)there exists an entity type denoted by e relational (more concise, a name denotes an object) object-based (more general, a name is a property of an object) name(e,E)the name of e is E must allow specification AND reasoning (e.g., DL) 4. Schema transformations

48 48 Expressing structural predicates intuitive example entity-type(E)there exists an entity type with name E attribute(O,A,m,M,T)object (with name) O has an attribute with name A, cardinality m-M and type T id(O,Cp)object (with name) O has an identifier comprising components Cp rel-type(R)there exists a rel-type with name R role(R,r,E,m,M)rel-type R has a role with name r, played by E, with cardinality m-M 4. Schema transformations

49 49 Specifying an entity type: entity-type(CUSTOMER)  attribute(CUSTOMER,Cust#,1,1,integer)  attribute(CUSTOMER,Name,1,1,string)  attribute(CUSTOMER,Phone,0,5,string)  id(CUSTOMER,{Cust#}) 4. Schema transformations

50 50 Practically, a structural predicate can be defined graphically: entity-type(CUSTOMER)  attribute(CUSTOMER,Cust#,1,1,integer)  attribute(CUSTOMER,Name,1,1,string)  attribute(CUSTOMER,Phone,0,5,string)  id(CUSTOMER,{Cust#}) = 4. Schema transformations

51 51 The structural mapping of a transformation can be defined graphically: P Q P = entity-type(CUSTOMER)  attribute(CUSTOMER,Cust#,1,1,integer)  attribute(CUSTOMER,Name,1,1,string)  attribute(CUSTOMER,Phone,0,5,string)  id(CUSTOMER,{Cust#}) Q = entity-type(CUSTOMER)  attribute(CUSTOMER,Cust#,1,1,integer)  attribute(CUSTOMER,Name,1,1,string)  id(CUSTOMER,{Cust#})  entity-type(PHONE)  attribute(PHONE,Phone,1,1,string)  id(PHONE,{Phone})  rel-type(has)  role(has,,CUSTOMER,0,5)  role(has,,PHONE,1,N) 1-N0-5 has PHONE Phone id:Phone CUSTOMER Cust# Name id:Cust# = =  4. Schema transformations

52 52 From now on: P Q 1-N0-5 has PHONE Phone id:Phone CUSTOMER Cust# Name id:Cust#  4. Schema transformations

53 53 Inverse transformation  2 =  1  iff  C: P1(C)  C = T2(T1(C)) 1-N0-5 has PHONE Phone id:Phone CUSTOMER Cust# Name id:Cust#   T1T1 T2T2 Intuitively,  2 undoes the effect of  1 at the structural level 4. Schema transformations

54 54 5. Bidirectional transformations

55 55 Goal: to study the semantics preservation of transformations or at last, could will talk about bx ?

56 56 A transformation can... l augment the information contents of the schema l decrease the information contents of the schema l preserve the information contents of the schema    5. Bidirectional transformations

57 57 A transformation can be... l not reversible: not semantics-preserving l reversible: "one-way" semantics-preserving l symmetrically reversible: fully semantics-preserving or bidirectional 5. Bidirectional transformations

58 58 Examples P:R(A,B,C); Q:R1(A,B); R2(A,C); not reversible P:R(A,B,C); A  B|C Q:R1(A,B); R2(A,C); reversible (Fagin's theorem) P:R(A,B,C); A  B|C Q:R1(A,B); R2(A,C); R1[A] = R2[C]; symmetrically reversible (bx) 5. Bidirectional transformations

59 59 Reversible transformation A transformation is reversible if there is an inverse mapping for instances as well  1 is reversible  iff   2 =  1 :  C: P(C)  C = T2(T1(C))   c  inst(C): c = t2(t1(c)) 5. Bidirectional transformations

60 60 Symmetrically reversible (or bx) transformation  is symmetrically reversible  iff both  and  are reversible  =   = l SR-transformations are the most desirable operators l They preserve the information contents of the source schema l They are semantics-preserving 5. Bidirectional transformations

61 61 Can we formally prove that a transformation is semantics- preserving, i.e., that it is SR? Yes, definitely. See: Jean-Luc Hainaut, J.-L. (2006) The Transformational Approach to Database Engineering, in Generative and Transformational Techniques in Software Engineering, LNCS, Volume 4143, pages , Springer-Verlag. LNCS-final-revised.pdf 5. Bidirectional transformations

62 62 6. Typology of practical transformations Elementary transformations

63 63 Goal: to look at some representative elementary transformations or could you give us some examples?

64 64 The working example 6. Typology of practical elementary transformations

65 65 The main classes of elementary SR-transformations l mutation transformations l ISA transformations l other elementary transformations 6. Typology of practical elementary transformations

66 66 Mutation transformations A mutation changes the gender of an object while preserving its information contents 3 genders  6 mutations Entity type Attribute Rel-type ET-to-RT RT-to-ET att-to-ET ET-to-att att-to-RT RT-to-att 6. Typology of practical elementary transformations

67 67 Mutation transformations (SR) Entity types and Rel-types (1)  6. Typology of practical elementary transformations

68 68 Mutation transformations (SR) Entity types and Attributes   6. Typology of practical elementary transformations

69 69 Mutation transformations (SR) Rel-types and Attributes  6. Typology of practical elementary transformations

70 70 ISA transformations (SR) Materialization Downward inheritance Upward inheritance 6. Typology of practical elementary transformations

71 71 Other elementary transformations Non-set attributes (SR)    6. Typology of practical elementary transformations

72 72 Other elementary transformations Multivalued attribute: instanciation and concatenation   ? ? Very common but not SR 6. Typology of practical elementary transformations

73 73 7. Typology of practical transformations Complex transformations

74 74 Goal: to examine some higher-level transformations or should I really apply these elementary operations to each of the 2,000 relationship types, 750 complex attributes and 682 is- a relations???

75 75 Elementary transformations are just building blocks for more complex operators challenge: Developing higher-level SR transformations with elementary SR-transformations 7. Typology of practical complex transformations

76 76 The main classes of complex SR-transformations l compound transformations l predicate-driven transformations l model-driven transformations 7. Typology of practical complex transformations

77 77 Compound transformations The composition of two transformations is a transformation The composition of two SR-transformations is an SR-transformation  1  =  2  =  12  =  2   1  = 7. Typology of practical complex transformations

78 78 Compound transformations  ACCOUNT AccID Available Exp-Monday[0-1] Exp-Tuesday[0-1] Exp-Wednesday[0-1] Exp-Thursday[0-1] Exp-Friday[0-1] id:AccID     new! known 7. Typology of practical complex transformations

79 79 Predicate-driven (conditional) transformations Transformations that apply to a set of qualified objects in the current schema  ( p ) where  is a transformation p is a structural predicate interpretation: apply  to all the objects that satisfy p ambiguous: if p(o1)  p(o2)  (apply  (o1)   p(o2) ) then should o2 be processed anyway? usual strategy (snapshot): first compute the set of objects that satisfy p, then apply  to each of its elements that survive. 7. Typology of practical complex transformations

80 80 Predicate-driven transformations We need a language for p  structural (e.g., DL, OCL): complex and leading to huge expressions  ad hoc for the GER: expressive, concise, parametric, but not generic, not closed ROLE_per_RT(I J): the number of roles of the current rel-type is between I and J ONE_ROLE_per_RT(I J): the number of "one" roles (with cardinality ?-1) is between I and J MAX_CARD_of_ATT(I J): the maximum cardinality of the current attribute is between I and J DEPTH_of_ATT(I J): the level of the current attribute is between I and J I  {0, 1, 2,.., J}; J  {I, I+1, …, N} 7. Typology of practical complex transformations

81 81 Predicate-driven transformations  (p) RT_into_ET(ROLE_per_RT(3 N)): transform all rel-types into an entity type (if they have at least 3 roles) RT_into_ATT(ROLE_per_RT(2 2) and ONE_ROLE_per_RT(1 2)): transform all rel-types into referential attributes (if they are binary and one-to-many or one-to-one) INSTANTIATE(MAX_CARD_of_ATT(2 4)): instanciate each attribute (if they are "slightly" multivalued: from 2 to 4values) ATT_into_ET_VAL(DEPTH_of_ATT(1 1) and MAX_CARD_of_ATT(5 N)): transform all attributes into an entity type (if they are at the top level and they are "strongly" multivalued: at least 5 values) 7. Typology of practical complex transformations

82 82 Model-driven transformation Goal: considering schema S1 in model M1, transform S1 into S2 that complies with model M2. Of course, as far as possible through SR-transformations! Example: considering the Entity-relationship schema S1, transform S1 into S2 that complies with the relational model. Of course, as far as possible without information loss! Structure: a compound transformation comprising predicate-driven trans- formations. Practical form: a transformation plan. 7. Typology of practical complex transformations

83 83 Model-driven transformation Principle: Identify the constructs of M1 that violate M2 For each such construct C, choose a transformation = such that P(C) T(C) satisfies M2 Things may be a bit more complex, requiring a compound transformation. Example: processing N-ary rel-types for relational compliance requires two successive transformations 7. Typology of practical complex transformations

84 84 Model-driven transformation Example: ER to Binary (flat Bachman) conversion The binary model is a variant of the ER model in which: l there is no ISA relations l the rel-types are functional (binary, one-to-many or one-to-one) l the rel-types have no attributes l each rel-type is defined on two distinct entity types (no cyclic rel-types) l the attributes are single-valued and atomic. 7. Typology of practical complex transformations

85 85 Model-driven transformation Flat Bachman schemas - invalid constructs: l ISA relations l cyclic rel-types l complex rel-types (with attributes, N-ary) l many-to-many binary rel-types l multivalued attributes l compound attributes. 7. Typology of practical complex transformations

86 86 Model-driven transformation Flat Bachman schemas - processing invalid constructs: l ISA relations: materialization l cyclic rel-types: transform into entity types l complex rel-types (with attributes, N-ary): transform into entity types l many-to-many binary rel-types: transform into entity types l multivalued attributes: transform into entity types l compound attributes: disagregate. 7. Typology of practical complex transformations

87 87 Model-driven transformation Transformation plan for ER to Flat Bachman conversion ISA_into_RT; transform ISA relations by materialization; RT_into_ET(RECURSIVITY_in_RT(2 N)); transform rel-types in which the same entity type appears more than once; RT_into_ET(ATT_per_RT(1 N) or ROLE_per_RT(3 N)); transform complex rel-types ; RT_into_ET(ONE_ROLE_per_RT(0 0)); transform rel-types in which there is no "one" role; LOOP; iteratively flatten the attribute structure ATT_into_ET_INST(MAX_CARD_of_ATT(2 N)) DISAGGREGATE ENDLOOP; 7. Typology of practical complex transformations

88 88 Model-driven transformation Example of ER to Flat Bachman conversion  7. Typology of practical complex transformations

89 89 Model-driven transformation Other popular examples  ER to UML  UML to ER  ER to relational  relational to ER  COBOL files to ER  ER to XML  relational to XML 7. Typology of practical complex transformations

90 90 8. Transformational modeling of database engineering processes

91 91 Goal: to show that large scope processes are transformational as well

92 92 Most database engineering processes are high-level transformations Example 1: database design DDL code = DB-design(Users Requirements) DB-design = Coding o PhysD o LogD o ConcD Conceptual design Logical design Physical design Coding Logical schema Physical schema Users requirements Conceptual schema DDL code 8. Modeling of DB engineering processes

93 93 Logical design Logical_schema = Logical_design(Conceptual_schema) Logical_design clearly is a model-driven transformation Let us develop its transformation plan Logical_design Logical_schema Conceptual_schema 8. Modeling of DB engineering processes

94 94 What are the invalid GER constructs in the relational model? l ISA relations l relationship types  complex  functional l multivalued attributes l compound attributes l names not compliant with the SQL syntax 8. Modeling of DB engineering processes

95 95 A transformation plan transform is-a relations transform complex rel-types transform level-1 multi- valued attributes disaggregate level-1 compound attributes still non simple attributes ? no yes transform functional rel-types any failure ? Add technical Id where needed yes no Process names 8. Modeling of DB engineering processes

96 96 Application  8. Modeling of DB engineering processes

97 97 Example 2: database reverse engineering Conceptual schema = DB-REng(code ddl, code prg ) DB-REng = Concept o Clean o Refine o Parse Cleaning Parsing Refinement Logical schema Physical schema Conceptual schema code ddl code prg Conceptualization Raw physical schema 8. Modeling of DB engineering processes

98 98 Example 2: database reverse engineering Interesting observations Refine o Parse = Coding -1 Cleaning = Physical_design -1 Conceptualization = Logical_design -1 Conclusion: DB reverse engineering is (grossly speaking) the inverse of DB engineering 8. Modeling of DB engineering processes

99 99 Hence the transformation plan of Conceptualization: transform is-a relations transform complex rel-types transform level-1 multi- valued attributes disaggregate level-1 compound attributes transform functional rel-types add technical Id where needed Remove technical Id Transform FK into functional rel-types Aggregate heterogeneous serial attributes transform attribute entity types into multi-valued attributes transform relationship entity types into rel-types transform one-to-one rel-types into is-a relations transform functional rel-types Transform FK into functional rel-types 8. Modeling of DB engineering processes

100 100 Experiment:  relational logical schema Convincing, but obviously needs some polishing! 8. Modeling of DB engineering processes

101 Conclusions and perspectives

102 102 l Intuitively, most database engineering processes are transformational by nature. l By combining elementary transformations, we can give these processes a precise transformational definition. l A transformation can be formalized so that its preservation properties can be proved. l We need a small set of elementary transformations ( ). l Once correctly defined, a transformation is quite reliable, and is guaranteed to preserve information whatever the context in which it is applied. l Transformation are (sort of …) easy to implement in CASE tools. l Several general-purpose languages and engines: QVT, AST, ATL, Kermeta, GReAT, VIATRA, Tefkat, TXL and... XSLT! 9. Conclusions and perspectives

103 103 However, some problems are not (completely) solved:  a transformation must address all the aspects of the data structures: documentation, annotations, statistics, operations (methods).  complex problem: propagating the constraints; OK for uniqueness, but others are less obvious.  how to efficiently transform the data, following schema transformation? See J.-M. Hick thesis (2003).  modifying a high-level abstract schema is easy, but how do we propagate the modifications to the lower-level schema and code (traceability)?  transforming the data structures is nice, but what about the programs? Notion of co-transformation. See A. Cleve’s thesis (2009)  how to derive a procedural transformation from the specification?  how to derive a transformation plan from couple (M1, M2)? 9. Conclusions and perspectives

104 104 Thanks

105 105 A. Schema transformations in CASE tools

106 106 CASE tools with DB design facilities offer explicit or implicit transformations for the production of the database code and for (limited) reverse engineering.  conceptual schema  DDL code  conceptual schema  relational schema  DDL code  DDL code  relational schema  conceptual schema Few CASE tools include transformations as a major engineering paradigm. Example DB-MAIN A. Schema transformations in CASE tools

107 107 The DB-MAIN CASE environment l Toolset of about 30 elementary transformations. Most are SR. The others trigger a warning. l Predicate-driven transformations (through two transformation assistants)  simplified (for the dummies)  advanced (for the smarties) l Model-driven transformations (through two transformation assistants)  scripting facilities for developing transformation plans  a dozen predefined, updatable, transformation plans A. Schema transformations in CASE tools

108 108 The DB-MAIN CASE environment Elementary transformations (Transforming attribute Phone into entity type PHONE) 1. select an object 2. select a transformation 3. if needed, select the variant 4. if needed, give target names A. Schema transformations in CASE tools

109 109 The DB-MAIN CASE environment Elementary transformations (Transforming bag attribute Keyword into a set attribute) A. Schema transformations in CASE tools

110 110 The DB-MAIN CASE environment Predicate-driven transformations: simplified assistant 1. choose a pattern 2. choose an action 3. execute A. Schema transformations in CASE tools

111 111 The DB-MAIN CASE environment Predicate-driven transformations: advanced assistant 1. select an operation 2. define the predicate 3. set its parameters A. Schema transformations in CASE tools

112 112 The DB-MAIN CASE environment Model-driven transformations: simplified assistant 1. build a couple (pattern,action) 2. write it 3. save script 4. execute script A. Schema transformations in CASE tools

113 113 The DB-MAIN CASE environment Model-driven transformations: advanced assistant A. Schema transformations in CASE tools

114 114 The DB-MAIN CASE environment Model-driven transformations: advanced assistant A. Schema transformations in CASE tools


Download ppt "PReCISE LIBD 1st International Workshop on Bidirectional Transformations - Bx 2012 Tallin, March 25, 2012 Bidirectional Transformations in Database Engineering."

Similar presentations


Ads by Google