Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
1999-11-01
2002-12-17
Breene, John (Department: 2177)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000
Reexamination Certificate
active
06496833
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates, in general, to databases and methods for accessing such databases with query objects, and, in particular, to a system and methods for generating the query objects.
BACKGROUND OF THE INVENTION
Databases represent an important data processing area in many applications. They are often used to store large amounts of information and then efficiently retrieve selected portions of the information. Many present day systems use a client/server database approach in which application programs running in clients access a central database management system (DBMS) located in a database server. In order to efficiently access the information in the database, the clients form queries which request information with selected characteristics. The queries are transmitted to the DBMS server which retrieves the desired information which meets the characteristics specified in the query and the results (commonly called a “result set”) are returned to the client.
Presently, such database environments are predominantly based on a “two-tiered” model consisting of a top tier containing one or more applications which generate queries that access the DBMS server in a bottom tier. The two-tiered model suffers from several drawbacks. First, the queries must be formulated in a specific query language, which is accepted by the DBMS server. While standard query languages exist, such as the Structured Query Language (SQL), specific DBMS query languages are often non-standard as a result of proprietary extensions made to the basic SQL query language. As a result, application programs written to generate queries in a particular query language are often not portable between different DBMS servers.
In addition, in order to generate the queries in the first place, each application developer, and, in some cases, the ultimate user, must understand the mechanics of the database, including the relationship of the files and tables therein and any relationships in the data required by the database organization. These relationships are commonly referred to as “business logic” since the relationships are typically based on shared business processes, practices and policies. Therefore, many parties must learn the business logic in order to generate meaningful queries.
Further, commonly-performed routines are typically replicated in each application program even if the application programs operate within the same business environment because each application functions autonomously from the other applications. This replication results in poor code re-use and maintenance problems if the replicated routines must be changed.
Consequently, there is a trend towards using a three-tiered model for database environments. Generally, the top tier in such a model consists of clients containing the application programs and the user interfaces, the middle tier consists of code that embodies the business logic and the bottom tier consists of the DBMS servers which contain the data. In this model, the applications are implemented as “thin” clients, all of which interface with the business logic by means of a common interface which does not involve knowledge of the business logic. The commonly-performed routines are all consolidated into the middle tier as part of the business logic. Since the business logic is shareable between the clients, code replication is avoided. The Common Object Request Broker Architecture (CORBA) presents one object-oriented approach to forming a three-tiered database environment, such as described in R. Orfali et al., “The Essential Client/Server Survival Guide,” pp. 375-458, John Wiley & Sons, Inc. (2d ed. 1996), the disclosure of which is incorporated herein by reference.
Several prior art methods of implementing the three-tiered model exist, however, most existing DBMS access mechanisms and tools, including fourth generation languages (4GLs) and application programming interfaces (APIs), have been designed for the two-tiered model and are ill-suited for use in the three-tiered model. Consequently, several prior art designs including “database” objects and “active data” objects have their own strengths and drawbacks. One promising prior art approach to constructing a middle tier containing business logic uses “query objects.” Each query object is a server object that:
(1) translates client method invocations into equivalent queries in a query language which is understood by a database;
(2) issues those queries to the database; and
(3) returns the results as strongly-typed data values.
The query object effectively encapsulates the DBMS specific query language so that the application programs do not have to know or use the DBMS query language. Query objects also encapsulate the database organization or “schema,” so that query object clients are isolated from database changes (although the query object itself may have to be changed if the underlying database must be changed.) Query objects also present their clients with a DBMS independent API, for example, CORBA defines an Interface Definition Language (IDL) interface. They do not require that the data be mapped into objects as is the case with active data objects so that significant performance advantages can be obtained and concurrency issues avoided.
Each query object provides as part of its interface one or more parameterized methods and calls on each method are translated by the query object into one or more standard queries such as SELECT, UPDATE, INSERT and DELETE or into the initiation of one or more stored procedures in the database. In order to use the query object, a client first establishes a connection to the query object via some mechanism, such as the CORBA naming service. One of the query object's methods is then invoked and the query object then executes the query.
However, in order to operate properly, the query object must be constructed to generate the correct DBMS queries in response to client requests. Constructing a query object to generate the correct queries requires a knowledge of SQL, an understanding of the underlying database schema, the possible handling of intermediate results generated by the query and interpretation of the results. In addition, a query object developer must consider other issues such as connection to the database using CORBA or similar arrangement, concurrency problems and translation required between the interface used by the query object and the API used by the database. Consequently, many query objects, including the most general query objects, are hand-written by skilled and knowledgeable developers. Hand-written objects are difficult to maintain and may require rewriting if the database schema changes. Therefore, it would be desirable to automate the generation of query objects.
SUMMARY OF THE INVENTION
The foregoing problems are solved in one illustrative embodiment of the invention in which a query object generator tool is used to generate interface definitions and code which implement a query object. The tool consists of an internal state object which represents the query object, including information which can be saved to reconstruct the query object at a later date, and code generator objects which generate the code required to implement the query object defined by the internal state object. In accordance with one embodiment, the code generator objects are arranged in a hierarchy so that a generator object can be instantiated which is specific to the database to be accessed and the language to which the implementation is targeted. An optional graphic user interface (GUI) may also be provided to allow a user to interact with the tool.
During operation, the inventive generator tool uses a special query object to access and extract database schema information from the database. The database schema can be displayed to the user using the GUI. The generator tool then receives input queries which may be text strings or may be constructed with a graphic interface. The text strings can be entered from either a command line or by means of the interactive GUI a
Goldberg Robert N.
Lam Gloria Y.
Le Chung
Breene John
Kudirka & Jobse LLP
Le Debbie
Sun Microsystems Inc.
LandOfFree
System and method for generating code for query 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 System and method for generating code for query object..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for generating code for query object... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2980812