Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
1998-06-19
2001-02-20
Breene, John (Department: 2777)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000, C707S793000, C707S793000
Reexamination Certificate
active
06192370
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates generally to a method of data storage, retrieval, and processing in a transactional system. More particularly, the invention relates to a method for integrating relational and object-oriented functionality in order to execute functions on stored data on a real-time basis.
BACKGROUND OF THE INVENTION
In the computing industry, it is common to store data in commercial database systems and to retrieve such data using a database management system. There are two general types of database management systems, relational and object-oriented. Relational database systems are good for managing large amounts of data, while object-oriented database systems are good for expressing complex relationships among objects. Relational database systems are good for data retrieval but provide little or no support for data manipulation, while object-oriented systems excel at data manipulation but provide little or no support for data query and retrieval. Depending on the task at hand, there are various systems available which are suited for particular tasks. In order to manage simple data without queries, a traditional database system is not even necessary. A simple file system will suffice. In order to manage simple data with queries, a relational database system would be ideal. If the subject data is complex without queries, an object-oriented database system would be used. Finally, for the case where the subject data is complex and requires query capabilities, one would want to use an object-relational database management system.
Attempts to combine the inherent functionalities have been made; however, as the two models are fundamentally different, integrating the two is quite difficult. Relational database systems are based on two-dimensional tables in which each item appears in a row. Relationships among the data are expressed by comparing the values stored in these tables. The object model is based on the tight integration of code and data, flexible data types, and references. Object-oriented databases have their origins in the object-oriented programming paradigm. In this paradigm, users are concerned with objects and operations on those objects. For example, instead of having to thing of a “DEPT tuple” plus a collection of corresponding “EMP tuples” that include “foreign key values” that reference the “primary key value” in that “DEPT tuple,” the user should be able to think directly of a department object that contains a corresponding set of employee objects.
It is a basic tenet of the OO approach that everything is an object. Some objects are primitive and immutable (integers, strings, etc.) Other objects—typically user-created—are more complex and mutable. These more complex objects correspond to variables of arbitrary internal complexity. Every object has a type (the OO term is a class). Individual objects are sometimes referred to as object instances. An intrinsic aspect of any given type consists of the set of operators or functions (the OO term is “methods”) that can be applied to objects of that type. Furthermore, all objects are encapsulated. This means that the representation or internal structure of a given object is not visible to the users of that object. Instead, users know only that the object is capable of performing certain functions. The advantage of encapsulation is that it allows the internal representation of objects to be changed without requiring any of the applications that use those objects to be rewritten. In other words, encapsulation implied data independence. Every object has a unique identity called the OID (object ID) which can be used as addresses for pointers from other parts of the database.
Relational database systems support a small, fixed collection of data types (e.g. integers, dates, and strings), which has proven adequate for traditional application domains such as administrative data processing. In many application domains, however, much more complex kinds of data must be handled. Typically, this complex data has been stored in Operating System file systems or specialized data structures, rather than in a DBMS. Examples of domains with complex data include computer aided design and modeling (CAD/CAM), multimedia repositories, and document management. As the amount of data grows, the many features offered by a DBMS for data management—for example, reduced application development time, concurrency control and recovery, indexing support, and query capabilities—become increasingly attractive and necessary. In order to support such applications, a DBMS must support complex data types. Object-oriented concepts have strongly influenced efforts to enhance database support for complex data. As mentioned before, there exist, in the prior art, relational database management systems which support these functions with regard to simple data. A relational DBMS could conceivably store complex data types. For example, images, videos, etc. could be stored as blobs (“basic large objects”) in current relational systems. A blob is just a long stream of bytes, and the DBMS's support consists of storing and retrieving blobs in such a manner that a user does not have to worry about the size of the blob; a blob can span several pages. All further processing of the blob has to be done by the user's application program, in the host language in which the SQL language is embedded. This solution is not efficient because we are forced to retrieve all the blobs in a collection even if most of them could be filtered out of the answer by applying a user-defined function within the DBMS. Although object-oriented databases of the prior art support storage of complex data, they fail to provide the query and indexing capabilities to manage such complex data. There is a need for a database management system which can provide the features and functionality of traditional relational database management systems, but for use with complex data types. As a result of this need, there has been a drive towards the development of object-relational database management systems.
Object relational databases can be thought of as an attempt to extend relational database systems with the functionality necessary to support a broader class of applications, and in many ways, provide a bridge between relational and object-oriented paradigms. There are several object-relational database management systems (ORDBMSs) in the market today. These include the Informix Universal Server, UniSQL, and
02
. The approach taken by the current trends in object relational technology is to extend the functionality of A existing relational DBMSs by adding new data types. Traditional systems offered limited flexibility in the data types available. Data is stored in tables, and the type of each field value is limited to be a simple atomic type. This limited type system has been extended in three ways: user-defined abstract types, constructed types, and reference types. Collectively, these are referred to as complex types. As an example, take a JPEG image. This type is not one of a typical DBMS's built-in types, but can be defined by a user in an ORDBMS, to store image data compressed using the JPEG standard. Allowing users to define arbitrary new data types is a key feature of ORDBMSs. The ORDBMS allows users to store and retrieve objects of type jpeg_image, just like an object of any other type, such as integer. New data types usually need to have type-specific operations defined by the user who creates them. For example, one might define operations on an image data type such as compress, rotate, shrink, and crop. The combination of the data type and its associated methods is called an Abstract Data Type (ADT). The label “abstract” is applied to these data types because the database system does not need to know how an ADT's data is stored, nor how the ADT's methods work. It merely needs to know what methods are available and the input and output types for the methods. Hiding of ADT internals is called encapsulation. When the object is especially large
Breene John
Chadbourne & Parke LLP
Lewis Cheryl
SAP Aktiengesellschaft
LandOfFree
Method and system for rapid memory-resident processing of... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and system for rapid memory-resident processing of..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and system for rapid memory-resident processing of... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2604088