paul c wrote:

As I said, I am unsure of the notation. Above, I more-or-less assumed
that GROUP would create a relation valued attribute from some specified
set of attributes while projecting on the remaining attributes, but one
probably wants to group things other than attributes in a single
relation, and one probably wants the option to project on an arbitrary
set of attributes.

Ignoring those notation problems, though, I assume you see how that
more-or-less expresses "Suppliers who supply all parts."

One could replace P{P} with any expression answering "All of what?" For
example, "Suppliers who supply all the green parts." might be:

(SP{S,P} GROUP Parts{P} | Parts = (P | COLOR='green'){P}){S}

assuming the P relation has a COLOR attribute and one of the possible
values is 'green'.

I used the vertical bar for RESTRICT similar to set notation, which I
generally read as "such that", and {} for PROJECT. Although, I have to
say that as my eyes age, I like notations that use both () and {} less
and less.

Bob Badour wrote:
....
Yes, I can see `all parts` and `all green parts`, as long as there are some green parts. If there aren`t any green parts, I`d say we get the same answer as Codd`s Divide, in which all suppliers might not appear. Is that why you said "one probably wants to group things other than attributes in a single relation"?

I'm okay with the bar, took it as a kind of cumulative <AND>, probably saves a lot of fiddly typing to express conversions.

paul c wrote:

Actually, there was a mistake in what I wrote:

(SP{S,P} GROUP Parts{P} |
(Parts join (P | COLOR='green')){P} = (P | COLOR='green'){P}
){S}

Alternatively, one could use a "contains" comparison rather than an
"equals" comparison.

The corrected expression would return all suppliers in SP if there are
no green parts. One would have to adjust it to return all suppliers in
S, and yes, to do that adjustment, one would have to have a better GROUP
notation.


One could replace both join and | with <AND> and get rid of most of the
brackets.

The notation may also have some name scoping issues, but I think we are
both on the same page about the relation equality comparison providing
both quantifiers to the algebra.

Bob Badour wrote:
....
I suspect so too. It's been many years since I used any SQL products much, maybe some of them have a relation comparison operation now, but I don't remember any. My hunch is that any implementation language that doesn't have such an op is not likely to be defined on much formal logic.

paul c wrote:

I strongly doubt any SQL dbms supports table comparison. I have no doubt
the vendors would say "That would be too slow and expensive" instead of
doing their jobs.