# Re: On Formal IS-A definition

Date: Thu, 6 May 2010 08:14:05 -0400

Message-ID: <RY6dnTVRULQTL3_WnZ2dnUVZ_hOdnZ2d_at_giganews.com>

<<QUOTE

"Erwin" <e.smout_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> Received on Thu May 06 2010 - 14:14:05 CEST