Opaque types

Details Opaque types Opaque types

2000-07-31

2002-10-22

Shah, Sanjiv (Department: 2172)

Data processing: database and file management or data structures

Database design

Data structure types

C707S793000

Reexamination Certificate

active

06470348

ABSTRACT:

FIELD OF THE INVENTION
The present invention relates to database systems and, more specifically, to the use of user-defined data types within database systems.
BACKGROUND OF THE INVENTION
Typically, data items are stored on non-volatile memory in a different way than they are stored in volatile memory. Thus, when loaded into volatile memory from non-volatile memory, some conversion operation must be performed. Similarly, when stored back onto non-volatile memory from volatile memory, another conversion operation must be performed. For the purpose of explanation, the process of converting data from a volatile format to a non-volatile format is referred to herein as “pickling” the data item, and the process of converting data from a non-volatile format to a volatile format is referred to herein as “unpickling” the data item.
Many conventional relational database systems perform automatic pickling and unpickling for only a few types of data. The types of data supported by such systems typically include scalar types, such as numbers and dates. Relative to other programming environments, such as “C” and “Java”, the set of data types supported by typical database systems is extremely limited. Thus, difficulties arise when the database systems are used to store data that is created and used by computer programs that were written in those other environments.
For example, a user may create a set of routines that represent and manipulate data using a complex user-defined data type (“TYPE
1
”). For the purpose of illustration, the user-implemented routines that use TYPE
1
are collectively referred to herein as APP
1
.
The structure of TYPE
1
, or any of the attributes thereof, may be significantly different than the structure of any data type supported by a database system (“DBS
1
”). To pass the data used by APP
1
to a database managed by DBS
1
, every TYPE
1
data item must be converted to one or more instances of the data types that are supported by DBS
1
. Once the data is converted to data types that DBS
1
understands and supports, DBS
1
can store and retrieve the data from disk. Likewise, for APP
1
to use data from DBS
1
, the data must be converted from the structure associated with the data types supported by DBS
1
into the structure and format associated with TYPE
1
.
Referring to
FIG. 1
, it is a block diagram illustrating the conversion operations that must be performed to allow APP
1
to store its data within DBS
1
. Specifically, a data item generated within APP
1
is stored according to the structure and format of user TYPE
1
. To pass the data item into DBS
1
for storage, the data item is converted to a data type supported by DBS
1
(DBTYPE
1
). While in volatile memory within DBS
1
, the data item is stored as an unpickled DBTYPE
1
. DBS
1
pickles the DBTYPE
1
data item to store it on disk.
To supply APP
1
with a data item stored on disk, DBS
1
unpickles the data item to create an unpickled DBTYPE
1
data item. The unpickled DBTYPE
1
data item is then converted to the user TYPE
1
data type before being supplied to the routines within APP
1
that manipulate the data item.
An example of a user-defined type is a type declared as follows:
struct TYPE
1
{
int i;
char *s;
}
This declaration may occur, for example, within the source code of APP
1
. The source code of APP
1
also includes one or more methods used to manipulate data that is stored in a TYPE
1
data structure. An example of the interface to such method is:
my_method(TYPE
1
*me, int i);
A TYPE
1
data item may be passed into DBS
1
by mapping the attributes of TYPE
1
to data types that are supported by DBS
1
, such as Number and Date. An example of a statement to create a database object for storing data from a TYPE
1
data item is:
create type DBTYPE
1
as OBJECT
(
a Number;
b Date;
memberprocedure.set_date();
To convert data between the TYPE
1
structure used by APP
1
and the DBTYPE
1
structure used within DBS
1
to store TYPE
1
data, the following structure may be used:
struct
{
OCINumber n;
OCIDate d;
}
In this example, it was assumed that the attributes of TYPE
1
could be adequately represented by data types supported by DBS
1
. However, data types designed and implemented in common programming languages (such as C or Java) are not easily captured by the database system because their internal structures are modeled using the particular constructs of the language, and are not understood by the database system.
Object oriented databases are tightly coupled to a particular programming language and, even though they enable modeling of data types in that language, the flexibility of language neutrality in the database system is lost. For example, if DBS
1
is designed around the same language as was used to create APP
1
, then DBS
1
may support the TYPE
1
data type. But if, on the other hand, DBS
1
is designed around a different language than was used to create APP
1
, complicated conversions may still be necessary.
To reduce the burden associated with converting user-defined types whose attributes do not closely correspond to data types supported by a database system, some database systems support a “RAW” data type. From the perspective of the database system, a RAW data item is simply a dump of bytes with no structure. As with other database-supported data types, RAW data items may be stored in the columns of relational tables. Because the database system does not assume any structure to a RAW data item, the RAW data item may be used to store the data for complex user-defined data types that have attributes that are not easily converted to any data type supported by the database system.
The following statements create a table with a RAW column that can be used, for example, for storing data from a TYPE
1
data items.
create table t
(coll raw(
20
), . . . );
The following statement creates a routine that is internal to the database for invoking the external my_method routine:
create procedure mymethod(a IN RAW)
The input to this internal routine is a RAW data item, while the external my method routine expects a TYPE
1
data item. Consequently, the implementation of the mymethod procedure must take the form:
mymethod(a)
{
raw-to-struct(a)
manipulate
struct-to-raw(a)
}
In this example, the mymethod routine receives a RAW data item “a”. The raw-to-struct(a) statement invokes a user-supplied routine that converts the data item from the RAW format used by the database to store the data item to the TYPE
1
format used by APP
1
. The “manipulate” statement generally represents calls to user-supplied routines that manipulate the TYPE
1
data item. After the desired operations have been performed on the data item, the call to struct-to-raw(a) converts the data item from the TYPE
1
structure back to the RAW format used by the database.
Referring to
FIG. 2
, it is a block diagram illustrating the conversion operations that must be performed to allow APP
1
to store its data within a database (DBS
1
) that supports the RAW data type. Specifically, a data item generated within APP
1
is formatted according as “user type
1
”. To pass the data item into DBS
1
for storage, the data item is converted to the RAW data type. While in volatile memory within DBS
1
, the data item is stored as unpickled RAW data. DBS
1
pickles the RAW data to store it on disk.
To supply APP
1
with a data item stored in the database, DBS
1
unpickles the RAW data item to create unpickled RAW data. The unpickled RAW data is then converted to the user TYPE
1
data type before being supplied to the routines within APP
1
that manipulate the data item.
As illustrated by the example, even with database systems that support the RAW data type, the user that creates the user-defined type (the “type implementor”) is responsible for providing routines for converting RAW entities back and forth into their appropriate structured equivalents every time the control is handed over to user routines from the database system. Specifically, in the example given above, the type implementor is responsible for writing

Affiliated with

Also associated with

Rating

Opaque types does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Opaque types, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Opaque types will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2982222