Party Model Overview
Working with a Party Model implements relationships for parties (entities) such as organisations and people. The super-type (organisation) is comprised of sub-types, i.e. people. People may have different roles, e.g. manager (responsible for) or employee (reports to) and the organisation (employs). Roles declare meaning when read in a direction, viz. left-to-right (Ltr) and right-to-left (Rtl). Party is the super-type entity entry that signifies the identity of an interest to the reference organisation, i.e. the one that implements the model. Party is viewed relative to this vantage point and is the superior interacted with. The next inter-actor follows a hierarchical model, i.e. forms a relationship (as party) as first inter-actor, e.g. organisation as employer to the person as employee. Both are Parties and have a representation in the Party table with PartyId as the unique identifier. These identity keys are used in a relationship table to create the relation: Acme Corp. (employer) — employs —> Engineer Joe (employee).
Party is a physical table in the database. The PartyId is the primary key of the table, an identifier that is the foreign key to the party being modelled, e.g. organisation or person.
The Party table with its associated Person and Organisation tables contain the business data, e.g. Figure 1 – Party Relationship. This Party structure is the basic relationship or root of the party model.
The Party Physical Data Model (Figure 2) implements the organisation (as Party) in the Party (primary key) to Organisation (foreign key/ Primary Key) in the relationship. Also for (Person) Individual, being defined by PartyId (PK) to IndividualPartyId (FK/ PK). The Primary Key of an Organisation is used in the foreign-key implementations of its reference data, e.g. Organisation Level OrgPartyId (FK/ PK).
The model (Figure 2) has very little meaning other than indicating a very explicit entity, defined as a party; the power of the relationship lies in the association of people (individuals) to the organisation, i.e. to be the bill-of-material (2016 – Jean-Marc Reynaud) of the organisation. An individual who is part of the company has a role as employee, with a designation of function,e.g. Engineer. Such a person could also be a line-manager, all of which requires the model to accommodate and extensible implementation. The root (internal) Organisation also has relationships with various other (external) Organisations, with their respective classifications and reference data modelled on the OrganisationPartyId as the PartyId foreign key, but primary key for the Organisation.
Two types of data are brought together, viz. the business data (relationship structures [taxonomies] for Party) and the metadata (reference/ lookup) data for the Organisation, People and other entities modelled with all other reference data-structures (objects) that relate.
According to Siebel in their description of The Party Model the model comprises a base table and extension tables, with external tables used to model the relationships between the Party tables. “Typically, you associate each employee and partner user with one or more positions. The employee or partner has only one active position at a time and automatically associated to one division and organisation, being associated with the active position.”
The business data leverages metadata, e.g. Role and Party type. For example, a Party is defined (in the Party type) as either a person or an organisation. The Role type describes the Peron and/ or the Organisation, e.g. Systems Analyst (role) for Person, or Public Company for Organisation.
For other entities (objects) in a business, e.g. Product, Events, Agreements, or Assets, these are modelled as objects and exposed to Part in a junction-table called: Party<Entity>. For example, PartyProduct, PartyEvents, PartyAgreements, or PartyAssets, following on from the previous example. The Party consequently “has a role with” the reciprocal Party<Entity>, e.g. a Product is linked to a Party by PartyId and ProductId (with an associated PartyProductRole) and Product defined in an associated data model that uses ProductId as the unique product identifier.
Building the Organisation and People Party Model
Party is a base entity type relating to the objective organisation modelling its business. A Party always represents a single person or a group, e.g. a company that can be viewed in a business as a single entity (Ref: Configure Siebel Applications). These entities (according to Oracle) could be:
- Person/ Contact
- Partner User
- User Group
- Access List
These parties are defined by a Party Type field, a code that uniquely identifies the sub-type discriminator for a party, as described in the list above. Extension tables are associated with the basic Party record to provide differentiation. Party joins extension tables explicitly. The business data must be modelled in a Role Type Relationship table to create role-pairs that model first and second inter-actors. This defines the type of relationships possible between Parties. For example, an Organisation implements many job roles, so the hierarchy of the role-pairs is to create the bill-of-materials of one organisation with its many job profiles. The organisation also employs an employee to fill a job profile. All these reference data entities (before relating them) must be created.
Define Party Types
Any Party is defined by its sub-type discriminator, describing the Party, what it is, viz. Organisation, Person, Position, Capbility, etc. The PartyTypeCode (an Integer number can also be used) is the primary key to the foreign key in the Party table.
Party Role Type
A party requires fulfilling a role within a business context. Each Party Type (person or organisation) plays a business contextual role in relation to the extensions of a business, e.g. Product, Events, Agreements, or Assets (as described in the overview). Consequently, in the extension’s junction table, an explicit Role Type Code would join the Role Type to the extension, e.g. Asset to indicate what role the connected Party plays in that context. For example: a company Product is joined to a Party in the Product Party junction table by relating PartyId and ProductId with a Party Product Role Code and a set of effective-from and effective-to dates to version the relationship. This could be that Acme Corp (an internal organisation) has an asset called an impact drilling machine in the role of owner.
Reference data for an Organisation can be carried at this level while more business modelling, to extend the configuration such as Address, Name History, SIC History, and Type, can be done in the extension tables. The Organisation Identifier (company code or some legal registration number) can be incorporated to uniquely identify the entity. Whatever information is presented at this level should only change or become defunct if the Organisation is terminated or becomes redundant.
Modelling an Organisation requires the Organisation and Division structures. In the Siebel CRM model and Organisation is a Division (2015 Gerhard Hermann), designated as an Organisation and can be hierarchical such as Divisions. A Division is an internal unit within the Organisation/ Company, e.g. a regional operating division of the company. The company is modelled directly on a Division and not the Organisation.
Attributes or the Organisation, irrespective of the Organisation Type, can be added to this level (The Data Model Resource Book, Volume 1 – Len Silverston 2001). It reduces the number of tables (containing business data) modelling the structures of Organisation. At this
Before an Organisation can be created, the type should be known. Basically, an organisation can be Internal (part of the reference organisation) or External, an organisation with whom the reference organisation has dealings and interactions. This break-down can take on the form Legal and Informal Organisations (Data Structure Patterns Topic 4.3), or whatever the reference Organisation has decreed how an Organisational model should look like. The hierarchy must be sensible and usable to the organisation. The delineation between internal and external organisations can also be achieved with a simple boolean flag to simplify the model and attach extension reference data at the Organisation level. According to Teradata: “A well-understood big picture of the organization needs to be captured and communicated in the form of a model.”