Re: Relational and multivalue databases

"Eric Kaun" <ekaun_at_yahoo.com> wrote in message news:xwm_b.27232$Zn.5493_at_newssvr16.news.prodigy.com...
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> news:c12rgj$4e1$1_at_news.netins.net...
> > [...]
> > 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)
>
> But the functions are only naming things, right? They don't really
establish
> any typing, nor are they computational functions (or can they be?). It's
> just to establish that field 3 is phone number?

These are actually able to define any derived data from any files across the system. So, they do linking, computation, etc (by use of subroutines employing procedural code -- feel free to groan, but ...).

> In any event, should you
> choose to, relational can do exactly the same thing - establish a
PHONELIST
> type, and write SECONDARY_PHONE as a function over it. Or even a LIST
type,
> and SECOND_ELEMENT on it, if you care to.

I know that PICK can emulate a relational database (at least to the extent that it can be SQL-compliant) and I know that relational db's can employ user-defined functions or stored procedures, or whatever, to add to the language. However, in implementations like Oracle, a stored procedure still doesn't return a list of values to my knowledge (SQL Server does have that capability). I recall a few years ago someone saying that PICK can pretend to be relational, but relational cannot pretend to be PICK. That might not be the case now with some of the additional types added to some rdbms's for non-simple values.
Cheers! --dawn Received on Mon Feb 23 2004 - 14:54:51 CET