Note: To demonstrate the stability afforded by a sound foundation relative to the industry's fad-driven cookbook practices, I am re-publishing under "Oldies But Goodies" material from the old DBDebunk.com (2000-06), so that you can judge for yourself how well my debunkings hold up, and whether the industry has progressed beyond the misconceptions they were intended to dispel. I may break long pieces into more pointed parts, and add comments and references to further reading.
From "Little Relationship to Relational" originally posted on March 29, 2001.
“Given the depth and complexity of Codd's thought, not to mention the arcane terms in which he often expressed himself, it is not difficult to grasp why so many of his key points have been widely misunderstood. Even programmers still often misconstrue the technical term "relational". The relational in relational theory refers to relations and not relationships. A relation is a special set of similar objects commonly modeled as entities or as database tables. Relationships may exist between these relations and if your relations are entities you could easily represent the whole thing using a Relational Entity Relationship approach. To elucidate a simple practical example, if you had a company table and an employee table and each company record could have many employee records associated with it, you would have two relations and one relationship. The relations would be the sets of similar objects found in the Employee and Company tables and the relationship would be the association between them. In this case one company to many employees.”Codd's thought was very deep indeed--new implications are still being derived from his original ideas--and one major objective of relational technology, now almost forgotten, is simplicity. There is little that is complex in relational technology and, in fact, it is the most simple approach possible. Any other general approach is more complex.
It is true that Codd, as a mathematician, did not present his ideas in a way comprehensible to the average practitioner. But it is also true that he had to use different terminology in order to distinguish his precise concepts from the fuzzy, problematic terms already used in the industry. It is also true that, as I argued in the first editorial launching this site, practitioners are so steeped in complex implementation details and devoid of education in fundamentals, that they have a hard time understanding simple logical concepts. It is rather ironic that the author of the article himself reveals some misunderstanding of his own. To clarify:
- formally a relation is a set of tuples, representing propositions about the real world.
- informally, a relational table can be viewed as representing an "entity type", with rows representing "entities" of that type.
- "entity" has no precise, formal definition
- "relationship" can and should be regarded as a special case of "entity"
Comments on re-publication:
- A relation is a relationship among domains that is constrained semantically to represent in the database real world relationships within and among entity groups.
- We no longer use R-table as a substitute for relation -- it is a visualization of a relation on some physical medium that plays no role in RDM. Note that constraints are not visible in a R-table.
- A relationship can be (1) among entities within an entity group, in which case it is a collective property of the group and is represented by a constraint or (2) between groups, in which case it is represented by an associative relation.
Further Reading
The Interpretation and Representation of Database Relations (Codd 1969-70)
Logical Symmetric Access, Data Sublanguage, Kinds of Relations, Redundancy and Consistency (Codd 1969-70)
What Relations Really Are and Why They Are Important
Understanding Relations series
Levels of Representation: Conceptual Modeling, Logical Database Design and Physical Implementation
Understanding Conceptual vs. Data Modeling series
Conceptual Modeling Is Not Data Modeling
Relationships and the RDM series
Relations & Relationships
Relationships, Rules, Relations and Constraints
What Is A Database Relationship
No comments:
Post a Comment