Re: More on lists and sets

From: Brian Selzer <brian_at_selzer-software.com>
Date: Mon, 27 Mar 2006 12:42:25 GMT
Message-ID: <R4RVf.59914$H71.43001_at_newssvr13.news.prodigy.com>


"Jan Hidders" <hidders_at_gmail.com> wrote in message news:1143452308.856695.294440_at_z34g2000cwc.googlegroups.com...
> Brian Selzer wrote:
>>
>> The problem with NFNF models is the introduction of redundancy and second
>> order predicate logic.
>
> NFNF models do not necessarily introduce redundancy. And neither is the
> logic that is required to deal with them a problem. Note that just as
> we only use a restricted subset of first-order logic for the flat
> relational model, you would also only use a restricted subset of
> second-order logic fo the nested relational model, and the prevents any
> theoretical problems.
>

They certainly can. I don't have time right now to provide an example, but maybe I'll get to it this evening.

>> Issues that are solved through the application of
>> higher normal forms reappear with the introduction of composite
>> attributes.
>
> Such as? In fact, the reverse true. It is for example known that in
> some cases normalization to BCNF while being dependency preserving is
> not possible in the flat model, but is in fact possible in the nested
> relational model (given appropriate generalizations of dependencies and
> normal forms).
>

If a tuple with a list is deleted, the contents of the list is also deleted, possibly snuffing out the only instance of that list in the database. This may not be a problem in most cases, but wasn't this same scenario one of the arguments for further normalization?

The problem caused by the lack of dependency preservation can be overcome in several ways, such as by using surrogates or circular inclusion dependencies.

>> The predicate of a NFNF relation may include variables that range over
>> subsets, which cannot be expressed using first order logic. I think that
>> this makes it much more difficult to verify the correctness of the model.
>
> You can express a larger class of constraints and some of those are
> indeed hard to verify, but since the alternative is to not express them
> at all and the old ones are still just as hard to verify, I find it
> hard to see that as a problem.
>
> -- Jan Hidders
>
Received on Mon Mar 27 2006 - 14:42:25 CEST

Original text of this message