International Business Machines Corporation

Wilson D Lee

Tracy Kim Burroughs

Cynthia Ann Rogers

Laura Jane Zaborowski

Gary Ross Ricard

Larry William Youngren

Peter B Passe

Steven John Gansemer

Vance Palmer Morrison

Mark John Anderson

Richard Lee Cole

Erik Edward Voldal

Dennis Steven DeLorme

George D Timms, Jr

William S Davidson

Mark L Holm

Susan Carol Luebbe

The preferred embodiment of the present invention provides a system and method is provided that allows transparent and flexible partitioning of created objects in the context of schema mapping. The preferred schema mapper uses partition key values to facilitate partitioning of the created objects. The partition key value for an object determines what partition that object belongs in. To facilitate the most flexible schema mapping and partitioning, the partition key value for an object can be defined by the developer to be an attribute of an owning object, a primary key field of an owning object, or constant defined for its class. When new owned objects are created the partition key values are retrieved from their specified location in the owning object to determine the partition in which the new owned object belongs. In the preferred embodiment the developer also specifies a corresponding column of fields in the owned objects table to store the partitioning key values. Preferably, the partitioning key values are stored as a subset of the primary key field for the owned object. Because the primary key field is used to uniquely identify the corresponding object, the partition information in the partition key value partially determines the unique identifier of the owned object.

Object identity and partitioning for user defined extents

A method and system for persisting an object in a relational database schema by creating a new relational table at application program run-time for each class of objects to be persisted. The method may generate a schema map object for each class of objects to be persisted. The schema map object may be generated in response to the first transaction in which an object of a certain class is to be persisted and remains in memory for persisting, querying, restoring or deleting objects of that class. The schema map object determines the fields of each class of objects to be persisted, defines one or more columns in the table in accordance with the data types of the fields, and controls the passing of data between the table and the object fields.

Default schema mapping

A method and system for mapping between relational schema and object schema, wherein the relational schema includes a table having a tiebreaker column. In accordance with the present invention, an object-oriented application program may instantiate a persistent dependent object with one of two or more specific instances that is selected in response to the value of a data element in a tiebreaker column. Alternatively, an object-oriented application program may instantiate a persistent entity object in accordance with one of two or more entity classes that is selected in response to the value of a data element in a tiebreaker column.

Legacy subclassing

A method and system for mapping an object and an associated handle between the object-oriented schema of an application program and the relational schema of a database in which the object is persisted. The handle is reconstructed in response to a run-time request by an application program to instantiate the object. The handle may be an independent handle or an embedded handle. The relationships afforded by primary keys and foreign keys in a legacy, i.e., existing, relational database, can be preserved by mapping them to the independent and embedded handles, respectively. The mapping is performed prior to application program run-time, and is defined in a high-level schema mapping language, which may be generated with the aid of a schema mapping software tool.

Schema mapping to a legacy table with primary and foreign key support

A method and system for mapping a persistent dependent object between object-oriented schema and relational data store schema. Prior to application program run-time, schema mapping code is generated that defines a logical combination of null and non-null columns in the relational tables for each dependent class and dependent subclass. The code maps each instance variable of each class and subclass of the dependent to one column of the relational data store schema. The code maps a null value to each column for which a dependent subclass has no corresponding instance variable. At run-time, an application program may invoke the services of a schema map object, which in turn calls an object database driver such as ODBC to store an object in the data store or retrieve an object from the data store. In response to such calls referencing an object, the object database driver accesses the data store and associates the data elements with instance variables of the object in accordance with the mapping defined by the mapping code. The subclasses of the dependent are determined by comparing the pattern or combination of null values and non-null values read from the columns corresponding to each class and subclasses to that which the mapping code defines for each class and subclass. The application program, having been provided with the class and subclasses of the dependent, may then store the (non-null) values read by the driver into the instance variables of the object.

Dependent object class and subclass mapping to relational data store

A quick recovery of logical files which provide alternate views of databases is provided. Unchanged logical file pages are journaled before being changed. Transactions affecting databases covered by the logical files are also journaled. To recover a logical file, the journaled unchanged pages of the logical file that correspond to the changed pages are inserted back into the logical file, and the transactions that were journaled are processed to provide the changes to the logical file and to the database. This brings the logical file and the underlying database up to date, and in synchronization with each other.

Database index journaling for enhanced recovery

A key estimator estimates the number of keys over a key range defined by key endpoints in an index to a data space. The number of keys in the key range required to be processed for a particular operation is estimated as a function of the number of pages referenced during a range level limited search. Two keys defining range endpoint keys are searched down to their lowest level in the tree. The level limit is then calculated as a function of desired granularity or accuracy of the estimate. The entire range of keys in the desired key range is then searched down to the level limit and the number of pages referenced during the search is counted and multiplied by an average key density per page to calculate the number of keys in the range.

Growing community of inventors

Rochester, MN, United States of America

Wilson D Lee