Party Relationship Best Practices

[cjhowe]

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!

[BJ Freeman]

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!
>

[cjhowe]

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!
> >
>
>

[BJ Freeman]

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!
>>>
>>
>
>

[cjhowe]

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!
> >>>
> >>
> >
> >
>

[cjhowe]

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!
> > >>>
> > >>
> > >
> > >
> >
>
>

[BJ Freeman]

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!
>>>>>>
>>>>
>>
>
>

[BJ Freeman]

The overall party entity Model on page 66 figure 2.14
shows as an example
the party (supertype) has releationship subtype PartyFacility to Enity
Facility.
and Party (supertype) has a relationship subtype PartyContactMechanism
to contactMechanism
Paryt (Supertype) has a relationship subtype PartyRole, that realates to
  PartyRelationship to CommunicationsEvents and PartyRoleType to
PartyContactMechanism.

I am looking a diagram and it still does not make since to me, yet, so
my just giving the description must be even more confusing.



BJ Freeman sent the following on 7/23/2006 1:58 PM:

> 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!
>>>>>>>
>>>>>
>>>
>>
>>
>

[cjhowe]

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!
> >>>>>>
> >>>>
> >>
> >
> >
>

[David E Jones-2]

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!
>>>>>>>
>>>>>
>>>
>>
>>

[David E Jones-2]

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!
>>>>>>>>
>>>
>

[cjhowe]

I agree, that is why I made the list.  Many of the
instances require the one to many relationship, many
do not (PaymentMethod.partyId comes to mind,
Product.manufacturerId has been mentioned recently).
Seeing as there are 120 or so entities in that list, I
wasn't about to confirm them all myself when there
exists a community much more knowledgable about the
exact implementation.  I would appreciate as much help
in the effort as anyone can give.  The fruits of it
are of course simpler, more useful code, that's easier
to learn and finds a larger audience.

--- David E Jones <[hidden email]>
wrote:

>
> 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
>

=== message truncated ===

[cjhowe]

Just bouncing this idea around.

What if the constraints (1 to many, many to many, or
in this case each invoiceId can have one party with
role type billToParty in the table InvoiceRole) were
handled in the application layer instead? Similar to
the valid stutus change.

I'm sure there are drawbacks, and I'd love to hear
them. (I'll even accept a "that's just silly" response
on this one, as it's not based on any theory or read
literature. :) )

The benefit of this (at least in my head) is that you
wouldn't have to worry about backward compatibility
ever again with the data model (which is the biggest
problem with backward compatibility), because all
relationships would be joins and very standardized.

Additionally, describing the data model would be
extremely easy as there wouldn't be caveats all over
the place, so the learning curve would decrease
dramaticaly.

Just a thought.

=========David Jones wrote:

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

[BJ Freeman]

constraints are to make sure that there is data supporting what has been
put in one place in another place, generally speaking.
I have achieved this by using link table in a DB, that have the
relationship constraints.

so only when the link table is in  a view do you have the constraints.

THis would be a lot of two parm entities, but would satisfy almost any
linking system you want.
Then it would be a matter of building Views as the layer that is
constant for backward compatibility.

if that makes sense :\

Chris Howe sent the following on 7/24/2006 11:35 AM:

> Just bouncing this idea around.
>
> What if the constraints (1 to many, many to many, or
> in this case each invoiceId can have one party with
> role type billToParty in the table InvoiceRole) were
> handled in the application layer instead? Similar to
> the valid stutus change.
>
> I'm sure there are drawbacks, and I'd love to hear
> them. (I'll even accept a "that's just silly" response
> on this one, as it's not based on any theory or read
> literature. :) )
>
> The benefit of this (at least in my head) is that you
> wouldn't have to worry about backward compatibility
> ever again with the data model (which is the biggest
> problem with backward compatibility), because all
> relationships would be joins and very standardized.
>
> Additionally, describing the data model would be
> extremely easy as there wouldn't be caveats all over
> the place, so the learning curve would decrease
> dramaticaly.
>
> Just a thought.
>
> =========David Jones wrote:
>
> 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
>

[cjhowe]

I'm talking about the constraints being managed by a
"constraint entity", where before inputing, updating,
deleting, the entity engine checks the rules for that
associative entity.  

for example if there was a rule that said "only one
tax authority per product" your record would be:
<ConstraintEntity entity="ProductRole"
constraintType="ROLE" constraint="TAX_AUTH"
field="partyId" value="1"/>

--- BJ Freeman <[hidden email]> wrote:

> constraints are to make sure that there is data
> supporting what has been
> put in one place in another place, generally
> speaking.
> I have achieved this by using link table in a DB,
> that have the
> relationship constraints.
>
> so only when the link table is in  a view do you
> have the constraints.
>
> THis would be a lot of two parm entities, but would
> satisfy almost any
> linking system you want.
> Then it would be a matter of building Views as the
> layer that is
> constant for backward compatibility.
>
> if that makes sense :\
>
> Chris Howe sent the following on 7/24/2006 11:35 AM:
> > Just bouncing this idea around.
> >
> > What if the constraints (1 to many, many to many,
> or
> > in this case each invoiceId can have one party
> with
> > role type billToParty in the table InvoiceRole)
> were
> > handled in the application layer instead? Similar
> to
> > the valid stutus change.
> >
> > I'm sure there are drawbacks, and I'd love to hear
> > them. (I'll even accept a "that's just silly"
> response
> > on this one, as it's not based on any theory or
> read
> > literature. :) )
> >
> > The benefit of this (at least in my head) is that
> you
> > wouldn't have to worry about backward
> compatibility
> > ever again with the data model (which is the
> biggest
> > problem with backward compatibility), because all
> > relationships would be joins and very
> standardized.
> >
> > Additionally, describing the data model would be
> > extremely easy as there wouldn't be caveats all
> over
> > the place, so the learning curve would decrease
> > dramaticaly.
> >
> > Just a thought.
> >
> > =========David Jones wrote:
> >
> > 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
> >
>

[BJ Freeman]

BJ busy reading, to figure out this Constraint entity.
will check in sometime next week.
:)

Chris Howe sent the following on 7/24/2006 1:20 PM:

> I'm talking about the constraints being managed by a
> "constraint entity", where before inputing, updating,
> deleting, the entity engine checks the rules for that
> associative entity.  
>
> for example if there was a rule that said "only one
> tax authority per product" your record would be:
> <ConstraintEntity entity="ProductRole"
> constraintType="ROLE" constraint="TAX_AUTH"
> field="partyId" value="1"/>
>
> --- BJ Freeman <[hidden email]> wrote:
>
>> constraints are to make sure that there is data
>> supporting what has been
>> put in one place in another place, generally
>> speaking.
>> I have achieved this by using link table in a DB,
>> that have the
>> relationship constraints.
>>
>> so only when the link table is in  a view do you
>> have the constraints.
>>
>> THis would be a lot of two parm entities, but would
>> satisfy almost any
>> linking system you want.
>> Then it would be a matter of building Views as the
>> layer that is
>> constant for backward compatibility.
>>
>> if that makes sense :\
>>
>> Chris Howe sent the following on 7/24/2006 11:35 AM:
>>> Just bouncing this idea around.
>>>
>>> What if the constraints (1 to many, many to many,
>> or
>>> in this case each invoiceId can have one party
>> with
>>> role type billToParty in the table InvoiceRole)
>> were
>>> handled in the application layer instead? Similar
>> to
>>> the valid stutus change.
>>>
>>> I'm sure there are drawbacks, and I'd love to hear
>>> them. (I'll even accept a "that's just silly"
>> response
>>> on this one, as it's not based on any theory or
>> read
>>> literature. :) )
>>>
>>> The benefit of this (at least in my head) is that
>> you
>>> wouldn't have to worry about backward
>> compatibility
>>> ever again with the data model (which is the
>> biggest
>>> problem with backward compatibility), because all
>>> relationships would be joins and very
>> standardized.
>>> Additionally, describing the data model would be
>>> extremely easy as there wouldn't be caveats all
>> over
>>> the place, so the learning curve would decrease
>>> dramaticaly.
>>>
>>> Just a thought.
>>>
>>> =========David Jones wrote:
>>>
>>> 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
>>>
>
>