Re: Party Relationship Best Practices
Posted by David E Jones-2 on
URL: http://ofbiz.116.s1.nabble.com/Party-Relationship-Best-Practices-tp170029p170041.html
I'm not going to comment on this extensively because of time, but I just wanted you (Chris) to know that I have read over these messages.
It looks like the model you are describing is that of a "join" entity that implements a many-to-many relationship between two other entities.
The only comment I have on this for Party and PartyRole relating to other entities is that we don't always want a many-to-many relationship. In many cases we want a one-to-many relationship and it would cause problems and lack of clarity in the data model to do otherwise.
-David
Chris Howe wrote:
> Thanks BJ. Those are good definitions to use.
> When looking at OFBiz there are a couple of
> incongruencies when applying those definitions but I
> will only go into the one that is relevent to the
> implementation of party relationships.
>
> 1) There is no defined enterprise.
>
> This isn't necessarily a bad thing, just means that
> when you come across something significant that one
> would want to store information on, we need to
> implement it as generic as possible or as generic as
> makes sense given some knowledge of the information.
>
> The most generic implementation possible is the
> following:
>
> http://aycu26.webshots.com/image/3545/1360379278212478564_rs.jpg
>
> Because we can't possibly forsee how someone would
> want to associate a party with something significant
> (SampleEntity in the picture) this model has been used
> extensively throughout OFBiz using the _Role as the
> associative entity and Party as SampleEntity1.
>
> The list in the wiki contains entities that on first
> glance do not follow this implementation model when
> associating a party with something significant.
>
> There may be implementations in that list that are
> perfectly fine, perhaps even superior in their use
> over this model. However, this model appears to be
> the best practice. When something is implemented
> outside of the best practice, the reasons the approach
> was chosen should be documented and reevaluated as
> technologies improve.
>
>
> --- BJ Freeman <[hidden email]> 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!
>>>>>>>>
>>>
>
URL: http://ofbiz.116.s1.nabble.com/Party-Relationship-Best-Practices-tp170029p170041.html
I'm not going to comment on this extensively because of time, but I just wanted you (Chris) to know that I have read over these messages.
It looks like the model you are describing is that of a "join" entity that implements a many-to-many relationship between two other entities.
The only comment I have on this for Party and PartyRole relating to other entities is that we don't always want a many-to-many relationship. In many cases we want a one-to-many relationship and it would cause problems and lack of clarity in the data model to do otherwise.
-David
Chris Howe wrote:
> Thanks BJ. Those are good definitions to use.
> When looking at OFBiz there are a couple of
> incongruencies when applying those definitions but I
> will only go into the one that is relevent to the
> implementation of party relationships.
>
> 1) There is no defined enterprise.
>
> This isn't necessarily a bad thing, just means that
> when you come across something significant that one
> would want to store information on, we need to
> implement it as generic as possible or as generic as
> makes sense given some knowledge of the information.
>
> The most generic implementation possible is the
> following:
>
> http://aycu26.webshots.com/image/3545/1360379278212478564_rs.jpg
>
> Because we can't possibly forsee how someone would
> want to associate a party with something significant
> (SampleEntity in the picture) this model has been used
> extensively throughout OFBiz using the _Role as the
> associative entity and Party as SampleEntity1.
>
> The list in the wiki contains entities that on first
> glance do not follow this implementation model when
> associating a party with something significant.
>
> There may be implementations in that list that are
> perfectly fine, perhaps even superior in their use
> over this model. However, this model appears to be
> the best practice. When something is implemented
> outside of the best practice, the reasons the approach
> was chosen should be documented and reevaluated as
> technologies improve.
>
>
> --- BJ Freeman <[hidden email]> 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!
>>>>>>>>
>>>
>
smime.p7s (4K) | Free forum by Nabble | Edit this page |