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

From: Paul <>
Date: 14 Feb 2003 01:31:03 -0800
Message-ID: <>

"Mikito Harakiri" <> wrote in message news:<m7Y2a.18$O%> "Steve Kass" <> wrote in message
> > I didn't read the whole thread, but in the right context, the
> > bags are functions, and intersect, union, etc. are all well-defined.
> I don't agree that the matter is "context dependent". One either has a model
> with a consistent set of operations that users like, or not.

What's the interpretation given to a table with duplicate rows?

In relational theory, each relation corresponds to a logical predicate e.g. the employee table has a truth-valued function f(emp, dept, salary) say.
and each row in the relation corresponds to the proposition obtained by substituting actual values for the placeholders emp, dept, salary. e.g. f("J Smith", 10, 20,000) means J Smith is in dept 10 and has a salary of 20,000.

So with this interpretation duplicate rows don't make sense because you're just making the same assertion more then once, which doesn't make it any more true.
So is "multi-set" relational algebra not based on predicate logic?

Also, there's no way for users to identify a row because the thing that differentiates them is held internally and is thus invisible to the user - and this breaks the logical/physical distinction.

You can always get the same duplicate row functionality in true relational algebra by adding another column which contains the "count" for the rest of the attributes.

If multi-set algebra is used maybe it should always be internal (i.e. part of the physical implementation) and hidden from the user?

Paul. Received on Fri Feb 14 2003 - 10:31:03 CET

Original text of this message