Re: Nested Relations / RVAs / NFNF

From: Kenneth Downs <firstinit.lastname_at_lastnameplusfam.net>
Date: Tue, 26 Oct 2004 16:55:51 -0400
Message-ID: <skdmlc.2b6.ln_at_mercury.downsfam.net>


Marshall Spight wrote:

> Let us discuss relations which have relations as attributes.
>
> As I see it, there are a few different ways to go.
>
> 1) Nesting. Relations may have relations as attributes. These
> attributes are relation values, and must conform to the ususal
> definitions: they have at least one key. But, since each row's value
> for the attribute is a separate value, the keys are not unique inter-row,
> but only intra-row. (That is, you can reuse key values afresh
> in each row.) There is no need to have anything in the relation
> value to indicate which row it's in, because it's nested. That is,
> no foreign key.

I tend to think in terms of tables and SQL, so my questions will be phrased that way. Let's make up a DDL for this:

CREATE TABLE order (

   order_num int PRIMARY KEY,
   order_date int,
   order_lines relvar (CREATE TABLE ....))

This is I suppose a "fixed" nested table, or homeo-morphic (? one shaped?). Can it be demonstrated that such a case is equivalent to simply having two tables?

Or perhaps the more flexible:

CREATE TABLE widgets (

   widget_id char(10) PRIMARY KEY,
   details relvar)

INSERT INTO widgets (widget_id,details)

   VALUES ('DOODADS',Select * from DOODADS) INSERT INTO widgets (widget_id,details)

   VALUES ('CHOMPERS',Select * from CHOMPERS)

>
> 2) Pseudo nesting. Relation attributes aren't anything "real"
> but are instead something that arises when another
> relation has a foreign key into this table. In that case, we have
> a "virtual" attribute whose value is necessarily a relation,
> but it's really more a view onto a nested world than
> anything new and specific. Nested relation are really
> just other tables, and so require keys, and from the
> viewpoint of the nesting table, the keys are unique
> across all rows. (Unlike in 1.)
>
> Something weird about 2). In the nested view, the
> foreign key goes away, okay fine, but the primary
> key of the nested table now has to be unique across
> the entire table, so you can have a perfectly good
> row for the nested table, and fail on insert because
> of a uniqueness constraint that's hard to mathematically
> justify.

I am not following #2 at all, can you give an example?

-- 
Kenneth Downs
Use first initial plus last name at last name plus literal "fam.net" to
email me
Received on Tue Oct 26 2004 - 22:55:51 CEST

Original text of this message