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

From: Paul <>
Date: 25 Feb 2003 06:29:05 -0800
Message-ID: <> (Jan Hidders) wrote in message news:<>...
> No. In fact, in theory, all optimizations that can be done in a set-based
> algebra can also be done in a bag-based algebra but not the other way
> around.

We can define a bag [a,a,a,b,c,c,d]
as the set {(a,3),(b,1),(c,2),(d,1)}
where a,b,c,d are distinct.
I assume this is the standard definition?

So doesn't any bag algebra have a isomorphic algebra of sets of the form:
{(a1,n1),(a2,n2),(a3,n3), ...}

where a1,a2,a3,... are distinct members of our domain set and n1,n2,n3,... are natural numbers (not necesarily distinct)?

The other thing I still don't understand: The underlying interpretation of a relvar is a predicate, with the rows being propositions. How can it make sense for a relvar to contain any proposition more than once? Does the bag-based "relational" algebra have a different starting point and what is it?

Is it more of a class/object thing with the relvars being classes and the rows being (possibly identical) objects? Isn't this approach inferior to the standard predicate logic approach though?

Should a bag-based SQL have some sort of extensions to cope with duplicate rows?
For example if I had n identical rows in a relvar and I wanted to update m of them (m < n) it should have the syntax to say "only update a maximum of m identical rows" (it wouldn't matter which ones because they are identical). Or if I wanted to delete one of them there would
be a corresponding DELETE extension. At the moment I can only delete all or nothing.

I'm having trouble working out which of the pro-bag posters are just playing devils advocate or trolling and which are genuine (if any). I assume from the cited papers that it must be a legitimate area of research (the algebra of a particular family or sets) but I can't really see its applicability to relational theory.

Paul. Received on Tue Feb 25 2003 - 15:29:05 CET

Original text of this message