Ref:/ISORC01
OBJECTS COLLECTION MANAGEMENT IN MULTIDIMENSIONAL DBMS DATA MODEL
Tong-Ming, Lim and Sai-Peck, Lee
Faculty of Computer Science and Information Technology
University Of Malaya
50603, Kuala Lumpur, Malaysia.
Fax : 603-7579249
email:saipeck@fsktm.um.edu.my
ABSTRACT :
Multidimensional DBMS data model basically is a nested relational DBMS that has been made available since 1970 by PICK Inc. USA. Multidimensional DBMS data model has strong flexibility in data management such as variable length field, variable length record, nested relational tables and a rich set of database management functions. In this paper, the design of object collections such as Set, Bag, List and Array will be proposed in order to demonstrate the mechanism of mapping onto the multidimensional DBMS data model. Many aspects of design considerations must be taken into account such as mapping mechanisms and rules of mapping, due to the fact that existing DBMS model by nature does not have built in object management rules and mechanisms at all. The mapping of object collections type onto multidimensional DBMS data model will also be discussed so as to provide communication mechanism to accommodate and maintain Set, Bag, List and Array object collection types.
KEYWORDS : D3 Item, multivalue, Object ID, Collection object type
1. INTRODUCTION
A D3 multidimensional DBMS [11] has a strong property of flexible field length, variable record structure, unstructured data type, nested table within table as well as multi operating system platform support.
A record is an item in D3. An item could contain virtually unlimited number of attributes (or fields). A D3 attribute is a field or a column in a flat 2-dimensional relational data model environment. Within an attribute of an item, it is possible to embed another table in it. A 1-to-many or parent-child table relation is automatically established in the D3 multidimensional DBMS data model. This provides a well-built referential integrity with a 1-to-many table relationship. A good example is an invoice with many invoice item detail. This also provides one disk read access to the database instead of conventional relational data model where a minimum of 2 disk read accesses to obtain a complete piece of information from the database.
An object is mapped onto a D3 multidimensional DBMS as an item. Each data member and member function of an object is mapped onto the D3 multidimensional DBMS as an attribute. The key of an item could be either a hashed item id or primary key of an item. A hashed item id for an item is obtained from the D3 multidimensional DBMS built-in hashing routine. A primary key for an item is the key field of an item that is used to identify an item in a D3 multidimensional DBMS. This will allow efficient access of an object or item in the D3 multidimensional DBMS environment.
The following is an example of a simple Class Customer that maps to a D3 Class customer item and a Customer object that is mapped onto a D3 customer item. The following example demonstrate a simple direct class and object mapping that does not consider other details such as inheritance property. Detail will be discussed in the next section.
The class Customer contains a name field of type character and an address field of type character. The class customer also contain a show_address method that returns a character string (Figure 1.0). In Figure 2.0, two variable of type Class Customer are created. In Figure 3.0, two objects are created using class Customer. Both objects are initialized. Data member within the ACustomer and BCustomer objects are assigned with appropriate values(Figure 3.0).
Class Customer {
char *name;
char *address;
public:
char * show_address();
}; | |
Figure 1.0
customer ACustomer, BCustomer, | |
Figure 2.0
ACustomer = New customer of size X;
BCustomer = New customer of size X;
ACustomer.name = “Mr. John Master”
ACustomer.address = “143, Penang Street, Penang”
BCustomer.name = “Ms. Silver John”
BCustomer.address = “4A, Jalan Petaling Jaya, KL” | |
Figure 3.0
D3 customer class item
name address
VARCHAR VARCHAR
CHAR CHAR
show_address()
()
X777 | |
Figure 4.0
D3 customer item with Item ID = “0310”
“Mr. John Master” “143, Penang Street, Penang” | |
D3 customer item with Item ID = “0010”
“Ms. Silver John” “4A, Jalan Petaling Jaya,KL” | |
Figure 5.0
The class Customer is mapped onto a D3 customer class item which contains detail of data member name such as name and address. Second attribute contains length of data member. Third attribute contains type of data. Attribute one to three could contains virtually unlimited nested information. Member functions detail are recorded in attribute four, five and six. Attribute four records name of function. Attribute five contains parameter list and attribute six contains executable absolute address. The next section onward, a much more detail mapping discussion will be presented.
2. OBJECT STRUCTURE AND REQUIREMENTS
An object consists of not only data members , it also contains member function or method. A member function for an object must be capable of performing a basic function. Some basic functions of an object are delete an object, duplicate an object, compare two different objects and locking an object. An object must have these stated methods built-in. As a result, an object class by default must contain a few primitive member functions defined (Figure 2.0 and Figure 3.0). As an object is created, it could have its own additional member functions with its inherited built-in functionality. As each object is mapped onto a D3 multidimensional DBMS as an item, the said four basic functions must also be able to be implemented as the most fundamental D3 item management capability (Figure 1.0). D3 multidimensional DBMS fortunately have some powerful built in database management functions such as copy an item, delete an item and locking an item.
The built-in functions or methods for an object are as follow.
The method, _CP_delete_item(int expression, CPSTR* string), allows the deletion of an item in D3 multidimensional DBMS. The expression is actually a file handler and the string is actually the item’s hashed ID (or an object ID) or the item ID. It returns a positive integer, if it succeeds, otherwise it returns -1.
The method, _CP_lock(int type, int expression) , where the type could either be a _CP_LOCK or _CP_LOCK_W lock type and the expression is 1 for a simple basic lock. It returns positive integer if it is successful, otherwise it returns -1.
The method, _CP_copy_item(int expression1, int expression2, CPSTR* string), where expression1 is a source file handler, expression2 is the destination file handler and the string is the key of a record to be copied. It returns positive integer if it is successful, otherwise it returns -1.
The method, _CP_compare_item(int expression1, CPSTR* string1 , int expression2, CPSTR* string2) , where expression1 is a source file handler, string1 is item id , expression2 is the destination file handler and string2 is the item id for expression2. It returns a positive integer if they are identical, otherwise it returns a -1.
A D3 class item structure representation for an object mapping requirement is as below.
| The address of the parent class |
|The name of data member The name of data member . . . The name of data member |
|Length of the data member Length of the data member . . . Length of the data member |
|Data type of the item data member Data type of the item data member . . Data type of the item data member |
|The name of member function The name of member function . . . The name of member function |
|The parameter type list of member function . . . The parameter type list of member function |
|The execution address of member function . . . The execution address of member function |
Figure 6.0
In the D3 item environment, an item must keep up with its parent’s class address (refer to Figure 6.0). The objective of keeping its parent’s class address is to be able to refer to its parent item. This allow an item to inherit all its parent’s characteristics. The data members and member functions of an object must be mapped onto an item structure in D3 environment. Each data member will keep up with its data member name, its data length and data type in attribute two, three and four respectively. Each attribute in the D3 item could contain virtually unlimited number of values in it (represented by symbol). All data member’s detail also store in the item. Each member function, function name, parameter type list and execution address are kept in attribute five, six and seven respectively. The proposed D3 item structure will allow all detail of an object to be properly kept up with (Figure 6.0).
An object data model supports simple literal, atomic object and collection of objects. It is important to provide some means so that have D3 multidimensional DBMS would be able to manage simple object as well as collection of objects type. A simple object mapping to an item in D3 multidimensional DBMS is a straight forward direct object-item mapping process. The management of an object ID as an item ID, either using a primary key or a hashed ID, will be able to manage all objects created utilizing the underneath database management services. For example, the object data model by ODMG [1], it proposes Set, Bag, List, Array and Dictionary collection object types as part of the standard object type implementation. Hence, it is important to discuss and design the necessary mechanisms required for Set, Bag, List and Array to be mapped successfully onto the D3 multidimensional DBMS. In this paper, Dictionary object type will not be discussed.
As an object is defined in an application, it will inherit all the basic properties of the basic object’s data members and member functions. Let’s take an example of a customer class (Figure 7.0 and Figure 8.0).
|Class basic_object { |
|. . . |
|_CP_compare_item(. . . ); |
|_CP_delete_item(. . .); |
|_CP_lock(. . .); |
|_CP_copy_item(. . .); |
|. . . |
|}; |
Figure 7.0
|Class customer : basic_object { |
|char *name; |
|char *address; |
|. . . |
|char * show_address(); |
|. . . |
|}; |
Figure 8.0
As an application object is being defined and initiated, it will inherit all the basic member functions from the basic_object class definition. The next important design considerations to be discussed here is the mechanisms required for the mapping of inherited properties in the context of a D3 multidimensional DBMS[11] , [16].
3. INHERITED PROPERTIES MAPPING MANAGEMENT IN D3 MULTIDIMENSIONAL DBMS
An object class is required to referred back to its parent class in order to inherit the parent class‘s properties. In Figure 9.0, it shows a D3 item representation for an object and in Figure 10.0, a customer item in D3 inherits all the basic_object’s characteristics besides having it’s own characteristics. A good example to illustrate this concept is to use the class customer show above (Figure 8.0) with the proposed D3 item structure shown in Figure 9.0 and 10.0.
|D3 basic_object class item |
|The address of parent class |
|The name of data member . . . The name of data member |
|The length of data member . . . The length of data member |
|The data type of data member . . . The data type of data member |
|member function _CP_compare_item(. . . ); |
|member function _CP_delete_item(. . .); |
|member function _CP_lock(. . .); |
|member function _CP_copy_item(. . .); |
|_CP_compare_item parameter list ; |
|_CP_delete_item parameter list ; |
|_CP_lock parameter list ; |
|_CP_copy_item parameter list ; |
|_CP_compare_item executable address in memory; |
|_CP_delete_item executable address in memory; |
|_CP_lock executable address in memory; |
|_CP_copy_item executable address in memory; |
Figure 9.0
|D3 customer class item |
|basic_object address as the parent class of customer class |
|The name data member The address data member |
|Variable field length for name Variable field length for address |
|Char type for name Char type for address |
|member function show_address() |
|show_address() parameter list |
|show_address() executable address |
Figure 10.0
Let’s create two separate object variables of type customer class such as Acustomer and Bcustomer. An object could be copied from one to another as shown below utilizing the built in methods such as _CP_copy_item .
Acustomer object is copied from variable Acustomer to variable Bcustomer by firing the member function _CP_copy_item(. . .). In the D3 basic_object item in the D3 environment. The same applied to others methods in the basic_object class defined above. This example successfully demonstrate the capability of mapping an object described in an object-oriented programming environment to D3 multidimensional DBMS environment [11].
4. COLLECTION OBJECT TYPES
A collection of object type such as Set, Bag, List or Array is actually an object generator in which the generator is responsible of generating objects of a defined type. Each generator will generate a number of objects for a collection object type which manage all the objects created. Each collection object type has its own characteristics.
A Set object collection type is a generator which generate objects of the same type. A Set object type is an unordered collection of elements which does not allow duplication at all.
A Bag object collection type is an unordered collection of objects that may contain duplicates. On the other hand, an Array object type is a dynamically sized ordered collection of objects that can be located by position while List object type is an ordered collection of objects it does not allow duplication. To allow D3 multidimensional DBMS to manage well each object collection type, it is essential to have a well-defined mapping mechanisms in order to manage the objects in each collection type.
4.1. SET IMPLEMENTATION UTILIZING D3 DATA MODEL
A Set collection object type [1] is managed by a Set header item in D3 multidimensional DBMS. The item ID of the Set header item is the name of the Set. Each object that belong to that Set will be inserted into the D3 multidimensional DBMS as an item. The object ID for an object will be the item ID for an item in D3. The item ID will be mapped on to the Set header item in D3 multidimensional DBMS. Each Set header item is actually a D3 item that is used to manage all item IDs of a Set. The Set header item in D3 multidimensional DBMS has a Set object ID field in the Set header item which manages all the object IDs of objects. The Set object ID field is defined as an multivalue field. A multivalue field is a field in D3 multidimensional DBMS which is capable of storing virtually unlimited number of values. A multivalue field is viewed as an embedded table within the Set header item. Each object ID is inserted into the Set object ID field if it is a new object. If it is an existing object ID, no insertion will take place. Each newly created object‘s object ID will be appended to the Set object ID field. D3 database functions provide the ability to append an item into the Set object ID field easily. As to traverse through the Set object ID field, D3 multidimensional DBMS also provides a sequential iterating mechanisms, as a result, all object IDs in the Set object ID could be traversed from the first value to the last value as well as from last value back to the first value. Another important features of a Set collection type is the requirement of none duplicating object IDs within the Set object ID field. D3 multidimensional DBMS has a built-in functionality to detect whether an item has already existed or it has never existed yet. D3 multidimensional DBMS provides a Locate built in database function to find or locate to see whether a value has already existed or not.
A collection object type is basically a revolution from an object type and all collection object types primitively inherit all object properties. In D3 multidimensional DBMS, a Basic_Collection_Type item is defined as shown which contains some basic member functions and data members described above.
|Basic_Collection class inherits from Class basic_object |
|Return_type _CP_is_empty_(. . .); |
|Return_type _CP_is_ordered_(. . .); |
|Return_type _CP_insert_(. . .); |
|Return_type _CP_delete_(. . .); |
|. . . ; |
Figure 11.0
The Basic_Collection class is defined as a template class which provide all the basic methods as well as all the necessary data members. The defined Basic_Collection class is mapped onto a Basic_Collection item in D3 environment to store all the necessary detail of a Basic_Collection class detail .
|Basic_Collection item |
|The Basic_Object address |
|Return_type _CP_is_empty_(. . .); |
|Return_type _CP_is_ordered_(. . .); |
|Return_type _CP_insert_(. . .); |
|Return_type _CP_delete_(. . .); |
|. . . ; |
Figure 12.0
The Basic_Collection item will consist of a few fundamental properties that any collection object type would required. Member functions such as _CP_is_empty_(. . .), _CP_is_ordered_(. . .), _CP_insert_(. . .) and _CP_delete_(. . .) which permits basic operations to be carried out on to any collection type items in D3 multidimensional DBMS environment.
To perform Set operations, here is some methods that must be provided to the management of items in a Set besides inheriting all properties from objects and collection types described.
|Basic_Set item in D3 |
|The Basic_Collection item address |
|Return_type _CP_insert_(. . .); |
|Return_type _CP_delete_(. . .); |
|Return_type _CP_locate_(. . .); |
|Return_type _CP_union_(. . .); |
|Return_type _CP_intersection_(. . .); |
|Return_type _CP_differences_(. . .); |
|. . . ; |
Figure 13.0
| Set_Header item in D3 |
|Set item multivalue nested table structure containing all application Set items’ item IDs |
Figure 14.0
The Set_Header item is used to manage all the operations described above. As an application Set is defined such as customer Set, it will inherits all the Basic_Set item’s capability. The following is an example that illustrate the management of a customer Set_Header item in D3 environment.
|Set_Header Customer item in D3 |
|ID100 ID300 ID200 |
A Set_Header Customer item is created to manage all Customer class’s items.
The Set_Header Customer will check whether the object IDs or item IDs exist using _CP_locate_(. . .). If it does not exist, the _CP_insert_(. . .) is used to insert the item into the Set_Header‘s first attribute which contains a list of object IDs.
|D3 Customer class item |
|basic_object address as the parent class of customer class |
|name address |
|VARCHAR VARCHAR |
|CHAR CHAR |
|show_address show_name |
|(CHAR *) (CHAR *) |
|X777 X666 |
Customer class item is created.
|D3 Customer item with hashed ID = “ID100” |
|basic_object address |
|“John” “Jalan Melawati, 56000, KL,Malaysia” |
Object ID100 is created.
|D3 Customer item with hashed ID = “ID300” |
|basic_object address |
|“Tom” “Happy garden, 67000, Cheras,Malaysia” |
Object ID300 is created.
|D3 Customer item with hashed ID = “ID200” |
|basic_object address |
|“Abu Bakar” “Melawati Lane, 61000, KL,Malaysia” |
Object ID200 is created.
4.2. BAG IMPLEMENTATION UTILIZING D3 DATA MODEL
A Bag collection type consists of a Bag_Header D3 item which is used to manage all items that is defined for a Bag collection type [1]. A Bag_Header item takes the following format. A Bag collection type is used to keep a collection of identical unordered object that allow duplication. A Bag collection type could be used to store car and time management clock-in information.
|Basic_Bag item in D3 |
|The Basic_Collection item address |
|Return_type _CP_union_(. . .); |
|Return_type _CP_intersection_(. . .); |
|Return_type _CP_differences_(. . .); |
|. . . ; |
Figure 15.0
| Bag_Header item in D3 |
|Bag item multivalue nested table structure containing all application Bag items’ item IDs |
Figure 16.0
The following example will demonstrate a Bag collection type which mnage car information.
|Bag_Header Car item in D3 |
|PROD1 PROD7 PROD3 |
A Bag_Header Car item is created to manage all Car class’s items.
The Bag_Header Car will use _CP_insert_(. . .) insert the car item into the Bag_Header‘s first attribute which contains a list of object IDs.
|D3 Car class item |
|basic_object address as the parent class of car class |
|chassis no_of_wheels engine_type |
|VARCHAR 4 VARCHAR |
|CHAR INT CHAR |
|show_yearmade show_description |
|(CHAR *) (CHAR *) |
|X777 X666 |
Car class item is created.
|D3 Car item with hashed ID = “PROD1” |
|basic_object address |
|“sedan” 4 “Engine1” |
Object PROD1 is created.
|D3 Car item with hashed ID = “ID300” |
|basic_object address |
|“sedan” 4 “Engine1” |
Object PROD7 is created.
|D3 Car item with hashed ID = “ID200” |
|basic_object address |
|“sedan” 4 “Engine1” |
Object PROD3 is created.
4.3. ARRAY IMPLEMENTATION UTILIZING D3 DATA MODEL
In the Array collection type, an Array_Header item in D3 is used to manage all items that is defined for a Array collection type [1]. A Array_Header item takes the following format.
|Basic_Array class inherits from Basic_Collection class ‘s properties |
|Return_type _CP_replace_at(. . .); |
|Return_type _CP_delete_at(. . .); |
|Return_type _CP_locate_at(. . .); |
|Return_type _CP_resize_(. . .); |
|. . . ; |
Figure 17.0
|Basic_Array item in D3 |
|Whatever Basic_Collction item address is |
|Return_type _CP_replace_at(. . .); |
|Return_type _CP_delete_at(. . .); |
|Return_type _CP_locate_at(. . .); |
|Return_type _CP_resize_(. . .); |
|. . . ; |
Figure 18.0
|Array_Header item in D3 |
|Array item multivalue nested table structure containing all application Array items’ item IDs |
Figure 19.0
An Array collection object type operates differently. It is an ordered collection of elements but it could resize dynamically on the fly. A good implementation of Array collection type is to manage frequency of hits per wed page.
4.4. LIST IMPLEMENTATION UTILIZING D3 DATA MODEL
As for a List collection type, a List_Header item in D3 is used to manage all items that is defined for a List collection type. A List_Header item takes the following format. A List object type is an ordered collection of elements which could either insert or remove an item or an object at a particular position, retrieve or store an item or object before or after a certain position in a List collection type.
|Basic_List class inherits from Basic_Collection class ‘s properties |
|Return_type _CP_replace_at(. . .); |
|Return_type _CP_delete_first(. . .); |
|Return_type _CP_delete_last(. . .); |
|Return_type _CP_delete_at(. . .); |
|Return_type _CP_locate_first(. . .); |
|Return_type _CP_locate_last(. . .); |
|Return_type _CP_locate_at(. . .); |
|Return_type _CP_insert_first_(. . .); |
|Return_type _CP_insert_last_(. . .); |
|Return_type _CP_insert_before_(. . .); |
|Return_type _CP_insert_after_(. . .); |
|Return_type _CP_append(. . .); |
|Return_type _CP_concat(. . .); |
|. . . ; |
Figure 20.0
The Basic_List class ‘s detail is mapped directly onto the Basic_List item in D3. It contains all the defined data members and member functions of a defined class described above. +
|Basic_List item in D3 |
|Whatever Basic_Collction item address is |
|Return_type _CP_replace_at(. . .); |
|Return_type _CP_delete_first(. . .); |
|Return_type _CP_delete_last(. . .); |
|Return_type _CP_delete_at(. . .); |
|Return_type _CP_locate_first(. . .); |
|Return_type _CP_locate_last(. . .); |
|Return_type _CP_locate_at(. . .); |
|Return_type _CP_insert_first_(. . .); |
|Return_type _CP_insert_last_(. . .); |
|Return_type _CP_insert_before_(. . .); |
|Return_type _CP_insert_after_(. . .); |
|Return_type _CP_append(. . .); |
|Return_type _CP_concat(. . .); |
|. . . ; |
Figure 21.0
|List_Header item in D3 |
|List item multivalue nested table structure containing all application List items’ item IDs |
Figure 22.0
The Basic_List [1] item defined in D3 multidimensional DBMS environment is used to store and manage all objects created in the object oriented programming environment. The List_Header item is maintained in D3 multidimensional DBMS to keep track of all objects that defined for this List. A multivalue field is used to maintain all the object ID s or item ID s in order to facilitate all the defined operations described above. In order to be able to replace, delete, insert and locate easily , a nested single field is used to keep track of all the objects or items in the database.
5. CONCLUDING REMARK AND OBSERVATION
A D3 header item is not enough to execute such an implementation. For example, if a picture is to consist of million of objects of pixels and colors, any collection object type would collapse if the database used does not support a super fast and efficient storing, locating and retrieving mechanisms in the database management system. Some new techniques and approaches must be devised in order to obtain an acceptable database management system to implement the proposed collection type. In D3 multidimensional DBMS, the existing database engine is not in the first place being designed to implement objects orientation concepts, as a result, if an object layer is to laid on top of the existing D3 DBMS or on to any other 2-dimension flat table DBMS, a newly device DBMS items searching, storing and locating algorithms must be found to achieve acceptable performance to implement objects management. A lot more research is required in order to ensure great practicality is achieved in the application of object database management in the real life world.
REFERENCES
1. R.G.G. Cattell and Douglas K. Barry , The Object Database Standard ODMG 2.0, Morgan Kaufmann Publishers Inc. San Francisco, California
2. Alfons Kemper and Guido Moerkotte , Object Oriented Database Management, Application in Engineering And Computer Science, Prentice Hall International publication
3. Stephen Kurtzman and Kayshav Dattatri. Object-oriented wrappers for the Mach Microkernel, ROAD magazine, May-June 1996
4. Mark Roy and Alan Ewald. Interworking COM with CORBA, OBJECT magazine, May 1996
5. Joshua Duhl. Integrating objects with relational data : architectural approaches, OBJECT magazine, May 1996
6. Douglas Barry. ODBMSs and complex data, OBJECT magazine, May 1996
7. Kumar Vadaparty. Programmer’ sinterface to Persistence_in_ODBMSs , Journal of object oriented programming, May 1996
8. Stanley B. Lippman. C++ Primer 2nd edition, Addison Wesley, 1993
9. Thomas J. Mowbray and Raphael C. Malweau. CORBA design patterns, John Wiley and Sons. Inc. , 1997
10. Simon J. Gibbs and Dionysios C. Tsichritzis. Multimedia Programming, Objects, Environments and Frameworks, Addison Wesley , 1995
11. Advanced PICK reference manual, Version 2.0, PICK SYSTEM , 1995
12. Roger J. Bourdon. Advanced Pick . Open database and Operating system, Addison Wesley , 1996
13. F. Bancilhon. Object Database Systems : the ODMG Standard. O2 technology Technical report No. 12, 1994
14. F. Ferrandina T. Meyer R. Zicari G. Ferran J. Madec. Schema and Database Evolution in the O2 object database system, O2 technology, Technical report No. 17, 1995
15. F. Bancilhon G. Ferran. ODMG-93: the object database standard, O2 technology, Technical report No. 11, 1994
16. F. Bancilhon G. Ferran. Object databases and the ODMG Standard, O2 technology, Technical report No. 15, 1995
17. C. Delobel C. Souza D. Tallot. Object Views of Relations., O2 technology, Technical report No. 19, 1995
18. Won Kim. Modem database systems. The object model, interoperability, and beyond. Addison Wesley. , 1995
TO : Professor Insup Lee
Department Of Computer and Information Science
University Of Pennsylvania
Philadelphia PA 19104-6389.
United Of America
(For 1st IEEE International Symposium on Object Oriented Real-time Distributed Computing)
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.