The simplest configuration is illustrated in Figure 19.1, “Single Stream (Basic Configuration)”. Here Snapshot would be being used to transfer the stream data held in the local filesystem into the Stream Source Table. The Stream Source Table is being used directly as the Couple Source Table for each couple synchronising to a Target Table. In this illustration multiple target tables are shown. This could also be the case in any of the other configurations illustrated but for simplicity only one target table (one couple) is shown in the others.

Figure 19.1. Single Stream (Basic Configuration)

A more complex example configuration is illustrated in Figure 19.2, “Dual Stream (Composite Configuration)”. Here Snapshot is being used on two different streams. The results are merged by using a view for example. This view is then used as the couple source table to synchronise with a target table. In this configuration it may (or may not) be important to refresh each stream first as a separate stage to ensure consistent data before the couple stage of each stream is initiated.

Figure 19.2. Dual Stream (Composite Configuration)

In Figure 19.3, “Dual Stream with Local Data (Composite Configuration)” much the same is happening but in addition the view defining the couple source table is including content from some tables local to the physical database itself. Here some local data is being used to complement and/or constrain the final data set that is used for synchronisation. Bear in mind that these local tables might themselves have content that has been synchronised against another stream.

Figure 19.3. Dual Stream with Local Data (Composite Configuration)

It is quite possible to use TheonCoupler with no external data stream whatsoever as illustrated in Figure 19.4, “Local Data Only (Composite Configuration)”. Here the couple source table is defined as a view based on data in local tables only. This can be used to drive any internal database functional processing that can be (re)defined in terms of a the generic TheonCoupler synchronisation function.

The refresh argument to the ttkm stream sub-command is not relevant to internal only streams as it does nothing. Often the individual couple processing (normally carried out by the couple argument to the ttkm stream sub-command) is also initiated by internal database triggers for internal only streams.

Figure 19.4. Local Data Only (Composite Configuration)

An extension of internal only stream processing is illustrated in Figure 19.5, “Single Stream with Local Data and Feedback Loop (Composite Configuration)”. Here the couple source data is defined as a view as in the previous configuration except that this view is constrained by data in the final target table itself, creating a form of feedback loop. This arrangement can be used in a number of clever ways to complement the generic synchronisation function. For example, the couple source table could include stream data as long as that data has not yet been written into the target table, or the couple source table could contain default values for the data in the target table but where the target table data has defined an alternative value that would be used in place of the default and preserved in the stream data itself (this is a subtle variation of local override).

Figure 19.5. Single Stream with Local Data and Feedback Loop (Composite Configuration)

Finally alternative means of incorporating external data without using Snapshot are illustrated in Figure 19.6, “Embedded Dual Stream with Local Functional Data and Feedback Loop (Composite Configuration)”:

Any or all of these can be used separately or together and/or with any of the other configurations to form the couple source table for a couple.

The refresh argument to the ttkm stream sub-command during stream processing in TheonCoupler does nothing (is defined to do nothing) for these embedded approaches.

Figure 19.6. Embedded Dual Stream with Local Functional Data and Feedback Loop (Composite Configuration)