On 5/30/07, Chris Travers <[EMAIL PROTECTED]> 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
--
The Last Great Frontier is in Your Mind
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
