Synchronization and Denormalization
In data modeling, synchronization and denormalization are often combined to respond to particular use cases.
Example
A PAYMENT entity that you wish to represent in the database by three tables TRANSFER, CHECK and OTHER. To produce this modeling:
1. Create the PAYMENT entity.
2. Run synchronization (logical to physical) to obtain the PAYMENT table.
3. Run the physical wizard to horizontally partition the PAYMENT table.
4. Rename the three duplicates TRANSFER, CHECK and OTHER.
The three tables obtained in this way are now connected to the PAYMENT entity and will follow the developments of future synchronizations.
Combining denormalization and synchronization options
Impact of a denormalization on two synchronized models varies depending on the options selected.
Consider the example of a logical denormalization. Possible combinations are:
• Deletion of source objects + transfer of mappings: logical model source objects are deleted. The physical level is unchanged; mapping with logical objects resulting from denormalization is assured.
• Deletion of source objects + non-transfer of mappings: physical objects corresponding to logical objects resulting from denormalization are created. The physical objects corresponding to deleted logical objects are deleted.
• Non-deletion of source objects + transfer of mappings: logical model source objects are kept. The physical level is unchanged; mapping with objects resulting from denormalization is assured.
• Non-deletion of source objects + non-transfer of mappings: physical objects corresponding to objects resulting from denormalization are created. Existing physical objects are kept.
Particular cases: ascending and descending merges:In the case of an ascending merge, the supertype entity plays a particular role. Denormalization keeps its mapping in all cases.
Similarly, in the case of a descending merge, subtype entities play a particular role; their mapping is kept in all cases.