Wednesday, December 28, 2011

Role versus Relationship - What Does it Mean for Definitions?

A couple of days ago I was reading some material on a semantics product and came upon the term "role".  We see role used in data modeling where a primary key migrated into a child entity can be assigned a "role name".  This is the name by which the attribute is known in the child entity, and is useful to disambiguate the same attribute migrated for other relationships between the same two entities.

You also hear about "role" in the party model.  Rather than say that Unindicted Broker is a client of Overleveraged Bank, and that Unindicted Broker is a prime broker for Overleveraged Bank, we can say that Unindicted Broker is a party that plays two roles with Overleveraged Bank: (a) client; and (b) prime broker.

I think that there are deeper issues here.  We think of a relationship in a data model as a line between two entities.  We cannot allocate attributes to the relationship as we can to entities.  Our notations, methodologies, and tools will not allows it (at least the commonly used ones).  Furthermore, it is relatively rare to find multiple relationships between the same entities.  When we do find quite different relationships between the same two entities we seem to start thinking of roles.

Now, a relationship is a concept, and therefore must have a description and hopefully a definition.  If a relationship can have a definition, it must have characteristics (qualities, i.e. attributes). This worries me somewhat as relation and quality are two Aristotelian categories and one should not be reducible to the other.  However, I cannot find the theoretical foundation for what I am describing.

A further issue is that what we are calling a relationship such as "Unindicted Broker is a client of Overleveraged Bank" is a generalization about a lot of processes.  Unindicted Broker had to be solicited to be a client, then onboarded as a client, and then assessed in terms of how the relationship would be managed.  All of these processes come under the umbrella of "Unindicted Broker is a client of Overleveraged Bank" but break down to many more detailed entities and relationships. So "Unindicted Broker is a client of Overleveraged Bank" is a generalization, although it is valid.

So where does this leave us?  Not very far I am afraid, but we can begin to see the outlines of the problem.  The term "role" is used in semantics, but it is not clear if it is used technically or informally.  "Role" exists in data modeling, but is for refining names of attributes associated with relations.  And "role" exists in the party model, for "high-level" relationships.  There is some evidence that relations can be broken down into more detailed entities and relations that may serve to describe a role.  Ultimately it does seem that roles can be resolved into sets of entities and relationships at the data model level.  However, at the level of semantics it is not clear how they can be treated as other than relationships.

A role does seem to demand a definition that is greater than what is to be supplied for a "regular" relationship.  A role must be distinct from other roles, or you could argue it should be collapsed with its sibling roles into one role. So at least we can conclude that if we have identified a role we need to provide it with a good enough definition to provide such distinction.  Obviously, there is a lot more to this, but that is enough for now. 


  1. Perhaps we should abandon the concept of relationship and use the concept of connections similar to a network connection. Since relationships are mostly temporal (marriage/divorce, friend/defriend) I think connections more accurately reflect the natural states between entities.

  2. First of all, it is quite normal to have attributes of relationships in database E/R models...

    Second, you are correct that roles are more than relationships. A role is an entity placeholder in a complex set of relationships with other roles/entities that is often called a Framework. Think of the roles and relationships between them in the "restaurant" framework: waitress, cook, customer, busboy, menu, food, money, bill, etc, etc.

    If you ever see a role being defined by itself, it is an (over)simplification of an entire framework (just as all models are simplifications of the real world). The relationship between the terms "role" and "entity", is analogous to the relationship between a socket on a circuit board and the chip that gets plugged into it.
    See my post about Components not existing (by themselves) in the same way that donut holes dont exist...

    Object Oriented Programming (ala Java) has the concept of Interface which is in the same ballpark as Role. E.G. X performs role ("implements interface") CUSTOMER versus X is a kind of ("extends class") PERSON [or CORPORATION]. But even THAT example shows the problem of over simplification...I said X performs Customer role when I really should have said X acts as role:customer in the framework:business where FOO-BANK acts as role:vendor.

    Roles (and whole frameworks) are also just like classes in that one can model at multiple levels of abstraction; mammal versus human and monkey, service-provider versus bank and bakery, bank-customer versus borrower and depositor. (Facility versus Loan and Line of Credit)