715
Journal of the Chinese Institute of Engineers, Vol. 26, No. 5, pp. 715-720 (2003)
Short Paper
THE QUERY TRANSLATION BETWEEN OBJECT-ORIENTED AND RELATIONAL DATABASES
Yin-Fu Huang* and Wen-Feng Kuo
ABSTRACT In this paper, we propose a solution for the query translation between objectoriented and relational databases. The translation was accomplished through a schema transformer and a query translator. The mapping rules defined within the schema transformer describe the transformation between an object-oriented schema and a relation schema. Then the query translator provides users a relational view of an object-oriented database, and vice-versa. In this work, we used Entity/Relationship model as a tool to describe the real world since Entity/Relationship model can be easily mapped to an object-oriented or relational schema according to the underlying DBMS. Finally, we implemented the query translation between OOSQL for WOO, an objectoriented database system developed at the Institute for the Information Industry, and SQL for the Microsoft FoxPro relational database system. Key Words: query translation, schema transformation, object-oriented databases, E/R model.
I. INTRODUCTION Although object-oriented databases have more advantages than relational databases, relational databases can not be replaced with object-oriented databases immediately because so many useful packages and robust mathematical theories have been developed for relational databases. Thus, for two different types of databases co-existing in a network, we must provide users a useful environment through query translation, no matter what databases they try to access. In this paper, we propose a solution for the query translation between object-oriented and relational databases. The translation was accomplished through a schema transformer and a query translator. The mapping rules defined within the schema transformer describe the transformation between an object-oriented schema and a relation schema. As for *Corresponding author. (Tel: 886-5-5342601 ext. 4314; Fax: 886-5-5312063; Email:
[email protected]) The authors are with the Institute of Electronic and Information Engineering, National Yunlin University of Science and Technology, Yunlin, Taiwan 640, R.O.C.
query translation, the query translator provides users a relational view of an object-oriented database, and vice-versa. In this work, we used Entity/Relationship model as a tool to describe the real world since Entity/Relationship model can be easily mapped to an object-oriented or relational schema according to the underlying DBMS. Finally, we implemented the query translation between OOSQL for WOO, an object-oriented database system developed at the Institute for the Information Industry, and SQL for the Microsoft FoxPro relational database system. II. SCHEMA TRANSFORMATION 1. Transformation from Object-oriented Schema to Relational One In schema transformation, Fitsilis et al. (1994), Hsieh and Chang (1993), and Meng et al. (1993) have presented how an object-oriented schema is transformed to a relational schema. In this section, the idea of the transformation is mostly according to Hsieh and Chang (1993), yet we complement the transformation for the relationships between entities.
716
Journal of the Chinese Institute of Engineers, Vol. 26, No. 5 (2003)
Depart_No
Depart_Name
DEPARTMENT
Hos_Emp_No
1
M DEP_EMP
Hos_Emp_Name
Hos_Emp_Birthday
HOSPITAL EMPLOYEE
N
Project_No
Degree
Skill
HOSPITAL_ RESEARCHER
HOSPITAL_ TECHNICIAN
Hos_Emp_Telno
Project_Name
EMP_PRO
M PROJECT
Project_Members
MEDICAL EMPLOYEE Med_Emp_No
HOSPITAL_ ADMINISTRATOR
Med_Emp_Name
Med_Emp_Birthday Med_Emp_Telno
Job
Fig. 1 Entity/relationship diagram of object oriented database HOSPITAL
Here an Entity/Relationship diagram shown in Fig. 1 is used to illustrate the schema transformation. This is an object-oriented database HOSPITAL about the hospital employees and their projects. According to Fig. 1, the object-oriented schema of Database
Relations DEPARTMENT HOSPITAL_EMPLOYEE HOSPITAL_RESEARCHER HOSPITAL_TECHNICIAN HOSPITAL_ADMINISTRATOR PROJECT MEDICAL_ EMPLOYEE HOS_EMP_TELNO MED_EMP_TELNO DEP_ HOS_EMP HOS_ EMP_PROJ PROJ_MED_ EMP
HOSPITAL can be transformed into the corresponding relational schema as follows where the attributes as primary keys are shown in boldface and as foreign keys shown in italic.
Attributes/Primary Keys/Foreign Keys Department_ Oid, Depart_No, Depart_ Name Hospital_Employee_Oid, Hos_ Emp_No, Hos_Emp_Name, Hos_Emp_Birthday Reseacher_Oid, Degree, Hospital_ Employee_Oid Technician_Oid, Skill, Hospital_ Employee_Oid Administrator_ Oid, Job, Hospital_ Employee_ Oid Project_Oid, Project_No, Project_Name Medical_Employee_Oid, Med_ Emp_No, Med_Emp_Name, Med_Emp_Birthday Hospital_Employee_Oid, Hos_ Emp_Telno Medical_Employee_Oid, Med_ Emp_Telno Department_Oid, Hospital_Employee_ Oid Hospital_Employee_Oid, Project_Oid Project_Oid, Medical_Employee_ Oid
Now we propose the schema transformation procedure step by step as follows: (a) Each class (named as C) is transformed to a relational table (denoted by R(C)). The object identifier of each object in the class corresponds to the primary key (PK) in the relation. Each instance of a class can be considered as a tuple of the relation. (b) In the inheritance hierarchy, a new attribute (i.e. the OID of the super-class) is added into the subclass, and it is used as a foreign key (FK) of the
sub-class to reference the super-class. (c) For non-reference attributes, they could be nonset attributes or set attributes. Each non-reference non-set attribute in a class is mapped to an attribute of the corresponding relation. However, a virtual relation is created for each non-reference set attribute. This virtual relation has two attributes, namely the OID of the enclosing class and the nonreference set attribute of the enclosing class. Those attributes form the primary key of the virtual relation. Finally, the set attribute is removed
Y.F. Huang and W.F. Kuo: The Query Translation between Object-oriented and Relational Databases
Depart_No
Depart_Name
DEPARTMENT 1
Emp_No
DEP_EMP
Emp_Name
M
Emp_Birthday
717
Emp_Telno
ADMINISTRATOR
EMPLOYEE Degree
TECHNICIAN
Job Skill
Order_No Order_Date
DOCTOR_ORDER
1
M
DOCTOR
DOCTOR_CHART
Chart_No
Order_Time
M Frequency
ORDER
M
1
ORDER_CHART
N CHART
Patient_No Patient_Name
Order_Qty
N Drug_No Base_Dose Generic_Name
Unit Drug_Qty
1
ORDER_DRUG
Depart_No
M
Section
DRUG
Usage_Medthod
Patient_Birthday
Reg_Date
CHART_REG
Patient_Telno
M REGISTRATION
Noon Seq_no
Fig. 2 Entity/relationship diagram of relational database DOCTOR_TREATMENT
from the original class. (d) For reference attributes, they could be non-set attributes or set attributes. For each reference nonset attribute incurred by “unidirectional reference” or one-to-one relationship, a new attribute (i.e. the OID of the referenced relation) is added into the referencing class, and it is used as a foreign key of the referencing relation to reference the referenced relation. As for the reference attribute (incurred by a one-to-many (a many-to-one) or a many-to-many relationship) and the reference set attribute (incurred by “unidirectional reference”), a new virtual relation R is created when class C1 contains a reference to a set of objects in class C2. The virtual relation R contains attributes such as OID of C1 and OID of C2. These two OID’s constitute the primary key of relation R, and each OID in the combination key is individually used as a foreign key of relation R to reference R(C1) and R(C2). Finally, the reference attribute is
Class DEPARTMENT EMPLOYEE
ADMINISTRATOR TECHNICIAN DOCTOR
ORDER
removed from the original class. 2. Transformation from Relational Schema to Object-oriented One In this section, we provide a mapping mechanism that transforms a relational schema to an object-oriented schema. The idea of the transformation is mostly according to Yu et al. (1995), yet we modify the transformation rule for binary many-to-many relationships, and complement two transformation rules for 1) many-to-one (or one-to-many) relationships and 2) the relation corresponding to a set attribute of an entity. Here an Entity/Relationship diagram shown in Fig. 2 is used to illustrate the schema transformation. This is a relational database DOCTOR_TREATMENT about the doctors and their medical treatments, and its relational schema can be transformed into the corresponding object-oriented schema as follows:
Attributes/References/Inheritances Depart_Oid, Depart_No, Depart_Name, Set Emp_No inverse EMPLOYEE::Depart_No Employee_Oid, Emp_No, Ref Depart_No inverse DEPARTMENT::Emp_No, Emp_Name, Emp_Birthday, Emp_Telno (set) Administrator_Oid, Ref Emp_No, Job Technician_Oid, Ref Emp_No, Skill Doctor_Oid, Ref Emp_No, Degree, Set Order_No inverse ORDER::Emp_No, Set Chart_No inverse CHART::Emp_No Order_Oid, Order_No, Ref Emp_No inverse DOCTOR::Order_No, Ref< CHART> Chart_No inverse
718
ORDER_DRUG
DRUG
CHART
REGISTRATION
Journal of the Chinese Institute of Engineers, Vol. 26, No. 5 (2003)
CHART::Order_No, Order_Date, Order_Time, Set Order_Drug inverse ORDER_DRUG::Order_No Order_Drug_Oid, Ref Order_No inverse ORDER::Order_Drug, Ref Drug_No inverse Drug::Order_Drug, Order_Qty, Frequency Drug_Oid, Drug_No, Base_Dose, Generic_Name, Unit, Drug_Qty, Usage_Method, SetOrder_Drug inverse ORDER_DRUG::Drug_No Chart_Oid, Chart_No, Patient_No, Patient_Name, Patient_Birthday, Set Reg inverse REGISTRATION::Chart_No, Patient_Telno (set) Registration_Oid, Reg_Date, Depart_No, Ref Chart_No inverse CHART::Reg, Section, Noon, Seq_No
Now we propose the schema transformation procedure as follows: (a) Each relation (named as R) is transformed to a class (denoted by C(R)). The OID is added as an attribute of the class by the way. Each tuple of a relation can be treated as an instance of the class, and the data type of a relation attribute becomes the domain class of the corresponding class attribute. (b) If relation R1 has a foreign key FK from relation R2, then change the domain class of FK to C(R2). If FK contains multiple attributes, then replace them with a single attribute. (c) For relations R1 and R2, if the entity type of relation R1 is a super-type of the entity type of relation R2, then C(R1) is a super-class of C(R2). All attributes except the OID of C(R1) will be removed from C(R2). (d) For relation R1 corresponding to a unary manyto-many relationship on an entity type E, if the relationship R1 does not have its own attribute, create two set attributes SA1 and SA2 for C(R(E)) and let C(R(E)) be the domain class of the two set attributes. Then discard C(R1). (e) For relation R1 corresponding to a binary manyto-many relationship between two entity type E1 and E2, if the relationship R1 does not have its own attribute, create a set attribute SA1 for C(R(E1)) with C(R(E2)) as its domain class, and a set attribute SA2 for C(R(E2)) with C(R(E1)) as its domain class. Then discard C(R1). If the relationship R1 has its own attribute, create a set attribute SA1 for C(R(E1)) with C(R1) as its domain class, and a set attribute SA2 for C(R(E2)) with C(R1) as its domain class. Then reserve C(R1). (f) For relation R1 having a many-to-one relationship with relation R2, create a set attribute SA for C(R2) with C(R1) as its domain class.
(g) For relation R corresponding to a set attribute of an entity E, create a set attribute SA for C(R(E)). Then discard C(R). III. QUERY TRANSLATION As mentioned in Section II, if a query issued by a user is not the same as the one supported by the underlying DBMS, we must provide the query translation to facilitate data access. As shown in Fig. 3, if the user issues a relational query to access an objectoriented database, the system will first validate the issued query for correctness according to the corresponding relational schema transformed in advance, and then perform the query translation from the relational query to the corresponding object-oriented one. 1. Translation from Relational Queries to Objectoriented Ones In query translation, Hsieh and Chang (1993) and Meng et al. (1993) proposed how a relational query is translated to an object-oriented query. In this section, the idea of the translation is mostly according to Hsieh and Chang (1993). First for the reference path C.r1.r2...rm.attr, the root must be identified in order to correctly identify attr. In order to maintain referential integrity constraints, we create an information base where referential information (i.e. Reference Table about Relationship, Reference Table about Inheritance, Reference Table about Reference, and Reference Closure Table) is stored. Next, for every attribute in the relational SQL SELECT query, we find its reference path. Any attribute with the same relation qualifier will have the same reference path. Each reference path is used to form the corresponding object SQL query. Examples for each reference table are shown as follows:
Y.F. Huang and W.F. Kuo: The Query Translation between Object-oriented and Relational Databases
Relational Users
Object Oriented Users
Input Object Oriented SQL
719
Validation
Corresponding Object Oriented Schema
Corresponding Relational Schema
Validation
Input Relational SQL
Query Translation From Relation To Object
Query Translation From Object To Relation
Relational DBMS
Relational Database
Object Oriented Database
Object Oriented DBMS
Results
Results
Fig. 3 Processing procedure of query translation
Class Reference Table about Relationship: Referencing class Relationship attribute DEPARTMENT Depart_Hos_Emp (set) Class Reference Table about Inheritance: Referencing class (Sub-class) HOSPITAL_RESEARCHER
Referenced class HOSPITAL_EMPLOYEE
Referenced class (Super-class) HOSPITAL_EMPLOYEE
Class Reference Table about “Reference”: Referencing class Reference attribute PROJECT Project_Members (set)
Referenced class MEDICAL_EMPLOYEEE
Finally a detailed translation example is shown as follows: Query 1. Select the project number joined by Mary. SQL: SELECT PROJECT.Project_No FROM PROJECT, PROJ_MED_EMP, MEDICAL_EMPLOYEE WHERE PROJECT.Project_Oid = PROJ_MED_EMP.Project_Oid And PROJ_MED_EMP.Medical_Employee_Oid = MEDICAL_EMPLOYEE.Medical_Employee_Oid And MEDICAL_EMPLOYEE.Med_Emp_Name = “Mary” OOSQL: SELECT PROJECT.Project_No FROM PROEJCT WHERE PROJECT.Project_Members.Med_Emp_Name = “Mary”
2. Translation from Object-oriented Queries to Relational Ones There have been a few papers investigating the query translation from an object-oriented query to a relational query (Kisworo and Rajagopalan, 1990; Yu et al., 1995). Here we propose a translation approach similar to the one presented by Hsieh and Chang
(1993). Translation from an OOSQL SELECT query to an SQL SELECT query can be viewed as finding the attributes and their corresponding relations, based on the reference path specified in the WHERE clause. Before query translation, two reference tables (i.e. Reference Table about Relationship, Reference Table about Inheritance) should be created. Examples for each reference table are shown as follows:
720
Journal of the Chinese Institute of Engineers, Vol. 26, No. 5 (2003)
Relation Reference Table about Relationship: Referencing relation Relationship attribute EMPLOYEE Depart_No
Referenced relation DEPARTMENT
Relation Reference Table about Inheritance: Referencing relation (Sub-class) Reference attribute DOCTOR Emp_No
The translation procedure from object-oriented queries to relational queries is to analyze the reference path specified in the WHERE clause. The root class of the reference path is assigned to the FROM clause of the relational SQL query. If the attribute specified in the reference path belongs to another class, search the referenced table about the relation-
Query 2. Select all drug names OOSQL: SELECT FROM WHERE SQL:
SELECT FROM WHERE
Reference attributes Emp_No, Depart_No
Referenced relation (Super-class) EMPLOYEE
ships (or the inheritances) based on the specified attribute. Then the predicate “Referencing-relation. Foreign-key = Referenced-relation.Primary-key” will be formed. Here the translation procedure from object-oriented queries to relational queries is omitted. Finally a detailed translation example is shown as follows:
whose order number is equal to “1234”. DRUG.Generic_Name DRUG DRUG.Order_Drug.Order_No = “1234” DRUG.Generic_Name DRUG, ORDER_DRUG, ORDER DRUG.Drug_No = ORDER_DRUG.Drug_No And ORDER_DRUG.Order_No = ORDER.Order_No And ORDER.Order_No = “1234”
IV. CONCLUSIONS To support the environment capable of accessing both different database systems using only one query type, we proposed schema transformation and query translation. In this work, we used Entity/Relationship model as a tool to describe the real world since Entity/Relationship model can be easily mapped to an object-oriented or relational schema according to the underlying DBMS. In the implementation, we carried out the query translation between OOSQL for WOO, an object-oriented database system developed at the Institute for the Information Industry, and SQL for the Microsoft FoxPro relational database system. These two systems co-exist in the LAN, and are constructed as a client-server architecture. REFERENCES Fitsilis, P., Gerogiannis, V., Kameas, A., and Pavlides, G., 1994, “Producing Relational Database Schemata from an Object Oriented Design,” Proceedings of the 20th EUROMICRO Conference on System Architecture and Integration, pp. 251-257.
Hsieh, S. Y., and Chang, C. K., 1993, “Capturing the Object-oriented Database Model in Relation Form,” Proceedings of the 17th Annual International Computer Software and Application Conference, pp. 202-208. Kisworo, M. W., and Rajagopalan, P., 1990, “Implementation of an Object-oriented Front-end to a Relation Database System,” Proceedings of the IEEE Region 10th Conference on Computer and Communication Systems, pp. 811-815. Meng, W., Yu, C., Kim, W., Wang, G., Pham, T., and Dao, S., 1993, “Construction of a Relational Front-end for Object-oriented Database Systems,” Proceedings of the 9th International Conference on Data Engineering, pp. 476-483. Yu, C., Zhang, Y., Meng, W., Kim, W., Wang, G., Pham, T., and Dao, S., 1995, “Translation of Object-oriented Queries to Relational Queries,” Proceedings of the 11th International Conference on Data Engineering, pp. 90-97. Manuscript Received: Mar. 23, 2001 Revision Received: Jan. 18, 2003 and Accepted: Mar. 21, 2003
