IBM InfoSphere Master Data Management, Version 10.1

Partitioning key oriented partitioning sample

One approach to address performance and response time issues is to employ a partitioning solution based on the primary key of those tables. This sample explains how to implement this approach.

The format for partitioning primary keys is as follows:

Table 1. Primary key partition format
2 digits	2 digits	13 digits	2 digits
Partition key	Random	Timestamp	Application InstanceId

The primary key assigned to new records for the following tables must be enhanced so that the child entities share the same partition key as used in their parent entities, as detailed below:

Table 2. Setting partition keys for tables
Table	How to set the partition key
Contact	Random number
Person	Same as Contact
Org	Same as Contact
LocationGroup	Same as the partition key used in cont_id
AddressGroup	Same as the partition key used in location_group_id
Address	Same as the first location_group_id that is using the address record
ContactMethodGroup	Same as the partition key used in location_group_id
ContactMethod	Same as the first location_group_id that is using the contact method record
ContEquiv	Same as the partition key used in cont_id
Identifier	Same as the partition key used in cont_id
IncomeSource	Same as the partition key used in cont_id
OrgName	Same as the partition key used in cont_id
PersonName	Same as the partition key used in cont_id
PersonSearch	Same as the partition key used in cont_id
Interaction	Same as the partition key used in interact_party
LobRel	Same as the partition key used in instance_pk
MiscValue	Same as the partition key used in instance_pk
ContactRel	Same as the partition key used in from_cont_id
Contract	Same as the cont_id of the contract role with the role type equal to the one defined in tcrm_extension.proprties file under the key cluster_key_selection_by_contract_role_type
ContractComponent	Same as the cont_id of the contract role with a the role type equal to the one defined in a tcrm_extension.proprties file under the key cluster_key_selection_by_contract_role_type If that role does not exist, then use the partition key used in contract_id
ContractRole	Same as the partition key used in cont_id
ContractRel	Same as the partition key used in from_contract_id
Campaign	Same as the partition key used in instance_pk

Both the Contract and ContractComponent ClusterKey are set by the contract role partyId with a role type equal to the one defined in a tcrm_extension.proprties file under the key cluster_key_selection_by_contract_role_type.

This sample only generates the partitioning primary key for new entities. It does not apply partitioning logic to existing entities.

The following Java™ class extensions are used to implement this sample:

PartyPartitionIDExtension: Intercepts the pre-add actions for the party descendent entities in order to assign a partitioning primary key.
FinancialPartitionIdExtension: Intercepts the pre-add actions for the financial entities in order to assign a partitioning primary key.
UpdatePartitionIdExtension: Intercepts the pre-update transactions when it holds new child entities and finds the partition key of the top level object.

Note: The maximum value for the partition key in this sample is limited to 92.

For more information on how to partition a database table, refer to the technical manual for your database.

Feedback

Last updated: 12 Sep 2012

Topic URL: