Relation subset operators
Cimode
While working on aggregation within groupping operations on the db
core I design for relation manipulation, I questionned myself about
the opportunity of using new operators to simplify relational division
formulation and make it more systematic. For instance, conside the
following questions:
suppose CAR_SALE relation represented as
CAR_SALE
id car salesman price color date
1 Buick Henderson 10000 Red 01/01/1990
2 Buick Wilkinson 10000 Red 02/01/1990
3 Chevrolet Hutchinson 10000 Red 12/01/1990
4 Buick Wilkinson 10000 Blue 13/01/1990
5 Chevrolet Henderson 10000 Red 14/01/1990
6 Buick Henderson 10000 Blue 16/01/1990
7 Buick Henderson 10000 Blue 18/01/1990
8 Chevrolet Parson 10000 Yellow 18/01/1990
Now consider the following questions
> Question 1: What are the total sales of salesmen who have sold AT LEAST (one) Blue car.
returning...
salesman total_sale
Wilkinson 20000
Henderson 30000
> Question 2: What are the total sales of salesman who have sold AT LEAST (one) blue car AND (one) red car.
returning...
salesman total_sale
Wilkinson 20000
Henderson 30000
> Question 3: What are the total sales of salesman who have sold AT LEAST (one) blue car OR (one) red car.
returning...
salesman total_sale
Hutchinson 10000
Wilkinson 20000
Henderson 30000
> Question 4: What are the total sales of salesman who have NOT sold ANY blue cars
returning...
salesman total_sale
Hutchinson 10000
Parson 10000
> Question 5: What are the total sales of salesman who have NOT sold NEITHER a blue car NOR a red car
returning...
salesman total_sale
Parson 10000
Even though the above examples are easy to express algebrically (at
least compared to their SQL expression), they must to be decomposed
into a minimum of two to three elementary operations to be solved when
using elementary operators (JOIN, UNION, GROUP BY). I thought about
creating an specific operator for groupping subsets to simplify the
expression of such problems. Such operator would allow to operate an
relation involved in a division operation with one attribute drawn
from the header subset. I thought about symbolizing the operator as */
* followed by the operator to be implemented within the groupping
subset such as */=* */>*, */<*, */<>*, */*. Using such operator
allows the expression of the questions above in a simpler way.
SYMBOLOGY
/ : relational division
+: relational union
/=: equality within the group
DEFINITION
For a relation R and un-ary relations p and q part of R header, and V
values drawn from any attribute of R, */=* would be defined such as
R/p WITH q /= V <=> R/p (INNER) JOIN (p WHERE q = V) ON p
Using the above definition, the expression of Question 1 comes to
CARSALE/salesman WITH color /= 'Blue' is a interesting shortcut to
(CARSALE/salesman) JOIN (salesman WHERE color = 'Blue') ON salesman
to get Question 2, instead of writing (CARSALE/salesman) JOIN
((salesman WHERE color = 'Blue') JOIN (salesman WHERE color = 'Red')
on salesman ) ON salesman, we could simply write...
CARSALE/salesman WITH color /= 'Blue' AND color /= 'Red'
to get Question 3, instead of writing (CARSALE/salesman) JOIN
((salesman WHERE color = 'Blue') UNION ALL (salesman WHERE color =
'Red') on salesman ) ON salesman, we could write...
CARSALE/salesman WITH color /= 'Blue' OR color /= 'Red'
to get Question 4 is even simpler...instead of writing (CARSALE/
salesman) JOIN (salesman MINUS (salesman WHERE color = 'Blue')) ON
salesman
we keep the coherence of expressing
CARSALE/salesman WITH color /<> 'Blue' (/<> would be the opposite of /
=)
Finally to get Question 5 expressed as (CARSALE/salesman) JOIN
(salesman MINUS (salesman WHERE color = 'Blue') MINUS (salesman WHERE
color = 'Red')) ON salesman
we would simply write
CARSALE/salesman WITH color /<> 'Blue' AND color /<> 'Red' .
The need for such simplification is even more obvious when the queries
become more complex
We could imagine a Question 6 which would be: What are the total
sales of salesmen who either have *not* sold a single Blue OR have
*not* sold a single Red car...
Using traditional operators, Question 6 would be expressed as
(CARSALE/salesman) JOIN ((salesman MINUS (salesman WHERE color =
'Blue')) UNION ALL (salesman MINUS (salesman WHERE color = 'Blue')))
ON salesman
where they could be written...
CARSALE/salesman WITH color /<> 'Blue' OR color /<> 'Red' .
It seems to me such simplification would be beneficial to express more
systematically algebric formulation of relational divisions.
Note: I do not mention SQL into this because there would be too much
verbose to write. Using the db core and subsequent language I am
working ontoI can write this...
--DEFINITION
R1 = (1, 'A', 0, 10) + (1, 'A', 1, 10) + (1, 'B', 1, 10) + (1,
'B', 1, 10) WITH LEFT TO RIGHT ALIGN (id, groupper, differentiator,
value)
Q1 = R1/salesman WITH (color /= 'Blue')
Q2 = R1/salesman WITH (color /= 'Blue' AND color /= 'Red')
Q3 = R1/salesman WITH (color /= 'Blue' OR color /= 'Red')
Q4 = R1/salesman WITH color /<> 'Blue'
Q5 = R1/salesman WITH color /<> 'Blue' AND color /<> 'Red'
Q5 = R1/salesman WITH color /<> 'Blue' OR color /<> 'Red'
--PRESENTATION in tabular format
PRESENT2D(salesman, SUM(price)).Q1
PRESENT2D(salesman, SUM(price)).Q2
PRESENT2D(salesman, SUM(price)).Q3
PRESENT2D(salesman, SUM(price)).Q4
PRESENT2D(salesman, SUM(price)).Q5
produces previously mentionned results..
Comments would be welcome to evaluate the usefulness of such
operator....
Thank you.
cim...@hotmail.com
I also forgot to mention that such operator would allow to express
specialization by constraints efficiently by expressing the any
constraint a un-ary relation as a subset of its domain. For instance,
considering domain I of Integers, a constraint to express un-ary
relation R(attribute1) containing only strictly positive values could
be expressed simply as
I/R WITH attribute1 /> 0
That way specialization by constraint can be formulated imperatively
and without necessarily involving a header definition.
--CELKO--
Just for comparison, I re-wrote the skeleton schema in SQL and brought
the data element names up to ISO-11179 standards. The dates also need
to be in ISO-8601 format, but that is not important for this
comparison.
CREATE TABLE CarSales
(invoice_nbr INTEGER NOT NULL PRIMARY KEY,
vehicle_make VARCHAR(10) NOT NULL,
salesman_name VARCHAR(10) NOT NULL,
vehicle_price DECIMAL (8,2) NOT NULL,
vehicle_color VARCHAR(10) NOT NULL,
sale_date DATE DEFAULT CURRENT_TIMESTAMP NOT NULL);
> Question 1: What are the total sales of salesmen who have sold AT LEAST (one) Blue vehicle.
SELECT C1.salesman_name, SUM(C1.vehicle_price) AS sales_tot
FROM CarSales AS C1
WHERE C1.salesman_name
IN (SELECT C2.salesman_name
FROM CarSales AS C2
WHERE C2.vehicle_color = 'Blue') ;
> Question 2: What are the total sales of salesmen who have sold AT LEAST (one) blue vehicle AND (one) red vehicle.
SELECT C1.salesman_name, SUM(C1.vehicle_price) AS sales_tot
FROM CarSales AS C1
WHERE C1.salesman_name
IN (SELECT C2.salesman_name
FROM CarSales AS C2
WHERE C2.vehicle_color IN ( 'Blue', 'Red')
GROUP BY C2.salesman_name
HAVING COUNT(DISTINCT C2.vehicle_color) = 2);
> Question 3: What are the total sales of salesmen who have sold AT LEAST (one) blue vehicle OR (one) red vehicle.
SELECT C1.salesman_name, SUM(C1.vehicle_price) AS sales_tot
FROM CarSales AS C1
WHERE C1.salesman_name
IN (SELECT C2.salesman_name
FROM CarSales AS C2
WHERE C2.vehicle_color IN ( 'Blue', 'Red')
GROUP BY C2.salesman_name
HAVING COUNT(DISTINCT C2.vehicle_color) > 0);
> Question 4: What are the total sales of salesmen who have NOT sold ANY blue vehicles
SELECT C1.salesman_name, SUM(C1.vehicle_price) AS sales_tot
FROM CarSales AS C1
WHERE C1.salesman_name
NOT IN (SELECT C2.salesman_name
FROM CarSales AS C2
WHERE C2.vehicle_color = 'Blue');
> Question 5: What are the total sales of salesmen who have NOT sold NEITHER a blue vehicle NOR a red vehicle
SELECT C1.salesman_name, SUM(C1.vehicle_price) AS sales_tot
FROM CarSales AS C1
WHERE C1.salesman_name
NOT IN (SELECT C2.salesman_name
FROM CarSales AS C2
WHERE C2.vehicle_color IN ( 'Blue', 'Red')
GROUP BY C2.salesman_name
HAVING COUNT(DISTINCT C2.vehicle_color) > 0);
I did not test these queries and I used the IN() predicate rather than
EXISTS() to keep them closer to relational algebra and set notation.
However, if the specs are changed a bit to show a zero total for the
disqualified salesmen, the queries could have been written with a CASE
expressions: Here is Q1:
SELECT C1.salesman_name,
SUM( CASE WHEN C1.vehicle_color = 'Blue'
THEN C1.vehicle_price ELSE 0.00 END)
AS blue_sales_tot
FROM CarSales AS C1
GROUP BY C1.salesman_name;
This is very simple SQL and you could nest it inside another query to
meet the original specs:
SELECT salesman_name, blue_sales_tot
FROM ( SELECT C1.salesman_name,
SUM( CASE WHEN C1.vehicle_color = 'Blue'
THEN C1.vehicle_price ELSE 0.00 END)
AS blue_sales_tot
FROM CarSales AS C1
GROUP BY C1.salesman_name) AS B(salesman_name, blue_sales_tot)
WHERE blue_sales_tot > 0;
paul c
>
> While working on aggregation within groupping operations on the db
> core I design for relation manipulation, I questionned myself about
> the opportunity of using new operators to simplify relational division
> formulation and make it more systematic. For instance, conside the
> following questions:
>
> suppose CAR_SALE relation represented as
>
> CAR_SALE
> id car salesman price color date
> 1 Buick Henderson 10000 Red 01/01/1990
> 2 Buick Wilkinson 10000 Red 02/01/1990
> 3 Chevrolet Hutchinson 10000 Red 12/01/1990
> 4 Buick Wilkinson 10000 Blue 13/01/1990
> 5 Chevrolet Henderson 10000 Red 14/01/1990
> 6 Buick Henderson 10000 Blue 16/01/1990
> 7 Buick Henderson 10000 Blue 18/01/1990
> 8 Chevrolet Parson 10000 Yellow 18/01/1990
>
Cimode, I'm struggling with this, trying to see the logical starting
point. I would try to write this en francais but that would be
incomprehensible, a teenage friend in France even runs rings around in
English. I can't remember when I might have read about logical
foundations of aggregate operators, but for me they've seemed to
involve, necessarily, the equivalent of TTM group (I'm always a little
leary of SQL GROUPBY because I gather it doesn't have a logical
definition). Assuming a 1970-Codd-style relation there are many "SUM's"
inherent in the above table/r-table/relation. To me, that 'inherency'
seems similar to the transitive closures that are visible in some other
relations. The examples I've seen elsewhere of TTM-style GROUP-ed
attributes haven't offered any kind of operation that queries a subset
of the tuples in a GROUPed value. So, if this makes any sense, from an
algebraic viewpoint, I see aggregates as being very similar to TCLOSE,
they must be applied first, before restriction. Are you following me?.
Tegiri Nenashi
> from an
> algebraic viewpoint, I see aggregates as being very similar to TCLOSE,
> they must be applied first, before restriction. Are you following me?.
TClose is an unary operation borrowed from [binary] relation algebra.
It applies to a binary relation (with the arguments of the same type),
and can't be applied to a relation with any other signature (unless it
is projected to a binary relation). Aggregate and set operations are
not unary but binary operations, and both operands are required to
have an attribute of the same type. In a way this is a dual
requirement to having two argument of the same type!
cim...@hotmail.com
to allow a practical formulation of some operation such as relational
division or specialization by constraint. As for TCLOSE, the
operation is close but different in the sense that subtyping allows to
get around a lot of restrictions that apply to TCLOSE.
cim...@hotmail.com
<<In a way this is a dual requirement to having two argument of the
same type! >>
need for such limitation. What prevents performing an agrregate or
set operation between a relation type and a relation subtype (the
subtype using the type as a domain of possible values) ?.
Tegiri Nenashi
Why do you bring in relation subtype (and what is it, actually)?
To clarify my original statement, TClose is applied to a relation with
two arguments x and y such that equality is a meaningful operation on
x and y values. For example, for a relation Flight(from,to), one has
to be able to do equality comparison of the attribute "from" with
"to". An obvious generalization would extend this definition onto
relations having the two sets of "matching" arguments.
An aggregate operation is different: as it is applied to two relations
having the same attribute. For example, aggregating Emp(deptno, ename,
sal) over Dept(deptno, dname) would produce a relation Budget
(deptno,expense). Therefore, I fail to see the similarity that Paul
mentioned.
cim...@hotmail.com
> On Jun 4, 2:09 am, cim...@hotmail.com wrote:
>
> > <<In a way this is a dual requirement to having two argument of the
> > same type! >>
> > I do not recall reading this but I have hard time understanding the
> > need for such limitation. What prevents performing an agrregate or
> > set operation between a relation type and a relation subtype (the
> > subtype using the type as a domain of possible values) ?.
>
> Why do you bring in relation subtype (and what is it, actually)?
domain of possible values (each relation value being a possible value
for R2) and before applying R2 specific constraints makes R2 a subtype
of R1. One could view a subtype as a declaratively constrained subset
of tuples or alternatively as specialized subset of tuples. Since all
tuples in R2 necessarily belong to R2, performing aggregation between
R1 and R2 does make sense. For instance consider INT as a relation
whose body includes all integers and ODD_NUMBERS as a relation that
derives from INT. Nothing prevents to my knowledge performing set
operations between INT and ODD_NUMBERS even though they are not
strictly speaking of the same type.
> To clarify my original statement, TClose is applied to a relation with
> two arguments x and y such that equality is a meaningful operation on
> x and y values. For example, for a relation Flight(from,to), one has
> to be able to do equality comparison of the attribute "from" with
> "to". An obvious generalization would extend this definition onto
> relations having the two sets of "matching" arguments.
No offense, but even though I do not disagree with that argument, I
only see its relevance under the premise that TCLOSE would be the same
operator than the one proposed (/=, />, /<, /<>) which have been
developped for practical purposes. I do believe that paul only noted
similarities which does not force it to share the same definition. Or
maybe I missed something.
> An aggregate operation is different: as it is applied to two relations
> having the same attribute. For example, aggregating Emp(deptno, ename,
> sal) over Dept(deptno, dname) would produce a relation Budget
> (deptno,expense). Therefore, I fail to see the similarity that Paul
> mentioned.
If I understand right, you are bothered by paul comparison of the
operator to TCLOSE. I let paul clarify further why he sees a
similarity. As far as I am concerned, I was simply hoping to get some
feedback on the *usefulness* of such operator into simplifying
groupped queries as well as specialization by constraint formulation.
Regards...
Gene Wirchenko
[snip]
>> Why do you bring in relation subtype (and what is it, actually)?
>A relation R1 de facto contitutes a type. A relation R2 using R1 as a
>domain of possible values (each relation value being a possible value
>for R2) and before applying R2 specific constraints makes R2 a subtype
>of R1. One could view a subtype as a declaratively constrained subset
>of tuples or alternatively as specialized subset of tuples. Since all
>tuples in R2 necessarily belong to R2, performing aggregation between
>R1 and R2 does make sense. For instance consider INT as a relation
>whose body includes all integers and ODD_NUMBERS as a relation that
>derives from INT. Nothing prevents to my knowledge performing set
>operations between INT and ODD_NUMBERS even though they are not
>strictly speaking of the same type.
Sure they are. For all x IN ODD_NUMBER, x IN INT.
[snip]
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
cim...@hotmail.com
> cim...@hotmail.com wrote:
>
> [snip]
>
> >> Why do you bring in relation subtype (and what is it, actually)?
> >A relation R1 de facto contitutes a type. A relation R2 using R1 as a
> >domain of possible values (each relation value being a possible value
> >for R2) and before applying R2 specific constraints makes R2 a subtype
> >of R1. One could view a subtype as a declaratively constrained subset
> >of tuples or alternatively as specialized subset of tuples. Since all
> >tuples in R2 necessarily belong to R2, performing aggregation between
> >R1 and R2 does make sense. For instance consider INT as a relation
> >whose body includes all integers and ODD_NUMBERS as a relation that
> >derives from INT. Nothing prevents to my knowledge performing set
> >operations between INT and ODD_NUMBERS even though they are not
> >strictly speaking of the same type.
>
> Sure they are. For all x IN ODD_NUMBER, x IN INT.
type does not mean their typing is the same. Think about this
analogy: ALL ORANGES are also FRUITS. But the question whether all
elements of ORANGES are more FRUITS than ORANGES is a matter of
perspective. As far as RM is concerned, stronger typing seems more
reasonnable.
cim...@hotmail.com
OK I will grant you that you have made an effort to formulate a
possible SQL, I voluntarily skipped. It is however unfortunate missed
the point behind the need to create a new operator. Try to formulate
for instance the following question someone brought up....
Question 7: What are the total sales of ALL salesmen who have sold ALL
possible colors...The SQL can become quite cumbersome. OTOH, using
the proposed operator it can simply be written as:
CARSALE/salesman WITH color /= color
paul c
Not that I admire people who admire SQL (I just admire people who can
cope with it, assuming they were forced into that position) but I
thought the SQL queries were useful, even though I didn't try them and
none of them involved any of the flavours of relational division I've
seen (nor did the original examples, which also confused me given that
division was mentioned in the original post). Perhaps you were looking
for a way to establish division as a generalization of simple
restriction, I'm not sure.
The syntax also confuses me, I'm not sure whether '/' is somehow,
sometimes, operating on an attribute (projection?) instead of a
relation, eg., the "color /= color" part. Probably I wouldn't be able
to see the point without more SQL comparisons or perhaps algebra
expressions that included a "SUM" operator, then I/we could see where
GROUP, DIVIDE and the aggregates come into play.
Another example to compare against division might be "total sales for
each salesman who sold all purple cars"! I don't yet know whether
optimizing that is easy or hard, but I think one lateral use for
shorthands, beyond reducing typos', is to make common optimizations
easier to recognize (though the longhand versions are still needed to
'prove' the optimizations)..
cim...@hotmail.com
The */* expresses a division between CARSALES and the attribute while
*/=* is a new operator that would indicate a restriction applied to
the division within each single group. Detecting potential confusions
is the precise reason I posted this examples...
> Probably I wouldn't be able
> to see the point without more SQL comparisons or perhaps algebra
> expressions that included a "SUM" operator, then I/we could see where
> GROUP, DIVIDE and the aggregates come into play.
Unfortunately for Celko's, his SQL formulation of the problem (even
though correct as far as result as concerned) uses an algebric *hack*
(thanks to SQL commitee's) that takes any algebrical analysis interest
out of the equation (I am taking about the HAVING COUNT operator).
Which is precisely why I did not mention it in the first place....But
for the sake of clarity...
A *sound* (sound is a risky word for SQL) equivalent to Question1 :
What are the total sales of salesmen who sold at least one Blue car?
would be...
select salesman, sum(price)
from CARSALE C1 inner join
(
select distinct salesman
from CARSALE
where color = 'Blue'
) C2
on C1. salesman = C2.salesman
group by C1.salesman
I propose to simplify the expression of the projection of C2 over C1
in the context of C1/salesman as a single operation performed by the
operator */=* ...The new formulation to get the same result than above
would be expressed as
CARSALE/salesman WITH color /= Blue
Question 2: What are the total sales of salesmen who sold at least one
Blue car AND one Red car would be expressed in SQL as
select salesman, sum(price)
from CARSALE C1 inner join
(
select b1.salesman from
(
select distinct salesman
from CARSALE
where color = 'Blue'
) b1
inner join
(
select distinct
salesman
from CARSALE
where color = 'Red'
) b2
on b1.salesman = b2.salesman
) C2
on C1. salesman = C2.salesman
group by C1.salesman
I propose to express the above as
CARSALE/salesman WITH color /= Blue AND color /= Red and so forth for
other questions brought...
Note that the */=* operates 2 relations, Blue and Red in fact are not
operated as values anymore but a single tuple subset of color
attribute.
Actually the operator would be */=* to operate 2 un-ary relations
*within* the context of a grouping operation. To be more explicit ,
if we consider relation R1 with attributes A1, B1 and B2 being single
tuple subtype of B1
B1 /= B2 in the context of R1/(A WITH B1/=B2) seems an important
simplification of formulation of divisions. The premise of such
simplification has a broad range of pratical uses among which algebric
formulation of frequent operations as well as a practical way to
declare specialization by constraints. See previous examples...
> Another example to compare against division might be "total sales for
> each salesman who sold all purple cars"!
There are many more complex queries, I did not mention, that were
taken into considération before creating the operator, queries such
as:
Question 7: What are the total sales of salesmen who sold ALL colors
sold ?
that would simply be expressed as
CARSALE/salesman WITH color /= color
Question 8 (the one you mentionned): What are the total sales of
salesmen who sold ALL purple cars is a particular case of Question1
since all salesmen who sold ALL purple cars are the same than ALL
salesmen who have sold AT LEAST one purple car. Therefore the
expression would also be similar to Question1
CARSALE/salesman WITH color /= Purple
>I don't yet know whether
> optimizing that is easy or hard, but I think one lateral use for
> shorthands, beyond reducing typos', is to make common optimizations
> easier to recognize (though the longhand versions are still needed to
> 'prove' the optimizations)..
I am sorry I do not understand exactly what you are getting at.
Hope this clarified...
paul c
> On 5 juin, 18:56, paul c <toledobythe...@oohay.ac> wrote:
>> cim...@hotmail.com wrote:
> Question 8 (the one you mentionned): What are the total sales of
> salesmen who sold ALL purple cars is a particular case of Question1
> since all salesmen who sold ALL purple cars are the same than ALL
I believe, au contraire, that the answer is the same as the total sales
of each salesman (assuming there never were any purple cars, which would
be a shame IMO). See "purple parts" in
cim...@hotmail.com
For the moment, let's keep aggregating out of the equation. First, I
want to make sure I understand correctly Question 8. The debunk link
provided does not explain under what conditions a salesman, who'd be a
part of a set of salesmen who have sold ALL purple cars, would NOT
also be a salesman who sold AT LEAST one purple car. I would
appreciate if you could give me one example clarifying the previous
question ?
paul c
It's to do with logical FORALL. If the set of purple cars is empty,
then no salesman could sell any purple cars (not even one) so all
salesman have sold all of them! (wish I could phrase that en francais.)
(I have seen people who are more patient than I express this is in SQL
by negating "NOT EXISTS".)
This query may not seem useful to many people, but if so I'd ask what
would they like to happen if suddently there were purple cars? Not
suggesting a language should be a slave to logic, however, if all the
logical rules aren't followed, then proving a result, comparing two
equal results from different queries (very useful for regression and
other testing), not to mention optimization all become hit-or-miss problems.
As far as I know, nobody, not even the originators, has ever tried to
formalize SQL 'logic'. I wonder why?
paul c
...
> It's to do with logical FORALL. If the set of purple cars is empty,
> then no salesman could sell any purple cars (not even one) so all
> salesman have sold all of them! (wish I could phrase that en francais.)
I really do. Used to have a friend who could give French and Latin and
sometimes Greek translations of my text. If Cimod gets the drift maybe
he'd oblige and maybe he or somebody else could post the Latin.
Something memorable, like semper ubi sub ubi, so I'd never have to think
twice about purple parts again.
paul c
...
> For the moment, let's keep aggregating out of the equation. First, I
> want to make sure I understand correctly Question 8. The debunk link
> provided does not explain under what conditions a salesman, who'd be a
> part of a set of salesmen who have sold ALL purple cars, would NOT
> also be a salesman who sold AT LEAST one purple car. I would
> appreciate if you could give me one example clarifying the previous
> question ?
Maybe this answer is easier for some of us: there are no purple people,
yet we know there are purple people eaters:
cim...@hotmail.com
> paul c wrote:
>
> ...
>
> > It's to do with logical FORALL. If the set of purple cars is empty,
> > then no salesman could sell any purple cars (not even one) so all
> > salesman have sold all of them! (wish I could phrase that en francais.)
doing that, here is the French translation of this assertion:
"Si l'ensemble des voitures pourpres est un ensemble vide, alors aucun
vendeur n'aurait pu vendre la moindre voiture pourpre (pas meme une
seule) alors tous les vendeurs les auraient toutes vendues." I
believe you are not aware how that sounds absurd in French...;)
Walter Mitty
<cim...@hotmail.com> wrote in message
news:007d0b6a-8698-4311...@s16g2000vbp.googlegroups.com...
Here's an attempt in Spanish
"Si el conjunto de autos morados fuese un conjunto vac�o,
entonces ningun vendedor no podr�a vender auto morado alguno
(nisiquiera uno) de tal modo que todos los vendedores
los han vendido todos. "
It sounds equally absurd to me. I'm not sure it's right.
Note the double negative, and the use of a subjunctive.
A guy walks into a coffee shop, and orders a coffee without cream.
The server says, "we're all out of cream today."
"In that case," the guy responds, "I'll have a cup of coffee without milk."
paul c
...
> "Si l'ensemble des voitures pourpres est un ensemble vide, alors aucun
> vendeur n'aurait pu vendre la moindre voiture pourpre (pas meme une
> seule) alors tous les vendeurs les auraient toutes vendues." I
> believe you are not aware how that sounds absurd in French...;)
Merci beaucoup. Maybe it sounds "fou", what about something more pithy
like "nothing is true of everything"?
paul c
...
> Here's an attempt in Spanish
>
> "Si el conjunto de autos morados fuese un conjunto vac�o,
> entonces ningun vendedor no podr�a vender auto morado alguno
> (nisiquiera uno) de tal modo que todos los vendedores
> los han vendido todos. "
>
> It sounds equally absurd to me. I'm not sure it's right.
> Note the double negative, and the use of a subjunctive.
Thanks. Good observations, one could say such queries are indeed
subjunctive (maybe all queries are), here's Date's SQL for "Get
suppliers who supply all purple parts":
SELECT DISTINCT s.*
FROM S AS s
WHERE NOT EXISTS
( SELECT DISTINCT p.*
FROM P AS p
WHERE p.COLOR = 'Purple'
AND NOT EXISTS
( SELECT DISTINCT sp.*
FROM SP AS p
WHERE s.S# = sp.S#
AND sp.P# = p.P# ) ).
If I'm not mistaken the answer is that all suppliers supply no purple
parts. Just a consequence of FOPC.
> A guy walks into a coffee shop, and orders a coffee without cream.
> The server says, "we're all out of cream today."
> "In that case," the guy responds, "I'll have a cup of coffee without milk."
>
You might've hit the nail on the head (which the SQL accomplishes rather
extravagantly by using a wrench instead of a hammer). They did that
joke in a Marlene Dietrich movie, cafe scene where the guy hustling her
and the (French) waiter can't take their eyes off her. Hustler asks for
coffee with no cream. Waiter says there is no cream, would coffee with
no milk do? So the coffee was the same, no matter whether it had no
cream or no milk. Perhaps a viewpoint that life is subjunctive is the
first baby step for escape from mysticism..
Walter Mitty
"paul c" <toledob...@oohay.ac> wrote in message
news:altWl.29656$Db2.6372@edtnps83...
Once in a while, I try to posit a subjunctive query to SQL. Often, the
response I get is "UNKNOWN".
Then I try to explain, carefully and methodically, that the the answer I'm
looking for is not "UNKNOWN".
SQL dutifully evaluates "NOT UNKNOWN" and responds with "UNKNOWN".
Facts are stubborn things. But, if SQL is to be believed, the absence of
facts is even more stubborn yet!
>> A guy walks into a coffee shop, and orders a coffee without cream.
>> The server says, "we're all out of cream today."
>> "In that case," the guy responds, "I'll have a cup of coffee without
>> milk."
>>
>
> You might've hit the nail on the head (which the SQL accomplishes rather
> extravagantly by using a wrench instead of a hammer). They did that joke
> in a Marlene Dietrich movie, cafe scene where the guy hustling her and the
> (French) waiter can't take their eyes off her. Hustler asks for coffee
> with no cream. Waiter says there is no cream, would coffee with no milk
> do? So the coffee was the same, no matter whether it had no cream or no
> milk. Perhaps a viewpoint that life is subjunctive is the first baby step
> for escape from mysticism..
What difference would it make if life were subjunctive?
Bob Badour
> Walter Mitty wrote:
> ...
>
>> Here's an attempt in Spanish
>>
>> "Si el conjunto de autos morados fuese un conjunto vacío,
>> entonces ningun vendedor no podría vender auto morado alguno
If you want subjunctive in English, you have to go with Tevye:
"If I were a rich man, ya ha deedle deedle, bubba bubba deedle deedle
dum. All day long I'd biddy biddy bum. If I were a weathy man, I
wouldn't have to work hard. Ya ha deedle deedle, bubba bubba deedle
deedle dum. If I were a rich, Yiddle-diddle-didle-didle man."
And if you want reflexive, you have to avail yourself of whatever you
can find.
cim...@hotmail.com
> Walter Mitty wrote:
>
> ...
>
> > Here's an attempt in Spanish
>
In a way that gave to think that relational model is *not* ready yet
to apply absurd mathematical reasonning yet. Be it finally sound or
not, absurd logical reasonning is too risky for a young science to be
used as a foundation . I will stick to basic clarifications on a step
y step basis and let the big theories to smarter people.
Regards...
cim...@hotmail.com
Actually I do respect *absurd* reasonning as a mathematical tool (if
you can't prove something is right try to prove that the opposite is
wrong)...I just don't believe that a science that does even yet have
consensus about how universal quantifiers are defined should even go
there. Not for a second. In French: Ne pas mettre la charrue avant
les boeufs.
paul c
...
> Absurd is not necessarily crazy(fou).
>
> Actually I do respect *absurd* reasonning as a mathematical tool (if
> you can't prove something is right try to prove that the opposite is
> wrong)...I just don't believe that a science that does even yet have
> consensus about how universal quantifiers are defined should even go
> there. Not for a second. In French: Ne pas mettre la charrue avant
> les boeufs.
Just curious, since everybody seems to be in such a good mood, is there
a French word for (logically) 'true', other than 'vrai'?, eg., true in
some formal logic sense.
(If English had no such word, limited, say, to 'real', there'd be no
stopping the mystics. Then there is 'faux' which I gather often stands
for artificial. I often think neither language has the exact right
words and think that would put any sensible person in a mood to think
that the relational 'modal' wouldn't be precisely expressible in either
one.)
This all reminds me that I've never tried to follow through Codd's
reduction algorithm nor the later corrections (ie., the equivalence
between the calculus and the algebra might be a way to constrain the
possible interpretations of each individuallly and so avoid the spoken
language problems . Does anybody know of a free online source for either?
cim...@hotmail.com
> cim...@hotmail.com wrote:
>
> ...
>
> > Absurd is not necessarily crazy(fou).
>
> > Actually I do respect *absurd* reasonning as a mathematical tool (if
> > you can't prove something is right try to prove that the opposite is
> > wrong)...I just don't believe that a science that does even yet have
> > consensus about how universal quantifiers are defined should even go
> > there. Not for a second. In French: Ne pas mettre la charrue avant
> > les boeufs.
>
> Just curious, since everybody seems to be in such a good mood, is there
> a French word for (logically) 'true', other than 'vrai'?, eg., true in
> some formal logic sense.
that soldier can answer *affirmatif* to validate the assertion or
negatif to deny it.
> (If English had no such word, limited, say, to 'real', there'd be no
> stopping the mystics. Then there is 'faux' which I gather often stands
> for artificial. I often think neither language has the exact right
> words and think that would put any sensible person in a mood to think
> that the relational 'modal' wouldn't be precisely expressible in either
> one.)
>
> This all reminds me that I've never tried to follow through Codd's
> reduction algorithm nor the later corrections (ie., the equivalence
> between the calculus and the algebra might be a way to constrain the
> possible interpretations of each individuallly and so avoid the spoken
> language problems . Does anybody know of a free online source for either?
Formalism is the only way around subjectiveness. I do somehow believe
that a formalism that is non universal is not good formalism. As far
as the formalism used in RM, I believe that D&D have failed a long
time ago onto designing an effective formalism for scrutiny (which
does not say anything about the algebra though). In a sense, their
body of logical work needs to be reexpressed and reformulated to be
more inclusive to larger audiences.
paul c
...
> In a way that gave to think that relational model is *not* ready yet
> to apply absurd mathematical reasonning yet. Be it finally sound or
> not, absurd logical reasonning is too risky for a young science to be
> used as a foundation . I will stick to basic clarifications on a step
> y step basis and let the big theories to smarter people.
No argument with that, but if we're talking about a shorthand for
division, which is universal quantification, which is defined in fopc,
then the shorthand should produce an equivalent answer to fopc, eg., as
Date says:
(quote)
Have you ever wondered why the operation is called "division?" The
following identity shows why:
( R TIMES S ) DIVIDEBY S = R
Division is a kind of inverse of Cartesian product, and it isn't quite
the counterpart to the universal quantifier that it was meant to be. It
suffers from problems having to do with empty sets and related matters.6
In fact, Codd offers an example that illustrates the problem: Given a
relation SP { S#, P#, ... } showing which suppliers supply which parts,
he claims that the expression SP { S#, P# } DIVIDEBY SP { P# } will give
numbers for suppliers who provide all parts. However, if there aren't
any parts, this expression gives the wrong answer. (It gives no supplier
numbers, yet it should give them all).
Relational comparisons provide a better basis for dealing with the kinds
of problems that division was intended to solve -- but the relational
model as originally defined by Codd didn't include such comparisons at
all.7
(end quote)
(I'm distinguishing shorthand from shortcut, one saves typos', the other
saves steps.)
cim...@hotmail.com
> Relational comparisons provide a better basis for dealing with the kinds
> of problems that division was intended to solve -- but the relational
> model as originally defined by Codd didn't include such comparisons at
> all.7
I would go further than that into saying that previous work has only
clarified side effects of relation operations. And a lot of it missed
the mark into expressing properties of operations that can not be
expressed without proper quantifiers. For instance, does the empty
set has the same role place in relational theory, than the zero would
have in traditional algebra. Up till, such questions have not been
answered and these claims have neither been properly demonstrated nor
they have been properly evaluated. However nothing prevented
demonstrators of using such quantifier in relational operations.
There is something in that puzzles me. The creators of the zero did
prove and demonstrate the usefulness of such value into simplifying
algebra before they could actually use it. Nothing similar can be
said of all particular relation that have been created in packs and
used (Empty sets, DEE, DUM etc...)...In a word, a lot of
demonstrations were made using tools but nobody questionned the
relevance of such tools before using them...That is a deep sign of
immaturity.
paul c
...
> I would go further than that into saying that previous work has only
> clarified side effects of relation operations. And a lot of it missed
> the mark into expressing properties of operations that can not be
> expressed without proper quantifiers. For instance, does the empty
> set has the same role place in relational theory, than the zero would
> have in traditional algebra. Up till, such questions have not been
> answered and these claims have neither been properly demonstrated nor
In relational algebra, I know of only two contexts for the empty set,
one is the empty heading/attribute set, the other is the empty
relation/tuple set. The first has two values, the second can have many
values. Neither operates like arithmetical zero, for example division
by the empty set is defined whereas it is undefined for zero. I'm not
sure what "questions" remain unanswered, as far as I know both empty set
contexts are defined and both function as identities that give
relational closure, unlike arithmetic.
cim...@hotmail.com
> In relational algebra, I know of only two contexts for the empty set,
> one is the empty heading/attribute set, the other is the empty
> relation/tuple set. The first has two values, the second can have many
> values. Neither operates like arithmetical zero, for example division
> by the empty set is defined whereas it is undefined for zero.
The tool of limits demonstrated that the operation is simply not
possible because the result would an infinite value that can not be
handled solely though mere algebra. I used the example of the zero
because this is how I perceive algebric rigor: the need for qualifying
a tool and the limits of such tool to be a reliable way to achieve
demonstrative properties. As for the empty set, describing some
characteristics does not determine it usefulness. I just wished I had
your optimism on that.
> I'm not
> sure what "questions" remain unanswered, as far as I know both empty set
> contexts are defined and both function as identities that give
> relational closure, unlike arithmetic.
I believe in the test of time. zero has now been around for more than
a millenia and allowed great progress for humanity. I would not say I
am confident that the concept of empty set (at least as currently
defined) would provide as much to advance research. Hard to say.
vadi...@gmail.com
> I would go further than that into saying that previous work has only
> clarified side effects of relation operations. And a lot of it missed
> the mark into expressing properties of operations that can not be
> expressed without proper quantifiers. For instance, does the empty
> set has the same role place in relational theory, than the zero would
> have in traditional algebra. Up till, such questions have not been
> answered and these claims have neither been properly demonstrated nor
> they have been properly evaluated. However nothing prevented
> demonstrators of using such quantifier in relational operations.
> There is something in that puzzles me. The creators of the zero did
> prove and demonstrate the usefulness of such value into simplifying
> algebra before they could actually use it. Nothing similar can be
> said of all particular relation that have been created in packs and
> used (Empty sets, DEE, DUM etc...)...In a word, a lot of
> demonstrations were made using tools but nobody questionned the
> relevance of such tools before using them...That is a deep sign of
> immaturity
Share many of your sentiments:
http://arxiv.org/abs/0902.3532
Page 5 documents four constants, compared to Boolean algebra which has
2 constants: top and bottom (aka true and false for two-valued boolean
algebras). In fact, everything exploded twice in relational lattice:
there are 2 pairs of true and false constants, two versions of logical
AND and OR operators (page 6, figure 1), and two versions of
negation!
The last assertion goes a little beyond the scope of the paper which
introduced complement as unary operation satisfying the two axioms:
x' ^ x = x ^ R00.
x' v x = x v R11.
The dual version of this operation also makes sence. Let's call it
"inversion" and use the back quote "`" symbol in postfix notation to
write down the defining axioms:
x` ^ x = x ^ R11.
x` v x = x v R00.
(For those readers who bothered to copy and paste in these identities
into Prover9, please don't forget to add something like
op(300, postfix, "`" ).
to Language options.)
Informally, inversion complements relation header, and it could be
demonstrated that the best it can do about the relation content is
producing either the cartesian product of the full domains, or the
empty relation. Not surprisingly, it is weaker than complement. Double
inversion doesn't hold, only
x```=x`.
The other interesting theorems:
x` v y` = (x + y)`.
x` + y` = (x v y)`.
x'`v y'`= (x ^ y )'`.
Complement and inversion can be viewed as "halves" of genuine boolean
negation operator, because in relational lattice it is impossible to
have a genuine negation.
Now into the main topic -- set equality join. I prefer to focus on set
equality rather than set containment because I expect it to have nicer
algebraic properties. For one thing, set equality join is commutative,
and set containment is not. Because set join is essentially universal
quantifier, and the later is often is written as "/\" (capital join
"^"), lets choose the notation appropriately, so that set equality
join of relations x and y is written as x/\y. What is set equality
join algebraically in terms of our basic operations?
A good starting point is taking a familiar representation of
relational division in terms of standard RA operations, and convert it
to RL. Unfortunately, in RA there is no escape from regressing to
explicit attribute usage, so lets assume that x=X(q,s) and y=Y(s,t).
Then,
X(q,s) /\ Y(s,t) = ( project_q(X) join project_t(Y) ) \
project_qt( (project_q(X) join Y ) symm_diff (X join project_t(Y) ) )
Here is direct RL equivalent:
x /\ y = (x v (y^R00)`) ^ (y v (x^R00)`) ^
(
(((x ^ y) v (x v y)`) ^ R00) v
(
( ((x v (y^R00)`) ^ y) v ((y v (x^R00)`) ^ x) )
^ ( ((x v (y^R00)`) ^ y) ^ ((y v (x^R00)`) ^ x) )'
)
)'.
This certainly looks more verbose than RA, on a plus side however,
there is no explicit reference to relation attributes; every variable
is a relation! Please also note how inversion came handy when we have
to construct relations with attribute sets which are set differences.
After writing this (and double checking its validity in QBQL) I
refused to believe that this is the shortest possible expression for
set equality join. There is no way one can get any insight from such
unwieldy blob!
There indeed is a nicer version:
x /\ y = ((x`*y)^(y`*x)) *
(
((x`*y)^(y`*x)) *
((x'^y)v(y'^x))
)'.
I especially like symmetries and dualities of this one:
x /\ y = ((x`*y)+(y`*x)) ^
(
((x`*y)+(y`*x)) *
((x'^y)v(y'^x))
)'.
I'm still not sure if there are shorter versions. Marshall (who is
apparently in stealth mode) used to work on a program that generates
all valid RL expressions, and this looks like a problem fitted for
such a tool. The other curiosity is how many different RL expressions
one can generate with inversions and complements alone. For example,
the identities
x``` = x`.
x'' = x.
x`'`'`'=x`'.
x'`'`'`=x'`.
show some limitations, but what about less obvious interleavings of
inversion and complement?
vadi...@gmail.com
> The dual version of this operation also makes sence. Let's call it
> "inversion" and use the back quote "`" symbol in postfix notation to
> write down the defining axioms:
>
> x` ^ x = x ^ R11.
> x` v x = x v R00.
>
>
> Informally, inversion complements relation header, and it could be
> demonstrated that the best it can do about the relation content is
> producing either the cartesian product of the full domains, or the
> empty relation. Not surprisingly, it is weaker than complement. Double
> inversion doesn't hold, only
>
> x```=x`.
>
> The other interesting theorems:
>
> x` v y` = (x + y)`.
> x` + y` = (x v y)`.
> x'`v y'`= (x ^ y )'`.
>
> Complement and inversion can be viewed as "halves" of genuine boolean
> negation operator, because in relational lattice it is impossible to
> have a genuine negation.
To clarify this a little more, the fundamental decomposition identity
x = (x ^ R00) v (x ^ R11).
generalizes to
x = (x ^ y') v (x ^ y`).
which the double complement law y = y'' makes it equivalent to
x = (x ^ y) v (x ^ y`').
Compare it to boolean algebra identity
x = (x ^ y) v (x ^ (-y)).
To repeat, one can't have a genuine negation -x in relational,
lattice. The composition of inversion and complement gets us as close
as it can. In order to have genuine negation one would have to
complement not only relation's content, but relation header as well,
and it is impossible to do it satisfactory.
Marshall
> apparently in stealth mode) used to work on a program that generates
> all valid RL expressions, and this looks like a problem fitted for
> such a tool. The other curiosity is how many different RL expressions
> one can generate with inversions and complements alone. For example,
> the identities
Yes, these are both things my program can handle. The theoretical
aspects are fairly far along; what is killing me is the practical
aspects.
Namely, the number of possible expressions in even mildly complex
algebras is mega gigantic, and in algebras with operators that
are both commutative and associative, simply noting that two
complex terms of the same size are syntactically equivalent
is excruciatingly slow. I have recently purchased a much
more powerful machine but I'm not sure how much this will
help; the big wins have all been the results of greater
understanding of the nature of Universal Algebra.
I still have good ideas left for how to do better, and I
believe a complete equational theory of Vadim's algebra
is mechanically achievable.
Marshall
Tegiri Nenashi
> one can generate with inversions and complements alone. For example,
> the identities
>
> x``` = x`.
> x'' = x.
> x`'`'`'=x`'.
> x'`'`'`=x'`.
>
> show some limitations, but what about less obvious interleavings of
> inversion and complement?
Neither complement (x') nor double inversion (x``) change the header
of an input relation. Therefore, they are set operations affecting
relation tuples only. Complement (x') is the set complement, and
double inversion (x``) is a closure:
(x``)`` = x``.
I vaguely remember an exercise in Kuratovski and Mostovski "Set
Theory" book that asserts that starting with an arbitrary set one can
build no more than 13 different sets by interleaving application of
closure and complement.
cim...@hotmail.com
> On Jun 6, 2:19 pm, vadim...@gmail.com wrote:
>
>
>
> > I'm still not sure if there are shorter versions. Marshall (who is
> > apparently in stealth mode) used to work on a program that generates
> > all valid RL expressions, and this looks like a problem fitted for
> > such a tool. The other curiosity is how many different RL expressions
> > one can generate with inversions and complements alone. For example,
> > the identities
>
> Yes, these are both things my program can handle. The theoretical
> aspects are fairly far along; what is killing me is the practical
> aspects.
> Namely, the number of possible expressions in even mildly complex
> algebras is mega gigantic, and in algebras with operators that
> are both commutative and associative, simply noting that two
> complex terms of the same size are syntactically equivalent
> is excruciatingly slow. I have recently purchased a much
> more powerful machine but I'm not sure how much this will
> help; the big wins have all been the results of greater
> understanding of the nature of Universal Algebra.
For what it's worth...
For having been involved in the exercice of attempting to build a
logical machine to be a sound evaluator for relational operations, I
have discovered that there is an intricate relationship between the
coherence of relation equation solving and the logical computing model
used to actually represent a single relation, given current
constraints imposed by memory/cpu architectures. In other words, the
two aspects simply can hardly be dissociated: building an relation
equation expressor without considering a serious work onto how there
are to be represented logically (and physically as a consequence) will
not only put such effort in jeopardy but will make one hit a stone
dead end due to the fact that a logical expression solvers built on
the principle of direct image systems relation representation, has a
very limited scope of verification.
I have designed a logical and computing model based on the principle
of representing relations thanks to fractal contructs which allows to
exploit other effective mathematical tools than traditional ra to
effectively operate relations and have the logical machine make
logical inferences as to the most appropriate formulation of a
relational operation. I am not sure that does make sense to somebody
who's involved deeply into the logical aspect of correctness but it is
a friendly word of warning.
> I still have good ideas left for how to do better, and I
> believe a complete equational theory of Vadim's algebra
> is mechanically achievable.
Yes it is but not without having a complete view of the problem and
taking into considerations the need for a sound logical representation
of relations.
> Marshall
cim...@hotmail.com
> 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.
I hoped that using questions would help clarify the scope but I am
realizing I was wrong.
> I prefer to focus on set
> equality rather than set containment because I expect it to have nicer
> algebraic properties.
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.
> For one thing, set equality join is commutative,
> and set containment is not. Because set join is essentially universal
> quantifier, and the later is often is written as "/\" (capital join
> "^"), lets choose the notation appropriately, so that set equality
> join of relations x and y is written as x/\y. What is set equality
> join algebraically in terms of our basic operations?
I would really appreciate if you could express the Questions proposed
(and only the Questions proposed), using the relations proposed (and
only the relations proposed), but using the notation you are more
confortable with. It would help me greatly to relate to the arguments
you are developping to apprehend the problem I am trying to address,
but through your angle. It will also allow me adapt my communication
to the logical tools you are using to verify correctness... Too many
times, differences in notations make it difficult for people to
exchange information into an effective way and tend to create
dispersion as to solve well defined problems (call it another sign of
immaturity of relational theory). That is why, I promote first the
focus onto a single problem and make the effort of understanding
somebody else notation.
vadi...@gmail.com
> On 6 juin, 23:19, vadim...@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.
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.
> 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?
cim...@hotmail.com
> 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.
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...
Vadim Tropashko
I added expression generator facility to QBQL. The key to
combinatorial explosion is to do a targeted search, rather than be
overwhelmed by finding everything. The facility is not mature yet to
search for relational division, but the search for x`` discovered the
following amaizing identity:
x`` = ( x v R11 ) ^ ( x v R00 ).
P.S. I realize that until I write a decent tutorial and make a
friendly user interface not many people (and most likely nobody at
all) would bother checking up QBQL. However, it is so much fun to
program and discover things than to write documentation!