Although some distributed transaction-processing applications maintain centralized primary data, others fragment primary data among replicate sites.
A primary fragment is a horizontal segment of a table that holds the primary version of a set of rows. Updates are applied to the primary version first and are then distributed to sites that have replicated copies of the data.
Sites that are responsible for, or own, portions of a table by definition have multiple primary fragments. For example, the salesdetail table in Figure 2-3 has primary fragments in Chicago, New York, and San Francisco:
Figure 2-3: Table with multiple primary fragments
A key constructed from one or more columns identifies the primary fragment where a row belongs. The key for the salesdetail table is the stor_id column.
Rows with “7067” in the stor_id column belong to the primary fragment at the Chicago site.
Rows with “5023” in the stor_id column belong to the primary fragment at the New York site.
Rows with “8042” in the stor_id column belong to the primary fragment at the San Francisco site.
There are three application models based on multiple primary fragments:
Distributed primary fragments – in this model, tables at each site contain both primary and replicated data. Updates to the primary version are distributed to other sites. Updates to non-primary data are received from the primary site.
Corporate rollup – in this model, multiple primary fragments maintained at remote sites are consolidated into a single aggregate replicate table at a central site.
Redistributed corporate rollup – this model is the same as the corporate rollup model, except that the consolidated table is redistributed.
More information about these models can be found in Chapter 3, “Implementation Strategies”
