Re: Extending my question. Was: The relational model and relational algebra - why did SQL become the industry standard?

From: Bob Badour <bbadour_at_golden.net>
Date: Tue, 18 Feb 2003 17:44:17 -0500
Message-ID: <c2z4a.34$sB3.3168405_at_mantis.golden.net>


"Steve Kass" <skass_at_drew.edu> wrote in message news:b2u8ht$9i0$1_at_slb2.atl.mindspring.net...
>
>
> Bob Badour wrote:
>
> >"Steve Kass" <skass_at_drew.edu> wrote in message
> >news:b2rqnp$1tj$1_at_slb2.atl.mindspring.net...
> >
> >
> >>Mikito Harakiri wrote:
> >>
> >>
> >>
> >>>"Paul" <pbrazier_at_cosmos-uk.co.uk> wrote in message
> >>>news:51d64140.0302170330.15d2a98f_at_posting.google.com...
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>OK suppose I have an employee "relation" which is a multiset.
> >>>>I have two employees called John Smith, in the same dept on the same
> >>>>salary.
> >>>>So my multi-relation contains two outwardly identical tuples:
> >>>>("John Smith", 10, 20000)
> >>>>("John Smith", 10, 20000)
> >>>>
> >>>>Now one of the John Smiths has a sex-change and becomes Jane Smith.
> >>>>
> >>>>How does the user update only one of the rows?
> >>>>Surely it's impossible because the two rows are only distinguished
> >>>>internally?
> >>>>
> >>>>
> >>>>
> >>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.
> >>
> >>If we wish to change our data so that it now represents two
> >>facts:
> >>"There is one John Smith in department 10 with salary 20000".
> >>"There is one Jane Smith in department 10 with salary 20000".
> >>
> >>we do so without any difficulty. There are many ways to
> >>devise a physical representation of our multiset, and how we
> >>transform it depends what the representation is.
> >>
> >>
> >
> >Exactly. Multisets have little utility for logical models, because one
must
> >resort to physical locations or addresses to make any use of the
duplicates.
> >
> >
> >
> I'm afraid I disagree. Multisets have plenty of utility for logical
models
> of items with multiplicities. As soon as you expect multisets to model
> something
> else, you're not going to have much luck. It sounds like you are
expecting
> the multiset to model the individuality of "the duplicates", and if you
> are, then
> you are thinking of the duplicates as separate facts, and
> distinguishable. Multisets
> don't model the "individual duplicates" as individual entities. If you
> want to do that,
> you need to use a set model and include a distinguishing attribute with
> the entity.

If the facts are truly indistinguishable, they are a single fact and we have a model based on sets. If they only represent multiplicities, one really has a relational logical data model with an implicit count attribute.

What benefit does this implicit attribute provide?

>
> SK
>
> >
> >
>
Received on Tue Feb 18 2003 - 23:44:17 CET

Original text of this message