Database Design Language Incorporating Collection Typesfor Web Database Applications

Eric PardedeWenny Rahayu

David Taniar

Bandung, 11 September 2002

Structure of Presentation Background Collection Types Current Standard/Products Proposed Database Design Language Example Conclusion and Future Work

Background Relational database (RDB) has been extended to capture

complex data structure in real world problem. One of them is by adding the collection types

In web database application, current implementation of collection types in XML schema and the need for meta-data repository are few examples of the collection type significance

Currently, the implementation of this feature still follows the traditional relational model and thus the efficiency and performance can become an issue

Background (2)

Traditional: Book (isbn, title); Reviewer (name, contact)Rate (isbn, name, rating)

Book Reviewerrate

rating

contact

name

title

isbn

Background (3)

With Collection: Book (isbn, title, set (name, rating)); Reviewer (name, contact)

Book Reviewerrate

rating

contact

name

title

isbn

Background(4) Although Object-Relational Database (ORDB)

accommodate them, the implementation of few collection types is not supported by good design

There is necessity to extend the way in modeling the problem domain, so it can capture the new data structures correctly and efficiently

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 ORDB

Collection Types A set is unordered collection of elements that do not allow

duplicates. The objects that belong to a set are all unique.

authors {Author}Book

titleisbnauthors

Author

nameaddresscontact

Collection Types (2) A list is ordered collections of elements that allows

duplicates

borrower_book [Book]

Book

titleisbnauthors

Borrower

borrower_noborrower_nameborrower_book

Collection Types (3) A Bag is an unordered collection that allows duplicates

book_rating<Rating>

Book

titleisbnauthorsbook_rating

Rating

pointcomment

Collection Types in Current Database Standard/Products SQL3 as new standard database language has provided

few collection types and also proposed foundation for full collection types in SQL4

Some DBMS products (such as Oracle 9i, Informix, etc) has implemented collection types for relational model in their ORDB products

Collection Types in Current Database Standard/Products (2) Existing SQL3:

Table-Name (attribute1 DATATYPE, attribute2 DATATYPE ARRAY(N));

SQL3 Proposal:Table-Name (attribute1 DATATYPE,

attribute2 LIST(DATATYPE))

Collection Types in Current Database Standard/Products (3) Existing Oracle9i:

Set ExampleTable-Name

(attribute DATATYPE, attribute nested_table_type)

Nested Table <attribute name> STORE AS <nested table name>(

(PRIMARY KEY (IDs)) ORGANIZATION INDEX);

Proposed Database Design In relational model, the result of design processes is a list

of 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

Database Design Language (DBDL) is needed to express the results of database design, including the attributes, keys, domains, referential integrity treatment, etc.

In this research, DBDL is used as the starting point of designing the collection types in the RDB, before full research on conceptual and logical design is done

Database Design Language1. Relation and its attributes are represented in the format

of Table Name(A1, A2,…, An)2. Set collection attributes are represented using curly

brackets, e.g. Table Name(A1, {A2, {A21, A22, …, A2m}},…, An)

3. List collection attributes are represented using square brackets, e.g. Table Name(A1, [A2, [A21, A22, …, A2m]],…, An)

4. Bag collection attributes are represented using angle brackets, e.g. Table Name(A1, <A2, <A21, A22, …, A2m>>,…, An)

Database Design Language (2)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(A1, {A2, {A21, A22, …, A2m}*},…, An*)

6. Primary keys are identified by the underline, e.g. Table

Name(A1, A2,…, An)

7. Collection keys are identified by the dotted underline, e.g. Table Name(A1, {A2, {A21, A22, …, A2m}},…, An)

Database Design Language (3)8. Collection keys with index are identified by the dotted

underline and super-script i after the attribute, e.g. Table Name(A1, [A2i, [A21i, A22, …, A2m]],…, An)

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

Database Design Language (4)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. After the parent relation name, determine the keys (including primary keys and collection keys where applicable) and the actual attribute being referred,

FK referencing-attribute

Table Name (PK, CK, referenced-attribute)

Database Design Language (5)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:

For delete action: DLT NLS (delete nullifies), DLT RSTR (delete restricted), DLT CSCD, (delete cascades)

For update action: UPD NLS (update nullifies), UPD RSTR (update restricted), UPD CSCD (update cascades)

ExampleGiven Relation:Faculty (faculty-number, faculty-name,

{degree-code, degree-name, degree-length})Department (dept-number, dept-name, dept-head)

Detail Relation:Student (stu-number, stu-name, address*, dept-number, {degree},

{subject, {assign-name, assign-mark}, {exam-no, exam-mark}}*, email)

AK email

FK dept-number Department (dept-number) DLT RSTR UPD CSCDdegree Faculty (fac-id, deg-code, deg-name) DLT RSTR UPD CSCD

Example (2)Relation:Student (stu-number, stu-name, address*, dept-number, {degree},

{subject, {assign-name, assign-mark}, {exam-no, exam-mark}}*, email)

Table

Table Student has attributes listed with stu-number 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, assign-name, exam-no, indicate by the dotted underlines

Example (3)Relation:Student (stu-number, stu-name, address*, dept-number, {degree},

{subject, {assign-name, assign-mark}, {exam-no, exam-mark}}*, email)

AK email

Attributes (1) Attribute address and all collection on subject may accept nulls

indicated by the asterisks Attribute email is another possible key, shown by the symbol AK

Example (4)Relation:Student (stu-number, stu-name, address*, dept-number, {degree},

{subject, {assign-name, assign-mark}, {exam-no, exam-mark}}*, email)

FK dept-number Department (dept-number) DLT RSTR UPD CSCDdegree Faculty (fac-id, deg-code, deg-name) DLT RSTR UPD CSCD

Attributes (2) Attribute dept-number is a foreign key pointing to the Department table

that has dept-number as the attribute being referenced Attribute degree is a foreign key pointing to the Faculty table. Notice the

primary key and collection key have to be specified first before specifying the actual attribute being referred

Example (5)Relation:FK dept-number Department (dept-number) DLT RSTR UPD CSCD

degree Faculty (fac-id, deg-code, deg-name) DLT RSTR UPD CSCD

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

Update of dept-number in Department and degree-name in Faculty may be updated and be cascaded in Student (UPD CSCD)

Conclusion and Future Work This paper proposes a database design, focusing in

Database Design Language, for relational model using collection types due to the inexistence of standardized design for relational model using collection types

Further work includes further design steps such as the transformation method of the collection into relations, the normalization, and the integrity constraint issue of the collection types