Re: Does entity integrity imply entity identity?

Walter Mitty wrote:

>"Mr. Scott" <do_not_reply_at_noone.com> wrote in message
>news:jrydnWYowLOIIurXnZ2dnUVZ_vmdnZ2d_at_giganews.com...

>>> Here's the way I learned it, back in 1984.
>>>
>>> Each row in a table represents either an instance of an entity or an
>>> instance of a relationship between or among entities. I'm not sure
>>> whether or not "represents" in my wording is equivalent to "maps to" in
>>> your wording.
>>
>> Isn't an instance of a relationship between or among entities also an
>> entity?
>>
>That's a real good question. My answer is, not necessarily. Some
>practicioners of ER modeling claim that relationships cannot have
>attributes, so if there's an attribute that belongs to a relationship, we
>redefine the relationship to be an entity. (Example: the enrollment status
>of a student enrolled in a course, where enrollment status could be "wait
>listed").

Even if relationships have attributes, the main difference is that (strong) entities are entirely identified by their own attributes, while relationships are entirely identified by (the identifying attributes of) the entities they relate. I.e. the key of a relationship is a combination of foreign keys of the entities it relates.

>In some cases, the subject matter experts treat the relationship as a
>"thing" in and of itself. (Example: a confirmation for a rental car. It
>has a "confirmation number" and is therefore identified as a "thing").

It's a "thing" because of this identifiability. It's a noun, while a relationship is a verb - except that natural language supports much more complex data modeling than ER modeling.

>In both cases this is somewhat subjective. There is a fancy word for
>treating a relationship as an entity. It's called "reification".

With reification, relationships may relate other relationships, but the difference in how relationships and entities are identified remains.

>At a lower level, many database designers (particularly ones who deal with
>SQL server) create an autogenerated first column called "ID", and make that
>the primary key for every last table. I think that's a mistake, but that's
>another discussion.

And at a higher level, it is possible to have an ER model in which not all the identifying attributes have yet been specified. In formalizing such partial models, similar "ID attributes" may appear but that doesn't imply they will exist in the database design.

-- 
Reinier