Re: Proposal: 6NF

Brian Selzer wrote:

[big snip]
>
> Two database schemata are equivalent if all of the information contained in
> an instance of one can be derived from the information contained in an
> instance of the other. Database schemata A and B are equivalent if and only
> if a pair of inverse mappings exist between A and B: one mapping from A to B
> such that for every legal instance of A, there exists one and only one legal
> instance of B, and one mapping from B to A such that for every legal
> instance of B, there exists one and only one legal instance of A. In other
> words, given any instance of A, only one instance of B can be derived using
> the mapping from A to B such that when the mapping from B to A is applied to
> that derived instance, the result is the original instance for A, and given
> any instance of B, only one instance of A can be derived using the mapping
> from B to A such that when the mapping from A to B is applied to that
> derived instance, the result is the original instance for B. Note that this
> applies to database schemata with and without nullable attributes. For
> example, a database schema D consisting of a single relation,
>
> R {A, B, C}
>
> that satisfies the functional dependency A --> B is not equivalent to a
> database schema D' consisting of two relations,
>
> S {A, B}, T {A, C}
>
> without the circular inclusion dependency S[A] <--> T[A] because for any
> given instance of D, there can be a huge number (infinite if any domain for
> A, B or C is infinite) of instances of D' where the natural join of the
> extensions of S and T is equal to the extension of R. The circular
> inclusion dependency ensures that the projections of S JOIN T over {A, B}
> and {A, C} are equal to the extensions of S and T respectively.
>
> I hope that the above description and example illustrate what I mean by
> equivalent database schemata. For a database schema without nullable
> attributes, the mappings involve sets of projections and natural joins. For
> a database schema with nullable attributes, the operations are different. A
> simple projection would still include nullable attributes. To eliminate
> them, the decomposition operation must also restrict the projection to
> eliminate any tuple with a null. As a consequence, the inverse operation
> must be an outer join which restores the eliminated tuples. In addition,
> instead of a circular inclusion dependency, all that is needed is a single
> foreign key constraint. There is no need to maintain a 1:1 correspondence
> between tuples from each projection because since the original attribute is
> nullable, the 1:1 correspondence didn't exist to begin with.

Schemata. Instances. Information. Pairs of inverse mappings. Laws. (And lawyers and judges?) Nullable attributes. Natural joins. Decomposition operations. Restricted projections. Inverse outer joins. Circular inclusion dependency.

I'm left scratching my head when, as it turns out, the "pairs of inverse mappings" have something to do with tuples from projections exchanging some sort of correspondence with each other. Or not. I think it depends. Right?

I'm sorry I asked. I should have known better... Received on Thu Oct 05 2006 - 03:16:45 CEST