Re: Proposal: 6NF

"J M Davitt" <jdavitt_at_aeneas.net> wrote in message news:12ZUg.8729$pq4.4606_at_tornado.ohiordc.rr.com...
> 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 don't think it depends. In the above example, if S and T do not "exchange some sort of correspondence with each other," then database schema D containing only R is broken, meaning that there are some legal combinations of values for S and T that cannot be represented in a legal value for R (without using nulls, of course).

> I'm sorry I asked. I should have known better...
Received on Fri Oct 06 2006 - 11:32:08 CEST