ࡱ> zakW7{y3T( TD( / 00DArialngs(0(z[ 0 DVerdanas(0(z[ 0 " DTimes New Roman(0(z[ 0 0DWingdingsRoman(0(z[ 0  A .  @n?" dd@  @@`` t-   HG    () >>,,HH 5.. //**21 _ `a ghijk lnrswxyz|} ~ /X$r$kW7{y3Ti 0AA@8\]ʚ;ʚ;g42d2d@z[ 0lppp@ <4ddddl 0d g4KdKd@z[ 0$p@ pp<4BdBdl 0d80___PPT10 ?  %O  =7VDatabase Design Language Incorporating Collection Types for Web Database Applications  WxV&Eric Pardede Wenny Rahayu David Taniar''PStructure of Presentation{Background Collection Types Current Standard/Products Proposed Database Design Language Example Conclusion and Future Work||8 BackgroundRelational 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 issueBackground (2)WTraditional: Book (isbn, title); Reviewer (name, contact) Rate (isbn, name, rating)#5   ,,#Background (3)ZWith Collection: Book (isbn, title, set (name, rating)); Reviewer (name, contact)X;  ? 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 ORDB2Collection TypesxA set is unordered collection of elements that do not allow duplicates. The objects that belong to a set are all unique.yy3Collection Types (2)@A list is ordered collections of elements that allows duplicatesAA6Collection Types (3)7A Bag is an unordered collection that allows duplicates886Collection Types in Current Database Standard/Products77" 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)) `JEJED U,:Collection Types in Current Database Standard/Products (3);;"Existing Oracle9i: Set Example Table-Name (attribute DATATYPE, attribute nested_table_type) Nested Table STORE AS ( (PRIMARY KEY (IDs)) ORGANIZATION INDEX);0.OE( Proposed Database DesignLIn 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 doneMxMDatabase Design Language~1. 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)r0@I.K.I. Database Design Language (2)B5. 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)016  @ " 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 key0V   , h "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)2jOjODatabase 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 CSCD degree Faculty (fac-id, deg-code, deg-name) DLT RSTR UPD CSCDR0  ^   + 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^0I   x ' / $^   s * Example (3)IRelation: 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 AK00    61L   }  Example (4)eRelation: 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 CSCD degree 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+0;0     " H"^   , <% 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)0     # :  X,    Conclusion and Future WorkThis 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 / !" $ & ' ( )+-4579O  ` !3̙` Q.<ffff3` 3333fff` 3K=̙fff` 3fffff` ff3ff3` aNR>ff` 3fY33` 3f3f>?" dd@&?oAd(@n<)o<6=nA+7%Z', n?" dd@   @@``PR   = 7 ,`(p>> |(  | | <{ #" `j  T Click to edit Master title style! !$ | 0T~ "Pe  RClick to edit Master text styles Second level Third level Fourth level Fifth level!     SpB | # ܃BCE6FGIIQU*VWX @`@$ G"  B0 `B | s *Dg "00 | 0p "^`  \*  | 0d "^   ^*  | 0 "^   ^*  | dA"޽h ?Light horizontal"` 3f3f___PPT10i. "+D=' = @B + Profile \ C(    < #" `p d T Click to edit Master title style! !  0 "p`  d W#Click to edit Master subtitle style$ $  0  "`` a \*   0p$d "`  d ^*   0\#d "`  d ^* pB  # ,dBCE6FGjIQU*VWX @`@$ G") B0   dA"޽h ?Light horizontal"` 3f3f___PPT10i. "+D=' = @B +\ 0  *(    0س P    X*   0     Z* d  c $ ?    0d  0  RClick to edit Master text styles Second level Third level Fourth level Fifth level!     S  6 _P   X*   6 _   Z* H  0޽h ? 3380___PPT10.6K~]K0  (  x  c $5d d x  c $l6d@  d   <7d   xBandung, 11 September 2002x"  H  0޽h ? 33___PPT10i.Ku`+D=' = @B +} \  $(  r   S d|j  d r   S d|Pe d H  0޽h ? 3f3f___PPT10i.K`>]+D=' = @B + \  p0(  px p c $qd|j  d x p c $qd|Pe d H p 0޽h ? 3f3f___PPT10i.K`>]+D=' = @B +  \   T (  x  c $̄d|j  d x  c $d| e d Z   #" @   S d(k"` z DBook$    c $Ld(k"`jz HReviewer$   B  # dM x Brate"  HB B C D \ HB  B C D[2   S (d "`M  Hrating&  HB   C D  2   S  "`jx Gcontact$  2   S d "`j Dname$  HB  C DIIHB  C DII2  S d"`x  Etitle$  2  S $d"`  ^isbn$  HB  C DHB  C DH  0޽h ? 3f3f___PPT10i.K`>]+D=' = @B +  \    pT (  x  c $d|j  d x  c $d| e d Z   #" @   S d(k"` z DBook$    c $d(k"`jz HReviewer$   B  # M x Brate"  HB B C D \ HB  B C D[2   S  "`M  Hrating&  HB   C D  2   S   "`jx Gcontact$  2   S D "`j Dname$  HB  C DIIHB  C DII2  S "`x  Etitle$  2  S "`  ^isbn$  HB  C DHB  C DH  0޽h ? 3f3f___PPT10i.K`>]+D=' = @B + \ p0(  x  c $ &|j   x  c $&|Pe`  H  0޽h ? 3f3f___PPT10i.K`>]+D=' = @B +f \ }u` X (  Xx X c $ 8|j   x X c $8|Pe`P  Z ` i X #" @  X 3 :X"`) ` w Cauthors {Author}  T u   X# s i X # T?Xu   lBook title isbn authors   HB X C DuM  N HB  X C Du# $h %  X# #" 1` V  X # @ X% NAuthor name address contact HB  X C D%/0HB  X C D%ZB X s *D1H X 0޽h ? 3f3f___PPT10i.K`>]+D=' = @B + \  `((  `x ` c $N|j   x ` c $T|Pe`   Z (~ ` #"   ` 3 lV`"`T& oborrower_book [Book] $    N (~ ` (~h u   `# #" _%(~ ` # p\`"`u   lBook title isbn authors   HB ` C DuM  N HB ` C Du# $h 0  `# #" \ ~ ` 3 _`"`0  1Borrower borrower_no borrower_name borrower_book2 2>   HB ` C D09 9 HB ` C D0  ZB ` s *D<)% H ` 0޽h ? 3f3f___PPT10i.K`>]+D=' = @B +< \ SK h(  hx h c $S|j   x h c $d|Pe` d Z =0O|6 h #" `@0  h C h"` 1o4 bbook_rating    yb =0O|6 h #" =0O|6h 0M z h# #" =0Z |6 h # |h0M z $Book title isbn authors book_rating% %,  HB h C D0M HB h C D0^M _h % h# #" 0O4 h 3 dh"`% GRating point comment HB h C D%HB h C D%ZB h s *D) <14H h 0޽h ? 3f3f___PPT10i.K`>]+D=' = @B + \  p0(  x  c $|j   x  c $|Pe  H  0޽h ? 3f3f___PPT10i.K`>]+D=' = @B + \ 80(  8x 8 c $|j   x 8 c $D|Pe  H 8 0޽h ? 3f3f___PPT10i.K`>]+D=' = @B + \  @0(  @x @ c $p|j   x @ c $|Pe  H @ 0޽h ? 3f3f___PPT10i.K`>]+D=' = @B + \  0(  x  c $|j   x  c $h|Pe  H  0޽h ? 3f3f___PPT10i.K`>]+D=' = @B + \ B(  x  c $t|j     c $|Pe`   8haQH  0޽h ? 3f3f___PPT10i.K`>]+D=' = @B +g \ ~v(  x  c $|j     c $ 3a|Pe`   8haQ^B  6D8cY # Y ^B  6D8cP P H  0޽h ? 3f3f___PPT10i.K`>]+D=' = @B +g \ ~v (  x  c $L|j     c $DYa|Pe   8haQ^B   6D8cc ^B   6D8c% F %H  0޽h ? 3f3f___PPT10i.K`>]+D=' = @B +W \ nf(  x  c $H|j     c $T|Pe   8haQf 5  C"_ HB  C D//HB  C DMMHB  C D-0NB  S ZD@5H  0޽h ? 3f3f___PPT10i.K`>]+D=' = @B + \ B(  x  c $`"|j     c $+|Pe   8haQH  0޽h ? 3f3f___PPT10i.K`>]+D=' = @B + \ @(  x  c $>|j   x  c $p?|Pe  f 5  C" yHB  C D//HB  C DMMHB  C D-0NB   S ZD@5f 5   C" 0  HB   C D//HB   C DMMHB   C D-0NB  S ZD@5^B  6D8c 8 ^B  6D8cj J`j ^B  6D8c  ^B  6D8c Z H  0޽h ? 3f3f___PPT10i.K`>]+D=' = @B +! \ 800 (   x   c $H|j   x   c $PI|Pe`  ^B   6D8c8^B   6D8cJ`^B   6D8c ^B   6D8c0Z0H   0޽h ? 3f3f___PPT10i.K`>]+D=' = @B +! \ 80(  x  c $xa|j  a x  c $ya|Pe a ^B  6D8c,^B  6D8c>T^B  6D8c ^B  6D8cNH  0޽h ? 3f3f___PPT10i.K`>]+D=' = @B + \  P@(  x  c $^|j   x  c $h_| e  f 5  C"  HB  C D//HB  C DMMHB  C D-0NB  S ZD@5f 5   C"=9)HB   C D//HB   C DMMHB   C D-0NB   S ZD@5^B  6D8c8^B  6D8cb>Tb^B  6D8c ^B  6D8cZH  0޽h ? 3f3f___PPT10i.K`>]+D=' = @B + \   $(  $x $ c $e|j   x $ c $hf|Pe  f 5 $ C"cHB $ C D//HB $ C DMMHB $ C D-0NB $ S ZD@5f 5  $ C"9)*HB  $ C D//HB  $ C DMMHB  $ C D-0NB  $ S ZD@5H $ 0޽h ? 3f3f___PPT10i.K`>]+D=' = @B + \ 0(  x  c $8d|j   x  c $d|Pe d H  0޽h ? 3f3f___PPT10i.K`>]+D=' = @B +* 0 0:(  X  C      S  0V  >6___PPT9 Relational data model has undergone extensions since it was first introduced 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. 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 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. 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.>Z   H  0޽h ? 3380___PPT10.6Kpń4 0 D(  ^  S      c $ 0T  <4___PPT9 Relational data model has undergone extensions since it was first introduced 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. 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 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. 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.>Z   H  0޽h ? 3380___PPT10.6Kpń4 0 D(  ^  S      c $h( 0T  <4___PPT9 Relational data model has undergone extensions since it was first introduced 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. 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 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. 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.>Z   H  0޽h ? 3380___PPT10.6KpńY  0 i(  X  C      S 08 0   kTable Table Student has attributes listed with student-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, 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 email is another possible key, shown by the symbol AK 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 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) F     '        /          %      6  ;  "  y  "            #   < S  E  H  0޽h ? 3380___PPT10.OKPS$e  0  u(  ^  S      c $ts 0   kTable Table Student has attributes listed with student-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, 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 email is another possible key, shown by the symbol AK 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 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) F     '        /          %      6  ;  "  y  "            #   < S  E  H  0޽h ? 3380___PPT10.OKPS$e  0 @u(  ^  S      c $( 0   kTable Table Student has attributes listed with student-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, 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 email is another possible key, shown by the symbol AK 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 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) F     '        /          %      6  ;  "  y  "            #   < S  E  H  0޽h ? 3380___PPT10.OKPS$e  0 `u(  ^  S      c $$ 0   kTable Table Student has attributes listed with student-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, 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 email is another possible key, shown by the symbol AK 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 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) F     '        /          %      6  ;  "  y  "            #   < S  E  H  0޽h ? 3380___PPT10.OKPS$4 0  D(   ^   S       c $a 0T  <4___PPT9 Relational data model has undergone extensions since it was first introduced 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. 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 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. 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.>Z   H   0޽h ? 3380___PPT10.6Kpńe  0 (u(  (^ ( S     ( c $p 0   kTable Table Student has attributes listed with student-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, 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 email is another possible key, shown by the symbol AK 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 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) F     '        /          %      6  ;  "  y  "            #   < S  E  H ( 0޽h ? 3380___PPT10.OKPS$  0 ,(  ,X , C     , S T 0    H , 0޽h ? 3380___PPT10.$L8UB  0 0(  0X 0 C     0 S  0    H 0 0޽h ? 3380___PPT10.$Lt4C  0 4(  4X 4 C     4 S t 0    H 4 0޽h ? 3380___PPT10.$LY 0 <((  <^ < S     < c $ 0    H < 0޽h ? 3380___PPT10.$Lt4C 0  D((  D^ D S     D c $ 0    H D 0޽h ? 3380___PPT10.$Lt4C6 0 p \F(  \^ \ S     \ c $ 0V  >6___PPT9 Relational data model has undergone extensions since it was first introduced 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. 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 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. 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.>Z   H \ 0޽h ? 3380___PPT10.6Kpń6 0  dF(  d^ d S     d c $ 0V  >6___PPT9 Relational data model has undergone extensions since it was first introduced 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. 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 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. 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.>Z   H d 0޽h ? 3380___PPT10.6Kpń6 0  lF(  l^ l S     l c $4 0V  >6___PPT9 Relational data model has undergone extensions since it was first introduced 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. 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 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. 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.>Z   H l 0޽h ? 3380___PPT10.6Kpń4 0  tD(  t^ t S     t c $h( 0T  <4___PPT9 Relational data model has undergone extensions since it was first introduced 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. 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 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. 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.>Z   H t 0޽h ? 3380___PPT10.6Kpńr\DP^PbOc X|pfg;a-V vr  "-$&2aφ)F0X7d>? E9AOh+'0H hp  Slide 1Eric 1Profilerevile34iMicrosoft PowerPointP@>wT@3K@ i"G6 g  B  -B( -- @ !--'-- @ ! K----%K--'@"Verdana-. B2 cU'Database Design Language Incorporating    ."System-@"Verdana-. 2 UCollection Types  .-@"Verdana-. 32 Ufor Web Database Applications '  .-@"Verdana-. 2 Eric n  .-@"Verdana-. 2 Pardede.-@"Verdana-. 2 XlWennyd'.-@"Verdana-. 2 XRahayu.-@"Verdana-. 2 David  .-@"Verdana-. 2 Taniar .-@"Verdana-. 2 keBandung.-@"Verdana-. $2 k, 11 September 2002    .-՜.+,0    AOn-screen Shown-sV&A ArialVerdanaTimes New Roman WingdingsProfileWDatabase Design Language Incorporating Collection Types for Web Database Applications Structure of Presentation BackgroundBackground (2)Background (3)Background(4)Collection TypesCollection Types (2)Collection Types (3)7Collection Types in Current Database Standard/Products;Collection Types in Current Database Standard/Products (2);Collection Types in Current Database Standard/Products (3)Proposed Database DesignDatabase Design LanguageDatabase Design Language (2)Database Design Language (3)Database Design Language (4)Database Design Language (5)Example Example (2) Example (3) Example (4) Example (5)Conclusion and Future Work  Fonts UsedDesign Template Slide Titles_Frevirevi  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~Root EntrydO)PicturesCurrent UserSummaryInformation(PowerPoint Document(FDocumentSummaryInformation8