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

From: Bob Badour <>
Date: Tue, 18 Feb 2003 22:34:21 -0500
Message-ID: <eiD4a.58$>

"Steve Kass" <> wrote in message news:b2ukru$g79$
> Bernard,
> Then perhaps we agree more than we disagree. I went back and read
>, which was referred to earlier
> in this thread, and two comments on it might be useful, if not
> in answer to this post of yours:
> Date characterizes the bag-advocate as saying "But I don't need to
> distinguish among the duplicates--all I want to do is be able to count
> them." I think that's an unfair characterization, and I would say "But
> I don't need to distinguish among the duplicates--all I want is to know
> how many there are."

Oh dear. Then you haven't any duplicates or any multisets. You have a relation with a count indicating how many there are.

> I would go further and ask Date, to whom it is
> important to be able to count (requiring distinguishability) three cans
> of cat food, whether it is equally important for him to distinguish and
> count five pounds of flour, or better yet, $1000 in a bank account.

Chris Date is a very intelligent man. You need to start by assuming he would make very intelligent decisions. He wouldn't record the money in a bank account as 100,000 distinct pennies. You are constructing a straw man.

Date, like any sensible person, would require a logically identifiable account tuple with a balance attribute.

> I think that for some purposes only one fact is needed to
> record the purchase of three cans of cat food,

True. A single tuple with a quantity suffices. I strongly suggest the use of one.

> and many stores reflect
> this conceptualization by representing this fact with a single line on a
> receipt.

Receipts are external physical representations and are no longer managed data.

> Does Date, or anyone, think that a withdrawal of ten dollars from
> a bank account requires the deletion of ten identical facts from a
> table?

No. Sensible folks would expect an update statement to adjust the balance attribute within a relation variable. What does this have to do with multisets?

> Later in the article, Date provides two bags, of parts and of
> suppliers, and asks the question (query) "list part numbers for
> parts that either are screws, or supplied by supplier S1, or both."
> Then he proposes twelve queries that might answer the question,
> and uses the fact that nine different results appear to support his
> argument against bags.
> Unfortunately when Date asks a stupid question, he gets many
> stupid answers.

How are casual users to know which of the twelve seemingly reasonable solutions will yield the answer they want? Are you suggesting that every user of a dbms must have expert level knowledge of dbms internals?

> The problem is that in his sample bag-database,
> "part number" is not an entity.

'Entity' is not well defined. 'Domains' are well defined. Part number is a domain.

> So even if the query were "list THE
> part numbers ...", which might mean list each part number in the
> part numbers bag ..., doesn't fly, since there is no part numbers bag.

You are making less and less sense as time goes on.

> The question he asks is not well-defined.

Sure it is. Table 'P' states which parts exist. ( ie. Part P# has name PNAME) Table 'SP' states which suppliers supply which parts. ( ie. Supplier S# supplies part P#)

> For it to be a valid query,
> it must specify the source of the items to be listed. I would interpret
> it to mean "For each part in the bag of Parts, list the part's part number
> if the part is a screw or if the part is supplied by supplier S1, or both.

All you have done is replace the name 'P' with the name 'Parts'. However, Date actually shows bag 'P' and you have not shown bag 'Parts'. I would say that makes Date's original example just a tad better defined.

> This question has an unambiguous answer, despite the fact that Date
> has intentionally thrown a wrench into the works as well, by providing
> a table SP (suppliers-parts?) that contains the same fact twice - a
> suppliers-parts table should be subject to a constraint that the
> multiplicity
> of any supplier-part fact be 1

Why? If multisets are useful, why are they not useful in an abstract example such as this one? Perhaps they mean 'stock on hand'. Or perhaps each duplicate represents an anonymous warehouse that supplies the part. If duplicates have a use anywhere, certainly they have a use here.

> since there is no real-world meaning to
> the two identical rows he lists, in contrast to the clear real-world
> of the three P1-screws in the parts table.

Please provide a similar example using bags where the duplicates have real-world meaning, then. And propose a similar query.

> His example is entirely
> unconvincing.

It convinces me.

> SK
> Bernard Peek wrote:
> > In message <b2uat1$f0t$>, Steve Kass
> > <> writes
> >
> >> Bernard,
> >>
> >> 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.
> >
> >
> > That's not my argument. My argument is that there may be no need to
> > distinguish between two real-world objects, each of which is
> > referenced by a single record in a database. The relational model (and
> > databases based on it) require that a distinguishing key be created
> > even if there is none in the logical data structure.
> >
> > I don't dispute that there are real pragmatic reasons for accepting
> > that deviation from the logical structure of the data. But as this is
> > a theory newsgroup I wanted to point out that this is a (minor)
> > failing in the relational model.
> >
> > [...]
> >
> >> 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,
> >
> >
> > No, that's not my objection. My objection is that the relational model
> > declares that there must be a distinction, when there is no such
> > requirement in the real world.
> >
> > It does makes the maths easier, and it makes the implementation much
> > easier.
> >
> >
> >
Received on Wed Feb 19 2003 - 04:34:21 CET

Original text of this message