On Apr 10, 9:45*am, com... (AT) hotmail (DOT) com wrote:

The problem for me is that I'm impatient, and it's really difficult to
write in genuine math symbology today. Absent that, I think the above
example at least is a completely standard ASCII rendition: K stands
for key, A stands for the first constant in use, subscripts are
underscored, the implication arrow reads as =>, set difference uses \
or -, even operator precedence is in order, and additionally the
primary symbols are explained in text. join_K is perhaps a bit
interesting, but on the math side of things, juggling arguments
between infix, prefix and subfix notations is really quite common, and
is thought to be obvious as long as the parameter symbols don't vary
on the way.

Thanks for putting up with me. That's the intuitive thinker speaking
in me. Once you have the trait, it's rather difficult to shake it: you
don't see the vagueness in your own writing even upon repeated reading
and editing.

The misconceptions you can correct, but yes, the histrionics is a
tough problem. That's then the borderline/bipolar/alcoholic/depressed/
insomniac side of me speaking; the results can't be excused, but again
the underlying reasons are somewhat difficult to control.

The most unclear and nonstandard part about what I was saying was
perhaps joins without renaming. At least it bugged me the most
afterwards. The idea there comes from one of my past lecturers. I
never really understood how you could call the relational algebra
closed in the standard, wider sense if you forbade joins among
relations with identical attributes unless you renamed one of them
first. His idea was that you can formalize the algebra in at least two
different ways such that renames aren't required, but the whole thing
still leads to equivalence with what you'd probably call the standard
RM. Namely, taking a self-equijoin of a relation with the heading {A,
B, C} on {A, B}, you could either define the unrenamed result
(notionally {A, B, C, C'} with C=C') as the empty set when there is
any case where C and C' disagree, or alternatively as the restriction
to those tuples where there is no disagreement. The same sort of
trickery can be performed on the definitions of the rest of the
operators, e.g. by allowing joins on keys absent from one or both
relations.

That does destroy some of the usual lattice properties of the theory,
but when you go through with it, the resulting algebra agrees with the
standard one. After the exercise, my suggestion of A join_K A=A goes
through as well. We can disagree about whether it's best to formalize
the theory this way or in some other, but personally I like the idea
that all operators can be applied indiscriminately to any arguments at
all.
--
Sampo

On Apr 6, 5:05 pm, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:

If we are precise it's a bit more complicated:
( r GROUP ( { n1, ... } AS n ) ) =
( EXTEND r ADD RELATION { TUPLE { n1 AS n1, ... } } AS n )
{ k1, ..., n }

Maybe, if you can find natural language to make it clear that this
captures the idea of key constraint.

You don't need to use COUNT or GROUP/nesting.
(Ironically the latter, like the former,
requires an extension to the original algebra.)
"A k-subtuple can't appear with a second n-subtuple."
Using calculus (with named arguments):
FALSE =
EXISTS k1, ..., n1, ..., _n1, ... :
r(k1 as k1, ..., n1 as n1, ...)
AND r(k1 as k1, ..., _n1 as n1, ...)
AND n1 NOT= _n1 AND ....
Using algebra (with parallel structure to above):
DUM =
( ( r JOIN (r RENAME { n1 TO _n1, ...}))
RESTRICT { n1 NOT= _n1, ...}
){ALL BUT}

I don't understand this.

By the way it is important to have a keyword for keys.
Although a non-keyword expression can be evaluated
as a constraint there is in general no way to for a dbms
to tell that a given constraint implies a key constraint.
And it needs to know this for important optimizations
(of other than just relational expressions).

Although I sympathize with you I suggest that it is
hopeless to choose the form of your specification on the basis
of hoping to circumvent incompetent programming.
COUNT has a precise & simple definition, why not use it?
Yes, competent designers and implementers use math.
Yes, most designers and implementers work willy-nilly.
This is true for all programming.

philip

compdb (AT) hotmail (DOT) com wrote:
That is the conventional definition, using cartesian product and rename.
I didn't say you NEED to use GROUP.

compdb (AT) hotmail (DOT) com wrote:
Among other things, ignores or mangles empty sets, Date has written
about that and other flaws. I thought the inconsistencies of SQL were
widely accepted. Is it necessary to repeat the various autopsies? If
it could be salvaged maybe, but I doubt if sql is salvageable.


As I said, I wanted to avoid COUNT even if I can't make it very clear
why. Also cheated a bit by using D&D GROUP in example rather than
trying to define an algebra that makes GROUP fundamental. But I wasn't
motivated by 'incompetent programming', thought I did emphasize that the
purpose was precise definitions for optimization.


I'll take a stab at a reason for avoiding COUNT even though I know it
will probably seem murky. Off the top, it requires either a 'sweep' of
tuples or a physical device that keeps a tally (I know D&D GROUP as
defined currently also requires a sweep, please ignore that objection
for now). Count or cardinality is an accepted property of a set and at
some point in the development of a logical machine, people will want it
(just as they will want keywords or some other convenient notation) but
I want to postpone the introduction as long as possible. Maybe it's all
prompted by my suspicion that Codd really should have made the values of
his triples sets. From an optimization point of view, a 'mapping' from
a key definition to the minimum 'access' performed by a logical machine
seems more obvious when it involves only one tuple so I think this
suggests confining attention to the possible forms a single tuple can
take. D&D algebra builds up a lot of logical machinery before it gets
around to grouping. It might be interesting or even useful to play the
key card earlier on. If I am wrong about this, the exercise might still
have value in showing that the COUNT approach is preferable.