Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
1998-11-30
2001-05-22
Vu, Kim (Department: 2172)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000, C707S793000, C707S793000, C707S793000, C700S103000, C700S106000, C709S213000, C709S217000
Reexamination Certificate
active
06237003
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to database systems and methods.
BACKGROUND INFORMATION
Applications that access a relational database reference objects in the database (tables, columns, etc.) by name. This creates a close coupling between applications and the database objects. This close coupling causes complications when upgrading either the database or the application. This situation is exacerbated when multiple applications may reference the same objects and those applications may themselves be upgraded at different times at an installed site.
A traditional solution to the aforementioned problem is to make use of the “view” construct typically provided by relational databases. The use of database view, however, is problematic due to the well-known deficiencies of updating views and because views often incorporate non-standard SQL syntax in their definitions. Being able to run on relational databases from different vendors is a desirable capability.
SUMMARY OF THE INVENTION
The present invention is directed to a method and apparatus that allows dynamic run-time object definition in a relational database.
In an exemplary embodiment of the present invention, a layer of data and processing is introduced between the application and the database object. This layer mediates access to the physical layer and allows the application to embed logical instead of physical names. The present invention also allows for the maintenance of this layer to happen dynamically, as applications are running, if desired. The mediating layer preferably can run on a variety of relational databases, overcoming the vendor-specific extensions to SQL that relational database vendors have introduced.
An exemplary embodiment of the present invention is implemented with the POEMS Data Exchange (a.k.a. “DEX”) and the POEMS service processor “ptsprdbm” of Platinum Technology, Inc. The DEX stores the data used by the mediating layer and the processing is handled by the ptsprdbm service processor. In this embodiment, the DEX mediating layer can be seen as a mapping between messages submitted to the DEX and the physical table layout of the DEX. This mapping allows for multiple associations to physical tables, thereby insulating higher layers from changes to the physical implementation. Also, the mediation defines logical transactions which associate one or more application requests with an action to be performed on a table or set of tables.
In an exemplary embodiment, each application creates one or more requests which are sent to the DEX. For each request, the DEX returns one result. There may be one or more ptsprdbm processes running. Each application request is handled by one ptsprdbm service processor process. The mediating layer data is stored in a metadata subject area of the DEX. All instances of ptsprdbm running on the same machine refer to the same metadata. The metadata maps requests from the applications to the physical tables. Consequently the applications do not need to know the identifiers of the physical tables. The physical tables may change over time and, provided that the metadata mapping is maintained, the applications will be insulated from these changes.
For example, a client may request data, through a message, about a logical entity called “machine”. The logical name “machine” may or may not correspond to a physical table called “machine”. It is the responsibility of the mediating layer to correctly translate logical transaction names to physical table names and columns.
In another example, a client may submit a message which is mapped to the logical transaction named “ip_address for machine” where “machine name”=absun10. In this example, the quoted elements should be considered logical objects which must be translated to physical objects. This is desirable since the requested data could change format as well. For example, in version 1 of POEMS, the physical database may store only one ip_address for each machine. In version 2 of POEMS, however, the database may store a list of ip_address for each machine. This would cause a different result set to be returned to the client, possibly breaking the client application. Using the mediating data, a new logical transaction is defined for version 2 which the service processor would know how to handle and the correct result set would be returned to the client.
An advantage of using a mediating data layer in accordance with the present invention is that applications can define new messages containing new logical transactions and have the DEX service processor correctly handle these new messages without modifications to the existing service processor. An application would simply add a row to the DEX metadata tables to define a new logical transaction. The service processor would know to map the new message to the logical transaction data added to the metadata tables and would consequently construct the correct SQL command for the new message.
Changes to the physical database can be handled in a similar way. A new logical transaction would be defined mapping an old message to a new table layout. This could be done either by using a version number with each transaction or by deleting the original transaction from the metadata.
The metadata could also be used to integrate tables created by the user into the DEX. The user would create a table using standard SQL, then would add rows to the DEX metadata tables to describe the new table. The user could also create per_triggers so that the new table could be automatically updated when an existing table is updated.
REFERENCES:
patent: 5181162 (1993-01-01), Smith et al.
patent: 5594899 (1997-01-01), Knudsen et al.
patent: 5734887 (1998-03-01), Kingberg et al.
patent: 5758347 (1998-05-01), Lo et al.
patent: 5873097 (1999-02-01), Harris et al.
patent: 5970490 (1999-10-01), Morgenstern
patent: 5978808 (1999-11-01), Wells et al.
patent: 6014674 (2000-01-01), McCargar
patent: 6016394 (2000-01-01), Walker
patent: 6122640 (2000-09-01), Pereira
patent: 6154750 (2000-11-01), Roberge et al.
patent: 6160549 (2000-12-01), Touma et al.
Hanson, Eric et al., “Scalable Trigger Processing”, Proceedings of the 15th International Conference on Data Engineering, Mar. 23-26, 1999, pp. 266-275.*
Kim, K. H. (Kane) et al., “Dynamic Configuration Management in Reliable Distributed Real-Time Information Systems”, IEEE Transactions on Knowledge and Data Engineering, Jan.-Feb. 1999, vol. 11, Issue 1, pp. 239-254.
Boone Duane
Carrigan Ed
Lewish Keith
Alam Shahid
Baker & McKenzie
PLATINUM technology IP, Inc.
Vu Kim
LandOfFree
Method and apparatus for supporting dynamic run-time object... 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 apparatus for supporting dynamic run-time object..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for supporting dynamic run-time object... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2454397