Re: More on lists and sets

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

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:
(1) There can be more than one order for producing batches of a particular product.
(2) A step may or may not require materials. (3) There can be more than one procedure for making a particular part--that is, the steps need not be the same for two orders, but can be. (4) There can be raw material substitutions. For example, it doesn't matter whether you use a Samsung op amp or a Toshiba op amp, provided the specifications are the same. Of course, the part number for a Samsung op amp is different from that for a Toshiba op amp.

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.

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. I would also invite suggestions on how to alter this scheme to eliminate the redundancy.

>> >> Issues that are solved through the application of
>> >> higher normal forms reappear with the introduction of composite
>> >> attributes.
>> >
>> > Such as? In fact, the reverse true. It is for example known that in
>> > some cases normalization to BCNF while being dependency preserving is
>> > not possible in the flat model, but is in fact possible in the nested
>> > relational model (given appropriate generalizations of dependencies and
>> > normal forms).
>>
>> If a tuple with a list is deleted, the contents of the list is also
>> deleted,
>> possibly snuffing out the only instance of that list in the database.
>> This
>> may not be a problem in most cases, but wasn't this same scenario one of
>> the
>> arguments for further normalization?
>
> No. It's the same scenario as where you delete a tuple with the last
> occurrence of the date of March 27th 2006. If that is problematic you
> have made a data modelling error.
>
>> The problem caused by the lack of dependency preservation can be overcome
>> in
>> several ways, such as by using surrogates or circular inclusion
>> dependencies.
>
> No. It cannot.
>
> -- Jan Hidders
>
Received on Thu Mar 30 2006 - 02:31:19 CEST