Re: On Formal IS-A definition

From: Mr. Scott <do_not_reply_at_noone.com>
Date: Thu, 6 May 2010 15:35:27 -0400
Message-ID: <_NCdnXxA0Pqch37WnZ2dnUVZ_gydnZ2d_at_giganews.com>


"Erwin" <e.smout_at_myonline.be> wrote in message news:68da88f6-6ca1-4f46-8333-fe84bfc91ce7_at_o11g2000yqj.googlegroups.com... 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 -

<<QUOTE

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.

>>QUOTE
I suggest that you revisit the definition of BCNF. A relation is in BCNF iff the determinant of every nontrivial functional dependency is a superkey. A database is in BCNF iff all of its base relations are in BCNF. . Received on Thu May 06 2010 - 21:35:27 CEST

Original text of this message