System and method for managing hierarchical objects

Details System and method for managing hierarchical objects System and method for managing hierarchical objects

2003-05-08

2004-12-28

Rones, Charles (Department: 2175)

Data processing: database and file management or data structures

Database design

Data structure types

C707S793000, C707S793000, C707S793000, C707S793000, C709S206000, C709S230000

Reexamination Certificate

active

06836776

ABSTRACT:

FIELD OF THE INVENTION
The invention relates to a system and method for storing and transmitting data. More particularly, the invention relates to a system and method for storing a list of hierarchies as a single object.
BACKGROUND OF THE INVENTION
Modern database applications are typically designed using relational data models that are implemented by well known technologies such as DB
2
. For many applications, a relational data model works well. For some applications, however, the relational database model limits the ability to represent complex conceptual information. Such systems typically store data in tables that include one or more columns. When data is stored in the tables, the data may not occupy all or a portion of one or more columns. Therefore, data storage space that includes unused columns may be unused. Additionally, such systems typically require a new table schema to be defined for each data collection to be saved. Therefore, data to be stored must be assembled by the system to populate the table's schema within the table. Additionally, systems typically only allow navigation through the table in a downward direction.
These tables contain named columns of information and one row for each data observation. Related tables may be joined by one or more columns that contain a common field. The descriptions of all tables, columns, and relationships are contained in the database schema, which is typically maintained by a full-time database administrator (DBA). The definition of new tables, columns, or relationships usually requires the intervention of a DBA.
Many applications typically store dense lists of information, such as financial data or employee records, where most data columns are fully populated. Other applications, such as name and address directories or product catalogues, contain sparse information. That is, out of many potential data elements, only a few may exist in any particular record. Address directories on product catalogues typically maintain relationships, especially inheritances that are usually more easily understood when expressed in hierarchical trees rather than joined relational tables.
Another drawback of existing systems is that data collections to be stored must be transformed to a format compatible with a table to be used to store the data. This may require modification of existing schema or reformatting a database to a particular format. This may include reorganization and possible downtime for the database.
Another drawback with existing systems is that multiple disk reads may be necessary for retrieving rows within a table. For example, if a user desires to further limit a search, and the user inserts additional criteria for searching an object, existing systems typically access a server each time an additional search criteria is input. This may slow the performance of the server and increase processing time.
Relational databases are used to store relationships among tables. Relational databases, however, are not very suitable for storing hierarchies. Therefore, hierarchical databases typically are used to store hierarchies. Data elements are stored as fixed lengths. If a data element does not occupy the fixed lengths, the excess data storage space may be wasted.
Existing systems are typically slow to resolve queries. For example, a query may take one hundred (100) milliseconds to be resolved. Another drawback is that applications are typically coded to retrieve one or at most a few attributes on any one server call. This may lead to multiple calls being issued to a server against the same data collection. Furthermore, because only portions of a data collection are retrieved, existing systems typically parse the data collection for particular information being requested. Parsing may occur for each call issued to a server. This may also increase processing time.
These and other drawbacks exist.
SUMMARY OF THE INVENTION
One object of the invention is to overcome these and other drawbacks of the existing systems.
Another object of the invention is to provide a system and method for storing and transmitting a hierarchical data list (HDL) and a hierarchical data container (HDC).
Another object of the invention is to provide a system and method for enabling an HDL to be stored to be a self-defining object.
Another object of the invention is to provide a system and method for retrieving an HDL with a single call.
Another object of the invention is to provide a system and method for retrieving HDLs without requiring parsing of information.
Another object of the invention is to provide a system and method for storing HDLs with the ability to navigate and read a hierarchy of the entire HDL.
Another object of the invention is to provide a system and method for storing HDLs that do not require reformatting or reorganization of data.
Another object of the invention is to provide a system and method for storing Hierarchical Data Elements (HDE) that do not require a fixed length attribute.
Another object of the invention is to provide a system and method for storing HDLs that enable an application to locate an HDE or HDL contained therein using any attribute of that HDL.
Another object of the invention is to provide a system and method for storing HDLs that enables load balancing among HDL database servers.
The invention relates to a system and method for storing and transmitting data. The data may be stored as an HDL, HDC, or an HDE. An HDE may include a structure that comprises a ‘name’, syntax, and value. Additionally, an HDE describes its relationship to sibling objects and/or a parent HDE. One example of an HDE is a linked attribute value pair (LAVP). An HDC is a particular type of HDE that comprises a name and pointers to a list of zero or more HDEs. An example of an HDC is a linked attribute value list (LAVL). An HDL may be an HDC and its collection of zero or more HDEs. An example of and HDL may be an LAVL and zero or more LAVPs.
The invention provides a system and method for representing, storing, transmitting, and retrieving information. The invention uses a hybrid data object containing hierarchical information and references back-end databases that may be stored with one or more keys that are dynamically derived from an HDE's content when the object is stored. The invention enables sufficient storage and retrieval of HDLs using indexing with Structured Query Language (SQL)-like complex query capabilities. Each HDL and HDE may be a self-defining entity. That is, each HDL and HDE contains its own schema. Each HDL may contain information to determine the attributes of the HDL, HDE, and each data element. The invention also enables rapid navigation, transmission, searching, construction, manipulation, and deletion of HDLs and HDEs.
The HDL may include collections of HDEs and possibly, other subordinate HDLs. This recursive data architecture enables complex hierarchies of data objects and enables data inheritance. Navigation through an HDL may be forward, backward, up, or down, through a navigational tree. The HDL may be broken apart and rearranged in any manner desired.
The invention also enables referencing back-end databases such as LDAP, DB
2
, and Oracle. These data references may be cached and subsequently retrieved without referring to the back-end databases. This enables faster retrieval of the data objects from such systems. A time-to-live for each cache entry may be set individually for each cached HDL. The invention also enables invalidation of a cached reference and rereading of a cached reference regardless of a status of the reference.
Each HDL may be stored as an ordinary “flat file,” and may be copied, moved, backed-up, or deleted using known operating system commands. HDLs may also be replicated to remote locations. Preferably, replication is performed in real-time.
Other objects, advantages, and embodiments of the invention are set forth in part in the description that follows and in part will be apparent to one of ordinary skill in the art.


REFERENCES:
patent: 4887206 (1989-12-01), Natarajan
patent: 4956774 (

Affiliated with

Also associated with

Rating

System and method for managing hierarchical objects does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with System and method for managing hierarchical objects, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for managing hierarchical objects will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3329501