Published in TDAN.com July 2002
Author’s Note: Ideas in this article are based on the work of Martin Fowler in his book “Analysis Patterns: Re-Usable Object Models”.
The Problem with Modeling People
It would be hard to imagine a data model that didn’t include persons, either as individuals or as groups. Models contain people in one of two ways: as organizational structures or as playing
roles in relationship to each other or to organizations, both inside and outside an enterprise. Since the structural arrangements between people and organizations can be fairly volatile over time,
trying to anticipate future possibilities for, say, organizational units in a data model can be a frustrating task. Moreover, the common practice of modeling person or organization roles as
separate entities, rather than as attributes of the relationships between people or organizations, leads to models that cannot answer some questions without inserting redundant attributes in
violation of relational rules.
Something with fixed components but capable of containing a shifting set of instances and their linkages in a fully normalizable (5NF) way is needed. The Party/Party-Relationship
pattern presented below meets this requirement.
This pattern arises from the fact that persons and organizations have many characteristics in common:
- One or more names
- One or more ways locations that may be shared with others
- One or more communication methods that also may be shared
- One or more internal or external identifiers
- One or more associations with each other
Additionally, organizations may act as if they were individual persons.
Party
Party is a convenient concept that allows us to deal with individuals or groups as if they were the same kind of thing. Figure 1 shows a Party as a supertype of
Person and Organization.
Party Characteristics
Names A Party has a ‘Name,’ but often may have many names. Persons have ‘Surnames’ plus one or more other names plus prefixes (salutations) and suffixes (generational or
titles). Organizations usually only have the equivalent of a surnames. When there are multiple names, each name will be used for a different purpose and may be time-bound. Figure 2 shows these
additions to the pattern.
Each Party Name has a specific function, such as a legal name or professional name or other alias, a date span when the name was used, and the name itself. The actual name is
divided into a required ‘Surname’ and an optional string containing the ‘Rest of the Name’ plus an optional ‘Salutation.’
Unless an enterprise has special searching requirements on the ‘Rest of the Name,’ there is no reason to break out its separate components. Trying to anticipate all the kinds of name
components and add them as attributes to Party Name will lead to the same frustration as trying to anticipate all the current and future needed organizational structure levels.
Persons will have all the name components shown. Organizations will have only a ‘Surname.’
Locators and Communicators Addresses and telephone numbers are not really locations. They are bits of code that smart agents use to route communicate to a party. One usually
will not find a party sitting inside their mail box.
Addresses and telephone numbers are best handled as locators between a party and an actual site or telephone device. With this in mind, Figure 3 adds Locator to the pattern. The
actual locations pointed to by a Locator belong to other patterns not presented here.
The subtype ‘type’ is part of the Locator key. A Mailbox or Telephone may be bound to a Site, although some
telephones like pagers or cellular phones are free-floating. A Web Site or an e-Mail Box probably cannot be usefully bound to a Site in the sense
that one can walk into a site and put a hand on an e-mail box.
Separating a Locator from a Site untangles postal addresses from the geographic points or floor plans that make up the site’s shape or structure.
External Identifiers A Party may be identified many ways both other parties. Social Security Numbers, various jurisdiction’s Tax Numbers, Customer
Numbers, and Vendor Numbers are just some examples. Adding an External Party Identifier entity to the pattern without, again, requireing all possible identifiers to be known in
advance.
Equivalencies
It isn’t uncommon to discover that two or more parties are the same. This raises a dilemma: which party or parties should be absorbed and should the absorption occur by deleting?
The dilemma can be resolved by adding a separate and distinct subtype set to Party containing an Active Party and a Superceded Party with a
linking relationship.
Other Attributes
There are other party attributes of interest. Either a Person or an Organization may have a birth – the date the party came into existence – as well as
a death date. Persons may have a gender. Other attributes such as marital status or total employment are derived from information held in other parts of this pattern, and are not shown here. Figure
6 shows how these attributes may be handled.
Party Classifications
It is convenient to classify parties along functional lines. For instance, some persons might be physicians with different specialties, and it would be of interest to be able to classify them
within a hierarchy of their specialties. Or some of organizations might be hospitals or insurance companies or technical recruiters. And any type of party might be segmented along some marketing
dimensions. We will add a Party Type entity in Figure 7 as part of a business rule level in the pattern to handle this.
In many cases, parties may be classified along many different dimensions, and the classifications within a dimension may be arranged in a network or a hierarchy. Figure 8 adds more business rules
to the pattern.
In Figure 8, many Party Types may classify a Party, and Party Types may be structured by Party Type Structure. A Party Type
Schemeowned by a Party groups may Party Type Structures.
Consider an American Medical Association classification of Physician specialties. The PartyAmerican Medical Association would own the
Party Type SchemeAMA Physician Classifications that would be composed of Physician, Surgeon, Internist, Pediatrician, Opthamalogist, and so on, each of which
would be a Party Type. Since all Surgeons also are Physicians, one Party Type Structure would have Physician and SurgeonParty
Types linked together. One then could search for Parties who were Surgeons and know that they also were Physicians. With the m:n link between
Party and Party Type, one could search cross-wise to the hierarcy for, say, Pediatric Opthamalogy Surgeons.
Similar structures can be built by an enterprise’s marketing department – or multiple marketing departments – to segment the parties that are their target customers in any and multiple ways.
Or managers could create organizational structures, some with the same organization showing up in multiple views of the organization. The possibilities are endless. But to handle real structures
between parties, not just classification structures, a Party Relationship entity needs to be added to the pattern, as is shown in Figure 9.
Party Relationship
The real power of the Party-Party Relationship pattern lies in the relationships between parties.
Party Relationship may be subtyped as Household, Employment, Customer, Sales Coverage, or any other interesting linkage between two parties as shown in Figure 10. The role
names become specific to the subtypes:
Notice that the role name of each party in the relationship is an attribute of the relationship, not of the party. This allows a party to play multiple roles to another party. An example would be
one party as an Employer and another party as an Employee in an Employment relationship. Or a party that is both a Customer and a Supplier, and a
Government Regulator, at the same time.
Party Relationship Business Rules Rules need to be in place that only allow certain combinations of party types in a relationship. Figure 11 adds these rules:
The rules that allow party types to be linked in a party relationship are held in the Party Relationship 1st Party Type Rule and Party Relationship 2nd Party Type
Rule entities. These are the rules that will not allow, for instance, a superior organizational level to be linked as a child to a subordinate level.
Since role names are business rules, they have been moved from Party Relationship to Party Relationship Type.
While not shown here, Party Relationship Types may be structured via Party Relationship Type Structure and Party Relationship Type Scheme entities
with a party type relationship scheme owned by a Party just as Party Type was structured.
Operating Scope
An added advantage of this pattern is that a Party Relationship Operating Scope entity may be attached to Party Relationship that would allow the linking of the
kinds of activities that may be performed within the relationship, the kinds of parties and products or service involved, and the bounding geographic areas and time periods.
Positions
Since many, if not most, operating scopes are defined by HR as Positions, it makes sense to include a Position entity as a subtype of Party. In this way, persons
or organizations may be assigned to positions at will, with the dates of assignment recorded in an Employment subtype of Party Relationship as shown in Figure 13:
With this bit of the pattern, HR may define positions as a relationship to themselves with one or more scopes, organizations may include those positions in their org charts as relationships to
their selves with additional scopes, and employees may be assigned the positions, again as a relationship with possibly even more scopes, all without needing to add entities.