# Re: More on lists and sets

From: Jan Hidders <hidders_at_gmail.com>
Date: 30 Mar 2006 00:33:25 -0800

Brian Selzer wrote:
> "Jan Hidders" <hidders_at_gmail.com> wrote in message
> >
> > Brian Selzer wrote:
> >> "Jan Hidders" <hidders_at_gmail.com> wrote in message
> >> > 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.

> I want to go into more detail, and I will in a later post, but there's