• No results found

Query reformulation for an XML-based Data Integration System

N/A
N/A
Protected

Academic year: 2021

Share "Query reformulation for an XML-based Data Integration System"

Copied!
5
0
0

Loading.... (view fulltext now)

Full text

(1)

Query reformulation for an XML-based

Data Integration System

Bernadette Farias Lóscio

Ceará State University Av. Paranjana, 1700, Itaperi, 60740-000 - Fortaleza - CE, Brazil

+55 85 3101.8600

berna@larces.uece.br

Thiago Costa

Center for Informatics Federal University of Pernambuco P.O. Box 7851 Cidade Universitária,

Recife - PE, Brazil, 50732-970 +55 81 2126.8430

tac@cin.ufpe.br

Ana Carolina Salgado

Center for Informatics Federal University of Pernambuco P.O. Box 7851 Cidade Universitária,

Recife - PE, Brazil, 50732-970 +55 81 2126.8430

acs@cin.ufpe.br

ABSTRACT

The main objective of a mediator-based data integration system is to provide a unified view of several distributed and heterogeneous data sources. This view, called mediation schema, corresponds to a set of elements computed from data available on the local data sources. One of the biggest challenges facing a data integration system consists in answering a user query submitted in terms of the mediation schema given that the data is at the sources. This problem consists mainly in reformulating the query in terms of the source schemas and in integrating the corresponding answers. In this paper we address the problem of query reformulation in the context of an XML-based data integration system. Our solution is based on algorithms that generate a set of source queries considering a given user query and a set of mappings between the mediation schema and the data source schemas.

Categories and Subject Descriptors

H.2.5 [Heterogeneous Databases].

General Terms

Languages.

Keywords

Data integration, XML, query reformulation, mediation.

1.

INTRODUCTION

Integrated access to distributed data is an important problem faced in many scientific and commercial domains. One of the main challenging problem in the context of data integration is query processing. In order to answer a query submitted to a data integration system various steps are necessary, including query decomposition, query translation, query optimization and data integration. The complexity of the query execution process depends mainly on the approach adopted to define the mappings between the mediation schema and the source schemas. Two main

approaches have been used to specify such mappings: Global as View (GAV) and Local as View (LAV) [12, 6]. In the GAV approach each object of the global schema is expressed as a view (i.e. a query) on the data sources. On the other hand, in the LAV approach, mediation mappings are defined in an opposite way; each object in a given source is defined as a view on the global schema.

In this paper we address the problem of how to process a query submitted to a data integration system based on the GAV approach. The query execution process was developed as part of an XML-based data integration system, called Integra, proposed in [8]. We focus our discussion on the problem of how to decompose a user query into a set of remote data source queries using a set of mediation mappings. The remainder of this paper is organized as follows. Section 2 provides some definitions. Section 3 describes the query execution process. Section 4 explains our approach to query reformulation. Section 5 presents some implementation issues. Section 6 discusses some related works and Section 7 presents our conclusions.

2.

SOME DEFINITIONS

To facilitate the query execution process and other relevant tasks of the Integra system a conceptual data model, called X-Entity [9], and a declarative internal language called XEQ (X-Entity Query language) [3] were proposed. In this section we give an overview of the main concepts proposed in the X-Entity model and in the XEQ language. We also present the formalism adopted to represent the mappings between the mediation schema and the source schemas.

2.1

X-Entity Model

Integra uses XML as the common data model for data exchange and integration. To represent the mediation schema and the source schemas Integra adopts the XML Schema language. To provide a high-level abstraction for information described in an XML schema a conceptual data model, called X-Entity model [9], was proposed. The X-Entity model is not a new formalism for conceptual modeling, rather it is an extension of the Entity Relationship model [2], i.e., it uses some basic features of the ER model and extends it with some additional ones to better represent XML schemas. The main concept of the X-Entity model is the entity type, which represents the structure of XML elements composed by other elements and attributes. In the X-Entity model, relationship types represent element-subelement relationships and

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

SAC’06, April, 23-27, 2006, Dijon, France.

(2)

references between elements. In the following, we present the main X-Entity model constructs used to create X-Entity schemas. An X-Entity schema S is denoted by S = (E, R), where E is a set of entity types and R is a set of relationship types.

Entity type: an entity type E, denoted by

E({A1,…,An},{R1,…,Rm}), is made up of an entity name E, a set

of attributes A1,…,An and a set of relationships R1,…,Rm. An

entity type represents a set of elements with a complex structure, composed by attributes and other elements (called subelements). An instance of an entity type is a particular element in the source XML document. Each entity type has attributes {A1,…,An} that

describe it. An attribute Airepresents either an attribute or a

subelement, which is not composed by other elements or attributes. In X-Entity diagrams, entity types are displayed as rectangles.

Containment relationship: a containment relationship between two entity types E and E1, specifies that each instance of E

contains instances of E1. It is denoted by R(E, E1,(min,max)),

where R is the relationship name and (min, max) defines the minimum and the maximum number of instances of E1 that can be

associated with an instance of E. In X-Entity diagrams, containment relationships are displayed as diamond-shaped boxes labeled with contains. The straight lines connecting the relationship with the participating entities are directed from the entity E to the entity E1.

Reference relationship: a reference relationship, denoted by

R(E1, E2,{A11,…,A1n}, {A21,…, A2n}), where R is the name of the

relationship, specifies that the entity type E1 references the entity

type E2. {A11,…, A1n} and {A21,…, A2n} represent the referencing

attributes between entities of E1 and E2 such that the value of A1i,

1≤in, in any entity of E1 must match a value of A2i, 1≤i≤n, in

some entity of E2. In X-Entity diagrams reference relationships

are represented as a diamond-shaped box labeled with refers. The straight lines connecting the relationship with the participating entities are directed to the referenced entity.

Figure 2 presents three examples of X-Entity schemas. The entity type bookm, for example, has two attributes: titlem and publisherm,

and one containment relationship, which specifies that an instance of bookm has at least one subelement and may have

unlimited occurrences of the subelement chapterm. The entity type

chapter1 has a reference relationship, which specifies that an

instance of chapter1 may be associated with an instance of book1.

The attributes book1_title1 and title1 are the referencing attributes

between chapter1 and book1, respectively. Lóscio [8] have

described and implemented the process of converting an XML Schema to an X-Entity schema.

2.2

XEQ Language

Queries submitted to a data integration system are, in most cases, defined using declarative query languages or templates. The great majority of such languages are intended to human comprehension, which leads to difficulties in the query decomposition [4] and translation [7]. In order to minimize the complexity of such problems we proposed XEQ (X-Entity Query language), an XML-based language, used to provide an internal query representation for the Integra system [3].

Considering that the queries submitted to the Integra system are specified according to a mediation schema defined in the X-Entity model, a XEQ expression uses X-Entity concepts to represent the

queried data. The simplest conceptual representation of a XEQ expression involves naming one entity (i.e. the parent entity), providing a list of attributes to be returned, as well as using an expression to constrain this entity. We may also define expressions that return values for subentities of the parent entity. A subentity of an entity type E is an entity type E’ which is associated with E through a containment relationship. Queries may associate parent entities and their referenced entities. A referenced entity type of an entity type E is an entity type E’

which is associated with E through a reference relationship. The basic element of a XEQ expression is the SELECT element. The SELECT element has one attribute, called ENTITY, whose value is the name of the entity type E being queried. The SELECT

element may be composed by other elements, as: i) a

REFERENCE element that defines the join condition used to combine related elements from the entity type E and a referenced entity type E’, ii) ATTRIBUTE elements that have in their content the name of an attribute of the entity type E whose value is to be retrieved by the query, iii) a WHERE element that filters the data to be retrieved by the query. To illustrate the use of the XEQ internal language we present, in Figure 1, an XQuery query and its corresponding XEQ expression.

User query: Retrieve the title, year, the title of the chapters and the publisher name of all books.

XQuery

<books> {

for $b in //book2

return <book2>

<title2>$b/title2 </title2>

<year2> $b/year2 </year2>

<chapter2> $b/chapter2/chapter_title2 </chapter2>

for $p in //publisher2

where $b/ref_publisher2 = $p/id_publisher2

return

<publisher2> $p/publisher_name2 </publisher2>

</book2>

}</books2> XEQ

<EXP>

<SELECT ENTITY="book2">

<ATTRIBUTE>title2</ATTRIBUTE>

<ATTRIBUTE>year2</ATTRIBUTE>

<SELECT ENTITY="chapter2">

<ATTRIBUTE> chapter_title2 </ATTRIBUTE>

</SELECT>

<SELECT ENTITY="publisher2">

<ATTRIBUTE> publisher_name2 </ATTRIBUTE>

<REFERENCE NAME="ref_book_publisher">

<MAP ATTRIBUTE="ref_publisher2"> id_publisher2 </MAP>

</REFERENCE> </SELECT> </SELECT> </EXP>

Figure 1. User query example

In the example of Figure 1, consider the X-Entity schema S2 of

Figure 2. During the query translation to XEQ the query is parsed and each one of the entities being queried is identified and represented using a SELECT element. In the example above,

book2 is the entity whose values should be retrieved. Since

chapter2 is a subentity of book2, to retrieve such information it

should be used a nested SELECT element. It is important to observe that in the SELECT element associated with the referenced entity publisher2, there is a MAP element. This element

(3)

entity publisher2 should be done in order to retrieve the value of

the publisher_name2 attribute.

2.3

Correspondence assertions

Our approach to query reformulation is widely based on correspondence assertions [11] specifying relationships between the mediation schema and the source schemas. In this section, we describe just the correspondence assertions relevant to this paper. Other correspondence assertions may be found in [8].

Definition 1 (Entity correspondence assertion): Let E1 and E2 be

entity types. The correspondence assertion E1E2 specifies that

E1 and E2 are semantically equivalent, i.e, they describe the same

real world concept and they have the same semantics.

Definition 2(Attribute correspondence assertion): Let A1 be an

attribute of the entity type E1 and A2 an attribute of the entity type

E2, such that E1E2. The correspondence assertion E1.A1E2.A2

specifies that the attributes A1 and A2 are semantically equivalent

(correspond to the same concept in the real world).

Definition 3 (Link): Let X1 and X2 be elements of an X-Entity

schema (an element can be an entity type, a containment relationship type or an attribute), X1.X2 is a link if: i) X2 is an

attribute of the entity type X1, or ii) X1 is an entity type

participating in the relationship type X2(or vice-versa).

Definition 4 (Path): If X1...Xn are elements of a schema, such that

Xi, 1 ≤ i ≤ n, Xi.Xi+1 is a link, then X1.X2. ... .Xn is a path from X1

(the path is directed from X1 to Xn).

Definition 5 (Inverse path): If there is a path from X1 denoted by

X1.X2. ... .Xn, such that Xn is an entity type, then there is a path

denoted by (X1.X2. ... .Xn)-1, which is called the inverse path of

X1.X2. ... .Xn.

Definition 6 (Path correspondence assertion): Let P1 and P2 be

two paths: Case 1: P1= X1.X2.... .Xn and P2 = Y1.Y2...Ym, where

X1Y1. The correspondence assertion P1P2 specifies that the

entity types Xn and Ym are semantically equivalent. Case 2: P1=

X1.X2.... .Xn and P2 = (Y1.Y2...Yn)-1, where X1Yn. The

correspondence assertion P1P2 specifies that the entity types Xn

and Y1 are semantically equivalent.

To better illustrate our ideas, consider the mediation schema and the source schemas presented in Figure 2.

Figure 2. Mediation schema Smed and source schemas S1 and S2 Table 1 presents the correspondence assertions (CA) between Smed

and the source schemas S1 and S2.

Table 1. Correspondence assertions between the mediation schema Smed and the source schemas S1 and S2 CA1: bookm≅ book1

CA2: bookm.titlem≅ book1.title1

CA3: bookm.publisherm≅ book1.publisher1

CA4: chapterm≅ chapter1

CA5: chapterm.chapter_titlem ≅ chapter1.chapter_title1

CA6: bookm.bookm_chapterm.chapterm≅ (chapter1.chapter_ref_book1.book1)-1

CA7: bookm≅ book2

CA8: bookm.titlem≅ book2.title2

CA9: chapterm≅ chapter2

CA10: bookm.bookm_chapterm.chapterm ≅ book2.book2_chapter2.chapter2

CA11: chapterm.chapter_titlem≅ chapter2.chapter_title2

CA12: bookm.publisherm ≅

book2.book2_ref_publisher2.publisher2.publisher_name2

3.

QUERY EXECUTION PROCESS

The query execution consists in receiving a user query, expressed in a declarative query language, and in returning a query answer expressed in XML as output. The query execution process [3], described in Figure 3, may be summarized as follows: i) The mediator receives a user query Q and performs the necessary translation and reformulation to produce the set of local XEQ expressions (q1, q2, …, qn), ii) Next, the mediator sends these

expressions to the corresponding wrappers which translate them to the source query language producing the local queries (q1’, q2’,

…, qn’), iii) The wrappers receive answers for such queries (r1’,

r2’, …, rn’) from the data sources, these answers are translated to

XML and sent to the mediator and iv) Finally, the mediator integrates the XML answers (r1, r2, …, rn) and returns the

integrated result R as the answer to the original user query Q. The components responsible for the query execution process are presented in Figure 3 and described next.

Figure 3. Query execution process

The Query Interface takes as input the user query expressed using a declarative query language and it returns an XML document as the answer to this query. The Query Translator receives a query written in a high level query language (XQuery for example) from the query interface and translates this query to the XEQ internal representation.The Query Reformulator takes a XEQ expression as input and produces as output a set of XEQ source expressions.The Source Manager receives as input a set of XEQ source expressions and sends them to the wrapper

Query interface Query translator Query reformulator Data integrator Relational Database Translation XEQ - SQL Wrapper1 q1’ Source manager (q1, q2 ,..., q n) (r1, r2,..., rn) Q R Mediation schema converter r1’ Mediator Knowledge Base Log Cache Cache manager Data Sources Knowledge Base Mediator User Query Q u e ry m a n a g e r

Object Oriented Database XML Documents

r2’ rn’ q2’ qn’ q1 r1 q2 r1 qn rn Wrapper2 Wrappern Translation Relations - XML Translation XEQ - OQL Translation Objects - XML Translation XEQ - XQuery Translation XML - XML titlem chapterm contains chapter_titlem bookm publisherm (1,N) Smed title1 chapter1 refers chapter_title1 book1 publisher1 book1_title1 S1 title2 chapter2 contains (1,N) chapter_title2 publisher2 refers publisher_name2 book2 year2 S2 id_publisher2 ref_publisher2

(4)

associated with the corresponding data source. It receives from the wrappers the answers for the local queries already converted to XML. The Mediation Schema Converter takes as input the XML data received from the wrappers and converts them to the mediation schema. This translation is necessary to facilitate the further data integration process. Transformation functions are used to convert data format to be conform to the mediation schema. The Data Integrator takes as input a set of XML documents and transforms them in a single integrated document.

4.

QUERY REFORMULATION

In this section, we describe the basic algorithm that reformulates a XEQ expression over the mediation schema into a set of XEQ expressions over the source schemas. Let Q be the original user query and XQ be the expression obtained after the translation of Q

to the XEQ representation. There are three phases in the algorithm: i) Identification of the mediation entity (Em) being

queried: this entity is specified in the most external SELECT

element of the X ii) Identification of data sources relevant to answer the user query: a data source DSi is relevant to answer the

user query Q if it contains one or more source entities necessary to compute the mediation entity Em, i.e., source entities semantically

equivalent to Em,iii) Reformulation phase: this phase consists in

generating a XEQ expression for each one of the data sources relevant to answer Q. This is done using the algorithms presented in Figure 4. Next consider:

-T/@ENTITY: value of the ENTITY attribute of the SELECT

element T

-T/ATTRIBUTE: value of an ATTRIBUTE element of the SELECT element T

-T/WHERE: value of a WHERE element of the SELECT element T -A/text( ): retrieves the content of the ATTRIBUTE element A -ECA(Si, Em): retrieves the entity correspondence assertion CEm

Ej, where EjSi.E (Si.E is the set of entity types of the source

achema Si)

-ACA(Si, Am): retrieves the attribute correspondence assertion C

AmAj, where AjE’.A and E’Si.E (E.A is the set of attributes

of the entity type E’)

-X1ΦX2: concatenation operator that joins two XEQ expressions

X1 and X2

During the third phase of the query reformulation process the ReformulateQuery algorithm is executed for each one of the relevant data sources {DS1,…, DSn}. The first task of this

algorithm consists in reformulating the element (X/Exp/SELECT) that defines the mediation entity Em being queried. To do this, the

algorithm calls the procedure ReformulateSelect. This procedure recursively analyses the nested SELECT elements of T (T =

X/Exp/SELECT) in order to identify the subentities {E1,…, En}

and attributes {A1,…, Ak} of the mediation entity Em such that

T/@entity = Em. For each mediation entity Ej the algorithm

ReformulateSelect obtains the correspondence assertion which specifies how to compute Ei over the data source DSi. In the same

way for each attribute Aj, the algorithm obtains the

correspondence assertion which specifies how to compute Aj over

the data source DSi. The algorithm also analyses WHERE

elements to transform the constraints applied on the mediation elements into constraints on the source elements. This transformation is done using the algorithm ReformulateWhere. XEQ elements of the resulting source expression are created by

the algorithm AddPathToQuery. Due to space limitations, in this

paper we present just the ReformulateQuery and

ReformulateSelect algorithms. More information about the other algorithms may be found in [3].

Algorithm ReformulateQuery(XQ, Si) {Si is the X-Entity schema of the

data source DSi }

T := XQ/Exp/SELECT {Exp is root element of a XEQ expression}

LSi := new XEQ expression

P := empty path

ReformulateSelect(Lsi, T, Si, P)

Return LSi

End

Algorithm ReformulateSelect(XSi, T, Si, P) {XSi is the XEQ expression

corresponding to the data source Si }

P:= P + T/@ENTITY

NS:= AddPathtoQuery(XSi, ECA(Si, P))

For each A = T/ATTRIBUTE do

AddPathtoQuery(EXPLS, ACA(Si, P + A/text()))

For each T’ = T/SELECT do ReformulateSelect(XSi, T’, Si, P)

If (W = T/WHERE) ≠ ∅ then XSi:= XSiΦReformulateWhere(NS, W, Si, P)

End

Figure 4. Query reformulation Algorithms

To illustrate the query reformulation process consider the user query Q1 over the mediation schema Smed and its corresponding

XEQ expression X1 presented in Figure 5. As specified by the

most external SELECT element of X1 we have that the mediation

entity being queried is bookm (X1/Exp/Select/@ENTITY = bookm).

Next, based on the set of correspondence assertions presented in Table 1 the algorithm identifies the relevant data sources to compute bookm. According to the correspondence assertions CA1

(CA1:bookm book1) and CA7 (CA7:bookm book2) the data

sources relevant to compute bookm are DS1 and DS2, since book1

and book2 are source entities from the schemas S1 and S2

respectively. Therefore, the algorithm ReformulateQuery must be executed for these two data sources.

User query Q1: Retrieve the title, publisher and the title of the chapters all books.

X1(XEQ)

<EXP>

<SELECT ENTITY="bookm">

<ATTRIBUTE> titlem </ATTRIBUTE>

<ATTRIBUTE> publisherm </ATTRIBUTE>

<SELECT ENTITY="chapterm">

<ATTRIBUTE> chapter_titlem </ATTRIBUTE>

</SELECT> </SELECT> <EXP>

XS1(XEQ) 1.<EXP>

2.<SELECT ENTITY="book1">

3. <ATTRIBUTE>title1</ATTRIBUTE>

4. <ATTRIBUTE>publisher1</ATTRIBUTE>

5. <SELECT ENTITY="chapter!">

6. <ATTRIBUTE>chapter_title1</ATTRIBUTE>

7. <REFERENCE NAME="ref_chapter1_book1">

8. <MAP ATTRIBUTE="book1_title1"> title1 </MAP>

9. </REFERENCE> 10. </SELECT> 11. </SELECT> 12. <EXP>

Figure 5. User query

In the first step, the algorithm generates the source expression

XS1, presented in Figure 5, for the data source DS1. The SELECT

element of line 2 was generated from the correspondence assertion

CA1. Lines 3 and 4 were generated based on the correspondence

assertions CA2 and CA3. To compute the subentity chapterm of

bookm the algorithm created a nested select element (line 5)

(5)

associated with book1 through a refers relationship then it was

used a reference element to identify this restriction. For the data source DS2 the algorithm Reformulate generates the XEQ

expression XS2 similar to the XEQ expression XS1.

5.

IMPLEMENTATION ISSUES

An Integra prototype was implemented allowing the execution of the whole query process: from the submission of a user query to the answer of the integrated results. Wrappers were implemented to translate queries from XEQ to the data sources’ native language. In the initial version of the prototype, only wrappers for relational databases were implemented. During the tests, we used two real databases that stores medical information: Healthnet1 and TELEMED2, both implemented in MySQL. In the current version of the prototype, the mediation schema and the correspondences between the mediation schema and the source schemas are manually defined and stored in the Mediator Knowledge Base. In the Integra prototype, the query is translated to SQL using a XSLT stylesheet, and it is submitted to the data source through a JDBC driver.

6.

RELATED WORK

The work presented in [4] states and solves the query decomposition problem for XML publishing in a general setting. It allows mixed (XML and relational) storage of proprietary data and exploits redundancies (materialized views, indexes and caches) to enhance performance. Other problem faced during query processing consists in translating data source queries to the native query language. To improve the query translation process, data integration systems use languages based on scripts or templates as the input format for wrappers [7]. There are also systems that use XML query languages as input format for wrappers. The e-XML [5], MARS [4] and XPERANTO [10] systems provide integration of multiple data sources based on XML schemas.AutoMed [1] adopts a functional language, called IQL, to provide a common query language where queries written in high level query languages can be translated into and out of. In our approach, the user query may be specified in a high level query language. This query is translated to XEQ and it can be easily rewritten into a set of local subqueries. As XEQ is an XML-based language we can take advantage of XML benefits as the capability to easily transform XML data into different formats and to easily navigate through its hierarchical structure.

7.

CONCLUSION

In this paper, we focused on the problem of how to process a user query submitted to an XML-based data integration system. To solve this problem we proposed X-Entity, an ER-based conceptual data model, and XEQ, an XML-based language, whose specification facilitates both query decomposition and translation. The process of decomposing or translating a XEQ expression to other query languages consists in performing a recursive navigation that visits the expression elements and constructs the query result. In this paper we did not consider the problem of generating a query execution plan nor the problem of

1 http://www.nutes.ufpe.br/servicos/health.html

2Database of a brazilian hospital (Hospital Português – Recife)

query optimization. As a future work, we intend to study such problems in order to improve our proposed approach.

8.

ADDITIONAL AUTHORS

Juliano F. de Souza, jsf@cin.ufpe.br, Center for Informatics Federal University of Pernambuco, P.O. Box 7851 Cidade Universitária, Recife - PE, Brazil, 50732-970, +55 81 2126.8430

9.

REFERENCES

[1] Boyd, M., Kittivoravitkul, S., Lazanitis, C., McBrien, P., Rizopoulos, N. AutoMed: A BAV Data Integration System for Heterogeneous Data Sources. In Proceedings of the 16th Advanced Information Systems Engineering Conference (CAiSE) (Riga, Latvia, June 7-11, 2004). Lecture Notes in Computer Science, Springer, 2004, 82-97.

[2] Chen, P.P. The Entity-Relationship Model: Toward a unified view of data. ACM Transactions on Database Systems, 1 (Mar. 1976), 1-36.

[3] Costa, T., A. O Gerenciador de Consultas de um Sistema de Integração de Dados. Master Thesis. Universidade Federal de Pernambuco, Recife, Brazil, 2005.

[4] Deutsch, A. and Tannen, V. Reformulation of XML Queries and Constraints. Proceedings of the 9th International Conference on Database Theory (ICDT) (Siena, Italy, January 8-10, 2003). Lecture Notes in Computer Science, Springer, 2002, 255–241.

[5] Gardarin, G., Mensch, A., Tomasic, A. An Introduction to the e-XML Data Integration Suite. In Proceedings of the 7th International Conference on Extending Database Technology (EDBT) (Konstanz, Germany, March 27-31, 2000). Lecture Notes in Computer Science, Springer, 2000, 297-306.

[6] Halevy, Y. Theory of answering queries using views.

SIGMOD Record, 29 (Dec. 2000), 40-47.

[7] Hammer J., Brennig, M., Garcia-Molina, H., Nesterov, S., Vassalos, V. and Yerneni, R. Template based wrappers in the tsimmis system. In Proceedings of the ACM SIGMOD International Conference on Management of Data (Tucson, Arizona, May 13-15, 1997). ACM Press, 1997, 532-535. [8] Lóscio, B. F. Managing the Evolution of XML-based

Mediation Queries. PhD Thesis. Universidade Federal de Pernambuco, Recife, Brazil, 2003.

[9] Lóscio, B. F., Salgado, A. C., Galvão, L. R. Conceptual Modeling of XML Schemas. In Proceedings of the Fifth International Workshop on Web Information and Data Management (WIDM) (New Orleans, Louisiana, November 7-8, 2003). ACM, 2003, 102-105.

[10]Shanmugasundaram, J, Kiernan, J., Shekita, E.J., Fan C., Funderburk J. Querying XML Views of Relational Data. In

Proceedings of the 27th International Conference on Very Large Data Bases (VLDB) (Roma, Italy, September 11-14, 2001). Morgan Kaufmann, 2001, 261-270.

[11]Spaccapietra, S. and Parent, C. View integration: a step forward in solving structural conflicts. IEEE Transactions on Knowledge and Data Engineering, 6 (Apr. 1994), 258-274. [12]Ullman, J. D. Information integration using logical views. In

Proceedings of the 6th International Conference on Database Theory (ICDT) (Delphi, Greece, January 8-10, 1997). Lecture Notes in Computer Science, Springer, 1997, 19-40.

References

Related documents

Finally the profit margin is presented as a percentage of the housing loans and calculated by taking the interest rate on housing and deducting the interest expense, the expense

The financial statements for the company issued by the Executive Board in accordance with the German Commercial Code (HGB) and the consolidated financial

horizontal opening angle of 90° at 4 kHz means that a single loudspeaker can provide natural sound.. reproduction over an extensive

More importantly, I demonstrate how they are engaging the discourse of cimarronaje cultural (cultural maroonage) as a counter-cartography of blackness, a decolonization

Th e concept of such a route running through Lika-Senj County would fi rst and foremost require involvement at the natio- 10 During 2018, the Town of Novalja was visited by

Write a short response paper comparing and contrasting these different histories of the same disease, with attention to how each historian attends to.. different kinds of