# Re: Relation subset operators

Date: Sun, 7 Jun 2009 10:57:10 -0700 (PDT)

Message-ID: <f3505fed-19a4-420d-87f8-ff5a93ded678_at_r13g2000vbr.googlegroups.com>

On Jun 7, 4:46 am, cim..._at_hotmail.com wrote:

> On 6 juin, 23:19, vadim..._at_gmail.com wrote:> On Jun 6, 11:43 am, cim...@hotmail.com wrote:

*>
**> Snipped
**>
**> > Now into the main topic -- set equality join.
**>
**> I am not sure that is actually the main topic.
*

> In my perception, the

*> specific problem which was adressed was the opportunity of using a new
**> operator to simplify relation handling in the context of relational
**> division. set equality is only but one aspect of operations that
**> could potentially be expressed more effectively using such operator.
*

Well, all the questions decompose into the two parts:
1. Find a subset of sales by a certain criteria
2. Aggregate/group by it

Inlike step 2, Step 1 is very well understood from relational theory
perspective. One can mix standard relational algebra operators,
rearrange their order under certain rules, etc. As soon as you lump 1
and 2 together, the optimization becomes much less clear (unless it is
just a shorthand/macro, which RDBMS engine expands into traditional
notation).

*> I am curious as to why you think that the idea of creating a new
*

> operator is *only* about *set containment*. As expressed the example

*> provided (Question 1 to Question 8). The idea behind creating a new
**> operator was actually that such operators allows a simpler but
**> logically sound formulation of some operations that are tedious to
**> express using traditional operators.
*

As I mentioned before there is no relational division anywhere in the examples 1-5. Yet you introduced the "/" symbol and call it relational division and later wrote an expression containing

CARSALE/salesman

This doesn't make any sense to me, how can you divide a relation CARSALE by an attribute salesman? Received on Sun Jun 07 2009 - 19:57:10 CEST