Presentation is loading. Please wait.

Presentation is loading. Please wait.

PReCISE LIBD Dagstuhl Seminar January 17, 2011 - Bidirectional Transformations Transformations in Database Engineering Jean-Luc Hainaut, Anthony Cleve.

Similar presentations


Presentation on theme: "PReCISE LIBD Dagstuhl Seminar January 17, 2011 - Bidirectional Transformations Transformations in Database Engineering Jean-Luc Hainaut, Anthony Cleve."— Presentation transcript:

1 PReCISE LIBD Dagstuhl Seminar January 17, Bidirectional Transformations Transformations in Database Engineering Jean-Luc Hainaut, Anthony Cleve

2 2 Objectives of the tutorial  to presents some important aspects of transformations in DB  in an informal and intuitive way  with practical applications in mind  mainly (but not exclusively) for non-DB communities

3 3 1. The context of databases 2. The concept of transformation in the DB context 3. Elementary and complex transformations 4. Representation of schemas in DB Engineering 5. About property preservation 6. Applications of transformations 7. Challenges Contents

4 4 1. The context of databases

5 5 What is a Database? The structured collection of the data necessary to  keep the memory of an organization (structures, rules and facts)  to act as a reliable and efficient data server for an application system schema Client program Information/data structures are known (a.o., for processing) through schema(s) 1. The context of databases - Concepts, terms, issues

6 6 The schemas and models of a database Schemas in DBMS's ( ) physical schema logical schema view n view 2 view 1 Client program = instance of = mapping = uses interface conceptual schema 1. The context of databases - Concepts, terms, issues

7 7 The schemas and models of a database Standard DB design methodologies ( ) physical schema logical schema conceptual schema view n view 2 view 1 Conceptual design Logical design Physical design View design Users requirements 1. The context of databases - Concepts, terms, issues DDL code Coding

8 8 Un ouvrage est une oeuvre littéraire publiée. Il est caractérisé par son numéro identifiant, son titre, son éditeur, sa date de première parution, ses mots-clés (10 au maximum), une brève note de présentation (ces notes sont en cours de constitution), le nom et le prénom de ses auteurs. A un ouvrage correspondent un certain nombre d'exemplaires, qui en sont la matérialisation physique.... create database BIB create dbspace BIB_DATA; create table OUVRAGE ( NUMERO char(18) not null, TITRE varchar(60) not null, EDITEUR char(32) not null, DATE_1RE_PARUTION date not null, PRESENTATION varchar(255), primary key (NUMERO)) in BIB_DATA;... alter table EXEMPLAIRE add constraint FKDE foreign key (NUMERO)references OUVRAGE;... create unique index IDOUVRAGE on OUVRAGE (NUMERO);... Logical schema (relational) physical schema (Oracle 11) N de 1-N0-N écrit OUVRAGE Numéro Titre Editeur Date 1re parution Mot clé[0-10] Présentation[0-1] id:Numéro EXEMPLAIRE Num série Date acquisition Localisation Etage Rayon Travée Etat[0-1] id:de.OUVRAGE Num série AUTEUR Nom Prénom conceptual schema Database design transformations 1. The context of databases - Concepts, terms, issues

9 9 l in UML:  a meta-model is a formal system of abstract constructs that can be used to describe any situation pertaining to a modeling domain; the notation is an integral part of a meta-model;  a model is an artefact made up of instances of constructs of a meta-model, and that specifies the structures of a definite situation of an application domain l in the Database realm:  a model is a formal system of abstract constructs that can be used to describe any situation pertaining to a modeling domain; can be given several notations;  a schema is an artefact using the constructs of a model, and that specifies the structures of one definite situation of an application domain l Examples:the relational model the Entity-relationship model the relational schema of the DAGSTUHL-ORG database. The schemas and models of a database 1. The context of databases - Concepts, terms, issues

10 10 model meta-model meta- meta-model expressed into instance of instance of real world system fact classes a way to see the world philosophy describes modelled by comply with is a domain of Seen as an evolving bag of facts schemameta-schemameta-meta-schema instance of instance of instance of The schemas and models of a database 1. The context of databases - Concepts, terms, issues

11 11 The schemas and models of a database Abstraction levels and paradigms abstraction levels Paradigms (aka "data model") 1. The context of databases - Concepts, terms, issues conceptual logical/view physical code ER; EER; OO (UML; etc.); ORM; Bachman; RDF;... relational; OO (UML; etc.); object-relational; XML DTD; XML Schema; standard file; network; hierarchical;... Oracle 11g; Oracle 8; DB2 9.7; MySQL 5.5; IDS2; IMS;... Oracle 11g SQL-DDL; IDS2 DDL;...

12 12 1. The context of databases - Engineering processes l DB Analysis and Design across abstraction levels (from abstract to concrete) and modelling paradigms l DB Reverse Engineering across abstraction levels (from concrete to abstract) and modelling paradigms l DB Evolution same abstraction level - same modelling paradigm l DB Migration same abstraction level - change of modelling paradigm l others : refactoring, integration, view derivation, ETL,... several abstraction levels - several modelling paradigms Database engineering processes

13 13 1. The context of databases - Engineering processes Database engineering processes conceptual logical/view physical code EREEROOORM relationalOOObj-relatnetwork Oracle 8Oracle 11gDB2 9.7IDS2 Oracle 8 DDL Oracle 11g DDL DB2 9.7 DDL IDS2 DDL DB Analysis and Design

14 14 1. The context of databases - Engineering processes Database engineering processes conceptual logical/view physical code EREEROOORM relationalOOObj-relatnetwork Oracle 8Oracle 11gDB2 9.7IDS2 Oracle 8 DDL Oracle 11g DDL DB2 9.7 DDL IDS2 DDL DB Reverse Engineering

15 15 1. The context of databases - Engineering processes Database engineering processes conceptual logical/view physical code EREEROOORM relationalOOObj-relatnetwork Oracle 8Oracle 11gDB2 9.7IDS2 Oracle 8 DDL Oracle 11g DDL DB2 9.7 DDL IDS2 DDL DB Evolution Not recommended

16 16 1. The context of databases - Engineering processes Database engineering processes conceptual logical/view physical code EREEROOORM relationalOOObj-relatnetwork Oracle 8Oracle 11gDB2 9.7IDS2 Oracle 8 DDL Oracle 11g DDL DB2 9.7 DDL IDS2 DDL DB Migration Not recommended

17 17 2. The concept of transformation in the DB context

18 18 DB engineering process modelling 2. The concept of transformation in the DB context DDL code = DB-design(Users Requirements) DB-design = Coding o PhysD o LogD o ConcD Conceptual schema = ConcD(Users Requirements) Logical schema = LogD(Conceptual schema) Physical schema = PhysD(Logical schema) DDL code = Coding(Physical schema) ConcD = Analysis o Normalisation o Integration etc. Conceptual design Logical design Physical design Coding Logical schema Physical schema Users requirements Conceptual schema DDL code Most engineering processes are artefact transformations

19 19 2. The concept of transformation in the DB context An example (relational logical design)  DB engineering process modelling

20 20  An example (transforming multivalued attributes) 2. The concept of transformation in the DB context DB engineering process modelling

21 21  An example (transforming many-to-many relationship types) 2. The concept of transformation in the DB context DB engineering process modelling

22 22  2. The concept of transformation in the DB context An example (transforming one-to-many relationship types) DB engineering process modelling

23 23 2. The concept of transformation in the DB context The concept of transformation 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'

24 24 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' The concept of transformation 2. The concept of transformation in the DB context

25 25 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 The concept of transformation - Definition 2. The concept of transformation in the DB context

26 26 Mapping T can be specified with two predicates: P: minimal pre-condition Q: maximal post-condition  = = The concept of transformation - Definition 2. The concept of transformation in the DB context

27 27 Expressing structural predicates P and Q entity-type(E)there exists an entity type with name E entity-type(e)there exists an entity type denoted by e Value-based (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., FOL, DL) 2. The concept of transformation in the DB context Specifying a transformation

28 28 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 2. The concept of transformation in the DB context Expressing structural predicates P and Q Specifying a transformation

29 29 2. The concept of transformation in the DB context Expressing structural predicates P and Q Specifying a transformation entity-type(CUSTOMER)  attribute(CUSTOMER,Cust#,1,1,integer)  attribute(CUSTOMER,Name,1,1,string)  attribute(CUSTOMER,Phone,0,5,string)  id(CUSTOMER,{Cust#}) =

30 30 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# = =  2. The concept of transformation in the DB context Specifying a transformation

31 31 From now on: P Q 1-N0-5 has PHONE Phone id:Phone CUSTOMER Cust# Name id:Cust#  2. The concept of transformation in the DB context Specifying a transformation

32 32 2. The concept of transformation in the DB context Inverse transformations  2 =  1  iff  C: P 1 (C)  C = T 2 (T 1 (C)) Intuitively,  2 undoes the effect of  1 at the structural level 1-N0-5 has PHONE Phone id:Phone CUSTOMER Cust# Name id:Cust#   T1T1 T2T2 -1 mapping t ignored

33 33 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 l more complex patterns exist    2. The concept of transformation in the DB context Reversible transformations

34 34 2. The concept of transformation in the DB context Reversible transformations Transformation  1 is reversible if it preserves the information contents of the source schema mapping t involved reversible= semantics preserving

35 35 A transformation can be... l not reversible: not semantics-preserving l reversible: "one-way" semantics-preserving l symmetrically reversible: fully semantics-preserving 2. The concept of transformation in the DB context Reversible transformations

36 36 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 2. The concept of transformation in the DB context Reversible transformations

37 37 A transformation is reversible if there is an inverse mapping for instances as well  1 is reversible  iff   2 =  1 :  C: P(C)  C = T 2 (T 1 (C))   c  inst(C): c = t 2 (t 1 (c)) 2. The concept of transformation in the DB context Reversible transformations

38 38  is symmetrically reversible  iff both  and  are reversible  =   = SR-transformations are the most desirable operators in analysis, design, reverse engineering, migration, refactoring, and (partially) evolution processes 2. The concept of transformation in the DB context Symmetrically reversible transformations

39 39 3. Elementary and complex transformations

40 40 3. Elementary and complex transformations Elementary : cannot be decomposed into smaller SR-transformations Complex : can be decomposed into (more) elementary SR-transformations

41 41 Elementary transformations  0-N written DOCUMENT DocID Title Date-Published Keyword[0-10] id:DocID AUTHOR Name First-Name Origin N doc N by WRITTEN id:doc.DOCUMENT by.AUTHOR DOCUMENT DocID Title Date-Published Keyword[0-10] id:DocID AUTHOR Name First-Name Origin 1-N0-10 describe KEYWORD Keyword id:Keyword DOCUMENT DocID Title Date-Published id:DocID DOCUMENT DocID Title Date-Published Keyword[0-10] id:DocID  COPY ISBN Serial-No Date-Acquired id:ISBN Serial-No ref:ISBN BOOK ISBN Publisher id:ISBN 0-N 1-1 of COPY Serial-No Date-Acquired id:of.BOOK Serial-No BOOK ISBN Publisher id:ISBN  3. Elementary and complex transformations

42 42 Elementary transformations are building blocks for more complex operators challenge: Developing higher-level SR transformations with elementary SR-transformations Elementary and complex SR-transformations 3. Elementary and complex transformations

43 43 Three classes of complex SR-transformations l compound transformations l predicate-driven transformations l model-driven transformations 3. Elementary and complex transformations

44 44 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  = 3. Elementary and complex transformations

45 45 Compound transformations  new!     known 3. Elementary and complex transformations

46 46 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 Predicate-driven (conditional) transformations 3. Elementary and complex transformations

47 47 We need a language for p  structural (e.g., DL): complex and leading to huge expressions  ad hoc : 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(1 2): 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 Predicate-driven (conditional) transformations 3. Elementary and complex transformations

48 48  (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_REF(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 amm attributes (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) Predicate-driven (conditional) transformations 3. Elementary and complex transformations

49 49 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. Model-driven transformation 3. Elementary and complex transformations

50 50 Model-driven transformation Building principles: 1. Identify the constructs of M1 that violate M2 (called invalid) 2. For each invalid construct C, apply a transformation = such that P(C) and 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 3. Elementary and complex transformations

51 51 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 rel-types are functional (binary + one-to-many or one-to-one) l rel-types have no attributes l each rel-type is defined on two distinct entity types (no cyclic rel-types) l attributes are single-valued and atomic. 3. Elementary and complex transformations

52 52 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. 3. Elementary and complex transformations

53 53 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. 3. Elementary and complex transformations

54 54 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; 3. Elementary and complex transformations

55 55 Model-driven transformation Example of ER to Flat Bachman conversion  3. Elementary and complex transformations

56 56 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 3. Elementary and complex transformations

57 57 4. Representation of schemas in DB Engineering

58 58 Dealing with multiple models A typical organization uses several 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. 4. Representation of schemas in DB Engineering

59 59 Dealing with multiple models ETL data warehouse application program operational data environment design conceptual schema migrate XML extract & export XML import organization 4. Representation of schemas in DB Engineering

60 60 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 4. Representation of schemas in DB Engineering

61 61 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 4. Representation of schemas in DB Engineering

62 62 abstraction levels data models conceptual logical/view physical code ER; EER; OO (UML; etc.); ORM; Bachman; RDF;... relational; OO (UML; etc.); object-relational; XML DTD; XML Schema; standard file; network; hierarchical;... Oracle 11g; Oracle 8; DB2 9.7; MySQL 5.5; IDS2; IMS;... Oracle 11g SQL-DDL; IDS2 DDL;... The Generic Entity-relationship (GER) model as the pivot model GER 4. Representation of schemas in DB Engineering

63 63 Specifying operational model M in the GER Procedure l identifying the concepts of the GER that are pertinent in M l specifying the structural constraints that hold in valid M schemas l renaming the selected constructs according to the taxonomy of M. GER Model Relat. Model UML Class Model XML Model  rel>ger  uml>ger  er>ger  xml>ger ER Model 4. Representation of schemas in DB Engineering

64 64 Example: SQL2 is a specialization of the GER 4. Representation of schemas in DB Engineering Specifying operational model M in the GER

65 65 Specifying operational model M in the GER Notion of M-compliant schema This schema is SQL2-compliant: This schema is not SQL2-compliant: is-a hierarchyno attributesrel-typenon-elementary attribute table column foreign key primary key 4. Representation of schemas in DB Engineering

66 66 Specifying operational model M in the GER Important consequence Inter-model engineering transformations (ER to SQL2) are expressed as intra- model transformations (ER to GER to GER to SQL2) SQL2 schemaER schema Logical design 4. Representation of schemas in DB Engineering Logical design GER schema  ger>ger  ger>rel  er>ger SQL2 schemaER schema

67 67 5. About property preservation

68 68 A schema has some important properties or facets l the semantics of its components l components may be assigned statistics (e.g., there are CUSTOMER entities) l constraints : identifiers, functional dependencies, existence constraints, cardinality constraints, etc. l generic operations can by applied to their instances (insert, update, delete, etc.) l some components have annotations (free text) l they have 2D coordinates in the schema space l others About property preservation  Are these properties preserved in SR-transformations?  How to propagate them to the target schema?  How can we prove they are preserved?

69 69 5. About property preservation Semantics preservation By definition, an R- or SR-transformations preserve the semantics of the schema. How to prove it? By mapping the GER model on a simpler model which already includes the concept of R- and SR- transformation. Example: the N1NF relational model. N1NF Relat. Model  NF2 > NF2  NF2 >ger  ger> NF2 GER Model

70 70 5. About property preservation Semantics preservation A GER transformation  g is SR if there exists a (possibly complex) SR-transformation  r such that,  g =  NF2 >ger o  r o  ger>NF2 N1NF schema rr  erm>ger  ger>erm GER schema gg

71 71 5. About property preservation project-join unnest extension       ger>NF2  NF2 >ger  att-into-ET/v Semantics preservation att-into-ET/v =  NF2 >ger o extension o unnest o project-join o  ger>NF2

72 72 5. About property preservation Statistics preservation Static and dynamic data metrics are important, specially for physical design: l How many CUSTOMER entities? l How many distinct values of CITY attribute? l How many ORDER entities per CUSTOMER entity? l How many CUSTOMER entities with no ORDER entites? l How many new ORDER entities per day? l How many updates of ADDRESS attribute per day? Hard to collect; easier to get at the conceptual level  how to propagate them at the other levels (logical and physical)

73 73 5. About property preservation Statistics preservation The main static statistics:

74 74 5. About property preservation Statistics preservation  att-into-ET/i  

75 75 6. Applications of transformations

76 76 Improving enginering processes Automating enginering processes Traceability Developing new engineering processes Education Co-transformations 6. Applications of transformations + a lot of other applications (see BX-Grace report)

77 77 Fosters systematic and reproducible engineering techniques Better control and auditing of the design products Minimize (or at least identify) semantic losses Improving enginering processes 6. Applications of transformations

78 78 Fairly easy to automate but requires very careful analysis of predicates P and Q Automating enginering processes 6. Applications of transformations

79 79 Automating enginering processes 6. Applications of transformations The DB-MAIN CASE environment - Elementary transformations 1. select an object 2. select a transformation 3. if needed, select the variant 4. if needed, give target names

80 80 Automating enginering processes 6. Applications of transformations The DB-MAIN CASE environment - Model-driven transformations

81 81 Such mappings are used to identify: for each construct in source schema S1, the constructs in target schema S2 that derive from it, for each construct in target schema S2, the constructs in source schema S2 that it derive from. Examples: which conceptual object does DB2 column ORDER.CUST implement? how has relationship type "writes" ben implemented in the DB2 schema? Traceability 6. Applications of transformations The history of the transformations applied to produce schema S2 from schema S1 is the trace of the "S1  S2" engineering process. It can be used to derive direct and reverse mappings.

82 82 Three examples: Database reverse engineering: modelled as the inverse of forward engineering. Challenge: finding the bi-directional transformation between the physical and conceptual schemas. Design recovery: reconstruction of the process that could have been executed when a legacy database was designed. Can be recovered induction on the history of the reverse enginering process. HIistory of a process = trace of the transformations that have been carried out during the process. Schema quality evaluation and improvement: identifying bad patterns in a schema and replacing them by better but equivalent data structures. Equivalent = that can be derived from each other through reversible transformations. Bad, better: according to quality criteria, such as simplicity, expressivity, no redundancy, normalization, etc. Developing new engineering processes 6. Applications of transformations

83 83 Obvious! provided transformation techniques are presented in an intuitive and natural way! Education 6. Applications of transformations

84 84 An complex software system includes artefacts pertaining to several paradigms: Co-transformations 6. Applications of transformations database : static structures, (re)active components, data programs GUI forms and reports various secondary components (e.g., ETL, validation, loading, security management scripts) When the database schema is modified, some of the other components must be updated accordingly. Can this update be automated? Yes, provided schema modification has ben carried out through formal transformations. Application: evolution of large, data-centered, systems (see Anthony's position statement.

85 85 7. Conclusions and challenges

86 86 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 Transformations are (sort of …) easy to implement in CASE tools. l Several general-purpose languages and engines: QVT, ATL, Kermeta, GReAT, VIATRA, Tefkat, TXL and... XSLT! 7. Conclusions and challenges

87 87 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)? 6. Challenges

88 88 Selected references (from our contribution)

89 89 References Anthony Cleve, Tom Mens, Jean-Luc Hainaut. Data-Intensive System Evolution, IEEE Computer, pp , IEEE CS, 43(8), August Anthony Cleve, Program Analysis and Transformation for Data-Intensive System Evolution, PhD Thesis, University of Namur, 2009 Jean-Luc Hainaut, Anthony Cleve, Jean Henrard and Jean-Marc Hick. Migration of Legacy Information Systems, in Software Evolution. Mens, T. and Demeyer, S. (Eds), Springer, pp , 2008 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) Jean-Marc Hick and Jean-Luc Hainaut. Database application evolution: A transformational approach, Data and Knowledge Engineering, 59(3): pp , Anthony Cleve and Jean-Luc Hainaut. Co-transformations in Database Applications Evolution, in Generative and Transformational Techniques in Software Engineering, LNCS, Vol. 4143, pp , Springer-Verlag, Jean-Luc Hainaut. Transformation-based Database Engineering, in Transformation of Knowledge, Information and Data: Theory and Applications, pages 1-26, IDEA Group, Jean Henrard, Anthony Cleve and Jean-Luc Hainaut. Inverse Wrappers for Legacy Information Systems Migration, in Proceedings of 1st International Workshop on Wrapper Techniques for Legacy Systems, (WCRE’04/WRAP’04), Computer Science Report, Volume 04-34, pages 30-43, Technische Universiteit Eindhoven, 2004.

90 90 References Anthony Cleve, Jean Henrard and Jean-Luc Hainaut. Co-transformations in Information System Reengineering, in Proceedings of the 2nd International Workshop on Metamodels, Schemas, and Grammars for Reverse Engineering, (WCRE’04/ATEM-04), Electronic Notes in Theoretical Computer Science, Volume 137, pages 5-15, Elsevier, Jean-Luc Hainaut. Specification preservation in schema transformations - Application to semantics and statistics, Data and Knowledge Engineering, 16(1): Elsevier Science Publish., 1996 Jean-Luc Hainaut, Jean Henrard, Jean-Marc Hick, Didier Roland and Vincent Englebert. Database Design Recovery, in Proceedings of the 8th Conference on Advanced Information Systems Engineering, (CAiSE’96), Lecture Notes in Computer Science, Volume 1080, pages , Springer-Verlag, 1996 Jean-Luc Hainaut. Transformation-Based Database Engineering, in Tutorials of the 21th International Conference on Very Large Data Bases, (VLDB’95), Jean-Luc Hainaut, Catherine Tonneau, Michel Joris and Muriel Chandelon. Transformation-based Database Reverse Engineering, in Proceedings of 12th International Conference on Entity-Relationship Approach (ER’93), Lecture Notes in Computer Science, Volume 823, pages , Springer-Verlag, Jean-Luc Hainaut,Mario Cadelli,Bernard Decuyper and Olivier Marchand. TRAMIS:a transformation- based database CASE tool, in Proceedings of 5th International Conference on Software Engineering and Applications, EC2 Publish., 1992.

91 91 References Jean-Luc Hainaut. Entity-generating Schema Transformations for Entity-Relationship Models, in Proceedings of the 10th International Conference on the Entity-Relationship Approach (ER’91), pages , ER Institute, 1991 Jean-Luc Hainaut. Theoretical and Practical Tools for Data Base Design, in Proceedings of the 7th International Conference on Very Large Data Bases, (VLDB’81), pages , IEEE Computer Society, 1981 Most of these references are available on the site of the LIBD: Otherwise, ask

92 92 Thanks


Download ppt "PReCISE LIBD Dagstuhl Seminar January 17, 2011 - Bidirectional Transformations Transformations in Database Engineering Jean-Luc Hainaut, Anthony Cleve."

Similar presentations


Ads by Google