Modeler’s Corner is our series of blog posts on best practices and practical tips & tricks for all you Ellie modelers out there. The series focuses on everyday issues you might face as a Data Modeler. We aim to help you build the most informative, understandable, and efficient business-driven models with Ellie. For more comprehensive training needs, don’t hesitate to ask us!

Roles and Subtypes – how to do it and what’s the difference?

Previously in our Modeler’s Corner series, we covered subtypes and supertypes, a powerful modeling pattern for situations where an entity has recognizable kinds of it while still maintaining some commonalities. It’s a must-have for every data modeler’s toolbox – but occasionally you’ll run into something that almost feels like a subtype situation but doesn’t quite seem to fit. That means you’ve probably encountered roles.

In this Modeler’s Corner entry, we’ll cover roles – what they are, how they differ from subtypes, and what we think you should do with them. Interestingly, we find that whereas identifying your entities in the first place is where the most fundamental modeling mistakes tend to happen, the roles-versus-subtypes issue is perhaps the most usual reason for “technical” modeling errors. Read on to find out how to get it right!

What are roles?

In the context of conceptual data modeling (which is what this blog series is all about!), “roles” are basically different ways an entity can interact with other entities. Consider an example: insurance policies and people involved with them. There are multiple people involved in different roles:

• Policyholder – the person insured and the “official” insured
• Claimant – the person requesting payments from the insurance company
• Additional insured – someone other than the policyholder who is still insured within the same policy
• Beneficiary – the person who will benefit from the insurance, i.e. actually get money

Any single person could be in any of the roles – including combinations, such as being the policyholder and the beneficiary at the same time.

If you now consider our entities to be “Insurance Policy” and “Person”, you’ll see how there are at least these 4 different ways in which a Person might interact with an Insurance Policy. These are the roles a person can take in our insurance model.

What are the differences between roles and subtypes?

Now, if you have read our previous post on subtypes, you might feel the urge to define our above examples simply as subtypes of the Person entity – after all, aren’t they types of Person? However, this would be a major mistake!

The important distinction between roles and subtypes is that whereas subtypes are always mandatory and mutually exclusive, roles are neither. An instance of an entity (an individual person, for example) can only ever represent a single subtype – and it must always represent one subtype. With roles, this is not true. An individual person can act in multiple roles at the same time: someone might be both the policyholder and the beneficiary of the same insurance policy, while also acting as a claimant on a separate policy.

Thus, roles are always optional. This also means that we need to have a different way to represent roles in our models – Ellie’s box-in-a-box notation is reserved for subtypes. It turns out there are in fact many different ways of doing that, and while all are “correct”, not all of them are equally good in all situations.

3 ways to model roles – and our recommendations

Modeling roles as relationships

We said that “roles are basically different ways an entity can interact with other entities”, and if that sounds like relationships to you, that’s perfectly understandable. Modeling roles as relationships means that when an entity (“Person”) interacts with another entity (“Insurance Policy”) in different ways, you draw a relationship line between them – one for each way of interaction.

This makes your model structurally very simple. You have your core entities, you have your relationships, and all the different interactions are identified as separate relationships with clear naming (you wouldn’t use multiple relationships without naming them, would you?). The roles are visible and understandable.

The problem with this model is that you cannot express anything else about the roles. What if you have different attributes for the primary policyholders and the claimants? What if the people who are claimants should be linked with claim events, but the other non-claimants obviously shouldn’t? The model is simple – but in many situations, perhaps too simple.

Modeling roles as a bridge entity

Some of the more technically oriented among us might perhaps balk at the relationship-based model above because it implies a lot of foreign key attributes between the same two entities (this would come up when creating a more detailed logical model – which is by the way something that you can soon do with Ellie!). What if we come up with a new role?A more generic and future-proof way would be to model the roles as a “bridge entity”, as these things tend to be called. In this separate entity, you would have the links between Persons and Insurance Policies, as well as the type of link, meaning the role.

Now you have a model which can handle any number of roles, with no changes whatsoever no matter how many roles you add later. The “Person-Insurance Policy role type” reference entity contains all the possible role types (in our case: policyholder, claimant, additional insured, and beneficiary).

Technically, this is very well optimized and powerful. But take a step back and consider what it looks like from a business perspective: what on Earth is a “Person-Insurance Policy role”? Where are the claimants, asks your business expert? You have created a model that describes a technically nice solution, but in the process loses almost all contact with real business.

Some of the key reasons why we do conceptual modeling are improved communication and common understanding. This model forfeits those aspects in favor of technical detail, and should therefore be considered only as a possible implementation alternative on lower-level logical and physical models.