SQL Extension for Multidatabase System

Fifth International Conference on Computational Science and Applications SQL Extension for Multidatabase System Mi-Yeon Kim*, Jung-Min Seo*, Chang-Joo Moon** *Korea Telecom, **Konkuk University miyeon@kt.co.kr, jmseo@kt.co.kr, cjmoon@konkuk.ac.kr main categories: First, we extend the standard of SQL (Structured Query Language) compliant with SQL:1999 [4][5] and SQL:2003 [6][7] in order to solve the problem of the syntactical difference among the local schemas. Second, we analyze semantic conflicts using case studies and provide the solution of the semantic conflicts using MQL. The rest of this paper is organized in follow sections. Section 2 describes the works related to various MDBS models and semantic conflicts in MDBS. In Section 3, we provide the MQL by creating the global table and global view. In Section 4, which is the main section, we present several case studies on semantic conflicts and the solutions using MQL. Finally, Section 5 presents our conclusion for this paper. Abstract The most important feature of a Multidatabase System (MDBS) is to provide the global schema with integrating various models of Local Database Systems (LDBS). However, it is difficult to integrate local schemas into the global schema due to the difference of the syntactical and semantic expressions of LDBSs. In this paper, we propose the standard SQL extension for MDBS called by Multidatabase Query Language (MQL) 1 . In addition, we analyze semantic conflicts using case studies and provide solutions to the semantic conflicts using MQL. 1. Introduction 2. Related works The Multidatabase System (MDBS) has been researched to access and manage the various data stored in the distributed heterogeneous database [1][2][3]. The most important feature of MDBS is to provide the global schema with single interface as well as to integrate several Local Database Systems (LDBSs). Therefore, the users can access and modify the data of LDBSs through the global schema. However, local schemas of LDBSs are expressed not only by different data models but also by different meanings—although they are implemented having the same data model. It is difficult to integrate local schemas into the global schema due to various syntactical and semantic expressions of LDBSs. In this paper, we propose the SQL extension for MDBS called by Multidatabase Query Language (MQL) and the methods of using MQL in order to solve the problem which we faced with in constructing the MDBS. Our main contribution is divided into two The Database Management System (DBMS) is software designed for the purpose of managing information. It has been built using a technique that was prevalent during its time. Therefore, there existed many different models of LDBSs such as (1) relational, (2) object oriented, and (3) object-relational model, and so on. The model followed the trends in those days where conventional LDBS techniques were employed. The first MDBS was “MULTIBASE” based on functional data integration model during the 1980s. After that, most of MDBSs supported the relational model. The examples of relational MDBS are ADDS (Amoco Distributed Database System) [8], DATAPLEX [9], Mermaid [10], Ingres/Star [11], and so on. The MDBS which is based on object-oriented model appeared towards the end of 1980s – Pegasus [12], OIS (Operational Integration System) [13], CIS (Comandos Integration System) [14]. The UNISQL/M [15] provided the object-relational integration model. The resolving methods of semantic conflicts are dependent on the integration model such as functional model, relational model and object-oriented model, too [16][17][18]. In addition, previous MDBSs define another Data Definition Language (DDL) and Data 1 This research was supported by the MIC(Ministry of Information and Communication), Korea, under the ITRC(Information Technology Research Center) support program supervised by the IITA(Institute of Information Technology Advancement). 0-7695-2945-3/07 $25.00 © 2007 IEEE DOI 10.1109/ICCSA.2007.42 283 Manipulation Language (DML) according to their integration models. As such, these cause some problems for users of LDBS to learn another language for using the MDBS. Therefore, the MDBS should be developed based on a standard SQL for the sake of integrating LDBS and resolving the semantic conflicts. schema and the tables of global schema should be on a one-to-one mapping. Using the following format, the global table definition statement satisfies the requirements. CREATE TABLE <table name> ( <table element> [ {, <table element> }... ) AS SELECT [ DISTINCT | ALL ] <select list> FROM <ldb entity-set name> [ WHERE <search condition> ] ON LDB <ldb name> 3. Definition of MQL In this section, we propose the MQL to create the global table and global view with the extension of SQL:2003. The MQL is used for transforming and integrating local schema to the global schema in the three-step MDB structure [19]. The SQL:2003 is the latest international standard that is compliant with SQL2 and SQL:1999. The SQL2 is the SQL standard for relational database models. The SQL:1999 called by SQL3 adds object-oriented features and supports object-relational database models. The SQL:2003 likewise supports object-relational models. Therefore, our MDBS can be integrated with any model of LDBS—be it relational, object-oriented, or objectrelational models. After this, we use the term entity-relation model [19] to unify the terminology of relational model, object-oriented model and object-relational model. Accordingly, the term “entity-set” denotes the table of relational model and the class of object-oriented model. The word “attribute” denotes the column of tables and the element of classes. The term “entity” denotes the tuple of tables and the object of classes. The syntax of MQL is expressed by Extended Backus-Naur Form (). The non-terminal symbol represented by “<>” means that it is necessary to redefine the term according to the rule of EBNF. For the non-terminal symbol which is not redefined in this paper, the specification of SQL:2003 [6] and our previous study for MQL [20] should be referred upon. The <table name> designated the global table is one-to-one mapping the <ldb entity-set name>. The <table element> which is the column of global table is also one-to-one mapping the attributes of <select list>. The differences between the definition statement of the global table and the local table are as follows. First, the AS SELECT clause is added for the sake of corresponding to the global columns and the local columns. Second, the ON LDB clause is added in order to designate the local schema including the local table which is mapped the global table. The following global table definition statement transforms the local schema to the global schema using User-Defined Type (UDT) in OF clause. The columns of global table correspond to the attributes of <member list> defined in UDT. The hierarchy of global tables is generated by using UNDER clause CREATE TABLE <table name> OF <user-defined type name> [ UNDER <supertable name> ] [ ( <table element> [ { , <table element> } ] ) ] AS SELECT [ DISTINCT | ALL ] <ldb select list> FROM <ldb entity set name> [ WHERE <search condition> ] ON LDB <ldb name> The UDT is defined as follows. CREATE TYPE <user-defined type name> [ UNDER <supertype name> ] [ AS <member list> ] [ INSTANTIABLE | NOT INSTANTIABLE ] 3.1. Global table definition statement The global table definition statement transforms heterogeneous models of local schema to a unified model of global schema. In order to transform the local schema to the global schema, it is essential that the entity-set of local schema should be mapped in the tables of global schema. Similarly, the attributes of the local schema should be mapped in the columns of global schema. In this case, it should be sustained that the entity-sets and attributes of local schema can be selectable and modifiable through the global schema. According to the requirements, the entity-sets of local 3.2. Global view definition statement The global view definition statement integrates the distributed local schemas to a single global schema. The view definition of MDBS is equal to that of the SQL standard. CREATE VIEW <view name> ( <view column list> ) AS <query expression> 284 [ WITH CHECK OPTION ] salary REAL, bonus REAL, tax REAL, bracket INTEGER ) The global view is not supposed to be modifiable, so that the global views must correspond to the local entity-sets using n-to-m mapping. The <query expression> references to the columns in the more than one global table or in another global view. The global view is also defined by using UDT. Infodb2(Ldb2): TABLE Grad_student ( sssn INTEGER, sname CHAR(25), gpa REAL, fssn INTEGER, fname CHAR(25), frank CHAR(10), thesis_title CHAR(50), thesis_grade CHAR(1) ) CREATE VIEW <view name> OF <user-defined type name> [ UNDER <table name> ] [ <view element list> ] AS <query expression> [ WITH CHECK OPTION ] The university B manages the whole graduate students in single relational DB, ORACLE. Oradb(Ldb3): TABLE Student ( ssn INTEGER, name CHAR(25), major CHAR(20), type CHAR(1) ) TABLE Graduate_info ( ssn INTEGER, advisor_ssn INTEGER ) TABLE Address ( ssn INTEGER, street VARCHAR2(25), city VARCHAR2(20), zip CHAR(5) ) TABLE Faculty ( ssn INTEGER, name CHAR(25), dept CHAR(20), rank CHAR(15) ) TABLE Register ( cnumber CHAR(7), fac_ssn INTEGER, stud_ssn INTEGER ) TABLE Course ( cno CHAR(7), cname CHAR(30) ) TABLE Course_restriction ( cno CHAR(7), major CHAR(20), prereg_cno CHAR(7) ) TABLE Thesis ( title CHAR(50), ssn INTEGER, grade REAL ) TABLE Employee ( ssn CHAR(13), name CHAR(25), position CHAR(25), supervisor INTEGER ) TABLE Emp_personal ( ssn INTEGER, age INTEGER, wt_in_kg INTEGER, ht_in_cm INTEGER ) TABLE Emp_salary ( ssn INTEGER, salary REAL, bonus REAL, tax REAL, bracket CHAR(6) ) 4. Resolution to semantic conflicts In the application of distributed heterogeneous LDB environments, the same meaning may be expressed in different languages for each LDB. Therefore, there are many semantic conflicts during the integration of LDBs. In this section, we analyze the case studies of semantic conflicts using the classification of semantic conflicts in [18]. In addition, we provide the methods to resolve the semantic conflicts for each case study. 4.1. LDB schema Before we analyze the case studies, we define the local schemas in reforming the local schema in the [18]. The university A manages the next two relational DBs: infodb1 (Ldb1) and infodb2 (Ldb2) in Informix. The one manages the graduate students in their course work, and the other manages the graduate students in their paper work. Infodb1(Ldb1): TABLE Under_grad ( ssn INTEGER, name CHAR(25), major CHAR(20), address CHAR(50)) TABLE Faculty ( ssn INTEGER, name CHAR(25), dept CHAR(20), rank CHAR(15)) TABLE Enroll ( cno CHAR(7), fssn INTEGER, sssn INTEGER ) TABLE Course ( cno INTEGER, cname CHAR(30) ) TABLE Restricted_course ( cno INTEGER, cname CHAR(25), major CHAR(20) ) TABLE Employee ( ssn INTEGER, name CHAR(25), position CHAR(25), supervisor INTEGER ) TABLE Emp_other ( ssn INTEGER, age INTEGER, wt_in_lb INTEGER, ht_in_in INTEGER, The university C and D manage the whole graduated students using single UNISQL/X DBMS, respectively; the university C manages Unidb1 and the university D manages Unidb2. The UNISQL/X is an objectrelational model. Unidb1(Ldb4): CLASS Student ( ssn CHAR(13), name CHAR(25), major CHAR(20) ) METHOD gpa() REAL FUNCTION student_gpa FILE ‘st_gpa.o’ CLASS Gradstudent SUPERCLASS Student ( advisor INTEGER ) 285 CLASS Employee ( ssn INTEGER, name CHAR(25), position CHAR(25), supervisor Employee ) CLASS Emp_salary ( ssn INTEGER, salary REAL, bonus REAL, bracket CHAR(6) ) CLASS Faculty SUPERCLASS Employee ( dept CHAR(20), rank CHAR(15) ) CLASS Enroll ( course Course, fssn INTEGER, sssn INTEGER, grade REAL ) CALSS Course ( cno CHAR(7), cname CHAR(30), prereq Course ) CLASS Thesis ( title CHAR(50), author Gradstudent, status CHAR(10) ) type; the type of “supervisor” attribute of “Employee” entity-set in Ldb4 is a class-type. In order to resolve these kinds of conflicts, we use two methods. The first method is to extract the attribute with primitive data type from the supervisor class of Ldb4 which corresponds to the supervisor attribute with primitive type of Ldb1. The following statement defines the global table named by “MTemp4” using the “ssn” attribute of the “supervisor” class. CREATE TABLE MTemp4 ( mt_name CHAR(25), mt_ssn INTEGER, mt_position CHAR(25), mt_supervisor INTEGER ) AS SELECT name, ssn, position, supervisor.ssn FROM Employee ON LDB Ldb4 Unidb2(Ldb5): CLASS Student ( ssn CHAR(13), fname CHAR(15), lname CHAR(15), major CHAR(20) ) METHOD gpa() REAL FUNCTION student_gpa FILE ‘st_gpa.o’ CLASS GradStudent SUPERCLASS Student ( advisor Faculty ) CLASS Faculty SUPERCLASS Employee ( dept Department, rank CHAR(15) ) CLASS Employee ( ssn CHAR(9), name CHAR(30), supervisor Employee ) CLASS Department ( name CHAR(20), chairperson CHAR(30) ) CALSS Course ( cno CHAR(7), cname CHAR(30), prereq Course ) CLASS Enroll ( course Course, fssn CHAR(9), sssn CHAR(9) ) CLASS Thesis ( title CHAR(50), author Gradstudent, status CHAR(10) ) The second solution is to define the UDT corresponding to the “supervisor” class of Ldb4. The following statement defines the UDT called by “MUemp”. The definition of “MUemp” table uses the “REF FROM” clause in order to designate “mu_ssn” as the reference of “MUemp”. CREATE TYPE MUemp AS ( mu_name CHAR(25), mu_ssnINTEGER, mu_position CHAR(25), mu_supervisor REF(MUemp) ) REF FROM ( mu_ssn ) INSTANTIABLE NOT FINAL The next statements define the global tables that correspond to the “Employee” local entity-set of Ldb1 and Ldb4 using “MUemp” type. The definition of “MTTemp1” uses the “REF” clause which refers to the tuple of global table using the attribute of supervisor. The definition of “MTTemp4” also uses the “MUemp” to transform the “Employee” entity-set of Ldb4 to the global table without “REF” clause. 4.2. Case studies and resolution of semantic conflicts Using the examples of LDBs, we present the case studies of semantic conflicts and the solution for each case. CREATE TABLE MTTemp1 OF MUemp AS SELECT name, ssn, position, REF(supervisor) FROM Employee ON LDB Ldb1 4.2.1. Attribute composition conflict. This kind of conflict arises when attributes represented by aggregation-type is corresponding to the attributes represented by primitive-type with the same meaning. When the “Employee” entity-set of Ldb1 integrates with the “Employee” entity-set of Ldb4, it is expected that attribute composition conflict will certainly happen. On the contrary, the type of “supervisor” attribute of the “Employee” entity set in Ldb1 is a primitive data CREATE TABLE MTTemp4 OF MUemp AS SELECT name, ssn, position, supervisor FROM Employee ON LDB Ldb4 4.2.2. Many-to-many attribute conflicts. This kind of attribute happens when the different numbers of 286 attributes represent the same meaning and information for each LDB. For example, the “name” attribute of the “Student” entity-set of Ldb4 and Ldb5. On the contrary, the “name” of “Student” entity-set in Ldb4 is expressed in single attribute—the “name” of “Student” entity-set in Ldb5 is represented by two attributes: the “fname” attribute and the “lname” attribute. To resolve this particular conflict, string concatenator represented by the symbol “||” should be used—the one attribute with string type maps more than the one attribute using the concatenator. The following statement defines “MTstudent5” global table corresponding to the “Student” entity-set in Ldb5. CREATE TYPE MUemp_sub UNDER MUemp_super AS ( mu_position CHAR(25) ) INSTANTIABLE NOT FINAL The global view “MTVemp_super” “MUemp_super” UDT is defined as follows: using CREATE VIEW MTVemp_super OF MUemp_super AS SELECT mt_name, mt_ssn, mt_supervisor FROM MTemp1 UNION SELECT mt_name, mt_ssn, mt_supervisor FROM MTemp3 UNION SELECT mt_name, mt_ssn, mt_supervisor FROM MTemp4 UNION SELECT mt_name, mt_ssn, mt_supervisor FROM MTemp5 CREATE TABLE MTstudent5 ( mt_name CHAR(25), mt_ssn INTEGER, mt_major CHAR(20) ) AS SELECT fname || lname, ssn, major FROM Student ON LDB Ldb5 The global view “MTVemp_sub” which is the sub global view of “MTVemp_super” using “MUemp_super” UDT is defined as follows: 4.2.3. Missing attribute conflict. This type of conflict happens when the information of one of the entity-sets differ from that of the other. For example, the “position” attribute is included in the “Employee” entity-set of Ldb1 but it is missed in the “Employee” entity-set of Ldb5. Therefore, when the “Employee” entity-sets of Ldb1 and Ldb5 are integrated, missing attribute conflicts arise. There are four methods to solve the problem. First, the missing attribute of local entity-set transforms to NULL value or default value in the definition of global table. Second, the attribute which corresponds to the missing attribute is omitted in the definition of global table. Third, only common attributes are included in the definition of global view instead of processing the missing attribute during the definition of global table. The last method is to use the UDT in the definition of global view and the inheritance property of class hierarchy. The super UDT is defined with including only common attributes and the sub-UDT is defined by including non-common attributes. The following statement defines the super UDT named by “MUemp_super” with excluding the “position” attribute. CREATE VIEW MTVemp_sub UNDER MTVemp_super OF MUemp_sub AS SELECT mt_position FROM MTemp1 UNION SELECT mt_position FROM MTemp3 UNION SELECT mt_position FROM MTemp4 4.2.4. Entity-set and attribute conflict. This kind of conflict occurs when one LDB expresses to be the entity-set and the other expresses to be the attribute for the same meaning information. This case is the integration of the “address” attribute of “Under_grad” entity-set in Ldb1 and the “Address” entity-set in Ldb3. To solve this problem, the number of methods expressed in two conducts. The first is to divide one entity-set which contain the attribute corresponding to the other entity-set with the same meaning. The second is to combine the entity-sets in order to match another entity-set including the attribute with the same meaning. Over all, it is necessary to define the global schema definition. The “MTunder_student1”, “Mstudent3” and “Maddress3” global tables are defined corresponding to the “Under_grad” entity-set in Ldb1, the “Student” entity-set in Ldb3 and “Address” entity-set in Ldb3, respectively. These global tables are as follows: CREATE TYPE MUemp_super AS ( mu_name CHAR(25), mu_ssnINTEGER, mu_supervisor REF(MUemp_super) ) REF FROM ( mu_ssn ) INSTANTIABLE NOT FINAL The next statement defines the sub-UDT called by “MVemp_sub” including only the “position” attribute. 287 CREATE TABLE MTunder_student1 ( mt_name CHAR(25), mt_ssn INTEGER, mt_major CHAR(20), mt_type CHAR(1), mt_address CHAR(50) ) AS SELECT name, ssn, major, ‘u’, address FROM Under_grad ON LDB Ldb1 CREATE VIEW MVunder_student_with_address ( mv_name, mv_ssn, mv_major, mv_type, mv_address ) AS SELECT mt_name, mt_ssn, mt_major, mt_address FROM MTunder_student1 UNION SELECT mt_name, MTstudent3.mt_ssn, mt_major, mt_street || mt_city || mt_zip FROM MTstudent3, MTaddress3 WHERE MTstudent3.ssn = MTaddress3.ssn AND MTstudent3.type = ‘u’ CREATE TABLE MTstudent3 ( mt_name CHAR(25), mt_ssn INTEGER, mt_major CHAR(20), mt_type CHAR(1) ) AS SELECT name, ssn, major, type FROM Student ON LDB Ldb3 4.2.5. Many-to-many entity-sets conflict. This kind of conflict happens when different numbers of entity-sets are used for the expression of the same meaning. For example, The “Emp_other” entity-set in Ldb1 is integrated with the “Emp_personal” and “Emp_salary” entities in Ldb3. For the resolution, the global tables should be defined the same applies to the global view which integrates the global tables. First, the “MTemp_other1”, “MTemp_personal3” and “MTemp_salary3” global tables should be defined with corresponding to the “Emp_other” entity-set in Ldb1, “Emp_personal” entity-set in Ldb3 and “Emp_salary” entity-set in Ldb3, respectively. After the definition of global tables, global view should be defined to integrate the global tables. The following statement defines the “MVemp_info” global view which integrates three global tables. CREATE TABLE MTaddress3 ( mt_ssn INTEGER, mt_street CAHR(25), mt_city CHAR(20), mt_zip CHAR(5) ) AS SELECT ssn, street, city, zip FROM Address ON LDB Ldb3 As the first solution, the global views are defined as follows: “MVunder_student_without_address” global view and “MVaddress” global view. The “MVunder_student_without_address” global view integrates the “MTunder_student1” global table excluding “mt_address” attribute and “MTstudent3” global table. The “MVaddress” global view integrates the “mt_address” attribute of “MTunder_student1” global table and “MTaddress3” global table. CREATE VIEW MVemp_info ( mv_ssn, mv_age, mv_wt_in_lb, mv_ht_in_in, mv_salary, mv_bonus, mv_tax ) AS SELECT mt_ssn, mt_age, mt_wt_in_lb, mt_ht_in_lb, mt_salary, mt_bonus, mt_tax FROM MTemp_other1 UNION SELECT MTemp_personal.mt_ssn, mt_age, mt_wt_in_lb, mt_ht_in_lb, mt_salary, mt_bonus, mt_tax FROM MTemp_personal3, MTemp_salary3 WHERE MTemp_personal3.ssn = MTemp_salary3.ssn CREATE VIEW MVunder_student_without_address ( mv_name, mv_ssn, mv_major, mv_type ) AS SELECT mt_name, mt_ssn, mt_major FROM MTunder_student1 UNION SELECT mt_name, MTstudent3.mt_ssn, mt_major FROM MTstudent3 WHERE MTstudent3.type = ‘u’ CREATE VIEW MVaddress ( mv_ssn, mv_address ) AS SELECT mt_ssn, mt_address FROM MTunder_student1 UNION SELECT mt_ssn, mt_street || mt_city || mt_zip FROM MTaddress3 5. Conclusion The one of the most important functions of MDBS is to integrate schemas in local database and to provide the global schema to users. The second solution is to integrate the “MTstudent3” and ‘MTaddress3’ global table to the one global view named by “MVunder_student_with_address”. 288 [9] C. W. Chung, "DATAPLEX: An Access to Heterogeneous Distributed Databases," Communication of the ACM, Vol.33, No.1, Jan. 1990, pp.70-80. However, the schemas that have the same meaning can be represented not only by the various models but also by the various methods of the same model. As a result, many semantic conflicts occur. Therefore, it is necessary to analyze the semantic conflicts in integrating local schemas and to suggest the method to resolve it. In this paper, I propose the MQL with extended SQL standard to support MDBS. Moreover, I provide the case studies of semantic conflicts in integrating local schemas and the method to resolve the conflict for each case of semantic conflicts. In the future, we will analyze the remainder of semantic conflicts which are not proposed in this paper and present the resolution methods. [10] M. Templeton, et al., " Mermaid: A Front-end to Distributed Heterogeneous Databases," In Proc. Special Issue on Distributed Database Systems, IEEE, Vol.75, No.5, May, 1987. [11] M. Stonebraker, The Ingress Papers: Anatomy of a Relational Database System, Addison-Wesley, 1986. [12] R. Ahmed et al., “An Overview of Pegasus,” In Proc. of the RIDE-IMS, 1993, pp. 273-277. [13] R. Gagliardi, M. Caneve, and G. Oldano, "An operational approach to the integration of distributed heterogeneous environment," In Proc. of the PARBASE-90 Conference, 1990, pp. 368-377. 6. References [14] E. Bertino, M. Negri, G. Pelaggati, and L. Sbatella, "Integration of Heterogeneous Database Applications through an Object-oriented Interface," Information Systems, Vol.14, No.5, 1989, pp. 407-420. [1] G. Tomas et al., “Heterogeneous Distributed Database Systems for Production Use,” ACM Computing Surveys, Vol.22, No.3, Sep. 1990, pp. 237-266. [2] E. Pitourra, O. Bukhres, and A. Elmagarmid, “Object Orientation in Multidatabase Systems,” ACM Computing Surveys, Vol.27, No.2, June 1995, pp. 141-195. [15] W. Kelley, S. Gala, Won Kim, T. Reyes, and B. Graham, “Schema Architecture of the UniSQL/M Multidatabase System,” Modern Database Systems, Won Kim ed., Addison Wesley, 1995, pp. 621-648. [3] Won Kim, “Introduction to Part2: Technology for Interoperating Legacy Databases,” Modern Database Systems, ACM Press and Addison Wesley, 1995, pp.521-550. [16] Umeshwar Dayal, Hai-Yann Hwang, "View Definition and Generalization for Database Integration in a Multidatabase System," IEEE Transactions on Software Engineering (TSE), Vol.10, No.6, 1984., pp. 628-645. [4] ANSI TC X3H2, ISO/IEC JTC 1/SC 21/WG, "ISOANSI Working Draft Foundation (SQL/Foundation)," March 1999. [5] A. Eisenberg, J. Melton, “SQL:1999, Formerly Known as SQL3,” ACM SIGMOD Record, Vol.28, No.1, March 1999. [17] Won Kim and Jungyun Seo, “Classifying Schematic and Data Heterogeneity in Multidatabase Systems," IEEE Computer, Vol.24, No.12, Dec. 1991, pp. 12-18. [6] ISO/IEC JTC 1/SC32, “Information technology-Database languages-SQL-Part2: Foundation (SQL/Foundation), “ American National Standards Institute (ANSI), New York, NY, www.ansi.org, 2004. [18] W. Kim, I. Choi, S. Gala, and M. Scheevel, "On Resolving Schematic Heterogeneity in Multidatabase Systems," Distributed and Parallel Databases, Vol.1, No.3, 1993, pp. 251-279. [7] Andrew Eisenberg, Krishna Kulkarni, Jim Melton, JanEike Michels, Fred Zemke, “SQL:2003 Has Been Published, “ACM SIGMOD Record, Vol.33, No.1, March 2004. [19] Mi-Yeon Kim, Ju-Won Song, Jeong-Oog Lee, and DooKwon Baik, "Schema Integration in Multidatabase Systems Using the Extension of SQL3," In Proc. Intl. Symposium on Future Software Technology 2000(ISFST-2000), Guiyang China, Aug. 2000, pp. 79-84. [8] Y. J. Breitbart and P. L. Olson, and G. R. Thompson, “Database Integration in a Distributed Heterogeneous Database System,” In Proc. of the Int’l Conf. on Data Engineering, 1986, pp.301-310. [20] P. P. Chen, “The Entity-Relationship Model: Toward a Unified View of Data,” ACM Transactions on Database Systems, Vol.1, No.1, Jan. 1976, pp. 9-36. 289