Re: I have read tons of theory...but still...one question

From: Dawn M. Wolthuis <dwolt_at_tincat-group.comREMOVE>
Date: Mon, 18 Oct 2004 08:06:52 -0500
Message-ID: <cl0f5o$3sp$1_at_news.netins.net>


"Marshall Spight" <mspight_at_dnai.com> wrote in message news:L9Kcd.268207$D%.254344_at_attbi_s51...
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.comREMOVE> wrote in message
news:ckumal$6op$1_at_news.netins.net...
> > "Marshall Spight" <mspight_at_dnai.com> wrote in message
> > news:l3icd.193833$wV.79092_at_attbi_s54...
> > >
> > > So let me ask how this "embedded sub-table" works, because I'm
> > > intrigued by NFNF but haven't had an opportunity to work with
> > > such a system.
> > >
> > > Does the embedded sub-table (EST) have its own key? Is it unique
> > > across the entire relation-valued attribute, or is in only unique for
> > > the row?
> >
> > For terminology, IBM calls it "nested" and just remember that we are
talking
> > about the logical structure.
>
> No need to remind me about logic; I'm practically Vulcan that way.
>
>
> > Nested lists (of one or more attributes) are
> > ordered, but not keyed from the perspective of the toolset (that I work
> > with) other than by the parent key and the position in the list.
>
> Is the top-level table ("file"?) ordered?

No. However, another "file" (yes, that is what it is called -- this is pre-relational stuff in origin) could include a foreign key list that is ordered. For example, you might very well have all people in one file, but have a foreign key that matches a parent (as in a real parent who raises kids) to their children and this list of keys might just order those children oldest to youngest.

> This distinction doesn't sound too important to me; they use a nested
> list but one could imagine a nested relation just as well.
>
>
> > However,
> > the list can be searched using values of other attrbutes, so if there is
> > another attributes that could be considered candidate keys, then a
> > particular row could be accessed by knowing that value as well. In the
case
> > of the toolset I work with, the uniqueness of that value within the
nested
> > list would not be enforced by the database., but by the application
> > (typically a wrapper servicing multiple applications).
>
> Again, it is fairly easy to imagine a relational/unordered version of
> the same, with a key required and the nested relation unordered.

Yes -- it simply trims back the required data elements so that there is no need to have a bunch of ordering data stored for simple lists where the ordering is sometimes relevant.

>
> > > For example, let's say I have a relation of (l=letter, set-of-(i=int,
> > s=string)).
> > > l is the key of the outer table; i is the key of the inner table. (Or
is
> > it (l,i)?)
> > >
> > > Is this a legal table:
> > > a,{(1,"hello")}
> > > b,{(1, "world"),(2,"foo")}
> > >
> > > Two rows have a value 1 for some i.
> >
> > Yes, definitely!
>
> Hmmm. I would think this is specific to the fact that you're
> used to nesting lists, and not relations. Lists would necessarily
> start the numbering over again, whereas a key might not.

I might not have followed your example. Is a one complete row and b another? I have never worked with a multivalued key to the table itself, although that might be possible. I was thinking that since b, was a list, it was embedded in a row with a different primary key. If the 1 in both a and b are primary keys to the table, then no, there is no duplicate permitted. However, one can have {(1, "hello", {(1,"world"), (2,"foo")})} as one row (record) and then a second as {(2, "goodbye", {(1,"world"), (2,"foo")})}

sorry for the confusion

> > > It seems both right and wrong either way. This is pretty much my only
> > > (current) point of confusion about RVAs.
> >
> > This is also the case with an RVA meeting SQL-99/SQL3 standards IIRC.
For
> > both the non-1NF (pre/"post"-relational) and the newer relational model,
> > this permits you to retrieve child relations without an explicit join
> > condition.
>
> Wait! How does it permit that? I didn't follow.

The database has an implicit join by declaring a nested structure in the definition of the schema. So, you don't code any joins for data retrieval -- you select from the parent table and it can find all nested structures

>
> > select * from table;
> >
> > above would yield a result set that includes 1 hello 1 world 1 foo
> > as a single "row" of output.
>
> Yoink! I didn't follow that.

As in the example below. You can tell a SINGLE table/file to select everything and it will find all nested lists -- no explicit joins because the structure knows you want to information about the parent and that includes the info from the children

>
> > Think what it takes in SQL to get the
> > following output from a typical structure
> >
> > Name .........E-mail addresses........Phone Type.....Phone Number
> > John Doe jdoe_at_aol.com Home (123) 555-2783
> > john_doe_at_msn.com Work (123) 555-1283
> > Mobile
> > (382) 555-2983
> > Jane Ayee janeayee_at_a.net Mobile (732) 555-2182
> >
> > Notice how the multiple nested lists (multiple 1-M child tables) are
> > handled. There is no assumption as there is witih SQL that a single row
of
> > output has data related to each other except through the parent.
>
> I could imagine a relational, NFNF version of the above table. I assume
> that name:email is 1:m, and name:(phone type, phone number) is 1:m.
> Something like
>
> { Name:string, email:{string}, phone:{type:enum, number:string}}

Yes. PostgreSQL permits such a construct IIRC. --dawn

>
>
> Marshall
Received on Mon Oct 18 2004 - 15:06:52 CEST

Original text of this message