Re: Relational and multivalue databases

"Eric Kaun" <ekaun_at_yahoo.com> wrote in message news:oa3Zb.23461$8X7.1156_at_newssvr16.news.prodigy.com...
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> news:c10ot4$pev$1_at_news.netins.net...
<snip>
> > It is typically considerably easier to query non-1NF structures than to
> use
> > SQL on anything. Here's a common type of query:
> >
> > LIST STUDENTS WITH EVERY MAJOR NOT EQUAL "MATH"
> >
> > Think this easy query through in your typical RDBMS (SQL)
implementation.
> > This is not an isolated case.
>
> So how would this "look" in Pick? Are your assumptions that a student has
> multiple majors? Once I see what you're getting at, I (we?) can respond
with
> relational counterparts. This doesn't look especially troubling, even for
> SQL. I'm assuming (until I hear otherwise) that you'd have a Student
> relation, a Major relation, and a StudentHasMajor relation. Depending on
how
> you "knew" it was "Math", you could omit the Major relation from your
query.
> Join Student to StudentHasMajor, limit based on major, and project over
> student ID (or whatever).

First note that the corresponding SQL statement is not complicated for a SQL coder, but notice how English-like the PICK counterpart sounds. Compare:

LIST STUDENTS WITH EVERY MAJOR NOT EQUAL "MATH" with the SQL corresponding statement that Bob wrote for this:

SELECT *
FROM STUDENTS
WHERE 'MATH' != ALL (
  SELECT SUBJECT
  FROM MAJOR
  WHERE STUDENTS.ID = MAJOR.STUDENT_ID
)

Think of a "file" as a function that maps an identifier to a set of attributes. For example, the STUDENTS function could be

STUDENT(identifier)={string-of-attribute-data-with-delimiters}

This string of data could be:
Joan<field-delimiter>
Doe<field-delimiter>
6165551234<value-delimiter>7615552222<field-delimiter> MATH<sub-value-delimiter>2002<value-delimiter>PHIL<sub-value-delimiter>2003< field-delimiter>

There are also
<record-delimiter>
<file-delimiter>

and one can define delimiters to any desired level, with typically at least this many included in the packaged functions for the database implementation

Then associate this with vocabulary functions such as

FirstName(STUDENTS, identifier) = string-field-in-location-1 SecondaryPhoneNumber(STUDENTS, identifier) = string-value-in-field-3-value-2

So it is the vocabulary functions that make the queries very easy for users. A vocabulary entry can contain many other types of functions, including those that reach to any other files within the system.

So, the details about a major, for example, would be in a subject file such as MAJORS, which would also be a function

MAJORS(identifier) = {string}

Then a vocabulary entry could be defined for students such as

MajorRequirement(STUDENTS, identifier) = MAJORS(StudentMajor, field n)

So, everything is defined in terms of functions including stored data and any other vocabulary (for stored or virtual fields)

>
> In Pick I'm guessing you'd say you have just 1 file, with a list of majors
> as an attribute. But consider the following:
> 1. To what would you attach, for example, requirements for a major? Surely
a
> major is more than a piece of text?
> 2. To what would you attach, for example, the date that the student picked
> up (or completed!) a major?
> 3. Do I really need to loop through every student in the file to determine
> how many math majors there are?
>
> And many such others.
>
> > And it isn't just single fields that can be nested, but fields can be
> > grouped together and nested as a "nested function" or "nested relation"
> (if
> > you prefer).
>
> Can you explain further? What does the grouping mean, and how does a
> function figure into this?

I think the above example shows this. Please let me know if I should clarify anything here. Thanks. --dawn

>
> - Eric
>
>
Received on Thu Feb 19 2004 - 18:24:28 CET