TABLE OF CONTENTS Both of Dr. Codd's relational models do not allow duplicate rows and are based on a set theoretical model. SQL has always allowed duplicate rows and is based on a multiset or bag model.
When the question of duplicates came up in SQL committee, we decided to leave it in the Standard. The example we used internally, and which Len Gallagher used in a reply letter to Database Programming & Design magazine and David Beech used in a letter to Datamation, was a cash register receipt with multiple occurrences of cans of cat food on it. Because of this example, the literature now refers to this as the "cat food problem."
The fundamental question is: What are you modeling in a table? Dr. Codd and Chris Date's position is that a table is a collection of facts. The other position is that a table can represent an entity, a class, or a relationship among entities. With that approach, a duplicate row means more than one occurrence of an entity. This leads to a more object-oriented view of data, where I have to deal with different fundamental relationships among duplicates, such as:
Identity = "Clark Kent is Superman!" We really have only one entity, but multiple expressions of it. These expression are not substitutable (Clark Kent does not fly until he changes into Superman).
Equality = "Two plus...
