You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Chris Howe <cj...@yahoo.com> on 2006/07/23 08:38:01 UTC
Party Relationship Best Practices
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!
Re: Party Relationship Best Practices
Posted by David E Jones <jo...@undersunconsulting.com>.
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 <cj...@yahoo.com> 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 <bj...@free-man.net> 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 <bj...@free-man.net> 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!
>>>>>>>
>>>>>
>>>
>>
>>
Re: Party Relationship Best Practices
Posted by BJ Freeman <bj...@free-man.net>.
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 <cj...@yahoo.com> 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 <bj...@free-man.net> 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 <bj...@free-man.net> 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!
>>>>>>>
>>>>>
>>>
>>
>>
>
Re: Party Relationship Best Practices
Posted by Chris Howe <cj...@yahoo.com>.
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 <jo...@undersunconsulting.com>
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 <bj...@free-man.net> 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 <cj...@yahoo.com> 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 <bj...@free-man.net> 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 <bj...@free-man.net> 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 ===
Re: Party Relationship Best Practices
Posted by David E Jones <jo...@undersunconsulting.com>.
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 <bj...@free-man.net> 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 <cj...@yahoo.com> 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 <bj...@free-man.net> 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 <bj...@free-man.net> 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!
>>>>>>>>
>>>
>
Re: Party Relationship Best Practices
Posted by Chris Howe <cj...@yahoo.com>.
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 <bj...@free-man.net> 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 <cj...@yahoo.com> 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 <bj...@free-man.net> 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 <bj...@free-man.net> 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!
> >>>>>>
> >>>>
> >>
> >
> >
>
Re: Party Relationship Best Practices
Posted by BJ Freeman <bj...@free-man.net>.
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 <cj...@yahoo.com> 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 <bj...@free-man.net> 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 <bj...@free-man.net> 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!
>>>>>>
>>>>
>>
>
>
Re: Party Relationship Best Practices
Posted by Chris Howe <cj...@yahoo.com>.
After rereading that website, it should be entity (not
entity table) and associative entity (not relationship
table).
--- Chris Howe <cj...@yahoo.com> 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 <bj...@free-man.net> 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 <bj...@free-man.net> 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!
> > >>>
> > >>
> > >
> > >
> >
>
>
Re: Party Relationship Best Practices
Posted by Chris Howe <cj...@yahoo.com>.
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 <bj...@free-man.net> 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 <bj...@free-man.net> 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!
> >>>
> >>
> >
> >
>
Re: Party Relationship Best Practices
Posted by BJ Freeman <bj...@free-man.net>.
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 <bj...@free-man.net> 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!
>>>
>>
>
>
Re: Party Relationship Best Practices
Posted by Chris Howe <cj...@yahoo.com>.
ie BillingAccountRole, ProductCategoryRole,
BudgetRole, InvoiceRole, etc
--- BJ Freeman <bj...@free-man.net> 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!
> >
>
>
Re: Party Relationship Best Practices
Posted by BJ Freeman <bj...@free-man.net>.
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!
>