[ABDO] Data Integration

642 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
642
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

[ABDO] Data Integration

  1. 1. Data Integration <ul><li>Techniques and Languages </li></ul><ul><li>Validation of Mappings </li></ul>
  2. 2. Data Integration: Problem Statement <ul><li>Data integration is the problem of providing unified and transparent access to a collection of data stored in multiple, autonomous, and heterogeneous data sources </li></ul>
  3. 3. Integration Architectures <ul><li>Distributed databases </li></ul><ul><ul><li>Data sources are homogeneous databases under the control of the distributed database management system. </li></ul></ul><ul><li>Multidatabase or federated databases </li></ul><ul><ul><li>Data sources are autonomous, heterogeneous databases. </li></ul></ul><ul><li>(Mediator-based) data integration </li></ul><ul><ul><li>Access through a global schema mapped to autonomous and heterogeneous data sources. Two approaches: </li></ul></ul><ul><ul><ul><li>Virtual Mediator </li></ul></ul></ul><ul><ul><ul><li>Data Warehouse </li></ul></ul></ul><ul><li>Peer-to-peer data integration </li></ul><ul><ul><li>Network of autonomous systems mapped one to each other, without a global schema. </li></ul></ul>
  4. 4. Data Warehouse Architecture Data source Data source Data source (Relational?) database (warehouse) User queries OLAP / Decision support/ Data mining Extract, Transform, Load (ETL)
  5. 5. (Virtual) Mediator Architecture Data source wrapper Data source wrapper Data source wrapper Sources can be: relational, hierarchical (IMS), structured files, web sites. Mediator: User queries Mediated schema Data source catalog Reformulator Optimizer Execution engine
  6. 6. Warehousing Vs. Virtual <ul><li>Advantages of warehousing: </li></ul><ul><ul><li>Typically more efficient </li></ul></ul><ul><ul><li>No need to touch sources at query time </li></ul></ul><ul><ul><li>Query processing is “traditional” </li></ul></ul><ul><li>Advantages of Virtual: </li></ul><ul><ul><li>Up-to-date data </li></ul></ul><ul><ul><li>Easier to set up (can do it incrementally) </li></ul></ul><ul><ul><li>Applicable in broader contexts </li></ul></ul>
  7. 7. P2P Data Integration Architecture Q Q1 Q3 Q2
  8. 8. Main problems in data integration <ul><li>How to construct the global schema. </li></ul><ul><li>How to discover mappings between sources and global schema. </li></ul><ul><li>Data extraction, cleaning, and reconciliation. </li></ul><ul><li>How to process updates expressed on the global schema and/or the sources </li></ul><ul><li>How to model the global schema, the sources, and the mappings between the two. </li></ul><ul><li>How to answer queries expressed on the global schema. </li></ul><ul><li>How to optimize query answering. </li></ul>
  9. 9. The Data Integration Modeling Problem <ul><li>How to model the global schema: </li></ul><ul><ul><li>data model </li></ul></ul><ul><ul><li>constraints </li></ul></ul><ul><li>How to model the sources: </li></ul><ul><ul><li>data model (conceptual and logical level) </li></ul></ul><ul><ul><li>access limitations </li></ul></ul><ul><ul><li>data values (common vs. different domains) </li></ul></ul><ul><li>How to model the mapping between global schemas and sources. </li></ul><ul><li>How to verify the quality of the modeling process. </li></ul>
  10. 10. The Query Reformulation Problem <ul><li>Given: </li></ul><ul><ul><li>A query Q posed over the mediated schema </li></ul></ul><ul><ul><li>Descriptions of the data sources </li></ul></ul><ul><li>Find: </li></ul><ul><ul><li>A query Q’ over the data source relations, such that: </li></ul></ul><ul><ul><ul><li>Q’ provides only correct answers to Q, and </li></ul></ul></ul><ul><ul><ul><li>Q’ provides all possible answers from to Q given the sources. </li></ul></ul></ul><ul><li>This process heavily depends on the approach adopted for modeling the data integration system. </li></ul>
  11. 11. Languages for Schema Mapping Modeling Mediated Schema Source Source Source Source Source GAV Q Q’ Q’ Q’ Q’ Q’ LAV GLAV
  12. 12. Global-as-View (GAV) <ul><li>Mediated schema defined as a set of views over the data sources </li></ul>S1 Movie (MID, title ) MovieDetails (MID, director , genre , year ) S2 MovieGenres ( title , genre ) S3 MovieDirectors ( title , dir ) S4 MovieYears ( title , year ) Movie(title,director,year,genre)  S2.MovieGenres(title,genre), S3.MovieDirectors(title,director), S4.MovieYears(title,year) Movie(title,director,year,genre)  S1.Movie(MID,title), S1.MovieDetais(MID,director, genre,year) Movie: title, director, year, genre
  13. 13. GAV: Formalization A set of expressions of the form: or <ul><li>G i : relation in mediated schema </li></ul><ul><li>: query over source relations </li></ul>closed-world assumption open-world assumption
  14. 14. Local-as-View (LAV) <ul><li>Data sources defined as views over mediated schema </li></ul>S5 MovieGenres ( title , genre ) S6 ActorDirectors ( actor , director ) S5.MovieGenres(title, genre)  Movie(title, director, year, genre) S6.ActorDirectors(actor, director)  Movie(title, director, year, genre), Actors(title, actor), year ≥ 1980 Movie: title, director, year, genre Actors: title, name
  15. 15. LAV: Formalization A set of expressions of the form: or <ul><li>S i : source relation </li></ul><ul><li>: query over mediated schema </li></ul>closed-world assumption open-world assumption
  16. 16. GAV vs LAV <ul><li>Not modular </li></ul><ul><ul><li>Addition of new sources changes the schema mapping </li></ul></ul><ul><li>Can be awkward to write mediated schema without loss of information </li></ul><ul><li>Query reformulation easy </li></ul><ul><ul><li>Often reduces to view unfolding (polynomial) </li></ul></ul><ul><ul><li>Can build hierarchies of mediated schemas </li></ul></ul><ul><li>Best when </li></ul><ul><ul><li>Few, stable, data sources </li></ul></ul><ul><ul><li>well-known to the mediator (e.g. corporate integration) </li></ul></ul><ul><li>Modular--adding new sources is easy </li></ul><ul><li>Very flexible--power of the entire query language available to describe sources </li></ul><ul><li>Reformulation is hard </li></ul><ul><ul><li>Involves answering queries only using views (can be intractable) </li></ul></ul><ul><li>Best when </li></ul><ul><ul><li>Many, relatively unknown data sources </li></ul></ul><ul><ul><li>possibility of addition/deletion of sources </li></ul></ul>
  17. 17. Query Reformulation in GAV: Example <ul><li>Source Schemas: </li></ul><ul><ul><li>S1: {Movie(MID,title), MovieDetails(MID, director, genre, year)} </li></ul></ul><ul><ul><li>S2: {Cinemas(location, movie, startTime)} </li></ul></ul><ul><li>Mediated Schema: </li></ul><ul><ul><li>Movie(title, director, genre, year)  S1.Movie(MID,title), S1.MovieDetails(MID, director, genre, year) </li></ul></ul><ul><ul><li>Plays(movie, location, startTime)  S2.Cinemas(location, movie, startTime) </li></ul></ul><ul><li>Query over mediated Schema: </li></ul><ul><ul><li>Q(title, location, startTime)  Movie(title, x, ‘comedy’, y), Plays(title, location, startTime), starTime > 20h </li></ul></ul>F 1 F 2
  18. 18. Query Reformulation in GAV: Example (cont.) Q(t, l, s)  Movie(t, x, ‘comedy’, y), Plays(t, l, s), s > 20h Q(t, l, s)  S1.Movie(MID, t), S1.MovieDetails(MID, x, ‘comedy’, y) , Plays(t, l, s), s > 20h Q(t, l, s)  S1.Movie(MID, t), S1.MovieDetails(MID, x, ‘comedy’, y), S2.Cinemas(l, t, s) , s > 20h unfolding F 1 unfolding F 2
  19. 19. Query Reformulation in LAV: Example Movie(MID, title,year,genre) Director(MID, director) Actor(MID, actor) Mediated Schema S1.Comedies(m,t,y)  …… Movie(m, t, y, ‘comedy’), …… y ≥ 1950 S2.Diractors(m,d)  ……. Director(m, d), Actor(m, d) Q(t,y,d)  Movie(m,t,y, ‘comedy’), y ≥ 1950, Director(m,d), Actor(m,d) Q’(t,y,d)  S1.Comedies(m,t,y), S2.Diractors(m,d) Answering Queries Using Views Algorithm
  20. 20. Answering Queries Using Views (AQUV) <ul><li>Given: </li></ul><ul><ul><li>Query Q </li></ul></ul><ul><ul><li>View definitions: V 1 ,…,V n </li></ul></ul><ul><li>Find : </li></ul><ul><ul><li>A query Q’ that is a rewriting of Q that refers only to the view and interpreted predicates </li></ul></ul><ul><li>Def. Q’ is an equivalent rewriting of Q using V 1 ,…,V n if Q’  Q , i.e. Q’ ⊑ Q and Q’ ⊒ Q </li></ul><ul><li>When Q, V 1 ,…,V n are conjunctive, finding the equivalent rewriting is NP-complete </li></ul><ul><ul><li>Need only consider rewritings of query length or less </li></ul></ul>
  21. 21. Maximally-Contained Rewritings <ul><li>Given: </li></ul><ul><ul><li>Query Q </li></ul></ul><ul><ul><li>Rewriting query language L </li></ul></ul><ul><ul><li>View definitions: V 1 ,…,V n </li></ul></ul><ul><li>Def. Q’ is a maximally-contained rewriting of Q given V 1 ,…,V n and L if : </li></ul><ul><ul><li>Q’  L, </li></ul></ul><ul><ul><li>Q’ ⊑ Q , and </li></ul></ul><ul><ul><li>there is no Q’’ in L such that Q’ ⊏ Q’’ ⊑ Q </li></ul></ul><ul><li>More appropriate semantics for mapping definitions under open-world assumption </li></ul>
  22. 22. AQUV Algorithms <ul><li>Bucket Algorithm </li></ul><ul><li>Inverse rules algorithm </li></ul><ul><li>MiniCon Algorithm </li></ul><ul><li>All three produce maximally-contained rewritings in L = UCQ for Q, V 1 ,…,V n in CQ </li></ul><ul><ul><li>CQ: Conjunctive Queries </li></ul></ul><ul><ul><li>UCQ: Union of CQ’s </li></ul></ul>
  23. 23. Bucket Algorithm <ul><li>Create a bucket for each subgoal g i in the query Q . </li></ul><ul><li>Fill each bucket with view atoms that contribute to g i (see next slide for further detail) </li></ul><ul><li>Create rewritings Q j ’ from the cartesian product of the buckets. </li></ul><ul><li>Discard those rewritings such that: </li></ul><ul><ul><li>Q j ’ ⋢ Q, and </li></ul></ul><ul><ul><li>it is not possible to add interpreted atoms such that the resulting rewriting is contained in Q . </li></ul></ul>
  24. 24. <ul><li>To decide whether a view V should be in the bucket of a subgoal g of Q , consider each of the subgoals v i in V and do the following </li></ul><ul><ul><li>Terminology: </li></ul></ul><ul><ul><ul><li>C ( Q ), C ( V ): the interpreted atoms (e.g. >, ≥) of Q , V </li></ul></ul></ul><ul><ul><ul><li>θ h(V ) : the same as θ but restricted to the head variables in V </li></ul></ul></ul><ul><ul><ul><li>If A = p (a 1 ,…,a k ,…a n ), then A [k] = a k </li></ul></ul></ul>Filling the Bucket <ul><li>for each v i n V </li></ul><ul><ul><li>if there is a unifier θ such that θ ( g ) = θ ( v i ) then </li></ul></ul><ul><ul><li>if ( is_satifiable ( θ h(V ) ( C ( Q ))  θ h(V ) ( C ( V )) </li></ul></ul><ul><ul><li> and  j is_varible ( g [j]) and  k head ( Q )[k] == g [j]  </li></ul></ul><ul><ul><li> is_varible ( v i [j]) and  m v i [j] == head ( V )[m] </li></ul></ul><ul><ul><li>then insert θ ( head ( V )) into the bucket of g </li></ul></ul><ul><li>end for each </li></ul>
  25. 25. Bucket Algorithm: Example View atoms that can contribute to g 1 : V 1 (ID,year), V 2 (ID,A’), V 4 (ID,D’,year) g 1 g 2 g 3
  26. 26. Bucket Algorithm: Example (cont.) V 3 (ID,amount) cannot contribute to g 2 : amount ≥ $200M  amount  $50M V 4 (ID,D’,year) V 2 (ID,amount) V 2 (ID,A’) V 4 (ID,Dir,Y’) V 1 (ID,Y’) V 1 (ID,year) g 3 g 2 g 1
  27. 27. Bucket Algorithm: Example (cont.) V 1 and V 4 are mutually disjoint… V 4 (ID,D’,year) V 2 (ID,amount) V 2 (ID,A’) V 4 (ID,Dir,Y’) V 1 (ID,Y’) V 1 (ID,year) g 3 g 2 g 1
  28. 28. The Inverse Rules Algorithm <ul><li>Given: </li></ul><ul><ul><li>Query Q </li></ul></ul><ul><ul><li>View definitions: V 1 ,…,V n </li></ul></ul><ul><li>Return </li></ul><ul><ul><li>where each is an inverse rule for V j </li></ul></ul>
  29. 29. The Inverse Rules Algorithm: Example Q(D,A)  Director(T, D), Actor(T, A) V 1 (T, Y, D)  Movie(T, Y, ‘comedy’), Director(T, D) V 2 (T, A)  Movie(T, Y, G), Actor(T, A) f1(T, A) , f2(T, A) : Skolem functions Movie(T, Y, ‘comedy’)  V 1 (T, Y, D) Director(T, D)  V 1 (T, Y, D) Movie(T, f 1 (T, A) , f 2 (T, A) )  V 2 (T, A) Actor(T, A)  V 2 (T, A) Q’ = Q 
  30. 30. Global-Local-as-View (GLAV) S7 Movies ( MID , title ) MovieDetais ( MID , dir, year ) Q 1 G (t,d,y)  Movie(t, d, ‘comedy’, y), y ≥ 1970 Q S7 (t,d,y)  Movies(i, t), MovieDetais(i, d, y) Movie: title, director, year, genre Q S7 (t,d,y)  Q 1 G (t,d,y)
  31. 31. GLAV: Formalization A set of expressions of the form: or closed-world assumption open-world assumption <ul><li>Q G : query over mediated schema </li></ul><ul><li>Q S : query over data sources </li></ul>
  32. 32. Query Reformulation in GLAV <ul><li>Given </li></ul><ul><ul><li>a query Q posed over the mediated schema </li></ul></ul><ul><ul><li>a set of queries (views) over the mediated schema </li></ul></ul><ul><ul><li>a set of queries (views) over source schema </li></ul></ul><ul><ul><li>a set of GLAV formulas of the form </li></ul></ul><ul><li>Find a rewriting Q’ over source schemas as follows: </li></ul><ul><ul><li>Obtain Q 1 by rewriting Q using views </li></ul></ul><ul><ul><li>Create Q 2 by replacing in Q 1 </li></ul></ul><ul><ul><li>Obtain Q’ by unfolding in Q 2 </li></ul></ul>
  33. 33. References <ul><li>A. Y. Halevy. Answering queries using views: A survey . The VLDB Journal, 10. Springer, 2001 </li></ul><ul><li>M. Lenzerini. Data Integration: A Theoretical Perspective .In Proceedings of PODS’02. ACM, 2002 </li></ul>
  34. 34. Validation of Mappings between Schemas Guillem Rull Carles Farré Ernest Teniente Toni Urpí
  35. 35. Motivation <ul><li>All techniques for building mappings are semi-automatic </li></ul><ul><li>Building a mapping always requires feedback from a human engineer </li></ul><ul><li>The engineer needs to validate the mapping </li></ul><ul><ul><li>That means checking if the mapping satisfies the needs and requirements </li></ul></ul><ul><ul><li>Few work has been done about validating mappings </li></ul></ul>
  36. 36. Purpose <ul><li>Our goal is to validate mappings </li></ul><ul><ul><li>Allowing the engineer to ask whether the mapping satisfies or not certain desirable properties </li></ul></ul><ul><ul><li>Applying DB schema-validation techniques </li></ul></ul><ul><ul><ul><li>Reformulating the mapping desirable properties in terms of the problem of query liveliness checking </li></ul></ul></ul><ul><ul><ul><li>Using our CQC Method to run the query liveliness tests </li></ul></ul></ul>
  37. 37. Initial Setting <ul><li>We consider mappings between two relational schemas. </li></ul><ul><li>We see a mapping as a set of GLAV formulas </li></ul><ul><ul><li>M = (F, A, B) denotes a mapping between schemas A and B with the set of formulas F. </li></ul></ul><ul><ul><li>Each mapping formula in F takes one of the following forms: </li></ul></ul><ul><ul><ul><li>Q A = Q B </li></ul></ul></ul><ul><ul><ul><li>Q A  Q B </li></ul></ul></ul><ul><ul><li>where Q A is a query over schema A, and Q B is a query over schema B. </li></ul></ul>
  38. 38. Our Approach: Sketch <ul><li>Define a set of desirable properties of mappings. </li></ul><ul><li>Reformulate these properties in terms of checking whether a certain query is lively. </li></ul><ul><ul><li>A query is lively if it admits a non-empty extension. </li></ul></ul><ul><li>Use the CQC method to perform the liveliness tests. </li></ul>
  39. 39. Mapping Properties in terms of Query Liveness <ul><li>Define a new schema S that combines the two mapped schemas. </li></ul><ul><ul><li>Mapped schemas: A = (DR A , IC A ), B = (DR B , IC B ) </li></ul></ul><ul><ul><li>Schema S = (DR A  DR B , IC A  IC B ) </li></ul></ul><ul><li>Make mapping M explicit by means of additional integrity constraints </li></ul><ul><ul><li>Schema S = (DR A  DR B , IC A  IC B  IC M ) </li></ul></ul><ul><li>Define a query Q over S such that </li></ul><ul><ul><li>Desirable mapping property holds for M </li></ul></ul><ul><ul><li>if and only if Q is lively over S </li></ul></ul>
  40. 40. Mapping Properties <ul><li>We have looked for already identified desirable properties of mappings in the literature </li></ul><ul><li>We have considered two of the properties identified in: </li></ul><ul><ul><li>Jayant Madhavan, Philip A. Bernstein, Pedro Domingos, Alon Y. Halevy: Representing and Reasoning about Mappings between Domain Models. AAAI/IAAI 2002: 80-86 </li></ul></ul><ul><li>These properties are: </li></ul><ul><ul><li>Mapping Inference </li></ul></ul><ul><ul><li>Query Answerability </li></ul></ul>
  41. 41. Mapping Properties <ul><li>We have defined a new property: </li></ul><ul><ul><li>Mapping Losslessness </li></ul></ul><ul><ul><li>It is an extension of query answerability </li></ul></ul><ul><ul><ul><li>Allows us to obtain useful validation information in those cases when query answerability is not useful. </li></ul></ul></ul><ul><li>We have also considered the property: </li></ul><ul><ul><li>Mapping Satisfiability (two variants: strong and weak) </li></ul></ul>
  42. 42. Mapping Inference <ul><li>Checks whether a given mapping formula is inferred from the other formulas in the mapping. </li></ul><ul><li>More formally, checks whether every pair of consistent instances that satisfies the mapping already satisfies the given formula. </li></ul>
  43. 43. Mapping Satisfiability <ul><li>Strong Satisfiability </li></ul><ul><ul><li>Checks whether there is a pair of instances that satisfies all mapping formulas in a non-trivial way. </li></ul></ul><ul><li>Weak Satisfiability </li></ul><ul><ul><li>Checks whether there is a pair of instances that satisfies at least one mapping formula in a non-trivial way. </li></ul></ul>
  44. 44. Query Answerability <ul><li>Checks if the two mapped schemas provide the same answer to a given query </li></ul><ul><li>More formally, </li></ul><ul><ul><li>Given a query Q defined over one of the mapped schemas, for instance, the schema A. </li></ul></ul><ul><ul><li>It checks whether </li></ul></ul><ul><ul><ul><li>For every consistent instance D B of schema B, </li></ul></ul></ul><ul><ul><ul><li>and for every pair of consistent instances D A , D A ’ of schema A that are mapped to D B , </li></ul></ul></ul><ul><ul><ul><li>then Q(D A ) = Q(D A ’) </li></ul></ul></ul><ul><li>Useless when mapping formulas are like Q A  Q B . </li></ul>
  45. 45. Mapping Losslessness <ul><li>Checks whether the mapping captures the information represented by a given query </li></ul><ul><li>More formally, </li></ul><ul><ul><li>Let Q be a query over schema A </li></ul></ul><ul><ul><li>Let M = (F, A, B) the mapping, where F = {V A 1 op V B 1 , …, V A N op V B N } </li></ul></ul><ul><ul><li>For every consistent instance D B of schema B, </li></ul></ul><ul><ul><li>and for every pair of consistent instances D A , D A ’ of A that are mapped to D B and such that V A 1 (D A )=V A 1 (D A ’),…, V A N (D A )=V A N (D A ’) , </li></ul></ul><ul><ul><li>then Q(D A ) = Q(D A ’) </li></ul></ul><ul><li>It is applicable when formulas are like V A  V B . </li></ul><ul><li>When mapping formulas are like V A = V B , mapping losslessness and query answerability are equivalent. </li></ul>
  46. 46. Example 1 referential constraint employee emp-id category happiness-degree category cat-id salary Schema A emp id salary Schema B queries: qA ( E , S )  employee ( E , C , H )  category ( C , S ) qB ( E , S )  emp ( E , S ) qA  qB
  47. 47. Example 1: Query Answerability vs Map. Losslessness Schema A = ( DR A , IC A ), where constraints IC A = { employee ( E , C , H )   S category ( C , S ) } and deductive rules DR A = { qA ( E , S )  employee ( E , C , H )  category ( C , S ) } Schema B = ( DR B ,  ), where deductive rules DR B = { qB ( E , S )  emp ( E , S ) }. Mapping M = ( F , A , B ), where formulas F = { qA  qB }. Query p ( E )  employee ( E , C , H ) <ul><li>Query Answerability does NOT hold: </li></ul>D B = {emp(0, 30), emp(1, 20)} D A = {employee( 0 , 0, 5), category(0, 30 )} D A ’ = {employee( 1 , 0, 5), category(0, 20 )} <ul><li>Mapping Losslessness holds: </li></ul>As all employees in A must have a category because of the referential constraint, query qA captures all employees.
  48. 48. Example 2: Mapping Losslessness Schema A = ( DR A , IC A ), where constraints IC A = { employee ( E , C , H )   S category ( C , S ) } and deductive rules DR A = { qA ( E , S )  employee ( E , C , H )  H > 5  category ( C , S ) } Schema B = ( DR B ,  ), where deductive rules DR B = { qB ( E , S )  emp ( E , S ) }. Mapping M = ( F , A , B ), where formulas F = { qA  qB }. Query p ( E )  employee ( E , C , H ) <ul><li>Mapping Losslessness does NOT hold: </li></ul>D B = {emp(0, 20)} D A = {employee(0, 0, 10), category(0, 20), employee(1, 1, 4), category(1, 30) } D A ’ = {employee(0, 0, 10), category(0, 20) , employee(2, 1, 4), category(1, 10) } qA(D A ) = qA(D A ’) = {qA(0, 20)} p(D A ) = {p(0, 20), p(1, 30)}  p(D A ’) = {p(0, 20), p(2, 10)}
  49. 49. Example 2: Map. Lossleness in terms of Query Liveliness Mapping M is lossless with respect to Q if and only if map_loss is not lively on this schema. Deductive rules: map_loss  p ( X )  ¬ p' ( X ) p ( E )  employee ( E , C , H ) qA ( E , S )  employee ( E , C , H )  H > 5  category ( C , S ) qB ( E , S )  emp ( E , S ) p' ( E )  employee' ( E , C , H ) qA' ( E , S )  employee' ( E , C , H )  H > 5  category' ( C , S ) DR A DR B DR A ' Constraints : employee ( E , C , H )   S category ( C , S ) employee' ( E , C , H )   S category' ( C , S ) qA ( X , Y )  qA' ( X , Y ) qA' ( X , Y )  qA ( X , Y ) qA ( X , Y )  qB ( X , Y ) IC A IC A ' IC L IC M
  50. 50. References <ul><li>J. Madhavan, P. A. Bernstein, P. Domingos, A. Y. Halevy: Representing and Reasoning about Mappings between Domain Models. AAAI/IAAI 2002: 80-86 </li></ul><ul><li>G. Rull, C. Farré, E. Teniente, T. Urpí: Validation of mappings between schemas. Data & Knowledge Engineering 66(3): 414-437 (2008) </li></ul>

×