## Data Model

Before you implement a synchronization, plan the technical system landscape and design the data model.

We recommend designing your data model on paper before defining it in the database instances with the Synchronization Manager GUI.

The data model comprises the tables in the master instance (master tables) and the tables in the client instances (client tables) that are involved in the synchronization.

The definitions of the client tables can be different from the definitions of the master tables. Client tables can, for example, belong to a different schema or have different table names or column names. You can synchronize all the columns of a table, or a selection of them. You can also define filters.

All tables to be synchronized must have a primary key.

You may not execute UPDATES for data in the primary key columns in tables that are participating in the synchronization.

To define the relationships between the master and client tables and the synchronization properties, you define replication tables and replication units.

#### Replication Tables

Define a replication table for each master table whose data is to be synchronized with the data in the client tables. The definition of a replication table contains the following information:

· Master table columns to be replicated

· Column groups (optional)

You can use column groups to define filters for the synchronization. You can also use column groups to prevent different client instances from simultaneously changing different columns in the same data record in the master instance.

· A versioned column group (optional)

If a table contains LONG columns, the Synchronization Manager automatically creates a versioned column group for the table.

Example of a Master Instance with a Master Table, a Replication Table and a Client Instance with a Client Table

#### Replication Units

You define the synchronization properties in the replication units:

· Type of synchronization (type of replication unit)

· Filters

· Other synchronization properties

You can activate and deactivate replication units.

There is at least one master replication unit for each master instance and at least one client replication unit for each client instance. Each master replication unit has at least one client replication unit assigned to it. You define all replication units in the master instance.

A master replication unit comprises one or more replication tables. A replication table can belong to multiple replication units.

A client replication unit comprises one or more client tables. A client table may only be assigned to one client replication unit (and to no other master or replication unit).

Example of a Master Replication Unit with Two Client Replication Units

The type of a replication unit defines in which direction data changes are transferred. The type of the master replication unit defines the type of the client replication units that belong to it.

Types of Replication Units

Type of the Master Replication Unit | Type of the Client Replication Units | Description
OUT | IN | The contents of the client tables are updated so that they correspond to the changed contents of the master tables.
IN/OUT | IN/OUT or IN | The contents of the client and master tables are synchronized. The client instances first send their changes to the master instance. Collisions are resolved there. Then the master instance sends the changes to all client instances. These changes then overwrite any contradictory changes in the client instances.

Types of Replication Units

#### Collision Resolution

A collision occurs if multiple database instances taking part in the synchronization simultaneously change the same data record. Simultaneously, in this case, means in the timeframe between two synchronizations performed by the synchronization services of the involved database instances. Collisions can only occur if the master replication unit is of the IN/OUT type. The Synchronization Manager applies fixed rules to determine which change to the data record has priority (collision resolution).

### Constraints

We recommend that the definitions of the client tables match the definition of the replication tables, for example that the client tables have no additional columns. The definition of the master tables can differ from the definition of the replication tables.

The following constraints apply for replication and client tables:

· They may not contain foreign key relationships.

· Certain mass updates may not be executed for columns with the UNIQUE column attribute; see the following example.

In the EXAMPLE table, the UNIQUE column ORDER specifies the sequence of the rows. You enter the following SQL statement:

UPDATE EXAMPLE SET ORDER + 1

The database system executes this SQL statement as a mass update: first it raises all the values in the ORDER column by 1 and only then checks if all the values in that column are unique.

In contrast, the Synchronization Manager executes this SQL statement in individual steps and checks if the values in the ORDER column are unique after each step. This leads to a violation of the UNIQUE condition in the ORDER column after the very first UPDATE.

### Result

After you have designed your technical system landscape and your data model, you can begin with the configuration.

### Example

Example: Data Model

See also:

Technical System Landscape