Re: ID field as logical address

On Jun 3, 4:06 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> > The relation variable changes its state from one set of statements to
> > a different one. No one should care which tuple was replaced by which
> > tuple. It is just a new set of statements consistent with the current
> > state of the database.
>
> I disagree. It is my contention that each tuple in a database--regardless
> of whether it is in a base or a derived relation--maps to some thing in the
> Universe of Discourse but no two tuples in the same database map to exactly
> the same thing. When presented with a proposed database, there must be some
> mechanism to correlate the things that each tuple in the current database
> maps to with the things that each tuple in the proposed database maps to.
> Keys are not sufficient because their scope is /each/ possible relation for
> a relation schema instead of /every/ possible relation. In the example,
> this is evidenced by the fact that the Mary Smith at one database may not be
> the Mary Smith at its successor. As a consequence, a join of a relation in
> the proposed database to its corresponding relation in the current database
> would compare the appearances of two different people instead of two
> appearances of the same person. It is only when every instance of every key
> permanently identifies some thing in the Universe that such a join can be
> considered valid, and that severely limits the expressiveness of the model.
> If, on the other hand, we simply make use of the information supplied by the
> user when they issue deletes, inserts and updates, then there is no need for
> the join because the requisite correlation of old to new values is in fact
> supplied.

Well, I think there are two different views (or understandings) of the same problem.

When looking at the Employees and the Department relations one might see a collection of objects (or entities) and a collection of references to employees working in one department. Hence the need to uniquely identify an entity.

However when looking at the Employees and Departments I see two sets of statements, one about employees and one about employees that are known to work in a certain department. The foreign key tells me that the Mary Smith in the statement “Mary Smith works in HR department” is the same as Mary Smith in the statement “Mary Smith is single”. To me they are just statements and not objects, that’s why they don’t need identities.

Continuing with examples, if we fire Mary Smith without removing the information from Departments, and add in the same time a new Mary Smith in the Employee, the update will be perfectly valid. The constraint happen to be satisfied so there is no reason to reject the change.

Now, while the database is consistent, the information does not reflect reality. But it is not system’s fault, it is ours because we made a mistake by not deleting the information from Departments. A database reflects what was told. It just records the statements we made if they conform to some constraints. It is our job to make sure that we tell it the truth.

The system doesn’t care which Mary Smith we are talking about since all the constraints are fulfilled. And it doesn’t care that there was sometime another Mary Smith that worked for the company. If such kind of information is required, then it is the designer job to model the database in such way. Received on Wed Jun 03 2009 - 16:49:05 CEST