This is a 06/18/17 rewrite of a 04/14/13 to bring it in line with the McGoveran interpretation of Codd's RDM[1].

Similarly, as we have explained, some object group properties arise from relationships among individual properties of its members and/or among the members themselves[4]. And a relationship can be modeled as an object, with properties of its own. For example, the relationship between a supplier and a part can be modeled as an object--a relationship object, with quantity as a property. On the other hand, a relationship can also be perceived as a property. For example, the relationships between supplies and suppliers and parts can be modeled with referencing properties. The distinction that the Entity/Relationship Model (E/RM) approach makes is unnecessary and contributes to the confusion[5]. Therefore, Kent should not be interpreted to mean that modeling choices, once made, are confusing, but rather that they are "in the eye of the beholder", so to speak--there is usefulness, not correctness. (Kent's book is a must-read Recommended Book). Otherwise put, make the most useful choice and strive for parsimony, explicitness, well-definedness, and consistency.

Read it all 

Do you like this post? Please link back to this article by copying one of the codes below.

URL: http://www.dbdebunk.com/2017/06/unmuddling-modeling-part-i-relations.html HTML link code: <a href="http://www.dbdebunk.com/2017/06/unmuddling-modeling-part-i-relations.html">Relations & Relationships Part I</a> BB (forum) link code: [url=http://www.dbdebunk.com/2017/06/unmuddling-modeling-part-i-relations.html]Relations & Relationships Part I[/url]