Dave Hay commented on my post How Many Attributes Do I Have? Dave notes that there is a difference between me and the roles that I play. This is an important point that I struggled with previously. Dave states "most of the examples are attributes of my role as a customer", meaning the examples I provided in my post.
"Role" is a term that gets bandied around a lot in data modeling. In my previous post on Role vs. Relationship I argued that roles really refer to certain kinds of relationships. However, Dave's point is one that I have heard on a lot of occasions and has to be taken seriously.
Let's state the question this way: is the attribute Customer Lifetime Value to Hardbitten Liquors an attribute of me, or an attribute of my role as a customer of Hardbitten Liquors? And if the latter, just what do we mean by "role".
There is no doubt that I am an instance of a concept. The concept is human being. Further, Customer Lifetime Value to Hardbitten Liquors can be predicated of me, strongly suggesting it is an attribute I possess.
But now let us think of the role that is being suggested in this discussion. What is it? Is this role "Customer of Hardbitten Liquors"? If so, I would argue that this is a relationship between me and Hardbitten Liquors. And if an entity type has attributes, and relationships do not, then we cannot say that a role has any attributes.
But suppose Dave is right and the role does have attributes. It will have to be an entity of some kind. What other thing could the role be - apart from "human being". There is a possibility. Suppose I only ever bought one bottle of Grandpa's Tipple from Hardbitten Liquors. Then, my entire relationship with Hardbitten Liquors could be encompassed by this one event - the purchase of this one bottle. Now, Purchase is an entity type, albeit non-material, so it can at least be a candidate for the role.
But can Purchase really be the same as role? I do not think that an event can have an attribute such as Customer Lifetime Value to Hardbitten Liquors, which really refers to the individual customer. And I do not think this can be true of any aggregate of instances of Purchase events either, supposing, for instance, that I buy one bottle of Grandpa's Tipple every week.
See my posts, "Is there anything left after all the roles are stripped away?"[1] and "Shakespeare is (not) Shakespeare"[2] for my musings on this topic. A large key to your question is the topic of Identity.
ReplyDelete[1] http://www.existentialprogramming.com/2008/02/is-there-anything-left-after-all-roles.html
[2] http://www.existentialprogramming.com/2007/12/shakespeare-is-not-shakespeare.html
P.S. 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.
ReplyDeleteIf 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...
http://www.existentialprogramming.com/2010/05/hole-for-every-component-and-every.html
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)