Siebel Database Upgrade Guide > Siebel Database and UI Upgrade Planning >

About the Siebel Party Model

Upgrades: Applies to Siebel Financial Services upgrades from Siebel 7.x that have retained the Siebel 6.x form of household associations.

Environments: Development, production test, production.

Databases: All databases.

Platforms: Windows, UNIX, IBM z/OS.

Siebel 7.x introduced a party table (S_PARTY) in which all persons and organizational units are held. Accounts, organizations, internal divisions, contacts, employees, positions, and households are all considered parties and can be referenced from this table.

Most of the tables that formerly contained this data still exist and are still used, but they are now extension tables to the S_PARTY base table. Data is loaded into the business components through an implicit join.

Additionally, Siebel 7.x uses a single-person table and a single-organization unit table. For example, Employees and Contacts are now combined in the same table (S_CONTACT). Similarly, internal and external Organization Units are now combined in the same table (S_ORG_EXT).

The S_PARTY table is the primary table in the Party or Single-Person model and is the base table for all Party business components.

Several extension tables support the Party Model:

• S_USER stores Siebel User information.
• S_EMP_PER stores attributes for Brand-Owner Employees and Partner Users who are considered agents of the Brand-Owner.
• S_BU stores Organization information.
• S_CONTACT
• S_ORG_EXT
• S_POSTN

Each nonperson party directly or indirectly has person members, such as employees or contacts.

The Party model makes several tables obsolete:

• S_EMPLOYEE. Its functionality is merged into S_CONTACT.
• S_ORG_INT. Its functionality is merged into S_ORG_EXT.
• S_EMP_POSTN has been replaced by S_PARTY_PER.
• S_EMPLOYEE_ATT
• S_ORG_INT_ATT
• S_POSTN_RPT_REL

Figure 6 depicts the Party changes to the data model that occur during upgrades from Siebel 6.x to Siebel 7.x.

Figure 6. Party Model Changes

How the Party Model Is Implemented During an Upgrade

When you upgrade to Siebel 7.x, the upgrade process implements the Party model as follows:

Data Migration

• Migrates data from S_EMPLOYEE to S_CONTACT, S_USER, S_EMP_PER for standard columns
• Migrates data from S_ORG_INT to S_ORG_EXT, S_BU for standard columns
• Creates S_PARTY records for each previous contact, position, employee, account, division

Business Component Definitions

• Updates business component definitions to reference S_PARTY as the Primary Table (for example, Employee, Contact, Position, and Account business components)
• Changes standard and custom joins on S_EMPLOYEE to S_CONTACT, S_USER, S_EMP_PER
• Changes standard and custom joins on S_ORG_INT to S_ORG_EXT
• Sets implicit joins for custom fields created on business components that have been retargeted to S_PARTY. For example, if a custom field, Alternate Phone, existed on the Contact business component, the upgrade initiates the following actions:
  • Retargets Contact business component to S_PARTY
  • Defines join to S_CONTACT from S_PARTY on Contact business component
  • Sets implicit join for the Alternate Phone field

How the Party Model Affects Siebel Financial Services Household Data

For Siebel 7.0.x, the Party model changed the relationship between a household and the following entities for Siebel Financial Services:

The relationship changed as follows:

• In Siebel Financial Services 6.x, these entities could be associated directly with a household.
• As of Siebel Financial Services 7.0.x, these entities cannot be associated directly with a household. Instead, they are associated with a contact. You associate an entity with a household, by adding a contact associated with the entity to the household.

To implement direct relationships between the entity tables and a household table in Siebel Financial Services 6.x, intersection tables were used for many-to-many relationships. A foreign key was used for one-to-many relationships. This design allowed a contact to be assigned to an entity but not be part of the household assigned to that entity. This caused possible data integrity problems, which the Party model resolves.

The tables required for maintaining the 6.x direct-relationship design are retained in Siebel 7.x. You can choose to maintain direct relationships between households and entities. However, this is not recommended. To maintain the 6.x direct-relationship design, contact your Oracle sales representative for Oracle Advanced Customer Services to request assistance from Oracle's Application Expert Services.

How Siebel Financial Services 6.x Household Data Is Migrated

During the upgrade to Siebel 7.x, relationships in S_CONTACT_REL are migrated to S_PARTY_REL. Relationships in S_PER_ORG_UNIT are migrated to S_PARTY_PER.

When defining relationships between entities, no records are written to S_PARTY. Instead, the "PARTY (FIN)" and "Party Relationship To" business components drive the relationships displayed in the Relationship Hierarchy applet and adjacent Party Relationship list applet:

• S_PARTY includes the following fields:
  • PAR_PARTY_ID. This identifies the parent entity.
  • ROW_ ID
  • NAME
  • PARTY_TYPE_CD. This identifies the type of entity.
• S_PARTY_REL includes three fields:
  • PARTY_ID. This identifies the entity that has the relationship (explicit owner).
  • REL_PARTY_ID. This identifies the entity that the relationship is with (implicit owner).
  • REL_TYPE_CD. This identifies the type of relationship.

S_PARTY_REL can be used to define custom relationships such as lawyer, accountant, board member, and influencer. Valid relationships can be created between the following entities: