Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> comp.databases.theory -> Re: More on lists and sets
Brian Selzer wrote:
> "Jan Hidders" <hidders_at_gmail.com> wrote in message
> news:1143466606.175179.157530_at_t31g2000cwb.googlegroups.com...
> >
> > Brian Selzer wrote:
> >> "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.
> >
> > Please do, and make sure you use a typed higher order logic.
>
> I'm not sure what a typed higher order logic has to do with redundancy.
Nothing, but you said there were two problems: redundancy and 2nd order logic. The theoretical issues you might expect with the latter are mostly prevented by using a typed version. But I know understand you think that redundancy is the only problem, so let's go from there.
> Let's say that you're creating work orders to make batches of finished parts
> (products). So, you have the following NFNF relation:
>
>
>
Of course, and you would have the same "problem" if you had flattened the table and then normalized it. Note that it may not always be true that you want to do the same thing for the same process, because it is also conceivable that it may depend upon the type of order whether the barcode labels are necessary or not.
However, you do have a point in that one has to be careful about when to nest an entity in another entity. Suppose that A : { B, C : { D, E } } then this implies that C is a weak entity that depends upon A, not only for its existence but also for its identification. If this is not the case then you get indeed the update anomalies you are talking about.
> I want to go into more detail, and I will in a later post, but there's
> something about this NFNF relation that intrigues me: you can't flatten it
> out without losing information, and I would invite comment on that.
My comment would be that I have no idea why you think it cannot be flattened. Assuming that {Order, Product} is a candidate key of the whole relation, and {Step} of the nested Process relation there is no information loss.