Re: Onto a potential relational manipulation language
Date: Tue, 9 Dec 2008 16:42:44 -0800 (PST)
Message-ID: <9d828b79-8324-46df-9bd6-94715d43e9c6_at_r36g2000prf.googlegroups.com>
On 10 déc, 00:14, paul c <toledobythe..._at_oohay.ac> wrote:
> Cimode wrote:
[Snipped]
--1st EXAMPLE
> Projection: The Tutorial D <project>
> R { ALL BUT A}
or more simply
R = [ALL - A], ALL being *any* un-ary relation and A being another
un-ary relation.
I use "-" sign to represent MINUS. Call it a math bias ;)
--2nd EXAMPLE> Join: The Tutorial D <join>
> R1 JOIN R2
> is semantically equivalent to the A expression
> R1 <AND> R2
Quite frankly, I always felt uncomfortable with Td implementation of
JOIN which leads to equate JOIN and AND on a semantic way. I tend to
think this may lead to confusion between UNION and JOIN. AND tends to
express additivity not JOIN. Besides, one does not naturally think of
a relation as a predicate. This may lead to important confusions.
In the computing model I am using the JOIN operator is a part of relation definition as opposed to being an operation in itself. The cardinalities of each relation may allow or not the definition.
To express R1 JOIN R2, I prefer the use of the following...
R3 = [R1 INTERSECT R2] in operation section where R3 is a new relation. For instance. The advantage is versatility: consider the following example:
I can do it both ways either operationally or declaratively
METHOD1
SCHOOL=[{NAME Char NATURAL_KEY}]
STUDENT=[{FNAME Char , LNAME Char , DOB Date, SCHOOL School}] STUDENT_FROM_HARVARD = [STUDENT WITH SCHOOL = 'Harvard']
OR I do the following
METHOD2
SCHOOL=[{NAME Char NATURAL_KEY}]
SCHOOL_HARVARD = [SCHOOL = 'Harvard']
STUDENT=[{FNAME Char , LNAME Char , DOB Date, SCHOOL School}] STUDENT_FROM_HARVARD = [STUDENT, SCHOOL_HARVARD] and I do not need to operate or JOIN anything since they are already defined
I somehow appreciate that versatility.
SELECT FNAME, LNAME
FROM STUDENT JOIN SCHOOL
ON STUDENT.SCHOOL = SCHOOL.NAME
WHERE SCHOOL = 'Harvard'
> The Tutorial D <intersect> R1 INTERSECT R2 is just that special case
> of R1 JOIN R2 in which R1 and R2 have the same heading, so the <AND>
> operator of A takes cares of INTERSECT as well.
This is where I do not feel comfortable with Td again. The
multiplication of synonyms (AND, JOIN, INTERSECT) leads to confusion.
> To me, starting this way is much more fruitful than starting with
> examples of complete statements that must necessarily involve other
> concepts such as assignment (not saying assignment is necessary, if it
> were up to me I would avoid explicit assignment entirely). I say
> fruitful because the resulting formal spec' is so small, just a couple
> of pages, that one can easily memorize it. This makes it so much easier
> to review real snippets of code or long expressions and compare to their
> correct behaviour. (When I first saw the original TTM book, it took a
> while for it to dawn on me that the definitions had a life of their own
> that went beyond just their use for initial implementation.)
>
> (You can guess from the use of the < and > delimiters that they wrap
> elements that show up later in the grammar.)
Cheers... Received on Wed Dec 10 2008 - 01:42:44 CET