# 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: Mon, 17 Feb 2003 22:35:50 -0500
Message-ID: <kdi4a.11\$_32.1323065_at_mantis.golden.net>

"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. Received on Tue Feb 18 2003 - 04:35:50 CET

Original text of this message