Re: Relation subset operators

Snipped
> You are right, I didn't read your message carefully. It was "subset"
> in the topic that confused me. None of your 5 questions require set
> join/relational division.
Thank you. The poor formulation I made of the issue have confused a lot of people. I was hoping the examples would be sufficient to express it but I should have stuck to traditional formalism. I have been involved in such difficult effort for building a computing model that I forget sometime relational formalism.

Allow me clarify again my position.

In a relational operation between 1 or more relations, a relation whose body is subdivided into smaller tuple subsets as a *consequence* of the operation (in this case a GROUP BY) may need to have restrictions applied at two levels: the level of the relation operation and the level of the subset that is a consequence of the operation. I believe that creating operators that would symbolize the the scope of such restrictions may simplify the expression of some relation operations and have many more applications, such as expressing specialization by constraints. I syntaxically designated the operator */=* with */* symbolizing the higher level operation (GROUP BY) and *=* the restriction applied to the subset subsequent to the operation. Throughout examples 1 to 8 I have attempted underlining that using such operator can express more concisely and more systematically allow the formalization of relation operation.

> > 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).
In fact, this is an effort to develop operators than can take advantage of some capabilities allowed by the computing model representation of relations I developped. In such model, the internal physical representation of relations is such as there is no one to one mapping between the number of relational operations and the number of physical operations performed on disk. In a word, the representation makes it possible to have the same number of physical operations for various combinations of basic elementary logical relational operations. As a consequence, I am currently developping a language for which I can afford to create pratical and unductive operators for the compiler I am building.

> > 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?
I apologize as it is a confusing choice on symbology used on my part. I have used the */* symbol in the framework of thought of the computing model I have developped which I consider relationally inspired but unbound to relational formalism. I should have also clarified this is not relational division defined according to the assumption that relational division would be an opposite to cartesian product. In fact, I should not have used relational division at all.

In this context when I wrote CARSALE/salesman I did mean CARSALE grouped by salesman. In the broader context of the framework of the computing model I am working onto, CARSALE/salesman means subdivision of tuple set OR subtype OR subset of CARSALE according to a rule carrying on salesman. This is not relational division in the traditional sense but I should have indicated it.

As you mentionned, question 1 to 5 are not relational divisions operation however you may have noticed that Question 8 mentionned is (What are the total sales of each salesman who have sold ALL cars). Still one can see that the pattern o programming proposed still holds. I hope this has clarified and apologize again for the confusions my notation has induced.

Regards... Received on Sun Jun 07 2009 - 22:04:48 CEST