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

jan.hidders_at_REMOVE.THIS.ua.ac.be (Jan Hidders) wrote in message news:<3e4bca2b.0_at_news.ruca.ua.ac.be>...
> 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