# Re: On Formal IS-A definition

From: Tegiri Nenashi <tegirinenashi_at_gmail.com>

Date: Thu, 6 May 2010 13:14:31 -0700 (PDT)

Message-ID: <90e167d3-4ae4-451c-9f3d-1e2c3e19c9f2_at_n15g2000yqf.googlegroups.com>

On May 5, 11:00 pm, "Mr. Scott" <do_not_re..._at_noone.com> wrote:

Date: Thu, 6 May 2010 13:14:31 -0700 (PDT)

Message-ID: <90e167d3-4ae4-451c-9f3d-1e2c3e19c9f2_at_n15g2000yqf.googlegroups.com>

On May 5, 11:00 pm, "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.*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 - 15:14:31 CDT