Re: Party Relationship Best Practices

[David E Jones]

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

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 <[EMAIL PROTECTED]> wrote:

implementation of party relationships. 1) There is no defined enterprise.

Chris Thanks.
BTW I just got the two modeling books. So I am now

Beyond entity there is supertypes entities, subtypes


 From the book Vol 1 pages 8-12
An entity, is something Significant about which the

A subtype is a classification of an entity that has

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


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:

trying to use the correct terminology. (exclusive and non exclusive)entities, Attributes, Relationships, intersection, and Association. Enterprise wishes to store information. characteristics, such as attributes or relationships in common with the presence of another entities primary ID in a Entity. BTW silverstone does equate tables to entities.

After rereading that website, it should be entity

(not

entity table) and associative entity (not

relationship

table).

--- Chris Howe <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:

When I read about "OBJECT", from a programming

point

of view, I have an
entirely different perspective than the Entity
Definition In the Data
model books they are based on.

So could you define your terms, maybe give an
example of what this is about.

It would help for clearer communication, IMHO.

Chris Howe sent the following on 7/22/2006

11:38

PM:

In the wiki http://docs.ofbiz.org/x/ZAE , I

have

listed all of the entities that do not comply

with

the

ObjectRole entity approach of showing a

relationship

between a party and an object.

Some of these implementations may be just

fine.

Some

of the implementations may have been done

before

utilization of the ObjectRole type of entity.

Some of

these entities may not make sense to use the
ObjectRole approach.

Whatever the case, I would appreciate any

feedback

on

each of these entities that knowledgable

people

can

offer.

Once it is determined that the ObjectRole

entity

would

be a better approach for an entity, we can

make

a

JIRA

issue for it and tackle the upgrade.

Thanks all!

smime.p7s
Description: S/MIME Cryptographic Signature