At 2:54 AM +0000 12/15/05, Luke Palmer wrote:
On 12/15/05, Darren Duncan <[EMAIL PROTECTED]> wrote:
 I propose, perhaps redundantly, that Perl 6 include a complete set of

Okay, I'm with you here.  Just please stop saying "native" and "core".

Yes, of course. What I meant was that I considered relational data important enough for common programming to be considered by the Perl 6 language designers, so that the language allows for it to be elegantly represented and processed. The implementation details aren't that important.

I would like to hear from Ovid and Dave Rolsky on this issue too, as
they seem to have been researching pure relational models.

As am I now. My own database access framework in development is evolving to be centered more around an ideal relational model rather than simply what SQL or existing databases define. It does any serious database developer good to be familiar with what the relational model actually says, and not just what tangential things have actually been implemented by various vendors. The sources I cited are good reference and/or explanatory materials.

 > Essentially it comes down to better handling of data sets.

Cool.  I've recently been taken by list comprehensions, and I keep
seeing "set comprehensions" in my math classes.  Maybe we can steal
some similar notation.

You probably could; the terms used in relational theory are mostly or entirely from mathematics. (I could stand to learn more about those maths too.)

Hmm.  I would say it's a hash not so much.  For instance, the
difference between an array and a tuple in many languages is that an
array is homogeneously-typed--that's what allows you to access it
using runtime values (integers).  Tuples are heterogeneously-typed, so
you can't say

    my $idx = get_input();
    say $tuple[$idx];

(Pretend that Perl 6 is some other language :-), because the compiler
can't know what type it's going to say.

In the same way, I see a hash as homogeneously-typed, because you can
index it by strings.  What you're referring to as a tuple here would
be called a "record" or a "struct" in most languages.

Yes, you are right; a Tuple is very much a "record" or a "struct"; I just didn't use those because Perl doesn't have them per se; the closest thing that Perl has is the "object", which you could say is exactly equivalent.

 >   * a Relation is an unordered set of Tuples, where every Tuple has
 the same definition, as if the Relation were akin to a specific Perl
 class and every Tuple in it were akin to a Perl object of that class

When you say "unordered set" (redundantly, of course), can this set be
infinite?  That is, can I consider this relation (using made-up set
comprehension notation):

    { ($x,$y) where $x & $y (in) Int, $x <= $y }

And do stuff with it?

Yes you can. A set can be infinite. For example, the set of INTEGER contains every whole number from negative infinity to positive infinity. At the same time, this set excludes all fractional numbers and all data that is not a number, such as characters. This only becomes finite when you place bounds on the range, such as saying it has to be between +/- 2 billion.

 > Specifically what I would like to see added to Perl, if that doesn't
 already exist, is a set of operators that work on Relations, like set
 operations, such as these (these bulleted definitions from "Database
 in Depth", 1.3.3, some context excluded):

   * Restrict - Returns a relation containing all tuples from a
 specified relation that satisfy a specified condition. For example,
 we might restrict relation EMP to just the tuples where the DNO value
 is D2.

Well, if we consider a relation to be a set, then we can use the set operations:

    my $newrel = $emp.grep: { .DNO === 'D2' };

I don't know what EMP, DNO, and D2 are...

Part of the context I excluded before, from section 1.3.1, is that the author is talking about hypothetical DEPT (Department) and EMP (Employee) relations (tables); DEPT has the attributes [DNO, DNAME, BUDGET], and EMP has the attributes [ENO, ENAME, DNO, SALARY]; DEPT.DNO is referenced by EMP.DNO; DEPT.DNO and EMP.ENO are primary keys in their respective relations.

So the restrict example is like, as you said, but with EMP an object:

  my $NEWREL = $EMP.grep:{ $.DNO eq 'D2' };

A SQLish equivalent would be:


 >   * Project - Returns a relation containing all (sub)tuples that
 remain in a specified relation after specified attributes have been
 removed. For example, we might project relation EMP on just the ENO
 and SALARY attributes.

Hmm...  Well, if we pretend that records and hashes are the same thing
for the moment, then:

    my $newrel = $ { .:<ENO SALARY> };

(See the new S06 for a description of the .: syntax)

Or with EMP an object:

  my $NEWREL = ${ $ ENO => $_.ENO, SALARY => $.SALARY ) };



 >   * Join - Returns a relation containing all possible tuples that are
 a combination of two tuples, one from each of two specified
 relations, such that the two tuples contributing to any given result
 tuple have a common value for the common attributes of the two
 relations (and that common value appears just once, not twice, in
 that result tuple).  NOTE, This kind of join was originally called
 the natural join. Since natural join is far and away the most
 important kind, however, it's become standard practice to take the
 unqualified term join to mean the natural join specifically, and I'll
 follow that practice in this book.

I would totally tell you what the best way to do this was if I could
understand what the hell it was talking about.  Examples?  Proposals?

Here's the example in the book (section 1.3.3):

The natural join of ...


... and ...


... is ...


SQLish is:


 >   * Divide - Takes two relations, one binary and one unary, and
 returns a relation consisting of all values of one attribute of the
 binary relation that match (in the other attribute) all values in the
 unary relation.

Again, I don't follow.

First of all, for language, an n-ary relation is a relation having n attributes; a binary relation is like a table with 2 columns, and a unary relation is like a table with 1 column.

This is the example the book gives (section 1.3.3):

If you take ...


... and divide it by ...


... the result is ...


I'm not sure if Divide has an equivalent in SQL.

-- Darren Duncan

Reply via email to