Re: Party Relationship Best Practices

Posted by cjhowe on
URL: http://ofbiz.116.s1.nabble.com/Party-Relationship-Best-Practices-tp170029p170042.html

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