Re: Extending my question. Was: The relational model and relational

From: Steve Kass <>
Date: Tue, 18 Feb 2003 17:10:10 -0500
Message-ID: <b2uat1$f0t$>


  This isn't a matter of opinion. There is one determinant: "there are two employees named John Smith". There are many consequential truths, such as "there is at least one employee", "there is an employee whose first name is not Nancy", "there are at least two employees whose first and last names share a common letter of the alphabet.", and so on.

  I don't deny that it can be important to distinguish between two John Smiths. If it is, then don't choose a logical model (multisets) that cannot make that distinction, and then blame your poor choice on a failure of the model. Or better yet, don't choose an insufficient logical model (multisets), embed it in a physical model that provides an attribute not in the logical model (the row number or disk location of the two separate rows representing John Smith), and evaluate the logical model on the basis of what the physical super-model can do.

Are the integers useless for modeling geometry because they can't distinguish between the number of sides of a triangle and the ratio of a circle's circumference to its radius? No. If you represent the integer 3 as the string "3" when you want it to represent the number of sides of a triangle and as "pi" when you want it to represent C/r, they do a greate job. Is the set of five platonic solids the wrong model for a collection of recordings of Beethoven's Ninth Symphony? No, not if you have a bunch of identical solids and scratch the waveform of the performance on the faces.

  I'm not redefining any words, but we have a fundamental difference in understanding logical vs. physical models. You are saying that the real-world scenario of books in a library must be represented by a logical model that does not keep track of an actual attribute of "book" (acquisition number), and then you blame the model for not being able to distinguish two identical books, which can only be distinguished in the real world by the fact that they have different values of the attribute you prohibited the model from using. Then you choose a physical model that distinguishes the two books by an equivalent attribute like file line number or disk sector, claim that it is a faithful model of a logical model that doesn't track that attribute, and take full advantage of the extra attribute whose existence you are denying. I would just be more comfortable if you acknowledged the addtional attribute your choice of physical model confers on the logical model.


Bernard Peek wrote:

> In message <b2rqnp$1tj$>, Steve Kass
> <> writes
>> I think you are confusing your employees with your model.
>> If we have only the two employees named John Smith, in
>> department 10 with salary 20000, and we are storing this
>> information in a multiset, we have only _one_ fact, not two:
>> "There are two John Smiths in department 10 with salary
>> 20000". Two employees, but only one fact.
> That depends entirely on an opinion on what constitutes a fact. It's
> equally true to say that there are two facts. The first fact is that
> there is an employee called John Smith, the second fact is that there
> are two John Smiths. If you redefine the word (making it a term of
> art) so that it always equals that which is recorded by a *unique*
> record in a database then your statement becomes true.
> It's usually quite important to be able to distinguish between people
> that may have the same name. Let's choose a different example.
> I collect books and as sometimes happens I have some duplicates. I
> have two copies of the same book, quite often both of them in mint
> condition. I have two database entries for that edition. I have two
> copies of the book on the shelf. Suppose I give one copy away? I take
> one copy off of the shelf and I delete one record from the database.
> It makes no difference whether I delete the record that was created
> when I acquired the first book or the second. It makes no difference
> whether I remove the first book or the second.
> I could create a new entity and call it "Acquisition Number" and
> that's what most librarians do. Acquisition numbers are simply
> identity fields. They should not be considered part of the logical
> data structure.
Received on Tue Feb 18 2003 - 23:10:10 CET

Original text of this message