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-12An 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 <[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 inEntities.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:56AM:ie BillingAccountRole, ProductCategoryRole, BudgetRole, InvoiceRole, etc --- BJ Freeman <[EMAIL PROTECTED]> wrote:When I read about "OBJECT", from a programmingpointof 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/200611:38PM:In the wiki http://docs.ofbiz.org/x/ZAE , Ihavelisted all of the entities that do not complywiththeObjectRole entity approach of showing arelationshipbetween a party and an object. Some of these implementations may be justfine.Someof the implementations may have been donebeforeutilization of the ObjectRole type of entity.Some ofthese entities may not make sense to use the ObjectRole approach. Whatever the case, I would appreciate anyfeedbackoneach of these entities that knowledgablepeoplecanoffer. Once it is determined that the ObjectRoleentitywouldbe a better approach for an entity, we canmakeaJIRAissue for it and tackle the upgrade. Thanks all!
smime.p7s
Description: S/MIME Cryptographic Signature
