On 5/30/07, Chris Travers <..hidden..> wrote:
Ok. Think of an entity as a "legal person" (corporate or natural) and
a contact as a "natural person."
Yes, I assume that a 'Contact' is a contact for an Entity. So Chris Travers can be the contact for Chris Travers. As a physical design issue you might consider Name on Contact to be NULL, or conversely redundantly store the same data value for Name on Entity and Contact.
The idea is that each entity has one
primary class and may have many auxiliary classes. So an entity can
be a customer, a vendor, etc. all at once.
Fine. You just need to decide on a similar physical design issue as above, once you get to the physical model, ie do you store the primary class in the intersect table to Class as well as in the Entity table.
> 2. The term and term fragment "class" (assuming it means "our way of
> classifying the entities") might be better understood using the term
> and term fragment "role". Term fragments class/group/type are all
> shallow terms in entity/logical modelling. What we want to know is WHY
> we are classifying/grouping/typifying an entity.
Think of possible classes as any of (lead, customer, vendor, member,
any that might be added later).
As long as the later values are mutually exclusive, otherwise it is merging types of classifications into one modelling entity (called 'class'), and is going to cause grief. In fact its a basic no-no in modelling.
I tend to think of "role" as being
somethign that defines what something defines what something does,
Yes, like 'Sell', ie a vendor, or 'Buy' ie a customer. That is what I am saying.
while this allows us to essentially categorize legal persons with
whome we do business or intend to do such business.
Wouldn't that get confusing when we implement "role-level security" for users?
Yes and no.
1. You already are using the term Entity and Class in both the modelling/system development domain and also the application/end user domain. It has probably confused some already.
2. Yes, therefore to differentiate the two, refine the terms further. 1. is concerned with "runtime end-user role" focussing on who is accessing the system and the other "business-role" focussing on Entities and the relationship they have to the Entity whose accounts are being kept.
Since Role is intended to be used elsewhere, I would
suggest we stick with class.
I do not think Class is a term that application end-users would so readily relate to. Then again, I am probably continuing to think of end-users as not being software-techoes, and this is a difference I think we have argued before.
At the end of the day I am sure you will build an application that makes sense to yourself.
Cheers
David