Party Data Model

The S_PARTY table is the base table for all of the parties listed in Table 9-1, "Party Types and Parties": Person (Contact), User, Employee, Partner User, Position, Account, Division, Organization, Partner Organization, Household, User List, and Access Group.

For each party record stored in the S_PARTY table, the value of the PARTY_TYPE_CD column denotes the party type. Along with the party type, extension tables provide the primary differentiation between the different parties.

For information about how joins are used to draw data from multiple tables into a single business component, such as is done for Employee, Account, and other business components for party-type data, see Configuring Siebel Business Applications.

In Figure 9-10, the base table and extension tables that make up the party data model are shown within the Party boundary box (all of the shaded area). The three tables shown outside of the Party boundary are used to define relationships among parties. Sections that follow illustrate how the party data model applies to various particular parties.

Figure 9-10 Party Data Model

How Parties Relate to Each Other

Parties have some required relationships, as described below.

• Divisions, organizations, and accounts are instances of the Organization party type.

• A division, internal or partner, is also an organization if its internal organization flag is TRUE (INT_ORG_FLG = "Y") and it has an associated S_BU record.

• Every division is associated with one organization: either itself or the closest ancestor division that is also an organization.

• Every position is associated with a division. The position is then also automatically associated with one organization: the organization with which the division is associated.

• Persons (contacts), users, employees, partner users are instances of the Person party type.

• Typically, you associate each employee and partner user with one or more positions. The employee or partner user has only one active position at one time. The employee or partner user is automatically associated with one division and one organization at a time; the division and organization associated with the active position.

  
  

  Caution: Merging employee records is not recommended. You can disrupt party relationships to a significant extent and get unexpected results.

  
  

• For purposes of granting visibility to data, associations of parties of type Person with other types of parties are stored using the S_PARTY_PER table. For example, accounts are associated with contacts, users are associated with positions, and so on. A user associated with a position can see data for accounts or opportunities assigned to the position (when this is the active position). Relationships stored in S_PARTY_REL also affect data routing for mobile users.

• Nonstructured and informational relationships between parties are stored in the table S_PARTY_REL. For example, a company and its accounting firm might both be stored as accounts. The relationship between these two accounts can be stored in the S_PARTY_REL table, assuming that your application has been configured to define these relationships.

Person (Contact) Data Model

In Figure 9-11, the base table and extension table (S_CONTACT) that define a Person, or Contact, are highlighted. A Person is the simplest representation of an individual in the database.

Figure 9-11 Person (Contact) Data Model

User Data Model

In Figure 9-12 the base table and extension tables (S_CONTACT and S_USER) that define a User are highlighted. A User is a Person with the following added qualities:

• The S_USER table contains a login for this user.

• The S_PER_RESP intersection table (not shown) specifies a responsibility for this user.

• It is possible to promote a contact to a user. For example, adding a User ID value for a person in the All Persons view in the Administration - User screen causes the person to appear as a user in the Users view.

Figure 9-12 User Data Model

Employee Data Model

In Figure 9-13 the base table and extension tables (S_CONTACT, S_USER, and S_EMP_PER) that define an Employee are highlighted. Internal Employees and Partner Users are each represented as Employee records.

An Employee is a User with the following added qualities:

• S_EMP_PER provides employee data for this user.

• A position defined using the S_POSTN table is typically (but not necessarily) associated with an employee.

  • If the organization to which the position belongs is not a partner organization, then the employee is an internal employee.

  • If the organization is a partner organization, then the employee is a partner user.

Figure 9-13 Employee Data Model

Position Data Model

In Figure 9-14 the base table and extension table (S_POSTN) that define a Position are highlighted.

Note: In positions, as in other areas of your Siebel application, foreign key references are implemented with the ROW_ID column in the base tables. The ROW_ID column is not visible in the user interface and cannot be changed manually. This is because the integrity between the various base tables would be lost if users were allowed to change this value. Changing a position name does not affect the foreign keys (the ROW_ID in the underlying base table).

Figure 9-14 Position Data Model

Account Data Model

In Figure 9-15, "Account Data Model" the base table and extension table (S_ORG_EXT) that define an Account are highlighted.

Note: Accounts, Divisions, Organizations, and Partner Organizations share many of the same data model elements.

Figure 9-15 Account Data Model

Division Data Model

In Figure 9-16 the base table and extension table (S_ORG_EXT) that define a Division are highlighted. In S_ORG_EXT, the flag INT_ORG_FLG = Y specifies that a division is an internal organization. (For an account, this flag is set to N.)

Note: Accounts, Divisions, Organizations, and Partner Organizations share many of the same data model elements.

Figure 9-16 Division Data Model

Organization Data Model

In Figure 9-17 the base table and extension tables (S_ORG_EXT and S_BU) that define an Organization are highlighted. An Organization, sometimes known as a business unit, is also a Division, but has a record in the S_BU table.

Note: Accounts, Divisions, Organizations, and Partner Organizations share many of the same data model elements.

Figure 9-17 Organization Data Model

Partner Organization Data Model

In Figure 9-18 the base table and extension tables (S_ORG_EXT, S_BU, and S_ORG_PRTNR) that define a Partner Organization are highlighted. A Partner Organization is the same as an Organization but the flag PRTNR_FLG in S_ORG_EXT qualifies it as a Partner Organization.

Note: Accounts, Divisions, Organizations, and Partner Organizations share many of the same data model elements.

Figure 9-18 Partner Organization Data Model

Household Data Model

In Figure 9-19 the base table and extension table (S_ORG_GROUP) that define a Household are highlighted.

Figure 9-19 Household Data Model

User List Data Model

In Figure 9-20 the base table and extension table (S_USERLIST) that define a User List are highlighted.

Figure 9-20 User List Data Model

Access Group Data Model

In Figure 9-21 the base table and extension table (S_PARTY_GROUP) that define an Access Group are highlighted.

Figure 9-21 Access Group Data Model