Re: More on lists and sets
Date: 30 Mar 2006 00:33:25 -0800
Message-ID: <1143707605.673005.123230_at_e56g2000cwe.googlegroups.com>
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:
>
> {Order, Product, Process: {Step, Operation, Materials: {Part, Quantity}}}
>
> To clarify a few things: [...]
>
> Now, this NFNF relation may work great for printing a routing, and it would
> be advantageous to have a mechanism to define a view for that purpose, but
> this scheme is riddled with redundancy. For example, if management decides
> to affix barcode labels on a particular line of products, then every work
> order for that product line must be modified to reflect the additional
> operation--even if there are many orders that use the exact same process.
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.
- Jan Hidders