Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
2000-09-22
2004-02-17
Mizrahi, Diane D. (Department: 2175)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000
Reexamination Certificate
active
06694321
ABSTRACT:
BACKGROUND
1. Field of the Invention
The present invention relates generally to methods and systems for accessing data in databases and, more particularly, to systems, methods, software products, and software product components used to develop software applications that access data in relational databases.
2. Related Art
The development and maintenance of client-server software systems can become extremely difficult when client software applications that access a database are dependent on the database schema. As the number of client applications increases, the amount of work required to implement a change of schema increases dramatically. Not only do all the affected client applications have to be changed, but it generally also is necessary to track all the dependencies between clients and the database so as to ensure that all the required changes are accounted for. Moreover, once the schema change is complete, it typically is necessary to recompile and redistribute all the affected client applications. As the number of client applications increases, these tasks can become complex and burdensome.
A variety of approaches have been developed for isolating client applications from the database schema so that certain types of schema changes can be made without requiring that the client applications be revised. For instance, some commercially available database products include user interfaces that implement a technique sometimes referred to as “data binding.” Data binding involves the use of SQL (Structured Query Language) commands to declaratively map server-side data into the user interface software component without requiring that the programmer manage details of the operation of the user interface component. Data binding is popular because it is simple, easy to use, relatively standard, and can be used casually without requiring any support outside the user-interface component.
The use of data-binding interfaces suffers, however, from a number of disadvantages. One is that result sets generally must be updateable, which may impose serious limitations on the design of the user interface component. Another disadvantage is that the SQL code responsible for the data binding generally is stored in the client application. Thus, when the data bindings are changed due to a change in the database scheme, the client application must be recompiled and redistributed. Moreover, many data-bound interface components employ a single SQL command to manage all of their operations, thereby significantly limiting functionality. Even if more than one SQL command is used, the functionality is limited by the scope of the SQL commands employed. Yet another disadvantage is that it typically is difficult to change the behavior of data-bound interface controls at runtime.
Another approach to isolating client applications from the database schema is to use views and stored procedures to map data and operations on the data from the client to the server, with applications accessing the database only through these objects. The views-and-stored-procedures approach generally offers the advantage over data-binding approaches of maintaining functionality on the server side. However, there are a number of disadvantages to the views-and-stored-procedures approach. For example, it typically is difficult to maintain stored procedures, as they contain no information about their intended use, or indeed, whether they are used at all. A typical database will soon become cluttered with unused code, creating a significant drain on maintenance efforts. Another disadvantage is that stored procedures and views generally are accessed by name, making naming problems likely as the number of clients increases or when clients are moved from one database to another. Moreover, all the available stored procedure names generally are not known in advance, and it typically is difficult for client applications to change their behavior at runtime without having this information available. Yet another disadvantage is that, unless regularly recompiled, it is possible for stored procedures to become invalid and therefore to fail without apparent explanation. Generally, the use of views also invites dependencies on the ability to update a view. This capability often cannot be guaranteed even as the result of seemingly minor schema changes.
Yet another approach has been used by database developers and has also been incorporated into commercial software products that often are referred to as “middleware.” These products provide an object-oriented view of the database so that compatibility with the client applications is maintained even as the underlying database changes. Middleware addresses a number of the problems associated with data binding by re-mapping the database schema to an invariant, often object-oriented form. Also, some middleware products offer the additional features of transaction management and integration of multiple data sources. Moreover, some middleware systems provide a view of the database that reduces the mismatch between the relational data structures in a database and the pointer-based data structures most often used in programming languages. However, conventional middleware products also generally have significant disadvantages when used as a mechanism for schema independence. For example, the queries they employ often are cumbersome and difficult to maintain, requiring a relatively formal configuration management strategy. Due to the complexity of configuring the middleware to particular applications, they generally are very expensive, whether purchased commercially or developed in-house. In addition, some middleware products are tied to a specific language, such as Java or C++, thereby dictating how client applications must be developed.
SUMMARY
Systems, methods, and products are described for developing, modifying, or maintaining client applications that access data in one more databases. For convenience, these one or more databases may sometimes be referred to hereafter singly or in the aggregate as the “target database.” The target database typically, but not necessarily, is a relational database. Systems in accordance with the present invention may hereafter be referred to for convenience as “schema-isolated systems.” Reference may occasionally be made in the detailed description or the figures to a particular implementation of a schema-isolated system, arbitrarily referred to convenience as the “Pantheon” system or architecture. It will be understood that these reference although made simply to “systems” for convenience, generally include methods and products in accordance with the present invention.
Embodiments of the present invention provide various combinations of advantages over conventional systems, methods, or products for developing, modifying, or maintaining applications that access databases. With respect to conventional approaches using data-binding interfaces, for example, the SQL code responsible for the binding in accordance with some implementations of a schema-isolated system is stored in the target database, rather than in the client application. Thus, when the bindings are changed, there is no need to recompile and redistribute the client application. Also, schema-isolated system components may have an unrestricted number of query templates. Thus, they offer greater functionality as compared with approaches employing conventional data-binding interfaces. For instance, optional features may be provided that that the user need not employ. Similarly, a schema-isolated system typically employs templates that update data in the target database. The schema-isolated system thus can perform arbitrarily complex operations using procedural code. This capability generally is not possible with the pure SQL used by most data-bound controls. Yet another advantage is that, as noted, it typically is difficult to change the behavior of data-bound interface controls at runtime. In contrast, the multiple configurations available to a schema-isolated system component makes it easy to implement and co
Affymetrix Inc.
Merkling John R.
Mizrahi Diane D.
Sherr Alan B.
Wu Yicun
LandOfFree
System, method, and product for development and maintenance... 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, method, and product for development and maintenance..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System, method, and product for development and maintenance... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3349397