Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
2002-11-14
2004-02-24
Channavajjala, Srirama (Department: 2177)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000, C707S793000, C707S793000, C707S793000, C707S793000, C707S793000, C707S793000
Reexamination Certificate
active
06697804
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to distributed database systems and more particularly to a method and article for mass deployment of front office applications using distributed database technology.
BACKGROUND OF THE INVENTION
Under certain conditions, it is desirable to have copies of a particular body of data, such as a relational database table, at multiple sites. The mechanism for maintaining multiple copies of the same body of data at multiple sites is generally referred to as “data replication.” In a distributed database system using data replication, multiple replicas of data exist in more than one database in the distributed database system.
One kind of data replication employs snapshots. A snapshot is a body of data constructed of data from one or more “master” tables, views, or even other snapshots, any of which can be stored locally or remotely relative to the snapshot. The data contained within the snapshot is defined by a query that references one or more master tables (and/or other database objects) and reflects the state of its master tables at a particular point in time. To bring the snapshot up-to-date with respect to the master tables, the snapshot is refreshed upon request, e.g. at a user's command or automatically on a periodic, scheduled basis.
There are two basic approaches for refreshing a snapshot. “Complete refreshing” involves reissuing the defining query for the snapshot and replacing the previous snapshot with the results of the reissued query. “Incremental refresh” or “fast refresh” refers to identifying the changes that have happened to the master tables (typically, by examining a log file of the changes) and transferring only the data for the rows in the snapshot that have been affected by the master table changes. An “updatable snapshot” is a snapshot to which updates may be directly made, which are propagated from the snapshot back to the master table before refreshing.
Traditionally, snapshots have been implemented for high-end computer systems, which are characterized by the use of high performance computers that are interconnected to one another by highly reliable and high bandwidth network links. Typically, highly experienced database administrators manage these high-end systems. Due to the expense of these high-end computers, high-end distributed systems tend to involve a small number of networked sites, whose users can be trusted at least in part because of the physical security of the computers.
Recently, there has been much interest in the marketplace for applications for front office automation. One example is sales force automation, where hundreds, if not thousands, of sales representatives in a company are given laptops to improve their productivity. The laptops are loaded with applications, for example, to help a sales representative sell the company's products to a customer and take the customer's order. Therefore, the laptops include a data store to keep the customer and order information handy for use by a specific sales representative.
Front office automation, however, challenges the operating assumptions behind the high-end snapshot implementations. For example, laptops are not high-performance computer systems and are only sporadically connected to a master site, typically for short periods of time. Moreover, laptops can get or stolen, raising security concerns. In addition, it is difficult to deploy a large number of front office applications with many different snapshots. Therefore, implementing a high-end snapshot replication approach for front-office automation incurs a number of disadvantages that, if not addressed, render the use of snapshots problematic for front office automation.
Mass deployment of front office applications and the data to support them is another difficult issue when there are hundreds, if not thousands, of laptops functioning as client sites. Since the snapshot metadata is stored at the client site in the high-end approach, the snapshots for the front office applications have to be individually instantiated by a person at the laptop, when the laptop is connected to the master site. The typical sales representative, however, does not have the training to perform this operation. Moreover, instantiating these snapshots is especially time-consuming when done over a low bandwidth connection.
SUMMARY OF THE INVENTION
There is a need for an implementation of mass deployment of snapshots that is suitable in a front office automation environment without incurring the above-described and other disadvantages incumbent in a high-end implement of snapshot replication.
This and other needs are addressed by the present invention in which mass deployment of snapshots is fostered by allowing collections of snapshots, called refresh groups, to be defined by a template. The template allows for a parameterized snapshot definition query or other Data Definition Language (DDL) or Data Manipulation Language (DML) statement to be defined, so that user-specific values can be substituted into parameters to create different objects. Furthermore, off-line instantiation of snapshots is provided, so that the data for an entire suite of front office applications can be stored on a floppy disk, magnetic disk, CD ROM, or other transportable computer-readable medium. This computer-readable medium is capable of being applied to a laptop, for example by insertion into a CD ROM drive, so that an installation program can install the requisite snapshots without the intervention required of an experienced database administrator.
Accordingly, one aspect of the invention relates to a computer-implemented method and a computer-readable medium bearing instructions for deploying a database object such as a relational database table, index, snapshot, view, materialized view, etc. The methodology includes storing a string that describes how to instantiate the database object and inspecting the string to determine if the string includes a substitutable parameter. If there is a substitutable parameter, a value is obtained for the substitutable parameter, and that value is substituted value for the substitutable parameter to produce a DDL text, which, when executed, causes the database object to be instantiated.
Another aspect of the invention pertains to a computer-implemented method and a computer-readable medium bearing instructions for deploying a plurality of snapshots. A refresh group is defined, listing the snapshots. Corresponding strings, each including at least one substitutable parameter, are stored that describe how to instantiate the snapshots. After a value for the substitutable parameter is obtained, the value is substituted for the substitutable parameter in each of the strings to produce a Data Description Language (DDL) text for each snapshot, which, when executed, causes the snapshots to be instantiated. In one embodiment, the DDL texts are stored on a transportable, computer-readable medium.
Still other objects and advantages of the present invention will become readily apparent from the following detailed description, simply by way of illustration of the best mode contemplated of carrying out the invention. As will be realized, the invention is capable of other and different embodiments, and its several details are capable of modifications in various obvious respects, all without departing from the invention. Accordingly, the drawing and description are to be regarded as illustrative in nature, and not as restrictive.
REFERENCES:
patent: 4631673 (1986-12-01), Haas
patent: 5375237 (1994-12-01), Tanaka et al.
patent: 5418966 (1995-05-01), Madduri
patent: 5440735 (1995-08-01), Goldring
patent: 5452448 (1995-09-01), Sakurabe et al.
patent: 5459860 (1995-10-01), Burnett et al.
patent: 5553279 (1996-09-01), Goldring
patent: 5603024 (1997-02-01), Goldring
patent: 5606699 (1997-02-01), De Pauw et al.
patent: 5613113 (1997-03-01), Goldring
patent: 5706509 (1998-01-01), Man-Hak Tso
patent: 5732262 (1998-03-01), Gillespie et al.
patent: 5737601 (1998-04-01), Jain et al.
patent: 5761493 (1998-06-01), Bl
Elsbernd Curtis
Smith Wayne E.
Souder Benny
Channavajjala Srirama
Ditthavong & Carlson P.C.
Oracle International Corp.
LandOfFree
Deploying plurality of sanpshots storing parameterized data... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Deploying plurality of sanpshots storing parameterized data..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Deploying plurality of sanpshots storing parameterized data... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3334158