Nested Relations / RVAs / NFNF

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.
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.

It occurred to me that Pick's use of lists as the nesting type, which means they use list indexes as the key, lets them get around this. This is probably an advantage.

Side option: opaque keys. You have a data type that supports only these operations: generate a unique value, test for equality. It is impossible to "forge" an existing value, but you can copy it.

If you had this data type, then it would solve the "something weird" above. I seem to recall reading a post by Jan Hidders from a year or two ago in which he says that this solves a lot of problems around nested relations.

Let's talk.

Marshall Received on Tue Oct 26 2004 - 16:16:56 CEST