In the R.E.P. scenario described in (see page CDDS Example: Subset of Tables, several databases are allowed to manipulate data. Paths must be defined for each originating database. To do this, a separate data propagation path is defined for each CDDS that resides on an originating database. The path itself consists of separate entries for each target of the originating database.

Here is the example for CDDS 1 in San Francisco, which is set up to transmit inventory information to New York and London.

Data Propagation Paths for CDDS 1 in San Francisco:

Note that the local database is part of all path definitions. It is used to differentiate between a direct and indirect path to a target. In the first entry of the example, the originator and local databases are both SFO; this refers to the start of the replication path. In the second entry, the originator and local databases differ; this indicates that the local database, NYC, is responsible for cascading replication to the target, LON. As a result of cascades, a data propagation path can run through many databases.

Data Propagation Paths for CDDS 1 in New York:

Note that in this example, New York sends inventory data directly to San Francisco and London. The choice between the cascading paths in the SFO example and the direct paths in the NYC example can be influenced by various factors, such as communications infrastructure, transaction volumes at each site, and processor capacities.

Remember that a CDDS is simply a piece of a larger database. These individual pieces can reside at any site in an enterprise. In the R.E.P. scenario, international sales information (CDDS 5) from Hong Kong does not get copied to the master database in New York. Thus, no path definition for Hong Kong to New York for CDDS 5 is required. The New York inventory CDDS (CDDS 1) maintains the same standard, sharing only with the necessary remote sites.