AN APPROACH TO UNIFICATION OF XML AND OBJECT- RELATIONAL DATA MODELS

Transcription

1 AN APPROACH TO UNIFICATION OF XML AND OBJECT- RELATIONAL DATA MODELS Iryna Kozlova 1 ), Norbert Ritter 1 ) Abstract The emergence and wide deployment of XML technologies in parallel to the (object-)relational paradigm has led to the necessity of managing distributed data spread across XML and objectrelational data sources. Our investigation focuses on the design and development of an integration middleware between the application and the data sources, allowing unified access to the entire information stored in autonomous (object-)relational and XML data sources through the corresponding unified global views, an SQL-View and an XML-View, via both query languages, SQL and XQuery. This paper introduces the challenges of the model unification process specially designed for integrated processing of data stored under XML and (object-)relational data models. We prove feasibility and correctness of the proposed approach by examining properties of the constructed unified model and the corresponding unified schemas during all phases of the integration process. Further, we investigate to which extent the schema transformation steps may be conducted automatically during the overall integration process. 1. Introduction A variety of data sources, which differ in their format, data models, and access mechanisms as well as a need to manage a plenitude of data spread across these sources has led to new challenges regarding efficient methods for the integrated processing of heterogeneous data sources. To the most widespread data storage systems in modern enterprises belong at the first place relational and object-relational databases, whereas considerable amount of information reside in XML data sources, like native XML database systems (i.e., X-Hive/DB, Tamino) or collections of XML documents with, e.g., XQuery access. The parallel existence of these systems leads to the necessity to integrate data stored in (object-)relational and XML data sources. In this paper, we focus on the effective integrated processing of data, which belong to the same or to close domains but are represented using different data models (object-)relational and XML data models. Integration is achieved by introducing a middleware layer that provides a uniform interface for accessing data in their native data sources. We call our integration middleware SQXML Integration System (or just SQXML, [10], [11]) to emphasize the focus on the unification of the two data models. The main idea here is to provide a schema integration process that generates a single global schema comprising the entire information from the local data sources. More exactly, two global views should be provided on the integrated data sources, an SQL view and an XML view, presenting the entire information in the user s preferable format. The user or the application obtain the possibility to access data via both query languages, SQL and XQuery, regardless of the data model of the local source where the data actually reside. An idea to achieve these requirements states in the development of a unified data model that allows for managing object-relational and XML modeling concepts. 1 Department of Informatics, University of Hamburg, Germany, kozlova ritter@informatik.uni-hamburg.de 309

2 The deployment of this unified data model in the schema integration process provides for automated resolution of structural heterogeneity between the local data sources, i.e., resolving conflicts arising from differences in data models. The use of the unified data model as a common data model during the schema integration process offers considerable advantages regarding the process efficiency and the result completeness, that is, the completeness of the integrated global schemas finally presented to the user or application. We state that the generated global schema represented either in an (object-) relational or in an XML data model contains the same and entire information stored in the local data sources under integration. The remainder of the paper is organized as follows: Section 2 gives an overview of the schema integration process in SQXML. Section 3 presents the data model unification process. Section 4 provides the schema conversion process that defines the rules for converting SQXML schemas to SQL schemas and to XML definitions. In Section 5 we provide a detailed examination of the schema unification and conversion processes, as well as of correctness of all schema transformations performed during the overall SQXML integration process. Section 6 reviews related work, and finally, Section 7 concludes the paper. 2. integration in SQXML An overview of the SQXML Integration System, its architecture and main components can be found in [10], [11]. In this section we briefly outline the main steps of the schema integration process in SQXML. There are two main problems to be solved during this process: the problem of structural heterogeneity refers to the differences in data models of the sources, and the problem of semantic heterogeneity points out differences in information representation within the scope of the same data model. Whenever it is clear from the context, we use the terms SQL and XML for both, the languages as well as the corresponding data models. With SQL we always refer to the SQL:2003 standard [7]. The main idea to resolve structural heterogeneity is to unify SQL and XML concepts into a single superset of concepts. The unification approach proposed in [10] results in a new metamodel called SQXML Metamodel, representing a superset of both models. The SQXML metamodel is then used as a common data model to achieve structural homogeneity of the local data sources in the integration process. SQXML was build using concepts of the Common Warehouse Metamodel (CWM) [15]. Table 1 illustrates the model hierarchies of SQL(:2003), XML, and SQXML according to the OMG metadata architecture. The SQXML metamodel was constructed by unifying the metamodels of SQL and XML (meta-level M2). Thus, each SQL schema and each XML definition can be transformed into an equivalent SQXML schema (meta-level M1). Table 1. Metamodel hierarchy. Meta-Level SQL XML SQXML M3: Meta-Metamodel MOF MOF MOF M2: Metamodel CWM:Relational Package CWM:XML Package SQXML M1: Model () Database XML Definition SQXML M0: Instances (Data) Database XML Documents Integrated Data The SQXML metamodel supports most features of Core SQL:2003 as well as the optional package PKG006 Basic object support and some features from the optional package PKG007 Enhanced object support [7], thus providing basic object-relational features. SQXML supports the main 310

3 modeling concepts of XML according to the XML Recommendations and uses the XML data types [19]. The SQL:2003 data types have been converted to XML simple types using the SQL/XML standard [8]. The process of creating the global schemas is depicted in Figure 1. More details on the process can be found in [10], here we just give a short overview. First, the structural heterogeneity between the local SQL and XML schemas is resolved by transforming each of them into an equivalent SQXML schema. Further integration steps are performed on already structurally homogeneous SQXML schemas, depicted in Figure 1 as 1 and 2. Resolving semantic heterogeneity is performed in two steps, illustrated in the figure as schema-matching and schema-merging processes. Local SQL Local XML Unification 1 (SQXML metamodel) 2 (SQXML metamodel) Matching 1 Mapping Model 2 Merging Integrated Global (SQXML metamodel) Conversion Global SQL Global XML Figure 1. Integration process in SQXML. During the schema-matching process, semantic correspondences between elements of the SQXML schemas are discovered (the search strategy is comparable to the Cupid algorithm [13]). The schema-merging process applies the ideas of a merge operator [1] and the Vanilla merge algorithm [17] resulting in the integrated global schema written in terms of the SQXML metamodel. Finally, the integrated global SQXML schema is converted into an SQL schema and an XML definition by a schema conversion process that results into the global SQL schema and the global XML schema presented to the corresponding applications. 3. Data model unification Our approach to data model unification allows us to resolve the structural heterogeneity between SQL and XML definitions: it unifies the SQL:2003 metamodel and the XML metamodel into a single SQXML metamodel. Figure 2 illustrates the simplified class diagrams of the corresponding metamodels. Later on in this section we describe only the main components of the SQXML metamodel, whereas details on data model unification can be found in [10]. The top-level container of SQXML is (Figure 2c). It can contain TypeDefinitions, Entities and Procedures. TypeDefinition is an abstract class, which can be either SimpleType or ComplexType. The Procedure class is the same as in SQL because there are no routines in XML. The SQXML Entity class unifies SQL s Columns with XML s ElementDeclaration and AttributeDeclaration. In order to keep the origin structure of the classes, which is needed later on for schema conversion (Section 4), the SQXML metamodel was extended by a Context class that is associated with the Entity class. The Context class stores the original structure of the unified classes, so that for each SQXML Entity it can be easily traced whether it originates from the ElementDeclaration or from the AttributeDeclaration class. 311

4 a) CWM:Relational Metamodel b) XML Metamodel Table Column type SQLStructuredType Procedure SQLParameter SQLDataType SQLDistinctType SQLSimpleType TypeDefinition type SimpleTD ComplexTD type Particle AttributeDeclaration Term ModelGroup Definition ModelGroup ElementDeclaration type c) SQXML Metamodel TypeDefinition Procedure Parameter type Context ForeignKey SimpleType ComplexType UniqueConstraint BuiltInSimpleType Facet particles PrimaryKey ModelGroup particles Facet Facet Entity Figure 2. Metamodels. The SQXML SimpleType class unifies the SimpleTypeDefinition of XML with SQLSimpleType and SQLDistinctType of SQL. The SQXML ComplexType class is a unification of structured types: It unifies XML s ComplexTypeDefinition with Table and SQLStructuredType of SQL. In SQL:2003, tables and structured user-defined types are similar enough to be unified. The information from what an SQXML ComplexType originates is stored in the Context class. The content of a ComplexType is always a ModelGroup. This reflects the modelling concept of XML, which requires a ComplexTypeDefinition to contain a Particle containing a ModelGroup. The classes ForeignKey, UniqueConstraint, PrimaryKey, and CheckConstraint of SQL and the IdentityConstraintDefinition of XML provide the same concepts in a different syntactical representation. Therefore, it is straightforward to unify these classes in same-name SQXML classes. To construct the SQXML metamodel, we have considered the modelling concepts of SQL and XML as well as the structures (i.e., classes and relationships) of the CWM Relational and CWM XML metamodels. Thus, each supported SQL:2003 and XML concept is also available in SQXML and can be expressed in terms of the SQXML metamodel. An idea of introducing a Context class is to enhance the SQXML metamodel so that it captures the information that would have been lost otherwise. During the schema integration process the Context class stores for each SQXML Entity the information about the database from that the entity originates, its original name in that database, its original structure (i.e., table, structured type, element, or attribute), integrity constraints and the access path to the entity. Therefore, the Context class stores the complete information required to reconstruct the original SQL schema or XML definition from the SQXML schema, as well as to convert the merged SQXML schema to SQL and XML. 312

5 4. conversion process In this section we present the schema conversion process which is reverse to schema unification. The conversion process is used in order to convert the global integrated SQXML schema into the global SQL schema and the global XML definition. The conversion process is also applied for creating SQL views on the local XML sources as well as XML views on the local SQL sources, which are needed to perform query processing SQXML-to-SQL conversion process According to the definition of the data model unification process, the SQXML metamodel uses XML data types (Section 2). As some XML types have no direct correspondences in SQL, the SQXML type conversion to SQL types is not a straightforward process. For example, some Gregorian Calendar types are not available in SQL:2003 and have to be mapped to user-defined structured types. For XML types with unbounded cardinality, such as integer and string, an exact mapping cannot be provided either. The SQXML-to-SQL conversion algorithm (Figure 3) takes an SQXML schema S as input and produces an SQL:2003 schema represented in terms of the CWM Relational metamodel. Using a top-down approach, the SQXML schema S is traversed starting from globally defined types and entities. First, all globally defined complex types are mapped to structured user-defined types (lines 3-5). Next, global entities are mapped to typed tables (lines 6-8). User-defined structured types may not have constraints in SQL, so constraints are discarded (line 10). Furthermore, if there is only one typed table of a structured type or if there was no structured type in the original SQL schema the type is eliminated (line 11) because it is not required. 1 convertsqxmltosql( S) 2 begin 3 for each complextype t in S do 4 convertcomplextype(type:t) 5 end for 6 for each global Entity e in S do 7 convertentity(type:createtable(),entity:e) 8 end for 9 for each StructuredType t in S do 10 delete constraints from t; 11 if t is referenced only once or t.context is marked as table then eliminate t 12 end for 13 create SQL schema from structured types, typed tables, tables, procedures; 14 output SQL schema; 15 end; Figure 3. SQXML-to-SQL conversion algorithm. Conversion of procedures is not specially required: They are simply taken to the SQL:2003 schema as they are already in the required SQL format. The algorithm for the conversion of complex types is of special interest and will be presented below. Figure 4 illustrates the main steps of the algorithm for converting SQXML ComplexTypes to SQL: It takes a CompexType as a parameter and produces an SQLStructuredType. First, the position of 313

6 the type in the inheritance hierarchy of the schema is considered (lines 3-14). There are two specific constructs in SQXML that originate from XML and have no equivalent in SQL. One special feature of SQXML is inheritance from a simple type, where the SQXML Complex Type consists of an SQXML Entity of a simple type plus additional SQXML Entities. As shown in lines 6-7, this is resolved by creating a new complex type with the simple type as its only attribute. Another special feature of SQXML speciality is derivation by restriction, where the SQXML Complex Type inherits from a parent by omitting some of the parent s Entities. This is resolved by simply ignoring the parent (line 10). For the case of derivation by extension (line 11), where the SQXML Complex Type inherits from its parent complex type by adding some new SQXML Entities, all supertypes are converted recursively, before the type itself is converted. 1 SQLStructuredType convertcomplextype(complextype type) 2 begin 3 p <- parent(type); 4 if p NOT NULL then 5 if p instanceof SimpleType then 6 parent <- newstructuredtype(name:p.name, parent:null, abstract:false, final:false); 7 parent.addcolumn(name:p.name, type:mapsimpletype(p)); 8 else if p instanceof ComplexType then 9 if derivationmethod=restriction then 10 parent <- NULL; 11 else parent <- convertcomplextype(p); 12 end if 13 end if 14 else parent <- NULL; end if 15 result <- newstructuredtype(name:type.name, parent:parent, abstract:type.abstract, final:type.isfinal); 16 result.addcolumn(name: id, type:integer, constraint: PRIMARY KEY ); { see Fig. 5 } 25 return result; 26 end; Figure 3. Conversion of SQXML Complex Types (1). As the next step, a user-defined structured type is created in line 15. It obtains the same name, parent type, abstract properties and finality as the SQXML type. Furthermore, a unique identifier is added as the self-referencing column in line 16. It will be used later to identify instances of the type. The content of the complex type is finally converted as shown in lines in Fig. 5. Again, such SQXML concepts as simple content (i.e., having only one SQXML Entity of a simple type) and mixed content (i.e., text interspersed with SQXML Entities) have no equivalent constructs in SQL. As shown in lines 18-19, simple content is converted by adding a single column of the respective type. Mixed content as well as complex content are handled by the convertmodelgroup procedure. 17 if type.contenttype = SimpleContent then 18 s <- convertsimpletype(type.simplecontent); 19 result.addcolumn(name:s.name, type:s, constraint: NOT NULL ); 20 else if type.contenttype = mixed then 21 convertmodelgroup(type:result, group:type.content, mixed:true); 22 else if type.contenttype = complex then 23 convertmodelgroup(type:result, group:type.content, mixed:false); 24 end if Figure 4. Conversion of SQXML Complex Types (2). The conversion of ModelGroups from SQXML to SQL:2003 is a challenging task, as there is no analogous construct in SQL. Recall (Section 3) that the SQXML ModelGroup is a unification of XML s ModelGroups that allow for defining sequence, choice, and all groups of XML elements and of Particles that can specify the minimum or maximum occurrence of an 314

7 element or a ModelGroup. As there is no support for attributes with unbounded maximum number of occurrences in SQL, we chose the decision to create a new table for them. Therefore, whenever an SQXML Entity may occur more than once, additional tables interconnected by unique key/foreign key relationships are created in SQL schema. Furthermore, in order to reflect the minimum and maximum occurrences as well as choice and all model groups special constraints are added. Figure 6 illustrates conversion of an SQXML ModelGroup with maximum occurrence Particle into two SQL tables interconnected by a foreign key relationship and defining a corresponding CHECK constraint. a) <xsd:complextype name= article"> <xsd:sequence> <xsd:element name= title" type= xsd:string"/> <xsd:element name= author" type="xsd:string"/> <xsd:element name= review" maxoccurs= 5 > <xsd:simpletype> <xsd:restriction base= xsd:string > <xsd:maxlength= 1024 /> <xsd:restriction> </xsd:simpletype> </xsd:element> </xsd:sequence> </xsd:complextype> b) c) CREATE TABLE article( article:complextype title VARCHAR(30), content author VARCHAR(40), review INTEGER UNIQUE sequence:modelgroup ); CREATE TABLE review( title:entity article INTEGER NOT NULL REFERENCES article(review), review VARCHAR(1024), author:entity CHECK (NOT EXISTS (SELECT FROM review GROUP BY article HAVING COUNT()>5) ) ); particles review:entity 4.2. SQXML-to-XML conversion process Figure 5. ModelGroup conversion example. Since the SQXML metamodel uses data types from XML it is trivial to map SQXML simple data types to XML data types. The SQXML-to-XML conversion algorithm is illustrated in Figure 7. It takes an SQXML schema S as input and produces an XML schema. A topdown approach is used where the global SQXML entities are placed as sub-elements under the root-element and recursively processed (line 9). Conversion of SQXML simple data types into XML data types (lines 3-5) is trivial as stated above. For each SQXML ComplexType a complex data type in XML is created (lines 6-8). The main steps of this procedure include recursive creation of inheritance hierarchies of complex types, recursive conversion of SQXML ModelGroup structures into corresponding XML constructs, conversion of SQXML Entities, and conversion of complex elements with simple, element-only and mixed content. The procedure of converting SQXML Entities is represented in lines 13-18: SQXML Entities can be mapped either to elements or to attributes of the XML. The decision is taken according to the data type of the entity and the information about the origin structure stored in the Context class. As a result, an SQXML Entity is converted into an XML attribute only in the case it was an attribute in the original XML source schema and it was not merged with any SQL element during the schema merging phase. Finally, the complex and simple types, elements, attributes and model groups are glued together to an XML schema (lines 10-11). 315

8 1 convertsqxmltoxsd( S) 2 begin 3 for each simpletype t in S do 4 convertsimpletype(type:t) 5 end for 6 for each complextype t in S do 7 convertcomplextype(type:t); 8 end for 9 convertrootentityrecursively(entity:root); 10 create XML schema from complextype, simpletype, element, attribute, modelgroup; 11 output XML schema; 12 end; 13 convertentity(entity e) 14 begin 15 if e.typedefinition instof SimpleType and e.maxoccurs=1 and e.context is marked as xsd:attribute 16 then res<-xsdattribut(name, type) 17 else res<-xsdelement(name, type, occurences) 18 end if; 19 output res; 20 end Figure 7. SQXML-to-XML conversion algorithm. 5. Correctness of schema transformations In this section we investigate the main properties of the constructed SQXML metamodel as well as corresponding schema transformations. In our integration process we distinguish the SQL-to- SQXML and XML-to-SQXML schema unification processes, as well as the SQXML-to-SQL and SQXML-to-XML schema conversion processes. We show that all schema transformations are correct in the sense that there is no loss of information when performing schema transformations from one data model to another. First (Section 5.1), we ensure that round-tripping from SQL (XML) to SQXML and back to SQL (XML) is correct. Next (Section 5.2), we show that all supported SQL (XML) constructs find a corresponding representation in XML (SQL). Finally (Section 5.3), we ensure correctness of the schema conversion process applied to the integrated global SQXML schema that results in the global SQL and XML views. This, all together, allows us to state that all transformation steps performed within SQXML are correct. Consequently, all possible transformation paths from local schema elements to elements of the global views are lossless so that both global views as generated by SQXML encompass the complete information as provided by all considered local data sources. 5.1 Round-tripping According to the data model unification processes, the SQL-to-SQXML schema unification process applied to a local SQL source schema results into a unique SQXML schema (denoted as SQXML 1 in Figure 8a), as for each supported SQL schema construct there is exactly one modeling concept in the SQXML model. If now an SQXML-to-SQL schema conversion process is applied to this schema, it will result into the same original SQL schema: Due to the fact that original structure of the source schema elements is stored in the Context class, the unique decision is made about the conversion of each SQXML schema element into the corresponding SQL schema element. For example, an SQXML ComplexType will be uniquely converted into its original structure, either Table or SQLStructuredType, as this information is stored in the Context class. This means that 316

9 schema unification and conversion allow round-tripping: An SQL schema that is transformed to SQXML and then converted back is the same as the original SQL schema. Analogously, the XML-to-SQXML schema unification process applied to the local XML source schema uniquely results in an SQXML schema (denoted as SQXML 2 in Figure 8b), as each supported XML construct has exactly one corresponding modeling concept in the SQXML metamodel. Applying the SQXML-to-XML conversion process to 2 will lead to the original XML. This is due to the fact, that the original structure has been stored in the Context class, so that SQXML Entity can be uniquely converted into the original structure, i.e., either ElementDeclaration or AttributeDeclaration. This ensures the round-tripping of the unification and conversion processes applied to an XML schema. a) b) SQL information from SQXML-to-SQL Conversion Context Class SQXML 1 SQL-to-SQXML Unification SQL XML SQXML-to-XML Conversion SQXML 2 XML-to-SQXML Unification XML Figure 8. transformation processes conversion for local view construction As mentioned in Section 4, the schema conversion process is used to create XML views on the local SQL sources as well as SQL views on the local XML sources. In case of creating an XML view on the local SQL source (Figure 9a), the SQXML-to-XML conversion process is used (Section 4.2). We are dealing with conversion of SQXML schema elements (that originate from the local SQL source schema) to the XML elements. The conversion of SQXML data types is trivial (see Section 4.2). Note that we do not use a Context class for this kind of conversion, as there are no SQXML elements originating from an XML source schema. The SQXML entities of simple type are converted to the XML elements, that is, no XML attributes are created. We can obviously state that all schema elements of the SQL local schema are represented in the resulting XML view, that is, the SQXML-to-XML process correctly converts all SQXML elements to the XML schema elements. In case of creating an SQL view on the local XML source (Figure 9b), the SQXML-to-SQL schema conversion approach is applied (Section 4.1). Here, all SQXML schema elements have their origin in the XML local schema and must be converted to SQL schema elements. Converting the SQXML schema to an SQL:2003 schema in this case is not a straightforward task: As it was discussed in Section 4.1, some XML constructs cannot be exactly mapped to SQL:2003 constructs. a) XML View b) SQXML-to-XML Conversion SQXML 1 SQL-to-SQXML Unification SQL SQL View SQXML-to-SQL Conversion SQXML 2 XML-to-SQXML Unification XML Figure 9. conversion for local view construction. 317

10 In our solution, the problem of simple types with unbounded cardinality (such as XML types integer and string) can be resolved using reasonable cardinalities in corresponding SQL types (such as INTEGER, SMALLINT, CLOB, VARCHAR, or CHAR). In the case that there are no corresponding types in SQL:2003, like for some Gregorian Calendar types, user-defined structured types have to be defined that express the same value space and semantics as the XML types. Summing up, the SQXML-to-SQL process correctly converts all SQXML elements to the SQL schema elements without loss of information. For special cases like using certain data types, mixed content, or derivation by restriction the conversion process has been specified as well, thus all supported XML constructs find their representation in the SQL schema conversion for global view construction The SQXML global schema illustrated in Figure 10 is the result of performing the schemamatching and schema-merging integration steps (Section 2). Our focus here is on the schema conversion process that results in the global SQL schema and the global XML schema representations. The integrated global SQXML schema may contain three sets of elements. First, there are elements that originate only from the local SQL schema (as no correspondent elements have been found in the local XML source). The second group consists of elements that originate only from the local XML schema. To the third set belong those elements that have been merged into one global element from both local source schemas, SQL and XML. The SQXML-to-SQL process correctly converts all SQXML global schema elements to SQL global schema elements according to the procedure represented in Section 4.1. Information from the Context class is used for conversion of the elements of the first and the third groups, i.e., originating from the SQL local source. According to the SQXML-to-XML conversion process defined in Section 4.2, the XML global schema is constructed. Again, the Context class is used for correct representation of the elements that have their origin in the XML local schema (from the second and third groups). SQL Global XML Global SQXML-to-SQL Conversion information from Context Class SQXML Global SQXML-to-XML Conversion Figure 10. conversion for global view construction. From the discussion above and from the special cases considered in Sections 5.1 and 5.2 we can conclude that conversion processes are also correct when applied to the integrated global SQXML schema, resulting in the global SQL:2003 schema and the global XML definition. 6. Related work Existing research approaches on integration and management of heterogeneous data sources are related to the wide spectrum of problems arising in such fields as information integration, data and model management, and interoperability of diverse data modelling technologies. Related work on the integration process developed in our SQXML Integration System draws mainly from the areas of interoperability of XML and relational technologies and information integration. 318

11 The great importance and popularity of XML in the database area is shown by the fact that all major object-relational database management systems such as Oracle, IBM DB2, and Microsoft SQL Server provide diverse solutions for integrating XML and SQL data. Here we briefly discuss the most widespread commercial solutions. Oracle 9i Release 2 (and the current Oracle 10g Release 2) [16] provides XML support with the Oracle XML DB. It supports storage of XML documents and XML fragments in object-relational databases using a pre-defined structured type called XMLType which can be used as the type of columns and typed tables. Unstructured XML documents are stored as a character large object (CLOB), whereas structured XML documents are stored using an approach of mapping the XML structure to the database structure. In summary, Oracle XML DB uses object-relational database schemas enhanced with the XMLType, that is, no single global schema is provided. In order to integrate SQL and XML data, the user must know the SQL schema, all XML schemas, and use both query languages, SQL and XML. IBM DB2 XML Extender [5] provides XML support by defining mappings between relational tables and XML documents (Document Access Definition) and allowing storage of both SQL tuples and XML documents in a single database. Like in Oracle XML DB, no schema integration is provided, and the user has to know all schema definitions and combine query results manually. The newly appeared on the market DB2 Version 9.1 [6] supports the native XML data store, where well-formed XML documents can be stored within columns of a table. Such XML columns are defined with the XML data type, so that the XML data is kept in its native hierarchical form, rather than stored as text or mapped to a different data model. The user may perform different database operations on XML data, such as creating tables with XML columns, adding XML columns to existing tables, as well as inserting, updating, or deleting XML documents. Microsoft SQL Server 2005 [14] supports mapping between SQL tables and XML documents and provides solutions for native storage of XML documents. Like in the case of Oracle and IBM DB2, no global integrated schema is created so that two query languages must be used to access data and the results must be combined manually. In summary, all solutions considered above provide diverse techniques for XML storage and publishing without taking into account information integration aspects. The goal of investigations in the field of information integration is to provide integrated access to multiple autonomous data sources. The wrapper-mediator architecture proposed in [18] is commonly used in information integration systems. As examples, we mention here such wrappermediator research projects as Information Manifold (IM) [9], TSIMMIS [2], and FLORID [12]. While FLORID performs materialised integration, TSIMMIS and IM apply virtual integration. In the Information Manifold project the local and global schemas are relational, and therefore it does not compare directly to our SQXML Integration System. In the TSIMMIS approach, the data model of the local source is converted into the Object Exchange Model (OEM). The schema integration process is specified by applying user-defined rules, that is, wrappers and mediators are hard coded. A special query language called LOREL is used to access the integrated data. The SQXML Integration System applies virtual integration as well, but in comparison to TSIMMIS, it provides the end-user with a complete global schema constructed in an almost automated way, and the special choice of the SQXML common data 319

12 model allows for provision of global views in both SQL and XML representations as well as access to the entire information via SQL and XQuery. Another strategy often applied in integration systems is to use a predefined global schema (also called target schema) and identify and explicitly specify the relationships between the target schema and the local source schemas. In such systems, the mediated schema is manually designed to satisfy particular needs of the end-user and to capture special aspects of the domain of the user interest. This strategy is realised for example in such research projects as BRIITY [4] and Clio [3]. In these projects, the global schema is predefined and thus may not be complete, representing only a special part of the information stored in the local data sources. In contrast, in the SQXML Integration System the constructed global schema fully integrates the entire information from the local sources and represents it to the end-user in her/his desired format. 7. Conclusions The main focus of our research states in the development of a new approach to integrated processing of (object-) relational and XML data. One of the central problems that has to be resolved by an integration system that operates on heterogeneous data sources is the choice of a proper common data model. The common data model has to be powerful enough to resolve data model conflicts between the local sources. As our system operates on data sources represented in XML and (object-)relational data models, we have constructed a new metamodel, called SQXML Metamodel, representing a superset of both models, and thus serving as a common data model through the integration process. To the best of our knowledge, there is no other integration system that provides a specially designed common data model exploiting all features of XML and (object-) relational data models. One of the special requirements on our system is to construct both global schema representations, SQL and XML, which is possible only in case of a common data model representing a super set of both data models. The developed techniques can find their application not only for the integration of (object-) relational and native XML databases, but also for dynamic coupling of XML documents to an SQL database. Further, we are positive that it can also be beneficial in the area of peer data management systems, in order to better connect (object-)relational and XML peers. More formal examinations of the notion of equivalence of integrated global schemas is a task for further research, as it will ensure the equal information access opportunities for XML-based and SQL-based applications. Currently, we are dealing with data sources where local source schemas remain unchanged. As future work, aspects of schema versioning and schema evolution have to be investigated in order to trace local schema changes and to propagate them to the global schema. References [1] Bernstein, P.A. et al.: A Vision for Management of Complex Models. In: SIGMOD Record, Vol. 29, [2] Garcia-Molina, H. et al.: The TSIMMIS Approach to Mediation: Data Models and Languages. In: Journal of Intelligent Information Systems, vol. 8, [3] Haas, L.M. et al.: Clio Grows Up: From Prototype to Industrial Tool. In: Proc. of the ACM SIGMOD International Conference on Management of Data,

13 [4] Haerder,T. et al.: The Intrinsic Problems of Structural Heterogeneity and an Approach to their Solution. In: The VLDB Journal, (8), [5] IBM DB2 UDB. DB2 XML Extender. See [6] IBM DB 2 Version 9.1. See [7] Information technology-database languages-sql-part 1: Framework (SQL/Framework), ANSI/ISO/IEC, [8] International Organization for Standardization. ISO/IEC :2005 : Information Technology, Database Language SQL; Part 14: XML Related Specifications (SQL/XML). [9] Kirk, T. et al.: The Information Manifold. In: Proc. of the AAAI Spring Symposium Series, [10] Kozlova, I. et al.: CWM-based Integration of XML Documents and object-relational Data. In: Proc. of the 7th International Conference on Enterprise Information Systems (ICEIS), [11] Kozlova, I.: SQXML: Integrated Processing of Information Stored in Object-Relational and Native XML Databases. In: Proc. 7th Int. Conf. on Inf. Integration and Web-based Applications & Services (iiwas), [12] Ludaescher, B. et al.: Managing Semistructured data with FLORID: A Deductive Object-Oriented Perspective. In: Information Systems, 23(8), [13] Madhavan, J. et al.: Generic Matching with Cupid. In: Proc. of the 27 th VLDB Conference, Italy, [14] Microsoft SQL Server See [15] OMG: Common Warehouse Metamodel (CWM) Specification, Version 1.1 Volume 1, [16] Oracle XML DB Developer's Guide 10g Release 2 (10.2). See [17] Pottinger, R.A., Bernstein, P.A.: Merging Models Based on Given Correspondences. In: Proc.of 29 th VLDB, [18] Wiederhold, G.: Mediators in the architecture of future information systems. IEEE Computer, 25(3), [19] W3C, XML Part 1: Structures. XML Part 2: Datatypes. W3C Recommendation,