Abstract: Schema evolution involves defining flavored object groups. Specifically, related collections of replicated tables and other database objects, which are defined as belonging to an object group, are given different “flavors.” A flavor describes different subsets of the objects and even different subsets of the columns in the master tables. In one embodiment, when one site in a distributed database system propagates changes to a replicated database object, the current flavor for the site is also transmitted, so that the destination site can make the necessary adjustments in the uploaded changes by dropping the values for obsolete columns and using default values for new columns.

Abstract: Techniques used in a distributed database system for simplifying copying of objects from one database system in the distributed database system to another and establishing the infrastructure necessary for the distributed system in the database systems. One application of the techniques is setting up a cache database system that has a subset of the objects in another database system and establishing a link for redirecting misses between the cache and the other database system. Also included is the infrastructure in the cache and the other database system for an authentication proxy that establishes sessions in the other database system for users to perform operations that have been redirected as a result of a miss in the cache. The techniques require only that the user supply simple descriptions of some of the objects to be copied; the techniques locate the necessary dependent objects and make objects for the infrastructure.

Abstract: 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 DDL text to be defined, so that user-specific or site-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.

Abstract: Replication for front office automation involves the use of snapshots that are instantiated on laptops, in which refreshing the snapshots is driven from a master site with a high-performance protocol. All of the necessary snapshot metadata for performing the snapshot refreshes is stored at the master site, so that the laptop only needs to send a single refresh request. In response to the refresh request, the master site reconciles the differences between the master tables and the laptop's snapshots and transmits the differences to the laptop, reducing the necessary network traffic for updating a snapshot to a single round trip.

Abstract: 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 DDL text to be defined, so that user-specific or site-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.

Abstract: Replication for front office automation involves the use of snapshots that are instantiated on laptops, in which refreshing the snapshots is driven from a master site with a high-performance protocol. All of the necessary snapshot metadata for performing the snapshot refreshes is stored at the master site, so that the laptop only needs to send a single refresh request. In response to the refresh request, the master site reconciles the differences between the master tables and the laptop's snapshots and transmits the differences to the laptop, reducing the necessary network traffic for updating a snapshot to a single round trip.

Abstract: Schema evolution involves defining flavored object groups. Specifically, related collections of replicated tables and other database objects, which are defined as belonging to an object group, are given different “flavors.” A flavor describes different subsets of the objects and even different subsets of the columns in the master tables. In one embodiment, when one site in a distributed database system propagates changes to a replicated database object, the current flavor for the site is also transmitted, so that the destination site can make the necessary adjustments in the uploaded changes by dropping the values for obsolete columns and using default values for new columns.

Abstract: A distributed system modeler for modeling a distributed system architecture. The distributed system modeler includes logic for receiving interdependency information specifying interdependencies between a plurality of data objects and programs, logic for defining a plurality of modules, wherein each module of the plurality of modules represents a different grouping of a portion of the plurality of data objects and programs, logic for assigning the modules to nodes in a distributed system, and logic for assigning a distributed transfer methodology between modules in the distributed system. The distributed system modeler includes logic for generating impact analysis criteria defining a quality of said distributed system. The impact analysis criteria includes performance metrics, conflict metrics, data object or program availability metrics, and transaction consistency metrics.