1. Model-independent Schema and Data Translation Paolo Atzeni Dipartimento di Informatica e Automazione Università Roma Tre 29/09/2010

2. Content Part 1: Background: –Data integration and transformationData integration and transformation Part 2: Core: –Model-independent Schema and Data Translation GII School 29/09/20102

3. References P. Atzeni, G. Gianforme, and P. Cappellari. A Universal Metamodel and Its Dictionary. Transactions on Large-Scale Data-and Knowledge-Centered Systems I, 2009A Universal Metamodel and Its Dictionary P. Atzeni, P. Cappellari, R. Torlone, P. A. Bernstein, and G. Gianforme. Model-independent schema translation. VLDB Journal, 2008Model-independent schema translation P. Atzeni, P. Cappellari, and P. A. Bernstein. Model independent schema and data translation. EDBT 2006.Model independent schema and data translation P. Atzeni, L. Bellomarini, F. Bugiotti and G. Gianforme. A runtime approach to model-independent schema and data translation. EDBT 2009A runtime approach to model-independent schema and data translation GII School 29/09/20103

4. 4 Schema and data translation Schema translation: –given schema S1 in model M1 and model M2 –find a schema S2 in M2 that “corresponds” to S1 Schema and data translation: –given also a database D1 for S1 –find also a database D2 for S2 that “contains the same data” as D1

5. GII School 29/09/20105 A wider perspective (Generic) Model Management: –A proposal by Bernstein et al (2000 +) –Includes a set of operators on schemas and mappings between schemas –The main operators Match Merge Diff ModelGen (=schema translation)

6. GII School 29/09/20106 A long standing issue Translations from a model to another have been studied since the 1970’s Whenever a new model is defined, techniques and tools to generate translations are studied However, proposals and solutions are usually model specific: –Given an ER schema, find the suitable relational schema that “implements” it the original paper (Chen 1976) contains the basics further discussions by many (e.g. Markowitz and Shoshani 1989) illustrated in every textbook –Similarly with any other conceptual model and any other logical one XML and relational (or object)

7. GII School 29/09/20107 A simple example An object relational database, to be translated in a relational one Source: the OR-model Target: the relational model System managed ids used as references

8. GII School 29/09/20108 Example, 2 How do we traslate? –Two possibilities. Does the OR model allow for keys? –If YES (EmpNo and Name are keys)

9. GII School 29/09/20109 Example, 3 How do we traslate? –Two possibilities. Does the OR model allow for keys? –If NOT

10. GII School 29/09/201010 Many different models (plus variants …) OR Relational OO … ER XSD

11. GII School 29/09/201011 Heterogeneity We need to handle artifacts and data in various models –Data are defined wrt to schemas –Schemas wrt to models –How can models be defined? We need metamodels Data Models Schemas = metaschemas = metadata

12. GII School 29/09/201012 A metamodel approach The constructs in the various models are rather similar: –can be classified into a few categories (Hull & King 1986): Abstract (entity, class, …) Lexical: set of printable values (domain) Aggregation: a construction based on (subsets of) cartesian products (relationship, table) Function (attribute, property) Hierarchies … We can fix a set of metaconstructs (each with variants): –abstract, lexical, aggregation, function,... –the set can be extended if needed, but this will not be frequent A model is defined in terms of the metaconstructs it uses

13. GII School 29/09/201013 The metamodel approach, example The ER model: –Abstract (called Entity) –Function from Abstract to Lexical (Attribute) –Aggregation of abstracts (Relationship) –…–… The OR model: –Abstract (Table with ID) –Function from Abstract to Lexical (value-based Attribute) –Function from Abstract to Abstract (reference Attribute) –Aggregation of lexicals (value-based Table) –Component of Aggregation of Lexicals (Column) –…–…

14. GII School 29/09/201014 The supermodel A model that includes all the meta-constructs (in their most general forms) –Each model is subsumed by the supermodel (modulo construct renaming) –Each schema for any model is also a schema for the supermodel (modulo construct renaming) In the example, a model that generalizes OR and relational Each translation from the supermodel SM to a target model M is also a translation from any other model to M: –given n models, we need n translations, not n 2

15. GII School 29/09/201015 Generic translations 1. Copy 2. Translation 3. Copy Supermodel Source model Target model Translation: composition 1,2 & 3

16. GII School 29/09/201016 Translations within the supermodel We still have too many models: –we have few constructs, but each has several independent features which give rise to variants for example, within simple OR model versions, –Key may be specifiable or not –Generalizations may be allowed or not –Foreign keys may be used or not –Nesting may be used or not –Combining all these, we get hundreds of models! –The management of a specific translation for each model would be hopeless

17. GII School 29/09/201017 The metamodel approach, translations As we saw, the constructs in the various models are similar: –can be classified according to the metaconstructs –translations can be defined on metaconstructs, there are standard, known ways to deal with translations of constructs (or variants theoreof) Elementary translation steps can be defined in this way –Each translation step handles a supermodel construct (or a feature thereof) "to be eliminated" or "transformed" Then, elementary translation steps to be combined A translation is the concatenation of elementary translation steps

18. GII School 29/09/201018 Many different models OR Relational OO … ER XSD

19. GII School 29/09/201019 Many different models (and variants …) OR w/ PK, gen, ref, FK Relational … OR w/ PK, gen, ref OR w/ PK, gen, FK OR w/ PK, ref, FK OR w/ gen, ref OR w/ PK, FK OR w/ PK, ref OR w/ ref

20. GII School 29/09/201020 A complex translation, example (0,N) Target: simple object model Eliminate N-ary relationships Eliminate attributes from relationships Eliminate many-to-many relationships Replace relationships with references Eliminate generalizations

21. GII School 29/09/201021 Complex translations Binary ER w/o gen N-ary ER w/ gen Binary ER w/ gen Relational Bin ER w/ gen w/o attr on rel OO w/ gen N-ary ER w/o gen Bin ER w/o gen w/o attr on rel Bin ER w/o gen w/o M:N rel Elim. N-ary relationships Elim. Relationship attr.s Elim. M:N relationships Replace relationships with references Elim OO generalizations Elim ER generalizations Bin ER w/ gen w/o M:N rel OO w/o gen …

22. GII School 29/09/201022 A more complex example An object relational database, to be translated in a relational one –Source: an OR-model –Target: the relational model

23. GII School 29/09/201023 A more complex example, 2 ENG EMP DEPT Last Name School Dept Name Address ID Dept_ID Emp_ID Target: relational model Eliminate generalizations Add keys Replace refs with FKs

24. A more complex example, 3 GII School 29/09/201024 EMP Last Name ID Dept_ID DEPT Name Address ID ENG School ID Emp_ID Target: relational model Eliminate generalizations Add keys Replace refs with FKs Replace objects with tables

25. GII School 29/09/201025 Many different models (and variants …) OR w/ PK, gen, ref, FK Relational OR w/ PK, gen, ref OR w/ PK, gen, FK OR w/ PK, ref, FK OR w/ gen, ref OR w/ PK, FK OR w/ PK, ref OR w/ ref Eliminate generalizations Add keys Replace refs with FKs Replace objects with tables Source Target

26. GII School 29/09/201026 Translations in MIDST (our tool) Basic translations are written in a variant of Datalog, with OID invention –We specify them at the schema level –The tool "translates them down" to the data level (both in off-line and run-time manners, see later) –Some completion or tuning may be needed

27. GII School 29/09/201027 A Multi-Level Dictionary Handles models, schemas and data Has both a model specific and a model independent component Relational implementation, so Datalog rules can be easily specified

28. GII School 29/09/201028 A common dictionary (for an ER design tool) Entity OIDSchemaName 3011Employees 3021Departments 2013Clerks 2023Offices AttributeOfEntity OIDSchemaNameisIdentisNullableTypeEntity 4011EmpNoTFInt301 4021NameFFText301 4041NameTFChar302 4051AddressFFText302 5013CodeTFInt201 ………………… Relationship OIDSchemaNameEntity1Entity2 4011Memb301302…… ………………… EmployeesDepartments Memb Name Address Name EmpNo

29. GII School 29/09/201029 Multi-Level Dictionary model schema model generic model specific description model independence Supermodel description (mSM) Model descriptions (mM) Supermodel schemas (SM) Model specific schemas (M) Supermodel instances (i-SM) Model specific instances (i-M) data

30. GII School 29/09/201030 The supermodel description MSM-Construct OIDNameIsLex 1AggregationOfLexicalsF 2ComponentOfAggrOfLexT 3AbstractF 4AttributeOfAbstractT 5BinaryAggregationOfAbstractsF MSM-Property OIDNameConstr.Type 11Name1String 12Name2String 13IsKey2Boolean 14IsNullable2Boolean 15Type2String 16Name3String 17Name4String 18IsIdentifier4Boolean 19IsNullable4Boolean 20Type4String 21IsFunct15Boolean 22IsOptional15Boolean 23Role15String 24IsFunct25Boolean 25IsOptional25Boolean 26Role25String MSM-Reference OIDNameConstructTarget 30Aggregation21 31Abstract43 32Abstract153 33Abstract253 mSMmM SMM i-SMi-M

31. GII School 29/09/201031 Model descriptions MSM-Construct OIDNameIsLex 1AggregationOfLexicalsF 2ComponentOfAggrOfLexT 3AbstractF 4AttributeOfAbstractT 5BinaryAggregationOfAbstractsF MM-Construct OIDModelMSM-ConstrName 123ER_Entity 224ER_Attribute 325ER_Relationship 411Rel_Table 512Rel_Column 633OO_Class MM-Model OIDName 1Relational 2Entity-Relationship 3Object MSM-Property OIDNameConstructType ………… MSM-Reference OIDNameConstruct… ………… MM-Property ………… MM-Reference ………… mSMmM SMM i-SMi-M

32. GII School 29/09/201032 Schemas in a model ER-Entity OIDSchemaName 3011Employees 3021Departments 2013Clerks 2023Offices ER-AttributeOfEntity OIDSchemaNameisIdentisNullableTypeAbstrOID 4011EmpNoTFInt301 4021NameFFText301 4041NameTFChar302 4051AddressFFText302 5013CodeTFInt201 ………………… SM-Construct OIDNameIsLex ……… 3ER-EntityF 4ER-AttributeOfEntityT ……… ER schemas mSMmM SMM i-SMi-M Employees Departments EmpNo Name Address

33. GII School 29/09/201033 Schemas in the supermodel SM-Abstract OIDSchemaName 3011Employees 3021Departments 2013Clerks 2023Offices SM-AttributeOfAbstract OIDSchemaNameisIdentisNullableTypeAbstrOID 4011EmpNoTFInt301 4021NameFFText301 4041NameTFChar302 4051AddressFFText302 5013CodeTFInt201 ………………… MSM-Construct OIDNameIsLex ……… 3AbstractF 4AttributeOfAbstractT ……… Supermodel schemas mSMmM SMM i-SMi-M Employees Departments EmpNo Name Address

34. GII School 29/09/201034 i-SM-Abstract OIDAbsOIDInstOID 30103011 30113011 ……… 30103012 i-SM-AttributeOfAbstract OIDAttrOfAbsOIDInstOIDValuei- AbsOID 40104011754323010 40204021John Doe3010 … 40214021Bob White3011 …………… Instances in the supermodel SM-Abstract OIDSchemaName 3011Employees 3021Departments 2013Clerks 2023Offices SM-AttributeOfAbstract OIDSchemaNameisIdentisNullableTypeAbstrOID 4011EmpNoTFInt301 4021NameFFText301 4041NameTFChar302 4051AddressFFText302 5013CodeTFInt201 ………………… Supermodel schemas Supermodel instances mSMmM SMM i-SMi-M

35. GII School 29/09/201035 Multi-Level Repository, generation and use model schema model generic model specific description model independence Supermodel description (mSM) Model descriptions (mM) Supermodel schemas (SM) Model specific schemas (M) Supermodel instances (i-SM) Model specific instances (i-M) data Structure fixed, content provided by tool designers Structure generated by the tool from the content of mSM Structure fixed, content provided by model designers out of mSM Structure generated by the tool from the content of mM

36. GII School 29/09/201036 Translations Basic translations are written in a variant of Datalog, with OID invention –We specify them at the schema level –The tool "translates them down" to the data level –Some completion or tuning may be needed

37. GII School 29/09/201037 A basic translation From (a simple) binary ER model to the relational model –a table for each entity –a column (in the table for E) for each attribute of an entity E –for each M:N relationship a table for the relationship columns … –for each 1:N and 1:1 relationship: a column for each attribute of the identifier …

38. GII School 29/09/201038 A basic translation application Departments NameAddress Employees EmpNo Name Affiliation Departments 1,1 0,N Name Address Employees EmpNoNameAffiliation

39. GII School 29/09/201039 A basic translation (in supermodel terms) From (a simple) binary ER model to the relational model –an aggregation of lexicals for each abstract –a component of the aggregation for each attribute of abstract –for each M:N aggregation of abstracts … … From (a simple) binary ER model to the relational model –a table for each entity –a column (in the table for E) for each attribute of an entity E –for each M:N relationship a table for the relationship columns … –for each 1:N and 1:1 relationship: a column for each attribute of the identifier …

40. GII School 29/09/201040 "An aggregation of lexicals for each abstract" SM_AggregationOfLexicals( OID: #aggregationOID_1(OID), Name: name)  SM_Abstract ( OID: OID, Name: name ) ;

41. GII School 29/09/201041 Datalog with OID invention Datalog (informally): –a logic programming language with no function symbols and predicates that correspond to relations in a database –we use a non-positional notation Datalog with OID invention: –an extension of Datalog that uses Skolem functions to generate new identifiers when needed Skolem functions: –injective functions that generate "new" values (value that do not appear anywhere else; so different Skolem functions have disjoint ranges

42. GII School 29/09/201042 "An aggregation of lexicals for each abstract" SM_AggregationOfLexicals( OID: #aggregationOID_1(OID), Name: n)  SM_Abstract ( OID: OID, Name: n ) ; the value for the attribute Name is copied (by using variable n) the value for OID is "invented": a new value for the function #aggregationOID_1(OID) for each different value of OID, so a different value for each value of SM_Abstract.OID

43. GII School 29/09/201043 "An aggregation of lexicals for each abstract" SM-Abstract OIDSchemaName 3011Employees 3021Departments ……… SM-AttributeOfAbstract OIDSchemaNameisIdentisNullableTypeAbstrOID 4011EmpNoTFInt301 4021NameFFText301 ………………… Employees EmpNo Name 11 Departments1002 Employees1001 SM_AggregationOfLexicals( OID: #aggregationOID_1(OID), Name: n)  SM_Abstract ( OID: OID, Name: n ) ; … 3021002 …… 1001 SM-AggregationOfLexicals SchemaNameOID SM-aggregationOID_1_SK absOIDOID 301 Employees

44. GII School 29/09/201044 "A component of the aggregation for each attribute of abstract" SM_ComponentOfAggregation… ( OID: #componentOID_1(attOID), Name: name, AggrOID: #aggregationOID_1(absOID), IsNullable: isNullable, IsKey: isIdent, Type : type ) ← SM_AttributeOfAbstract( OID: attOID, Name: name, AbstractOID: absOID, IsIdent: isIdent, IsNullable: isNullable, Type : type ) ; Skolem functions –are functions –are injective –have disjoint ranges the first function "generates" a new value the second "reuses" the value generated by the first rule

45. GII School 29/09/201045 A component of the aggregation for each attribute of abstract" SM-Abstract OIDSchemaName 3011Employees 3021Departments ……… Employees EmpNo Name 11 Departments1002 Employees1001 … 3021002 …… 1001 SM-AggregationOfLexicals SchemaNameOID SM-aggregationOID_1_SK absOIDOID 301 SM_ComponentOfAggregation… ( OID: #componentOID_1(attOID), Name: name, AggrOID: #aggregationOID_1(absOID), IsNullable: isNullable, IsKey: isIdent, Type : type ) ← SM_AttributeOfAbstract( OID: attOID, Name: name, AbstractOID: absOID, IsIdent: isIdent, IsNullable: isNullable, Type : type ) ; SM-componentOID_1_SK absOIDOID Employees EmpNoName SM-AttributeOfAbstract OIDSchemaNameisIdentisNullableTypeAbstrOID 4011EmpNoTFInt301 4021NameFFText301 ………………… SM-ComponentOfAggregationOfLexicals SchemaTypeAggrOIDisNullableisIdentNameOID Text1001FFName111004 1001IntFTEmpNo11 1003 401 1004402 1003

46. Many rules, how to choose? Models can be described in a compact way –the involved constructs and their properties (boolean propositions) Datalog rules can be "summarized" by means of "signatures" that describe the involved constructs and how they are transformed (in terms of boolean properties) GII School 29/09/201046

47. GII School 29/09/201047 Model Signatures M Rel = {T(true), C(true)} relational M RelNoN = {T(true), C(¬N)} relational with no nulls M ER = {E(true), A(true), R(true), A-R(true)} ER M ERsimple = {E(true), A(¬N), R(true)} M ERnoM2N = {E(true), A(true), R(F 1  F 2 ), A-R(true)} T table C column; ¬N: no null values allowed E entity R relationship ; F 1  F 2 : no many-to-many A attribute A-R attribute of relationship

48. GII School 29/09/2010 48 Rule signature –Body - B List of signatures of body constructs Applicability of the rule –Head - H Signature of the atom in the head Sure conditions of the result of the application of the rule –MAP Mapping between properties of body constructs and properties of the head construct Transfer of values from the body to the head of the rule

49. GII School 29/09/2010 49 Rule signature Example Relationship (OID:#relationship_1(eOid,rOid), Name: eN+rN, isOpt1: false, isFunct1: true, isIdent: true, isOpt2: isOpt, isFunct2: false, Entity1: #entity_1(rOid), Entity2: #entity_0(eOid))  Relationship (OID:,rOid, Name: rN, isOpt1: isOpt, isFunct1: false, isFunct2: false, Entity1: eOid), Entity (OID: eOid, Name:eN)

50. GII School 29/09/2010 50 Rule signature –Body Relationship (OID:#relationship_1(eOid,rOid), Name: eN+rN, isOpt1: false, isFunct1: true, isIdent: true, isOpt2: isOpt, isFunct2: false, Entity1: #entity_1(rOid), Entity2: #entity_0(eOid))  Relationship (OID:,rOid, Name: rN, isOpt1: isOpt, isFunct1: false, isFunct2: false, Entity1: eOid), Entity (OID: eOid, Name:eN)

51. GII School 29/09/2010 51 Rule signature –Head Relationship (OID:#relationship_1(eOid,rOid), Name: eN+rN, isOpt1: false, isFunct1: true, isIdent: true, isOpt2: isOpt, isFunct2: false, Entity1: #entity_1(rOid), Entity2: #entity_0(eOid))  Relationship (OID:,rOid, Name: rN, isOpt1: isOpt, isFunct1: false, isFunct2: false, Entity1: eOid), Entity (OID: eOid, Name:eN)

52. GII School 29/09/2010 52 Rule signature –MAP Relationship (OID:#relationship_1(eOid,rOid), Name: eN+rN, isOpt1: false, isFunct1: true, isIdent: true, isOpt2: isOpt, isFunct2: false, Entity1: #entity_1(rOid), Entity2: #entity_0(eOid))  Relationship (OID:,rOid, Name: rN, isOpt1: isOpt, isFunct1: false, isFunct2: false, Entity1: eOid), Entity (OID: eOid, Name:eN)

53. Reasoning Formal System –Compact representation of models and rules Based on logical formulas –Reasoning on data models Union, intersection, difference of models and schemas Applicability and application of rules and programs –Sound and complete with respect to the Datalog programs let us see 53GII School 29/09/2010

54. 54 Reasoning on translations M 1 = SIG( M 1 ) description of model M 1 r P = SIG( P ) signature of Datalog program P M 2 = r P (M 1 ) application of the sig of P to the desc of M 1 S1  M1S1  M1 P S 2 = P (S 1 ) M 2 = r P (M 1 ) M 1 = SIG( M 1 ) r P = SIG( P ) Theorem Program P applied to schemas of M 1 generates schemas (and somehow all of them) that belong to a model M 2 whose description is M 2 = r P (M 1 ) schema model program S 2  M 2 M 2 = SIG( M 2 )

55. Reasoning Main application –We automatically find a sequence of basic translations to perform the transformation of a schema from a model to another, under suitable assumptions Observations –Few “families” of models ER, OO, Relational… Each family has a progenitor –Two kinds of Datalog programs Reduction Transformation 55GII School 29/09/2010

56. Reasoning Automatic Translation –3-step transformation Reduction within the source family Transformation from the source family to the target family Reduction within the target family M∗1M∗1 M∗2M∗2 M1M1 M'1M'1 M'2M'2 M2M2 T F1F1 F2F2 56GII School 29/09/2010

57. 57 Correctness Usually modelled in terms of information capacity equivalence/dominance (Hull 1986, Miller 1993, 1994) Mainly negative results in practical settings that are non-trivial Probably hopeless to have correctness in general We follow an "axiomatic" approach: –We have to verify the correctness of the basic translations, and then infer that of complex ones

58. The data level So far, we have considered only schemas How do we translate data? Should we move data or translate it on the fly? GII School 29/09/201058

59. GII School 29/09/201059 Translations: off-line approach The dictionary has a third level, for data Basic translations are "translates them down" to the data level Some completion or tuning may be needed

60. GII School 29/09/201060 Multi-Level Dictionary model schema model generic model specific description model independence Supermodel description (mSM) Model descriptions (mM) Supermodel schemas (SM) Model specific schemas (M) Supermodel instances (i-SM) Model specific instances (i-M) data

61. GII School 29/09/201061 i-SM-Abstract OIDAbsOIDInstOID 30103011 30113011 ……… 30103012 i-SM-AttributeOfAbstract OIDAttrOfAbsOIDInstOIDValuei- AbsOID 40104011754323010 40204021John Doe3010 … 40214021Bob White3011 …………… Instances in the supermodel SM-Abstract OIDSchemaName 3011Employees 3021Departments 2013Clerks 2023Offices SM-AttributeOfAbstract OIDSchemaNameisIdentisNullableTypeAbstrOID 4011EmpNoTFInt301 4021NameFFText301 4041NameTFChar302 4051AddressFFText302 5013CodeTFInt201 ………………… Supermodel schemas Supermodel instances mSMmM SMM i-SMi-M

62. GII School 29/09/201062 Generating data-level translations Schema translation Data translation Same environment Same language High level translation specification Supermodel description (mSM) Supermodel schemas (SM) Supermodel instances (i-SM)

63. GII School 29/09/201063 Translation rules, data level i-SM_ ComponentOfAggregation… ( OID: #i-componentOID_1 (i-attOID), i-AggrOID: #i-aggregationOID_1(i-absOID), ComponentOfAggregationOfLexicalsOID: #componentOID_1(attOID), Value: Value ) ← i-SM_AttributeOfAbstract( OID: i-attOID, i-AbstractOID: i-absOID, AttributeOfAbstractOID: attOID, Value: Value ), SM_AttributeOfAbstract( OID: attOID, AbstractOID: absOID, Name: attName, IsNullable: isNull, IsID: isIdent, Type: type ) SM_ComponentOfAggregation… ( OID: #componentOID_1(attOID), Name: name, AggrOID: #aggregationOID_1(absOID), IsNullable: isNullable, IsKey: isIdent, Type : type ) ← SM_AttributeOfAbstract( OID: attOID, Name: name, AbstractOID: absOID, IsIdent: isIdent, IsNullable: isNullable, Type: type ) ;

64. GII School 29/09/201064 i-SM-Abstract OIDAbsOIDInstOID 30103011 30113011 30123021 ……… i-SM-AttributeOfAbstract OIDAttrOfAbsOIDInstOIDValuei- AbsOID 40104011754323010 40204021John Doe3010 40214021Bob White3011 40224041CS3012 …………… Instances in our dictionary SM-Abstract OIDSchemaName 3011Employees 3021Departments SM-AttributeOfAbstract OIDSchemaNameisIdentisNullableTypeAbstrOID 4011EmpNoTFInt301 4021NameFFText301 4041NameTFChar302 ………………… mSMmM SMM i-SMi-M 75432 John Doe Bob White … CS

65. GII School 29/09/201065 Translation of instances 75432 John Doe Bob White … CS Employees EmpNoNameAffiliation 75432John DoeCS Bob White Departments Name CS Departments NameAddress Employees EmpNo Name Affiliation Departments 1,1 0,N Name Address Employees EmpNoNameAffiliation

66. GII School 29/09/201066 i-SM-Abstract OIDAbsOIDInstOID 30103011 30113011 30123021 ……… i-SM-AttributeOfAbstract OIDAttrOfAbsOIDInstOIDValuei- AbsOID 40104011754323010 40204021John Doe3010 40224041CS3012 …………… Instances in our dictionary 75432 John Doe Bob White … CS Employees EmpNoNameAffiliation 75432John DoeCS Departments Name CS i-SM-AggregationOfLexicals 1002 1001 AggOID 115011 115010 InstOIDOID 5010CS1110054030 5010754321110034010 5010John Doe1110044020 i-SM-ComponentOfAggregationOfLexicals i- AggOIDValueInstOIDCompOfAggOIDOID

67. GII School 29/09/201067 i-SM-Abstract OIDAbsOIDInstOID 30103011 30113011 30123021 ……… i-SM-AttributeOfAbstract OIDAttrOfAbsOIDInstOIDValuei- AbsOID 40104011754323010 40204021John Doe3010 40224041CS3012 …………… Instances in our dictionary i-SM-AggregationOfLexicals 1002 1001 AggrOID 115011 115010 InstOIDOID 5010754321110036010 5010John Doe1110046020 5010CS1110056030 i-SM-ComponentOfAggregationOfLexicals i- AggrOIDValueInstOIDCompOfAggOIDOID i-SM_ComponentOfAggregation… (OID: #i-componentOID_1 (i-attOID), i-AggrOID: #i-aggregationOID_1(i-absOID), ComponentOfAggregationOfLexicalsOID: #componentOID_1(attOID),Value: Val ) ← i-SM_AttributeOfAbstract( OID: i-attOID, i-AbstractOID: i-absOID, AttributeOfAbstractOID: attOID, Value: Val ), SM_AttributeOfAbstract( OID: attOID, AbstractOID: absOID)

68. GII School 29/09/201068 Translation rules, data level i-SM_ Lexical ( OID: #i-lexicalOID_1 (i-attOID), i-AggrOID: #i-aggregationOID_1(i-absOID), LexicalOID: #lexicalOID_1(attOID), Value: Value ) ← i-SM_AttributeOfAbstract( OID: i-attOID, i-AbstractOID: i-absOID, AttributeOfAbstractOID: attOID, Value: Value ), SM_AttributeOfAbstract( OID: attOID, AbstractOID: absOID, Name: attName, IsNullable: isNull, IsID: isIdent, Type: type ) SM_Lexical( OID: #lexicalOID_1(attOID), Name: name, AggrOID: #aggregationOID_1(absOID), IsNullable: isNullable, IsKey: isIdent, Type : type ) ← SM_AttributeOfAbstract( OID: attOID, Name: name, AbstractOID: absOID, IsIdent: isIdent, IsNullable: isNullable, Type: type ) ;

69. Off-line approach GII School 29/09/201069 Operational Systems MIDST DB Translator Importer Exporter Supermodel DB

70. GII School 29/09/201070 Experiments A significant set of models –ER (in many variants and extensions) –Relational –OR –XSD –UML

71. GII School 29/09/201071 XSD OR noTab ref, FK, nested Relational OO ref, nested OR Tab, ref, FK, nested OO ref, flat OR noTab, FK, nested OR noTab, FK, flat OR Tab, gen ref, FK, nested OR noTab, gen ref, FK, nested OR noTab, gen, FK, nested 37+ Remove generalizations 36 Unnest sets (with ref) 03 Unnest sets (with FKs) 24 Unnest structures (flatten) 06 Unnest structures (TT & FKs) 01 Unnest structures (TT & ref) 43 FKs for references 29 Tables for typed tables 30 Typed tables for tables 13 References for FK 31 Nest referenced classes

72. The off-line approach: drawbacks It is highly inefficient, because it requires databases to be moved back and forth It does not allow data to be used directly A "run-time" approach is needed 72GII School 29/09/2010

73. A run-time alternative: generating views Main feature: –generate, from the datalog traslation programs, executable statements defining views representing the target schema. How: –by means an analysis of the datalog schema rules under a new classification of constructs 73GII School 29/09/2010

74. Runtime translation procedure Views DB Supermodel Schema Importer View Generator Translator MIDSTOperational System Access via target schema S t Access via source schema S s 74GII School 29/09/2010

75. Run-time vs off-line GII School 29/09/201075 Operational Systems MIDST DB Translator Importer Exporter Supermodel DB Views DB Supermodel Schema Importer View Generator Translator MIDSTOperational System Access via target schema Access via source schema

76. GII School 29/09/201076 Issues Reasoning on translations ModelGen in the model management scenario: –Round-trip engineering (and more) Customization of translations Off-line translation vs run-time “Correctness” of data translation wrt schema translation: –compare with data exchange Schematic heterogeneity and semantic Web framework: –What if the distinction between schemas and instances is blurred? Materialized Skolem function & provenance