Category: Understanding Data Modeling

We’ve explored who a Party is, the roles a Party can perform, and how those roles change over time.

But knowing who someone is and what they do doesn’t necessarily tell us how they are connected to others.

A Role Is Not the Same as a Relationship

Consider a person who is a manager.

The term Manager may describe a role or responsibility within an organization.

But it does not tell us whom that person manages.

To answer that question, we need a relationship between Parties.

For example:

• Person A manages Person B.
• Person B is managed by Person A.
• Organization A is a subsidiary of Organization B.
• Person C serves as an advisor to Organization A.

These examples describe connections between specific people or organizations.

Relationships Have Meaning and Direction

A Party Relationship describes an association between two Parties within a defined business context.

One way to represent that relationship is to identify:

• From Party: The Party from whose perspective the relationship is described.
• To Party: The Party to which the relationship points.
• Party Relationship Type: The nature of the relationship connecting them.

For example:

• From Party: Jane
• To Party: Robert
• Party Relationship Type: Manages

Together, these tell us that Jane manages Robert.

Looking at the relationship from Robert’s perspective, we would say that Robert is managed by Jane.

The Parties are the same, but the way we describe their relationship depends on its direction.

Business Context Matters

Relationships must also be understood within their business context.

A person may manage employees in one organization while serving as a volunteer in another.

Those relationships have different meanings and responsibilities.

We should not assume that a relationship established in one context automatically applies in another.

Why Does This Matter?

When relationships are treated simply as attributes of a Party, we may lose important information about who is connected to whom.

For example, recording that someone is a manager does not necessarily identify the people they manage.

Similarly, knowing that two organizations are business partners does not explain the nature or direction of their relationship.

Representing relationships explicitly helps businesses understand organizational structures, responsibilities, reporting arrangements, and other connections.

The Key Point

A Party Role describes the capacity in which a Party participates. A Party Relationship describes how one Party is connected to another.

Both concepts matter, but they answer different questions.

Before modeling a business association, ask:

Are we describing what a Party does, or how that Party is connected to another Party?

Understanding the difference helps us build models that represent business relationships more accurately.

Continue Exploring Understanding Data Modeling

This article concludes our introductory seven-part discussion of the Party Model.

Visit the Understanding Data Modeling series index for the other articles and future topics exploring enterprise data modeling.

Return to the Understanding Data Modeling Series Index

In our previous post, we explored how a single Party can perform multiple roles within a business.

But those roles are not necessarily permanent.

A person may become a customer, later accept employment with the same company, and eventually leave that employment while remaining a customer.

The person is still the same individual. What has changed is the role, or combination of roles, that the person performs.

Roles Have a Lifecycle

A Party Role may begin, change, or end without changing the Party’s underlying identity.

Consider someone who:

• Becomes a customer.
• Accepts employment while remaining a customer.
• Leaves employment but continues as a customer.
• Returns as an employee several years later.

The person remains the same, even as their roles change over time.

Depending on the business requirements, the model may need to represent multiple periods during which the same Party performed a particular role.

Why Does Time Matter?

Business systems often need to answer questions about both current and historical activities.

• Who was an employee on a particular date?
• When did an organization become a supplier?
• Was someone acting as a customer, employee, or both when a transaction occurred?

If our model represents only current roles, we may lose the ability to answer these questions accurately.

One common approach is to record when a Party Role becomes effective and, when applicable, when it ends.

The appropriate level of historical detail depends on the business requirements. Not every system needs to preserve the same information.

What Happens When We Get This Wrong?

When identity and role are combined, ending a role may inadvertently remove or obscure information about the Party.

We may also create duplicate records when someone returns to the business in a different capacity.

Both situations make it more difficult to maintain accurate information and reconstruct historical business activities.

The Key Point

A Party’s identity can remain consistent even as its roles change over time.

Separating Party from Party Role allows us to represent changing participation without unnecessarily creating new identities or losing information about existing ones.

Before designing how a role will be represented, ask:

Do we need to know only the Party’s current role, or must we also know when that role was active?

Next in This Series

Party Relationships

In our next post, we’ll examine how people and organizations are connected to one another.

Return to the Understanding Data Modeling Series Index

In the previous posts, we separated who a Party is from what that Party does.

That distinction becomes especially important when one person or organization participates in the business in several ways at the same time.

Consider Maria again.

Maria may be an employee. She may also be a customer. She might volunteer for an event or participate as a member of an organization.

Those activities do not create four Marias.

There is one Party performing multiple roles.

The Party represents Maria’s identity. Her roles describe the different ways she participates in the business.

Different Roles, Different Information

Each of Maria’s roles represents a different business context.

As an employee, the business may need information about her employment. As a customer, it may need information about her customer activity. As a volunteer, it may need information about her participation in the volunteer program.

Each role may require different information. But Maria’s underlying identity does not need to be duplicated each time.

Party Role gives us a way to represent those different ways of participating while keeping them connected to the same Party.

This allows the business to see Maria as one person while still recognizing each of the roles she performs.

Why Does This Matter?

Without that distinction, each business area may see only its own version of Maria.

Human Resources sees an employee. Sales sees a customer. The volunteer program sees a volunteer.

Each view may be correct, but none of them alone represents the whole person.

When those roles are connected to the same Party, the business can recognize that they all refer to Maria while still preserving the information that belongs to each business context.

One Party with many roles gives the business a more complete view without losing the distinctions that make each role meaningful.

What Happens When Roles Change?

A Party can perform several roles at the same time.

But those roles do not necessarily remain the same.

A person may become an employee, later leave that employment, remain a customer, and perhaps take on another role in the future.

The Party remains the same even as its roles change.

Next in This Series

Roles Change Over Time

Return to the Understanding Data Modeling Series Index

In data modeling, the word entity has a broad meaning.

An entity represents something of interest to the business. Depending on the business and the model, that could include people, organizations, places, things, events, transactions, concepts, and much more.

The word entity may also have a particular meaning within the business itself. An organization may already use the term as part of its established business vocabulary.

So why introduce another term?

Party does not replace the concept of Entity.

It gives us a more specific term for something we need to model.

A Party represents a person or organization whose identity matters to the business.

In that sense, Party gives us greater precision without requiring us to abandon the broader concept of Entity.

Why the Distinction Matters

That precision becomes useful when we look at the other things a business may need to model.

An order is something of interest to the business. So is a product, a location, or a transaction. Each may be represented as an entity in a model.

But people and organizations are different in an important way: they can perform roles and participate in relationships while retaining their underlying identity.

The term Party tells us that this is the kind of entity we are talking about.

That shared meaning becomes especially valuable when data crosses business processes or systems. A Customer in one context and an Employee in another may still refer to the same Party.

A Technically Sound Model Can Still Fail

But precision in the model is only part of the challenge.

A model can be technically sound and still fail.

Enterprise data models depend on a shared understanding between the people creating the model and the people whose business the model represents.

If the business already uses the word entity in a particular way, simply telling people that their terminology is wrong can create an unnecessary barrier.

The model may be accurate, but if the people who need to use it feel that their language or expertise has been dismissed, they may never accept the model.

That does not mean the modeler should simply adopt every business term without examining what it means.

The modeler’s responsibility is to listen first, understand what the business means by its terminology, and then make the concepts in the model clear and unambiguous.

Sometimes that means retaining the business term. Sometimes it means introducing a modeling term such as Party and explaining why the distinction is useful.

The goal is not to win an argument about vocabulary.

The goal is to create a model that accurately represents the business and that the business can recognize as its own.

Moving from Identity to Roles

Party gives us that precision for people and organizations.

Once we have identified the Party, the next question is what that Party does.

And the answer is not always just one thing.

A person or organization may participate in the business in several different ways at the same time.

Next in This Series

One Party, Many Roles

Return to the Understanding Data Modeling Series Index

Consider two examples.

Maria is a person. She has a name, an identity, and information that describes who she is.

Northstar Services is an organization. It also has a name, an identity, and information that describes the organization.

Maria and Northstar Services are clearly different. One is a person and the other is an organization.

But from a data modeling perspective, they have something important in common.

The business may need to recognize each of them separately from the roles they perform.

Maria might be an employee, a customer, or a volunteer.

Northstar Services might be a supplier, a customer, or a business partner.

As we saw in the previous post, those roles can change without changing the underlying identity.

The Party Model needs a common concept for representing that identity.

That concept is Party.

A Party represents a person or organization whose identity we need to distinguish from the roles that person or organization performs.

---

---

Party gives us a common way to represent identity. It does not mean that people and organizations are identical. A person and an organization have different characteristics and may require different information.

What they share is the ability to participate in the business while retaining their own identity.

Maria does not become a different person because she is both an employee and a customer. Northstar Services does not become a different organization because it is both a supplier and a business partner.

The Party remains the same. What it does can change.

A useful question is:

“Who is the person or organization, apart from the role it is performing right now?”

That question points us toward the Party.

The word Party may sound unusual, especially when Entity is already a familiar term in data modeling. So why introduce another term?

Next in This Series

Why Not Just Call It Entity?

Return to the Understanding Data Modeling Series Index

The central idea behind the Party Model is the separation of identity from role.

Identity answers the question:

“Who is this person or organization?”

Role answers a different question:

“What part does this person or organization perform in a particular business context?”

Consider a person named Maria.

Maria may be:

• An employee
• A customer
• A volunteer
• A supplier contact
• A member of a professional organization

Those are not five different people. They are five roles performed by the same person.

Information such as Maria’s name and identifying details describes the party. Information such as her employee number, customer account, volunteer assignment, or supplier responsibilities describes a particular role or relationship.

This distinction matters because roles change.

Maria may leave her employment but remain a customer. She may stop volunteering and later become a contractor. Her roles can begin, end, overlap, or change while her underlying identity remains the same.

If each role is modeled as a separate person, the organization may create duplicate records and lose the ability to recognize that those records refer to the same real-world individual.

Separating Identity from Business Context

The Party Model separates these concepts:

• Party records the identity.
• Party Role records the capacity in which the party participates.
• Party Relationship connects one party to another within a defined context.

This allows the model to preserve one identity while supporting multiple roles over time.

The distinction also helps determine what information describes the underlying identity and what information describes a particular business context.

A person’s name describes the person. An employee number describes the person’s employment context. A customer account number describes a particular customer context.

A useful test is to ask:

“Would this information still describe the person or organization if this particular role ended?”

If the answer is no, the information probably belongs with the role or relationship rather than with the party’s identity.

Next in This Series

What Is a Party?

Return to the Understanding Data Modeling Series Index

For More Information

The Party Model and the patterns discussed in this series are strongly influenced by the work of Len Silverston.

For a deeper treatment of reusable data modeling patterns, including party roles, relationships, classifications, hierarchies, and contact mechanisms, see:

Len Silverston and Paul Agnew, The Data Model Resource Book, Volume 3: Universal Patterns for Data Modeling, Wiley.

Additional articles and historical material from The Data Administration Newsletter (TDAN) are available through DATAVERSITY.

When I began working with the Party Model in 2012, Len Silverston was the first authority I turned to.

Silverston did not necessarily invent every underlying concept. Similar modeling ideas existed before his work. His important contribution was bringing those ideas together, developing them into a practical enterprise pattern, and explaining the pattern so data modelers could apply it consistently.

What Problem Was He Trying to Solve?

Organizations commonly create separate records for:

• Customer
• Employee
• Supplier
• Contractor
• Partner
• Volunteer

That seems reasonable because those are the terms the business uses. However, the same person or organization can appear in several of these categories.

A person might be both an employee and a customer. A consultant might operate through a company that is both a supplier and a business partner.

If every role is modeled separately, the enterprise may create multiple records for the same real-world person or organization.

That leads to duplicate names, addresses, telephone numbers, email addresses, and identifiers.

It also makes it difficult to determine whether several records represent different parties or the same party performing different roles.

The Party Model Begins with a Different Question

Instead of asking, “Is this a customer, employee, or supplier?” it first asks:

“Who is this person or organization?”

Once identity is established, the model can record the roles that the party performs.

That separation between identity and role is the central idea behind the Party Model.

Next in This Series

Identity and Role Are Different Questions

Return to the Understanding Data Modeling Series Index