Re: On Formal IS-A definition

"Erwin" <e.smout_at_myonline.be> wrote in message news:06a06592-5752-42c4-b6b9-23ebaa42b23a_at_i10g2000yqh.googlegroups.com... On 6 mei, 22:02, "Mr. Scott" <do_not_re..._at_noone.com> wrote:
> "Erwin" <e.sm..._at_myonline.be> wrote in message
>
> news:88f215e4-8651-44cb-8d58-07b8dbea4a08_at_37g2000yqm.googlegroups.com...
> On 6 mei, 14:51, Erwin <e.sm..._at_myonline.be> wrote:
>
>
>
>
>
> > On 6 mei, 14:14, "Mr. Scott" <do_not_re..._at_noone.com> wrote:
>
> > > <<QUOTE"Erwin" <e.sm..._at_myonline.be> wrote in message
>
> > >news:9fc21a72-6865-4a73-9183-a897275b6fdf_at_37g2000yqm.googlegroups.com...
> > > On 6 mei, 09:00, "Mr. Scott" <do_not_re..._at_noone.com> wrote:
>
> > > > "Tegiri Nenashi" <tegirinena..._at_gmail.com> wrote in message
>
> > > >news:0b2f71d0-34b5-4661-a8f6-21a40cdb9989_at_n37g2000prc.googlegroups.com...
>
> > > > > Given the two relations R and S, the R is a subtype of S or simply
> > > > > "R
> > > > > is an S" (was this the source of Reinier blunder?-) iff the two
> > > > > conditions hold:
>
> > > > > 1. R ^ S = R (where the ^ is natural join operation). This can be
> > > > > expressed succinctly as R < S with generalized subset constraint
> > > > > "<".
>
> > > > > The immediate consequence is that the attributes of S are the
> > > > > subset
> > > > > of attributes R (formally: R ^ [] < S ^ [] where the "[]" is the
> > > > > relation with empty set of attributes and empty set of tuples, aka
> > > > > DUM). Then, one may add second requirement that
>
> > > > > 2. Attributes of S form a key in relation R.
>
> > > > > My question is if the condition #2 is really necessary. Consider
> > > > > the
> > > > > two relations:
>
> > > > > Animals = [Name]
> > > > > bear
> > > > > sheep
> > > > > wolf
> > > > > ;
>
> > > > > Carnivores1 = [Name FavoritePrey]
> > > > > bear deer
> > > > > wolf sheep
> > > > > ;
>
> > > > > They satisfy both conditions so that informally we say
> > > > > "Carnivores1"
> > > > > IS-A "Animals".
>
> > > > > Contrast this with
>
> > > > > Animals = [Name]
> > > > > bear
> > > > > sheep
> > > > > wolf
> > > > > ;
>
> > > > > Carnivores2 = [Name Prey]
> > > > > bear deer
> > > > > wolf sheep
> > > > > wolf deer
> > > > > ;
>
> > > > > I suggest that we still have "Carnivores2" IS-A "Animals". Do you
> > > > > agree?
>
> > > > There is a problem here. Which scheme is better?
>
> > > > Employees{taxid,name,startdate} KEY{taxid},
> > > > ContractEmployees{taxid,name,startdate,enddate} KEY{taxid},
> > > > ContractEmployees[taxid,name,startdate] is a subset of
> > > > Employees[taxid,name,startdate]
>
> > > > or
>
> > > > Employees{taxid,name,startdate} KEY{taxid},
> > > > ContractEmployees{taxid,enddate} KEY{taxid},
> > > > ContractEmployees[taxid] is a subset of Employees[taxid]
>
> > > > Clearly the second scheme is equivalent to the first with respect to
> > > > information content, so if a ContractEmployee is an Employee in the
> > > > first
> > > > scheme, then it must also be in the second, but in the second
> > > > scheme,
> > > > the
> > > > set of attributes for Employees is not a subset of the set of
> > > > attributes
> > > > for
> > > > ContractEmployees. I think the effect of the foreign key constraint,
> > > > namely, that the components of the referenced tuple are effectively
> > > > 'included' with the referencing tuple, must be taken into account.-
> > > > Tekst
> > > > uit oorspronkelijk bericht niet weergeven -
>
> > > > - Tekst uit oorspronkelijk bericht weergeven -
>
> > > The first is a violation of BCNF.
>
> > > >>QUOTE
>
> > > No, it's not. Both schemes are in BCNF.
>
> > > <snip>- Tekst uit oorspronkelijk bericht niet weergeven -
>
> > > - Tekst uit oorspronkelijk bericht weergeven -
>
> > OK. Your example was this :
>
> > Employees{taxid,name,startdate} KEY{taxid},
> > ContractEmployees{taxid,name,startdate,enddate} KEY{taxid},
> > ContractEmployees[taxid,name,startdate] is a subset of
> > Employees[taxid,name,startdate]
>
> > This tells me that within the Employees relvar, the FD
> > taxid->{name,startdate} holds.
>
> > And within ContractEmployees, the FD taxid->{name,startdate,enddate}
> > holds.
> > And the subset constraint tells me that the name and startdate
> > associated with any given ContractEmployees.taxid must be equal to the
> > name and startdate associated with the corresponding Employees.taxid.
>
> > Meaning that those two attributes are redundant in ContractEmployees.
>
> > Not a violation of BCNF ? My foot.- Tekst uit oorspronkelijk bericht
> > niet
> > weergeven -
>
> > - Tekst uit oorspronkelijk bericht weergeven -
>
> <<QUOTE
> Or let me put it differently.
>
> If it is indeed true that the given example satisfies BCNF, then I
> must conclude that normalization as the-formal-method-as-we-know-it,
> fails to detect and eliminate this kind of redundancy.
>
> And if normalization as a formal method fails to detect and eliminate
> this kind of redundancy, then it is pretty darn useless and we can
> just as well stop teaching it.
>
> >>QUOTE
>
> Well that argument is just plain stupid. Should you stop wearing your
> seatbelt just because some collisions are so severe that people are
> seriously injured or die even though they are wearing one?- Tekst uit
> oorspronkelijk bericht niet weergeven -
>
> - Tekst uit oorspronkelijk bericht weergeven -

<<QUOTE

Normalization was invented with the specific purpose of eliminating redundancies such as that from the example you gave.

If BCNF still allows designs that contain/involve such reduncancies, then the only possible conclusion is that normalization has failed to achieve its stated goal. And please don't give me the argument that normalization was already known not to be able to eliminate all redundancies. The known situations in which this occurred are way more "exotic" than what you presented as an example here, and that remains true even if I cannot give a precise, formal and scientific definition of what "exotic" means in this phrase.

And if we must acknowledge that BCNF has failed to achieve its stated goal, then it must be either ditched or improved. In either case, BCNF as we know it right now can be stopped talking about. Just like 2NF and 4NF can be stopped talking about because they are irrelevant intermediate steps toward the normal forms that are (usually considered as being) way more important.
>>QUOTE
There are normal forms that involve inclusion dependencies as well as functional dependencies. BCNF is not one of them. Received on Fri May 07 2010 - 05:43:42 CEST