Database having an integrated transformation engine using...

Details Database having an integrated transformation engine using... Database having an integrated transformation engine using...

1998-12-30

2002-04-23

Black, Thomas (Department: 2171)

Data processing: database and file management or data structures

Database design

Data structure types

C707S793000, C707S793000, C709S217000, C705S014270

Reexamination Certificate

active

06377953

ABSTRACT:

FIELD OF THE INVENTION
The present invention relates to database systems and, more specifically, to the use within database systems of data types that are not supported by the database language of the database systems.
BACKGROUND OF THE INVENTION
The data types supported by a database system are generally dictated by the database language through which the database system communicates with external applications. The data types that are supported by the database language of a database system are referred to herein as “supported data types”, while data types that are not supported by the language used by the database are referred to as “unsupported data types”. Instances of supported and unsupported data types are respectively referred to as supported and unsupported data items.
A popular database language is known as the Structured Query Language (SQL). Numerous versions of SQL have been developed, including SQL
92
and more recently SQL
3
. The types of data supported by SQL generally 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 SQL is extremely limited. For example, SQL does not provide support for multimedia objects, time series, and spatial data. 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, but which cannot be expressed in the database language understood by the database system.
One environment in which complex data types are prevalent is the electronic commerce (“e-commerce”) environment. In the e-commerce environment, numerous standards attempt to dictate the format of complex objects that should be used for exchanging business data. One such standard, referred to as EDI (Electronic Data Interchange), was developed by the Data Interchange Standards Association and has been established as ANSI X12.
An EDI message contains a string of data elements, each of which represents a singular fact, such as a price, product model number, and so forth, separated by delimiters. The entire string is called a data segment. One or more data segments framed by a header and trailer form a transaction set, which is the EDI unit of transmission (equivalent to a message). A transaction set often consists of what would usually be contained in a typical business document or form. The parties who exchange EDI transmissions are referred to as trading partners.
In addition to EDI, certain industries have developed their own industry-specific data format standards. For example, SWIFT (Society for Worldwide Interbank Financial Telecommunication) specifies the data formats and protocol for transferring funds electronically. HL
7
(Health Level
7
) specifies the data formats and protocol for transferring patient records electronically.
Data definition languages, such as XML (Extensible Markup Language), allow individuals, groups or industries to define data formats that can be used to share data on the World Wide Web, intranets, and elsewhere. For example, a set of companies might agree on a standard or common way to describe the information about a particular type of product that they manufacture. The companies can then use XML to describe a data format for storing the product description information. If the companies store data in the agreed-upon format, then a user may send an intelligent agent (a program) to each company's Web site, gather data, and make a valid comparison.
Difficulties arise when a database system is used to store data that, in its native environment, has a format that is not understood by the database system. One approach to using a database system under these circumstances involves converting each element of the unsupported data type to a data type that is supported by the database system.
For example, a business application (APP
1
) may expect data to be formatted according to a complex EDI data type (“TYPE
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 attribute of a TYPE
1
data item must be transformed to one or more instances of the data types that are supported by DBS
1
.
Once the data is transformed 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 by transformed 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 transformation 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 organized according to the structure and format of TYPE
1
. To pass the data item into DBS
1
for storage, the data item is transformed to data types supported by DBS
1
(dbtype
1
. . . dbtypeN). While in volatile memory within DBS
1
, the data item is stored as unpickled instances of dbtype
1
. . . dbtypeN. DBS
1
pickles the instances to store them on disk.
To supply APP
1
with data currently stored on disk, DBS
1
unpickles the instances of dbtype
1
. . . dbtypeN to create unpickled instances of dbtype
1
. . . dbtypeN. The unpickled data is then transformed to the structure of the TYPE
1
data type before being supplied to the routines within APP
1
that manipulate the data item.
To reduce the burden associated with transforming unsupported 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 unsupported data types that have attributes that are not easily transformed to any data type supported by the database system.
The following statement creates a routine that is internal to the database for invoking an external “manipulate” routine:
create procedure my method(a IN RAW)
The input to this internal routine is a RAW data item, while the external manipulate routine expects a TYPE
1
data item. Consequently, the implementation of the my method procedure must take the form:
my method(a)
{
raw-to-struct(a)
manipulate
struct-to-raw(a)
}
In this example, the my method routine receives a RAW data item “a”. The raw-to-struct(a) statement invokes a user-supplied routine that transforms 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) transforms 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 transformation 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 to “user type
1
”. To pass the data item into DBS
1
for storage, the data item is transformed 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 transformed to the user TYPE
1
data type before being supplied to the routines within APP
1
that manipulate the data ite

Affiliated with

Also associated with

Rating

Database having an integrated transformation engine using... does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Database having an integrated transformation engine using..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Database having an integrated transformation engine using... will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2878927