Re: Party Relationship Best Practices

Posted by David E Jones-2 on
URL: http://ofbiz.116.s1.nabble.com/Party-Relationship-Best-Practices-tp170029p170043.html


These look like accurate definitions from the books.

The thing to keep in mind with these definitions, and with the data model resource books in general, is that they describe a conceptual data model, not a "physical" data model (ie the one which is actually in the database). Silverston makes this clear in the introduction.

So, that's a good thing to keep in mind for these word definitions as well. Based on that remember than "entity" in the Silverston sense is _not_ quite the same as an entity in OFBiz. They are similar on one level, but only as much as the conceptual data model correlates with the physical data model.

-David


BJ Freeman wrote:

> Chris Thanks.
> BTW I just got the two modeling books. So I am now trying to use the
> correct terminology.
> Beyond entity there is supertypes entities, subtypes (exclusive and non
> exclusive)entities, Attributes, Relationships, intersection, and
> Association.
>
>  From the book Vol 1 pages 8-12
> An entity, is something Significant about which the Enterprise wishes to
> store information.
> A subtype is a classification of an entity that has characteristics,
> such as attributes or relationships in common with more general entities.
> An Attribute holds a particular piece of information about the entity.
> A relationship defines how two entities are associated.
>
> rest is not from the book parse.
> the relationships have foreingKeys and is defined as the presence of
> another entities primary ID in a Entity. BTW silverstone does equate
> tables to entities.
>
> So with that as a frame work, what is it you are showing?
>
>
>
> Chris Howe sent the following on 7/23/2006 1:24 PM:
>> After rereading that website, it should be entity (not
>> entity table) and associative entity (not relationship
>> table).
>>
>> --- Chris Howe <[hidden email]> wrote:
>>
>>> Let me retract the use of the word "Object" and
>>> replace it with "Entity".  I didn't use "entity"
>>> initially because the mailing list has used the word
>>> entity to refer to any table in the data model which
>>> is broader than what I'm describing.
>>>
>>> Entity tables: Invoice, Product, ProductCategory,
>>> BillingAccount, etc
>>>
>>> differs from Relationship tables
>>> Relationship tables: InvoiceRole,
>>> ProductCategoryRole,
>>> BillingAccountRole, etc.
>>>
>>> All of the tables that end in "Role" describe the
>>> relationship between the prefix Entity (ie
>>> InvoiceRole, the prefix is Inovice) and the entity
>>> "Party".
>>>
>>>
>>> This site is similar to how I understand the actual
>>> semantics of this type of discussion.  If it will
>>> make
>>> it easier, I will use word choice from it.
>>>
>> http://www.utexas.edu/its/windows/database/datamodeling/
>>> --- BJ Freeman <[hidden email]> wrote:
>>>
>>>> I know that means something to you, but does not
>>>> convey much to me.
>>>> At least as far as how you see Objects in
>>> Entities.
>>>> At this point not trying to get into weather they
>>>> should or should not be changed, just the semantics.
>>>>
>>>> Chris Howe sent the following on 7/23/2006 8:56
>>> AM:
>>>>> ie BillingAccountRole, ProductCategoryRole,
>>>>> BudgetRole, InvoiceRole, etc
>>>>>
>>>>> --- BJ Freeman <[hidden email]> wrote:
>>>>>
>>>>>> When I read about "OBJECT", from a programming
>>>> point
>>>>>> of view, I have an
>>>>>> entirely different perspective than the Entity
>>>>>> Definition In the Data
>>>>>> model books they are based on.
>>>>>>
>>>>>> So could you define your terms, maybe give an
>>>>>> example of what this is about.
>>>>>>
>>>>>> It would help for clearer communication, IMHO.
>>>>>>
>>>>>> Chris Howe sent the following on 7/22/2006
>>> 11:38
>>>> PM:
>>>>>>> In the wiki http://docs.ofbiz.org/x/ZAE , I
>>> have
>>>>>>> listed all of the entities that do not comply
>>>> with
>>>>>> the
>>>>>>> ObjectRole entity approach of showing a
>>>>>> relationship
>>>>>>> between a party and an object.
>>>>>>>
>>>>>>> Some of these implementations may be just
>>> fine.
>>>>>> Some
>>>>>>> of the implementations may have been done
>>> before
>>>>>>> utilization of the ObjectRole type of entity.
>>>>>> Some of
>>>>>>> these entities may not make sense to use the
>>>>>>> ObjectRole approach.
>>>>>>>
>>>>>>> Whatever the case, I would appreciate any
>>>> feedback
>>>>>> on
>>>>>>> each of these entities that knowledgable
>>> people
>>>>>> can
>>>>>>> offer.
>>>>>>>
>>>>>>> Once it is determined that the ObjectRole
>>> entity
>>>>>> would
>>>>>>> be a better approach for an entity, we can
>>> make
>>>> a
>>>>>> JIRA
>>>>>>> issue for it and tackle the upgrade.
>>>>>>>
>>>>>>> Thanks all!
>>>>>>>
>>>>>
>>>
>>
>>