# Re: On Formal IS-A definition

From: Tegiri Nenashi <tegirinenashi_at_gmail.com>
Date: Thu, 6 May 2010 13:14:31 -0700 (PDT)

On May 5, 11:00 pm, "Mr. Scott" <do_not_re..._at_noone.com> wrote:
> "Tegiri Nenashi" <tegirinena..._at_gmail.com> wrote in message
>
>
>
>
> > 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.

I'd suggest different naming in the second case. The relation with attributes {taxid,enddate} is called Terminations, and a Termination IS not-An Employee. ContractEmployees relation is a view, which is a join of Employees with Terminations. Received on Thu May 06 2010 - 22:14:31 CEST

Original text of this message