Database Design Language Incorporating Collection Types for Web Database Applications

Transcription

1 Database Design Language Incorporating Collection Types for Web Database Applications Eric Pardede, Wenny Rahayu Department of Computer Science La Trobe University Bundoora 3086 Australia David Taniar School of Business System Monash University PO BOX 63B, Clayton 3800 Australia KEYWORDS Database Design, Collection Types, Set, List, Bag, Database Design Language ABSTRACT As the most widely used data model, the relational data model has undergone extensions since it was first introduced. The motivation is mainly to increase the ability in capturing complex real world problems. The new era of Internet databases, which includes document meta-data repository and multi media databases have raised a need for more complex semantics of data modeling. Thus, the existing relational database design needs to be extended to capture more complex data structure. One of the data structures is represented by collection types in the attributes of an entity or relationship. With collection type, an attribute can be an atomic type, but also a non-atomic or complex type. The existence of collection type then has changed the whole design methods in relational databases. However, the relational model design has not captured the collection types. Thus, this paper proposes the new database design for the purpose. 1. INTRODUCTION Relational database (RDB) has been very useful for database purposes. However, many believe that this model does not have enough capability to capture the real world problem and thus need to be enriched with concepts from object-oriented database (OODB). One feature that has been introduced in RDB from object-oriented concepts is various data types. RDB attributes of normalized relations are nondecomposable and they tend to have simple data type. On the other side, OODB can support not only atomic data types, but also collection types (Cattell et al. 1997). This feature has emerged the needs for new database design in relational model using collection types. The aim of this paper is to propose an extension to RDB design as opposed to the existing design in OODB or existing implementation in Object Relational Database (ORDB). Even in ORDB, the implementation of few collection types is not supported by good design. There is need to extend the way in modeling the problem domain, so it can capture the new data structures correctly and efficiently. In this paper the design will focus on the database design language (DBDL), which is normally used to express the results of a database design. The proposed DBDL that focuses on collection types is very much suitable for web database applications, in which collections are naturally encountered. 2. THE NEED OF COLLECTION TYPES IN DATABASE FOR WEB APPLICATIONS The current implementation of collection types in XML schema and the need for meta-data repository are only few examples of the collection type significance in web database applications. Currently, the implementation of this feature still follows the traditional relational model and thus the efficiency and performance can become an issue. To demonstrate the current practice, an example is shown in figure 1. With a traditional implementation the association between and Reviewer tables will create another table Rate that stores the references to both tables as well as its own attribute, rating. rating rate name Reviewer contact Figure 1. Association Relationship in Traditional RDB

2 In this association, even a simple query like retrieving the ratings for a book and its particular reviewers will require join operation. In a mark up language like XML, each join will require an individual tedious code. It is very inefficient and one way to solve the problem is by enabling the tables to store the rating as collection type either as a list or a bag (because duplication will be very probable). Despite the increased of its implementation, specific design method on database using collection types has not been existed. It is true that some commercial relational DBMS have already applied the collection types for their products, but even so there are certain aspects of collection types that have not been covered. 3. CURRENT IMPLEMENTATION OF COLLECTION TYPES: STATE OF THE ART Despite the non-existence of a formal design method of collection type in a relational model, some relational DBMS products have provided features to implement collection type. One of the products that has been used in industry and in academic world is Oracle. Oracle 9i has improved the previous release by some additional features, including the collection type implementation, varray and nested table. Most of the additional were intended to access and manage the database using the style and the infrastructure of the Internet. That is why it gives a significance importance of database in Internet computing. Figure 2 shows the syntax and example of creating varray in Oracle9i. In the example Contacts is a collection of data type NUMBER. The collection then can be used as attribute like it is shown by Person table. General Syntax: CREATE [OR REPLACE] TYPE <object schema> AS VARRAY(n) OF (data typeobject); CREATE TABLE <table schema> attribute attribute type); Example: CREATE OR REPLACE TYPE Contacts AS VARRAY(3) OF NUMBER CREATE TABLE Person (person_id person_name person_contact VARCHAR2(10), VARCHAR2(20), Contacts); Figure 2. Oracle 9i Varray Type In Oracle, collections are means of storing a series of data entries that are jointly associated to a corresponding row in the database. Varrays are typically stored inline with respect to their containing row and are assigned an outer limit of values. The collections provided model a one-to-many relationship between a row and a collection without necessitating integrity constraints and a separate data structure (Dorsey and Hudicka 1999). On the other side, nested table is essentially an additional relational table and is not stored inline with the master table. Figure 3 shows the syntax and sample of creating nested table in Oracle9i. General Syntax: CREATE [OR REPLACE] TYPE <object schema> AS OBJECT attribute attribute type); CREATE [OR REPLACE] TYPE <object table schema> AS TABLE OF (object schema); CREATE TABLE <table schema> attribute attribute type, nested item object table schema); NESTED TABLE nested item STORE AS storage table schema (PRIMARY KEY (object table id;object type id)) ORGANIZATION INDEX); Example: CREATE OR REPLACE TYPE Person_Type AS OBJECT (person_id VARCHAR2(10), person_name VARCHAR2(30)) CREATE OR REPLACE TYPE Person_Table_Type AS TABLE OF Person_Type CREATE TABLE Course (course_id VARCHAR2(10), course_name VARCHAR2(20), lecturer Person_Table) NESTED TABLE lecturer STORE AS Person_tab( (PRIMARY KEY (nested_table_id, person_id)) ORGANIZATION INDEX); Figure 3. Oracle9i Nested Table An object type Person_Type is created with its attributes and an object table, Person_Table_Type is created as table of Person_Type. This object table can then be used as a column in a table. When a table type appears as the type of a column in a table or as an attribute of the underlying object type, Oracle stores all of the nested table data in a single table, which is associated with the enclosing table or object type. Every time users create a table with columns or column attributes whose type is nested table, users have to include nested table storage clause, NESTED TABLE (object table column schema) STORE AS followed by the separate storage table name.

3 The example of collection types implementation in figure 2 is actually the implementation of bag collection. Without primary key attached to the collection attributes, the duplication is allowed. On the other side, the nested table in figure 3 is now treated as set collection. The users will not be able to duplicate the person in lecturer attribute. The organization index is a facility in Oracle to sort the data in storage table based on the associated parent table. Sets are unordered collection of elements that do not allow duplicates. The objects that belong to a set are all unique. Figure 4 shows the object or entity with attribute, which is a collection of type set. A book can have several, but a duplication of author is not allowed. In addition the order of author for the book is not concerned. The curly bracket ({}) notation is used to represent sets collection like it is used in ODM. Out of three collection types mentioned before, Oracle can accommodate bags and sets implementation. At this stage, Oracle has not provided method to implement lists. {Author} Author name address contact The implementation of collection type in Oracle and other products have demonstrated the importance and usability of this complex data type. Nevertheless, no formal database design that captures the entire collection types has been proposed. 4. PROPOSED DATABASE DESIGN OF COLLECTION TYPE IN RELATIONAL MODEL In this section the proposed database design to relational model using collection types is provided. The design in this paper will cover the basic formulation of collection types and the DBDL as the language representation of the database design results Formulation of Traditional Relational Model Formulation of traditional relational model is well known since the model was introduced. A simplified formulation involving relations, attributes, domains, tuples, and the keys are described below. Let R be a relation scheme with a finite set of attributes A {A 1, A 2,,A n } and D is the domain of these attributes where D = D 1 D 2 D n. Note that the domain in traditional relational model has atomic restriction. Each attribute A i corresponds to the domain D i where 1 i n. On R, let r be a relation that is a finite set of tuples or set of mapping {t 1, t 2,, t p } from R to D with restriction that for each mapping t r, t(a i ) must be in D i, 1 i n. Let I {I 1, I 2, I m } be the identifiers of a set of objects and the constraint is that I j I k for j N Formulation of New Relational Model incorporating Collection Types The Object Database Management Standard has defined four collection types, namely: sets, lists, arrays, and bags (Cattell et al. 1997). Figure 4. Set Collection Type The formulation of relational model with set collection types in some level has similarity to the traditional relational model formulation. The only difference is that the Domain D has no atomic restriction like in the previous example, where is a set of values of name, address, and contact. Note that the implementation of set collection type does not straightforwardly resemble the traditional relational model implementation, as in the traditional relational model the set has to be implemented as different relation and thus the original relation is flattened. Next collection type, lists are ordered collections of elements that allow duplicates. Similar to the concept of list, arrays are dynamically sized ordered collections that allow duplicates. The main difference between a list and an array is in the method used to store the pointers that assign the next element. Since the difference is from the implementation point of view, both will have the same design procedures. Figure 5 shows the object or entity Borrower with attribute borrower_book, which is a list. A borrower can borrow several books in a span of time. The order of the books borrowed has to be kept and the borrower can borrow the same book several times. The square bracket ([ ]) notation is used to represent lists collection. Borrower borrower_no borrower_name borrower_book borrower_book [] Figure 5. List Collection Type The formulation of relational model with list collection types will change the traditional formulation. Like in set, the domain D will allow non-atomic values. In addition, the key or identifier formulation will have to be changed. In listarray, I {I 1, I 2,, I k,, I m-1, I m }

4 are the identifiers of a listarray of objects and the constraint is that ϑ [ I j, (I 1..m I j ))] (m j where k is the insertion order,ϑ is the number of elements in a listarray, and I j {I 1, I 2,, I m }. The last collection type is bags. A bag is an unordered collection that allows duplicates. Figure 6 shows the renewed object with attribute book_rating, which is a bag. A book can have similar ratings without concerning the order of the ratings. The angle brackets (<>) notation is used to represent sets collection. book_rating book_rating <> Figure 6. Bag Collection Type Rating point comment Like in the previous collection types, if bags are allowed, the domain D will allow non-atomic values. In addition, the key or identifier formulation will have to be changed. In Bag, I {I 1, I 2,, I m } are the identifiers of a bag of objects and the constraint is that ϑ [ I j, (I 1..m I j ))] (m j ZKHUHϑ is the number of elements in a bag, and I j {I 1, I 2,, I m } Database Design Language incorporating Collection Types In relational model, the result of mapping and normalization is basically a list of relational tables that conforms to a certain level of normal forms. These tables however do not allow the designer to include details of various design constraints or issues that are essential to a good design, such as primary and foreign keys, nulls, integrity constraints, etc (Pratt and Adamski 1994). Therefore a specific language is needed to express the results of database design and it is called Database Design Language (DBDL). In relational model, DBDL will focus on the table descriptions including attributes, keys, domains, and referential integrity treatment for database. In this research, DBDL can be used as the starting point of designing the collection types in the RDB, before full research on logical and physical design can be conducted. Most designers put concern on the conceptual, logical, and physical database design for their main interests. There are not many literatures found mentioning DBDL although the purpose is profound. With the foundation from previous research (Pratt and Adamski 1994), we propose a set of rules that can be applied to every type of domains for every type of collection attribute. The rules are described below: 1. Relation and its attributes are represented in the format of Table Name(A 1, A 2,, A n ) 2. Set collection attributes are represented using curly brackets, e.g. Table Name(A 1, {A 2, {A 21, A 22,, A 2m }},, A n ) 3. List collection attributes are represented using square brackets, e.g. Table Name(A 1, [A 2, [A 21, A 22,, A 2m ]],, A n ) 4. Bag collection attributes are represented using angle brackets, e.g. Table Name(A 1, <A 2, <A 21, A 22,, A 2m >>,, A n ) 5. Attributes that are allowed to be null are followed by an asterisk (*). An asterisk on a collection attribute applied to every sub-attributes of the particular attribute, e.g. Table Name(A 1, {A 2, {A 21, A 22,, A 2m } * },, A * n ) 6. Primary keys are identified by the underline, e.g. Table Name(A 1, A 2,, A n ) 7. Collection keys are identified by the dotted underline, e.g. Table Name(A 1, {A 2, {A 21, A 22,, A 2m }},, A n ) 8. Collection keys with index are identified by the dotted underline and super-script i after the attribute, e.g. Table Name(A 1, [A i 2, [A i 21, A 22,, A 2m ]],, A n ) 9. Alternative keys are identified by the letters AK followed by the attribute(s) that comprise the alternative key 10. Secondary keys are identified by the letters SK followed by the attribute(s) that comprise the secondary key 11. Foreign keys are identified by the letters FK followed by the attributes that comprise the foreign keys. These attributes are followed by an arrow pointing to the relation identified by the foreign key, which is the parent relation. After the parent relation name, determine the keys (including primary keys and collection keys where applicable) and the actual attribute being referred, e.g. FK referencing-attribute Table Name (PK, CK1, CK2, referenced-attribute) 12. The rules for maintaining the integrity constraints are specified after the foreign keys declaration mentioned before. After determining the referenced attributes, the action to anticipate update and delete operations are specified, following these rules: a) For delete action: DLT NLS (delete nullifies), DLT RSTR (delete restricted), DLT CSCD, (delete cascades) b) For update action: UPD NLS (update nullifies), UPD RSTR (update restricted), UPD CSCD (update cascades) To demonstrate the use of DBDL an example is provided in figure 7. The DBDL is applied for the Student table, given two other tables Faculty, and Department to display the relationship.

5 Given: Faculty (faculty-number, faculty-name, {degree-code, degree-name, degreelength}) Department (dept-number, dept-name, dept-head) Detailed relation: Student (student-number, student-name, address *, dept-number, {degree}, {subject, {assignment-name, assignment-mark}, {exam-no, exammark}} *, ) AK SK student-name FK dept-number Department (dept-number) DLT RSTR UPD CSCD degree Faculty (facultynumber, degree-code, degreename) DLT RSTR UPD CSCD Figure 7. DBDL Example The simple language for Student table captures the whole design result of the table including the design constraints. This table can be interpreted as follows. Table Table Student has attributes listed with studentnumber as the primary key (underlined) Table Student has two set collection types degree and subject, shown by the curly brackets. The latter has sub-collection inside it Table Student has four collection keys, degree, subject, assignment-name, exam-no, indicate by the dotted underlines Attributes Attribute address and all collection on subject may accept nulls indicated by the asterisks Attribute is another possible key, shown by the symbol AK Attribute student-name is a secondary key, shown by the symbol SK Attribute dept-number is a foreign key pointing to the Department table that has dept-number as primary key and also the attribute being referenced, indicated by the symbol FK Attribute degree is a foreign key pointing to the Faculty table, both are collection attributes. Notice that after the table name, the primary key and collection key have to be specified first before specifying the actual attribute being referred Update of dept-number in Department and degreename in Faculty may be updated and be cascaded in Student (UPD CSCD) 5. CONCLUSIONS AND FUTURE WORK This paper proposes a database design in relational model using collection types. Despite its increasing usage, there is no formal design on database using collection type. Although there are some relational DBMS products have implemented a few of the collection types, the implementation is not accompanied by standardized design. This is the main motivation of the research. This work is just a beginning of series of potential work. They include further design steps that have not been covered in this paper such as the transformation method of the collection into relations, the normalization, and the integrity constraint issue of the collection types. Other potential researches are the query language for the database incorporating collection types and the implementation of the design to the full database application using complete set of collection like it has been performed in OODB. REFERENCES Cattell, R.C.G. (ed.) The Object Database Standard: ODMG 2.0, Morgan Kaufmann Publisher, Inc. Dorsey, P. and J. Hudicka Oracle 8 Design Using UML Object Modelling, Oracle Press, Osborne McGraw Hill Elmasri, R. and S.B. Navathe Fundamentals of Database Systems, 3 rd ed., Addison Wesley Pratt, P.J. and J.J. Adamski Database System: Management and Design, Boyd & Fraser Publishing Co. Boston Operations Deletion of a department is restricted if any student exist (DLT RSTR) and deletion of a degree is restricted if any student exists with the particular degree