Re: More on lists and sets
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.
> 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.
>
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