Posted by
cjhowe on
URL: http://ofbiz.116.s1.nabble.com/Party-Relationship-Best-Practices-tp170029p170040.html
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.jpgBecause 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.
> >>
> >
>
> >> --- 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!
> >>>>>>
> >>>>
> >>
> >
> >
>