Re: More on lists and sets

From: Brian Selzer <brian_at_selzer-software.com>
Date: Thu, 30 Mar 2006 13:49:06 GMT
Message-ID: <mlRWf.49589$2O6.44754_at_newssvr12.news.prodigy.com>


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

The barcode example was just for instance. Management could have also required an additional QA inspection.

I disagree. If the table were flattened and then normalized, then the processes would live in their own table and one update per process would be all that is required, instead of one update per order.

> 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.
>

Interesting. So in other words nesting is safe when the relationship between the respective entities is one of composition rather than aggregation. What about generalization?

>> 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.
>

Actually, Order is the candidate key for the whole NFNF relation.

The irreducible functional dependencies are:

Order --> Product
{Order, Step} --> Operation
{Order, Step, Part} --> Quantity

Order --> Process (This is lost when the relation is flattened.)

But there's also a dependency between Product and Process. It's not a functional dependency. It's more like a multivalued dependency but not exactly, because it doesn't appear to be circular:

Product ->-> Process | ????

There's also a similar dependency between {Order, Step} and Materials.

After reviewing everything, you're right, the relation can be flattened without losing information. I was focusing on the Product : Process dependency and lost sight of the fact that Order provides the grouping in the flattened relation.

> -- Jan Hidders
>
Received on Thu Mar 30 2006 - 15:49:06 CEST

Original text of this message