Mapping methods and query for aggregation and ... - User Web Pages

Mapping Methods and Query for Aggregation and Association in ObjectRelational Database using Collection Eric Pardede, J. Wenny Rahayu Dept. of Comp. Science & Comp. Engineering La Trobe University Bundoora VIC 3086, Australia {ekparded, wenny}@cs.latrobe.edu.au Abstract Association and aggregation are two relationship types in the Object-Oriented Conceptual Model (OOCM) that frequently involve collection of elements/attributes. However, very often when the relationships are stored in Object Relational Database (ORDB) the collection is flattened like it is implemented by pure relational model. In this paper we propose the mapping methods to preserve the collection semantics in ORDB using collection data type. In aggregation we propose methods for different constraints types, while in association we propose methods for “many” cardinality (1:N, N:N) relationships. In addition, we also show how queries can be performed in the relationships using collection type.

1. Introduction Object Relational Database (ORDB) is well known as the Relational Database (RDB) with the OO features. Most major Relational DBMS (RDBMS) vendors have now migrated toward an Object Relational DBMS (ORDBMS) [5]. Oracle 8.0, DB2 V5, and Informix US are three major commercial products that have shifted from pure RDBMS to the ORDBMS. This is the trend that will be followed by most RDBMS products. Many works have proposed the design methods for the ORDB, includes different relationship types such as association and aggregation. While an association is defined as a “reference” relationship between objects in a system, an aggregation is a tightly coupled form of association, in which a composite object (“whole”) consists of other component objects (“parts”) [11]. These relationships in OOCM involve collection of elements. However, the existing implementations transform the collection into flat relations and thus diminish the conceptual level semantic. With the existence of collection type in ORDB standardized in SQL4 [8], the collection semantic can be preserved. It is the aim of this paper to propose models for preserving collection in aggregation and association relationships into ORDB. For the purpose we introduce

David Taniar School of Business Systems Monash University Clayton VIC 3800, Australia [email protected] the use of collection type. We also propose the main queries required for the model.

2. Related work 2.1. Existing implementation of collection Some works have tried to preserve collection in aggregation hierarchy for ORDB. Very often the collection is either flattened or split into an entirely separate table. The most common practice of storing the aggregation is by separating the “part” collection in another table with composite Primary Keys (PK). This practice uses the OO paradigm for the conceptual modeling, while the implementation is purely relational [6, 1]. [7] stores the aggregation into nested table. It cannot represent the aggregation with non-shareable and existence-dependent constraints since the “part” collection is actually stored in a separate table. [10] uses index clustering for relationship that requires ordering semantic and nested table for the one who does not. However, same as [7] this work cannot be applicable for composition aggregation. For the association relationship, the usage of the collection is even more uncommon. [4] shows that database users still follow the pure relational model. In this case the “many” side will hold the reference to “one” side or another table is added to store the relationship. We find that the existing works have either not preserved the collection in the aggregation by separating the “part” from the “whole” components or have not considered the constraints. For the association relationship, in our best knowledge no works have maintained the collection in the ORDB.

2.2. ORDB collection type: an overview Collection types are formulated by Object Database Management Group (ODMG). The collections are composed of distinct elements, each of which can be of a simple data type, constructed data type or user-defined

Proceedings of the International Conference on Information Technology: Coding and Computing (ITCC’04) 0-7695-2108-8/04 $ 20.00 © 2004 IEEE

type [9]. An important distinguishing characteristic is that all collection elements must be of the same type [3]. ODMG has defined four collection types namely: sets, lists, arrays, and bag (multiset) [3]. However until the time of writing, SQL4 [8, 9] has only standardized two types, array and multiset. An array is a dynamically sized ordered collection that allows duplicates. A multiset is an unordered collection that allows duplicates.

Rule 1: For two classes namely C1 (A,B) and C2 (M,N), if C1 can be composed by more than one shareable and existence-independent C2, implement C2 as UDT collection attribute of table C1. Transformation result is n

Table C1 (A, B, UDT C2 (M, N)) 0

Class C1 A B

SQL Collection Syntax CREATE TABLE (att1 data_type CONSTRAINT attr1 PRIMARY KEY,..., att1+n ARRAY[NUMBER] ());

For simple data type, we can use the predefined type such as integer, char, etc. Collection can also be formed by a constructed data type. One of them that will be used in our proposed methods is the ROW type. It contains a sequence of attribute names and data types [5, 8]. SQL ROW Type Syntax CREATE TABLE (att1 data_type CONSTRAINT attr1 PRIMARY KEY,..., att1+m COLLECTION (ROW (att(1+m)(1) data_type,..., att(1+m)(1+n) data_type)));

Finally, we will also use user-defined type (UDT) inside the collection. We use this data type to accommodate the sharing constraints in an aggregation relationship.

TABLE C1 Att A Val A

Att B Val B

Coll. Att M Val M1 Val M2

C2 Att N Val N1 Val N2

1 General Syntax * Class C2 M N

CREATE TYPE (att1 data_type,... att1+m

data_type);

CREATE TABLE data_type, ...., (att1 att1+n MULTISET|ARRAY ROW ());

Figure 1. Aggregation type 1 Example 1: Type Staff is the aggregation of type Dependent (see Fig.2). The latter type can still exist outside type Staff, probably in type Student. The aggregation will be mapped as a collection of UDT. STAFF StaffID StaffName

1

*

DEPENDENT DepName DepAge

Figure 2. Aggregation type 1 example Transformation into ORDB:

SQL User-Defined Type Syntax CREATE TYPE (att1 data_type,... att1+n data_type); CREATE TABLE (att1 data_type, ...., att1+m MULTISET|ARRAY ());

3. Proposed method for aggregation In this section we propose the mapping methods of the collection in the aggregation relationship. To model the conceptual level, we use UML notation [2]. We map the “whole” class as the table and the “part” class as a collection of ROW or UDT.

3.1. Shareable and existence-independent aggregation In the first type, the “part” component is shareable and its existence is independent from the “whole” component. Therefore, we have to enable the “part” component to be accessed without firstly accessing the “whole” component. To meet the requirement, we use the collection of UDT.

CREATE TYPE DependentType (DepName CHARACTER VARYING(40), DepAge INTEGER)/ CREATE TABLE Staff (StaffID CHARACTER VARYING(5) CONSTRAINT StaffID_pk PRIMARY KEY, StaffName CHARACTER VARYING(40), Dependent MULTISET (DependentType));

The query cost with our method will be obviously smaller since we can eliminate or reduce the join operations. Nevertheless, the most important contribution is the fact of semantic preservation of the aggregation. In addition, with this method we can facilitate ordering semantic and allow duplication.

3.2. Non shareable and existence-dependent aggregation This type is frequently called composition. The “part” component is non-shareable and its existence is dependent to the “whole” component. We need to exclusively define the “part” component inside the “whole” component and for that reason we use the collection of ROW type. Rule2: For two classes namely C1 (A, B) and C2 (M,N), if C1 can be composed by more than one C2 in a

Proceedings of the International Conference on Information Technology: Coding and Computing (ITCC’04) 0-7695-2108-8/04 $ 20.00 © 2004 IEEE

composition aggregation, implement C2 as a ROW collection attribute of table C1. Transformation result is n

Table C1 (A, B, ROW C2 (M, N)) 0

Class C1 A B

Att A Val A

Att B Val B

1 *

TABLE C1 Coll.C2 Att M Att N Val M1 Val N1 Val M2 Val N2

General Syntax

Class C2 M N

CREATE TABLE (att1 data_type, ...., att1+n MULTISET|ARRAY ROW (C2att(1+n)(1) data_type,...., C2att(1+n)(1+m) data_type));

1

SUBJECT SubjectCode SubjectName

1

*

n 1

Example 2: Class Subject is the composition of two multiple classes Assignment and Exam (see Fig.4). The composition type will be mapped into a collection of ROW type in the ORDB table.

*

With the collection we can maintain the logical design in the implementation level. In usual practice, the mapping is not straight forward since the reference key will be located in the “many” side. Our method proposes a more straight forward mapping since the reference type is located as collection in the “one” side. Rule 3: For two classes namely C1 (A,B) and C2 (M,N), if C1 and C2 has 1:N association relationship, implement both as tables with C1 has a collection attribute refer to the keys of C2. Transformation result is Table C1 (A, B, C 2 _ Key ) and Table C2 (M, N)

Figure 3. Aggregation type 2

EXAM ExamDate ExamPercent

4.1. 1:N association

ASSIGNMENT AssignTitle AssignType

Figure 4. Aggregation type 2 example Transformation into ORDB: CREATE TABLE Subject (SubjectCode CHARACTER VARYING(5) CONSTRAINT SubjectCode_pk PRIMARY KEY, SubjectName CHARACTER VARYING(40), Assignment MULTISET (ROW (AssignTitle CHARACTER VARYING(40), AssignType CHARACTER VARYING(20)), Exam MULTISET (ROW (ExamDate DATE, ExamPercent INTEGER)));

The proposed method has captured the real semantic of a composition hierarchy. The “part” class is physically implemented inside the “whole” class. Hence, we avoid other classes to share the particular “part” class (nonshareable constraint). We also ensure that on removal of the “whole” class, we remove all “part” classes that are defined inside it (existence-dependent constraint).

4. Proposed method for association In this section we propose the mapping methods of the collection in the association relationship. We know that the association is differentiated by its cardinality: 1:1, 1:N, and N:N. Collection can only be utilized in the association that involves “many” cardinality.

Class C1 A B

Att A Val A

1

*

TABLE C1 Att B Coll. C2 Key Val B Val M1 Val M2

Class C2 M N TABLE Att M Val M1 Val M2

C2 Att N Val N1 Val N2

General Syntax CREATE TABLE (att1 data_type, ....,att1+m data_type); CREATE TABLE (att1 data_type, ...., att1+n MULTISET|ARRAY (C2 Key data_type));

Figure 5. 1:N association Example 3: Classes Faculty and Building have 1:N association relationship (see Fig.6). The reference attribute from the “one” to the “many” side will be mapped as a collection attribute in ORDB table. 1 FACULTY FacultyID FacultyName

* BUILDING BuildingID BuildingName

Figure 6. 1:N association example Transformation into ORDB: CREATE TABLE Building (BuildingID CHARACTER VARYING(5) CONSTRAINT BuildingID_pk PRIMARY KEY, BuildingName CHARACTER VARYING(40)); CREATE TABLE Faculty (FacultyID CHARACTER VARYING(5) CONSTRAINT FacultyID_pk PRIMARY KEY, FacultyName CHARACTER VARYING(50), BuildingID MULTISET(CHARACTER VARYING(5)));

The proposed method shows a novel approach of maintaining the collection semantic in 1:N association relationship. This will be most suitable for complex

Proceedings of the International Conference on Information Technology: Coding and Computing (ITCC’04) 0-7695-2108-8/04 $ 20.00 © 2004 IEEE

queries that involve collection and ordered predicates, which cannot be performed using traditional relational model. Our method can also gain benefit for tables that are frequently used for multiple-table-query and for relationship in which the “many” side is not very large.

4.2. N:N association In this type the reference can be stored as a collection inside one of the associated type (see Fig.7). With this proposed method we do not require to store the relationship in a separate table. Rule 4 For two classes namely C1 (A,B) and C2 (M,N) have N:N association relationship in C3 (X), implement C1 and C2 as tables with C1 has a collection of C3 and a reference to C2. Transformation results are Table C1 (A, B, n

ROW (C2 Key, C3 (X))) and Table C2 (M, N) 1

*

Class C1 A B

Att A Val A

* Class C3 X

Att B Val B

TABLE Att M Val M1 Val M2

Class C2 M N

TABLE C1 Coll. C2 Key and C3 C2 Key C3 Att X Val M1 Val X1 Val M2 Val X2

CREATE TABLE Subject (SubjectCode CHARACTER VARYING(5) CONSTRAINT SubjectCode_pk PRIMARY KEY, SubjectName CHARACTER VARYING(20)); CREATE TABLE Student (StudentID CHARACTER VARYING(5) CONSTRAINT StudentID_pk PRIMARY KEY, StudentName CHARACTER VARYING(20), SubjectTaken MULTISET(ROW (SubjectCode CHARACTER VARYING(5), Marks NUMBER(3)));

Like in the previous method, this method will be most suitable for complex queries that involve collection and ordered predicates. It can also gain benefit if the participating classes have different importance level and if the number of relationship attributes is not very large. Despite the benefits of our methods, we have a shortcoming of using the collection in the association relationship. At present, we cannot use SQL to embed integrity constraint checking in ORDB collection. As we know, in traditional methods we can include the foreign key or REF and then define the integrity constraint checking such as: on delete cascade, on update nullify, etc. We still cannot apply this for collection attribute. Nevertheless, it does not mean we cannot have integrity constraint checking for our methods. We still can use trigger or methods if the storage table is a typed table.

5. Queries for the proposed methods

General Syntax

C2 Att N Val N1 Val N2

CREATE TABLE (att1 data_type, ...., att1+m data_type);

CREATE TABLE data_type, ...., (att1 att1+n MULTISET|ARRAY ROW (C2 Key data_type, C3 att(1+n)(1) data_type,… C3 att(1+n)(1+o) data_type));

Figure 7. N:N association Example 4 Classes Student and Subject have N:N association relationship (see Fig.8). The reference of one class together with the relationships attributes will be mapped as a collection in another class table. STUDENT StudentID StudentName

Transformation into ORDB:

*

* SUBJECT SubjectCode SubjectName

ENROLMENT Marks

Figure 8. N:N association example

We describe two types of queries namely collection queries and non-collection queries. Collection query is query used to retrieve the information of the collection attributes with the selection predicates originated at the simple attributes. Non-collection query is query used to retrieve information of simple attributes with the selection predicates originated at the collection. The queries will be further down classified based on the data type of the collection (see Table. 1). Table 1. Query classification

QUERY TYPE

DATA TYPE Collection Query – Collection Query – Simple Data Type ROW & UDT Non-Collection Query Non-Collection Query – Simple Data Type – ROW & UDT

SQL provides double dot notation [5] to specify a subpart of a table such as ROW type or UDT. TABLE keyword is used to treat collection type as a table, allowing querying in the same way that any base table would be accessed. For the general syntax we will use certain name described in Fig 9.

Proceedings of the International Conference on Information Technology: Coding and Computing (ITCC’04) 0-7695-2108-8/04 $ 20.00 © 2004 IEEE

non-collection_attributes

owner_table

CREATE TABLE data_type, ...., (att1 att1+n MULTISET|ARRAY ROW (att(1+n)(1) data_type, ....)); collection_name

collection_attributes

Figure 9. Names for general query Collection Query – Simple Data Type: SELECT FROM WHERE Collection Query – ROW & UDT: SELECT FROM WHERE Non-Collection Query – Simple Data Type: SELECT FROM WHERE Non-Collection Query – ROW & UDT: SELECT FROM WHERE

An example of a collection query is to retrieve the assignment details of a given subject name (e.g. SubjectName = ‘Database Systems’). The SQL statement for this query is shown below. SELECT A..AssignTitle, A..AssignType FROM Subject S, TABLE(S.Assignment) A WHERE S.SubjectName = ‘Database Systems’;

An example of a non-collection query is to retrieve the subject name of a given exam date (e.g. ExamDate = ‘15/08/2003’). The SQL statement for this query is shown below. SELECT S.SubjectName FROM Subject S, TABLE(S.Exam) E WHERE E..ExamDate = TO_DATE (‘15/08/2003’, ‘DD/MM/YYYY’);

6. Conclusion In this paper we show how to maintain the collection semantics stated in the conceptual model into the implementation using ORDB. We propose the usage of collection type both for aggregation and association relationship. In the aggregation we differentiate the method based on the hierarchy constraints, while in the association we differentiate based on the cardinality. The proposed methods have given contributions to ORDB implementation. For the aggregation type, the methods have captured more semantics than the traditional mapping method. Now, instead of being implemented as a flat association, we can really accommodate the true semantics of an aggregation hierarchy. For the association, the proposed methods have added alternative implementation to the existing methods. These new methods can gain benefit for specific cases such as tables with collection and ordered query, etc. We also provide two main queries that can be used in our proposed methods. The queries are namely collection and non-collection queries. These queries are further classified based on the data type inside the collection.

7. References [1] S.W. Ambler, Mapping Objects to Relational Databases, Ambysoft Inc., 1997 [2] G. Booch, Object-Oriented Analysis and Design with Applications, Benjamin Cummings, 1997 [3] R.C.G. Cattell, (ed), The Object Database Standard: ODMG 2.0. Morgan Kaufmann, 1997 [4] R. Elmasri, and S.B. Navathe, Fundamentals of Database Systems. Addison Wesley, 2003 [5] P. Fortier, SQL3 Implementing the SQL Foundation Standard, McGraw Hill, 1999 [6] S.Y. Hsieh, and C.K. Chang, “Capturing The Object-oriented database Model in relational Form”. COMPSAC 1993, IEEE, 1993 [7] E. Marcos, B. Vela, J.M. Cavero, and P. Caceres, “Aggregation and Composition in Object-Relational Database Design”, ADBIS 2001, Springer, 2001, pp. 195-209 [8] J. Melton, (ed.), Database Language SQL – Part 2 Foundation, ISO-ANSI WD 9072-2, International Organization for Standardization, Working Group WG3, 2002 [9] E. Pardede, J.W. Rahayu, and D. Taniar, “New SQL Standard for Object-Relational Database Applications”, SIIT 2003, IEEE, 2003, pp.191-203 [10] J.W. Rahayu, and D. Taniar, “Preserving Aggregation in an Object-Relational DBMS”, ADVIS 2002, Springer, 2002, pp. 110 [11] J. Rumbaugh, et al, Object-Oriented modelling and design, Prentice Hall, 1991

Proceedings of the International Conference on Information Technology: Coding and Computing (ITCC’04) 0-7695-2108-8/04 $ 20.00 © 2004 IEEE