On Formal IS-A definition

#1

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?

#2

On 29 avr, 21:38, Tegiri Nenashi <tegirinena... (AT) gmail (DOT) com> wrote:

Quote:

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?
1 - I like the elegance of your notation and its underlying idea of

operating relations as part of inequalities.
2 - The condition is not only unnecessary it also false because
sharing the same header as the supertype Name defeats the purpose to
define a subtype in the first place. Hence, a distinguishable header
for each subtype makes a the concept of *key formation* or *key
inheritance* an absurd concept.

As a side note, there is a need to be cautious about terminology,
Based on your example, Carnivores is not a subtype of Animals: only un-
ary Name attribute (as part of Carnivore is) is.

#3

Tegiri Nenashi wrote:

[...]

Quote:

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?

No. I've never seen this. The naming of Carnivores2
is strange: it should name what each tuple stands for,
but a carnivore isn't always represented by a single tuple.

Suppose we have

Herbivores = [Name Foodtype]
deer grass
rabbit grass
rabbit carrots

and

Vegetables = [Foodtype]
grass
carrots

Would you say that Herbivores IS-A Animals?
What about Herbivores IS-A Foodtype? If not, why not?

--
Reinier

#4

On Apr 29, 2:31*pm, r... (AT) raampje (DOT) lan (Reinier Post) wrote:

Quote:

Tegiri Nenashi wrote:

[...]

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?

No. *I've never seen this. *The naming of Carnivores2
is strange: it should name what each tuple stands for,
but a carnivore isn't always represented by a single tuple.

Just to remove any confusion about Carnivores2 name origin:
1. It is plural because of convention to name relations as sets of
things
2. The number two is version number designed to distinguish this
relation from Carnivores1

Perhaps you are not comfortable with the idea than more than one tuple
of Carnivores2 might represent each "entity"? At this moment I can't
suggest a convincing argument other than vague intuition that database
theory should deviate from explicit mentioning tuples (and attributes,
for that matter, either). All information should be presented in terms
of constraints, expressed in relational algebra terms.

Quote:

Suppose we have

*Herbivores = [Name Foodtype]
* * * * * * * deer *grass
* * * * * * * rabbit grass
* * * * * * * rabbit carrots

and

*Vegetables = [Foodtype]
* * * * * * * grass
* * * * * * * carrots

Would you say that Herbivores IS-A Animals?
What about Herbivores IS-A Foodtype? *If not, why not?

Wouldn't

Vegetables = [Name]
grass
carrots

be a more appropriate choice? Then, we can combine Animals and
Vegetables into LivingThings. Attribute naming seems to be a tricky
subject in Relational Model...

#5

Tegiri Nenashi wrote:

Quote:

On Apr 29, 2:31*pm, r... (AT) raampje (DOT) lan (Reinier Post) wrote:
Tegiri Nenashi wrote:

[...]

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?

No. *I've never seen this. *The naming of Carnivores2
is strange: it should name what each tuple stands for,
but a carnivore isn't always represented by a single tuple.

Just to remove any confusion about Carnivores2 name origin:
1. It is plural because of convention to name relations as sets of
things
2. The number two is version number designed to distinguish this
relation from Carnivores1

I didn't comment on those points.

Quote:

Perhaps you are not comfortable with the idea than more than one tuple
of Carnivores2 might represent each "entity"?

That's what I wrote, didn't I? It's strange. It's very unusual.
It doesn't fit in with ER modelling, for instance.

Quote:

At this moment I can't
suggest a convincing argument other than vague intuition that database
theory should deviate from explicit mentioning tuples (and attributes,
for that matter, either). All information should be presented in terms
of constraints, expressed in relational algebra terms.

Thus far I can agree with you: naming isn't really part of
the modelling mathematically, and using strange names doesn't
make a model any more correct or incorrect in mathematical terms.

But this isn't my main argument against your interpretation
of IS-A. THe main argument is the following.

Quote:

Suppose we have

*Herbivores = [Name Foodtype]
* * * * * * * deer *grass
* * * * * * * rabbit grass
* * * * * * * rabbit carrots

and

*Vegetables = [Foodtype]
* * * * * * * grass
* * * * * * * carrots

Would you say that Herbivores IS-A Animals?
What about Herbivores IS-A Foodtype? *If not, why not?

Wouldn't

Vegetables = [Name]
grass
carrots

be a more appropriate choice? Then, we can combine Animals and
Vegetables into LivingThings. Attribute naming seems to be a tricky
subject in Relational Model...

I was trying to sidestep the issue of attribute (re)naming here,
because it is beside the main point of the example, which is that
according to your definition, the same relation (Herbivores)
has two different IS-A relations, one with Animals and
one with Vegetables. I know multiple inheritance in
programming languages tends to be used in just this kind
of way (with "mixin classes" for instance) but I think with
such a notion the name "IS-A" is just wrong. It's fine to have
your proposed notion but give it a different name: call it a role
or something. A Herbivore just isn't a Vegetable.

I know this is again an argument about naming, but this time
it's about the name "is a" itself.

--
Reinier

#6

Reinier Post wrote:

Quote:

Tegiri Nenashi wrote:

On Apr 29, 2:31 pm, r... (AT) raampje (DOT) lan (Reinier Post) wrote:

Tegiri Nenashi wrote:

[...]

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?

No. I've never seen this. The naming of Carnivores2
is strange: it should name what each tuple stands for,
but a carnivore isn't always represented by a single tuple.

Just to remove any confusion about Carnivores2 name origin:
1. It is plural because of convention to name relations as sets of
things
2. The number two is version number designed to distinguish this
relation from Carnivores1

I didn't comment on those points.

Perhaps you are not comfortable with the idea than more than one tuple
of Carnivores2 might represent each "entity"?

That's what I wrote, didn't I? It's strange. It's very unusual.
It doesn't fit in with ER modelling, for instance.

At this moment I can't
suggest a convincing argument other than vague intuition that database
theory should deviate from explicit mentioning tuples (and attributes,
for that matter, either). All information should be presented in terms
of constraints, expressed in relational algebra terms.

Thus far I can agree with you: naming isn't really part of
the modelling mathematically, and using strange names doesn't
make a model any more correct or incorrect in mathematical terms.

But this isn't my main argument against your interpretation
of IS-A. THe main argument is the following.

Suppose we have

Herbivores = [Name Foodtype]
deer grass
rabbit grass
rabbit carrots

and

Vegetables = [Foodtype]
grass
carrots

Would you say that Herbivores IS-A Animals?
What about Herbivores IS-A Foodtype? If not, why not?

Wouldn't

Vegetables = [Name]
grass
carrots

be a more appropriate choice? Then, we can combine Animals and
Vegetables into LivingThings. Attribute naming seems to be a tricky
subject in Relational Model...

I was trying to sidestep the issue of attribute (re)naming here,
because it is beside the main point of the example, which is that
according to your definition, the same relation (Herbivores)
has two different IS-A relations, one with Animals and
one with Vegetables. I know multiple inheritance in
programming languages tends to be used in just this kind
of way (with "mixin classes" for instance) but I think with
such a notion the name "IS-A" is just wrong. It's fine to have
your proposed notion but give it a different name: call it a role
or something. A Herbivore just isn't a Vegetable.

I know this is again an argument about naming, but this time
it's about the name "is a" itself.

I thought Clinton settled this whole issue already. Cigar anyone?

#7

Bob Badour wrote:

Quote:

Reinier Post wrote:
....
I was trying to sidestep the issue of attribute (re)naming here,
because it is beside the main point of the example, which is that
according to your definition, the same relation (Herbivores)
has two different IS-A relations, one with Animals and
one with Vegetables. I know multiple inheritance in
programming languages tends to be used in just this kind
of way (with "mixin classes" for instance) but I think with
such a notion the name "IS-A" is just wrong. It's fine to have
your proposed notion but give it a different name: call it a role
or something. A Herbivore just isn't a Vegetable.

I know this is again an argument about naming, but this time
it's about the name "is a" itself.

I thought Clinton settled this whole issue already. Cigar anyone?

I think Clinton knew his silly language parsing didn't matter to the
majority of his (semi-literate) public. What puzzles me is why smart
people here spend time on such subjective fooferah and never bring up,
say, just what the Information Principle really means.

#8

On May 3, 11:49*pm, r... (AT) raampje (DOT) lan (Reinier Post) wrote:

Quote:

Tegiri Nenashi wrote:
Perhaps you are not comfortable with the idea than more than one tuple
of Carnivores2 might represent each "entity"?

That's what I wrote, didn't I? *It's strange. *It's very unusual.
It doesn't fit in with ER modelling, for instance.

Perhaps we should name the relvar CarnivoreEatsAnimal? It would
correspond to the Eats relationship between Carnivore and Animal
entities in the ER model.

#9

On May 3, 5:04*pm, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:

Quote:

... and never bring up,
say, just what the Information Principle really means.

...."the entire information content of the database is represented in
one and only one way. Namely as explicit values in column positions
(attributes) and rows in relations (tuples)."?

It is obsolete.

Seriously, I think it is aimed at cowboys who try to invent new data
management systems without studying what relational model is about. It
is about attributes and tuples because both relational calculus, and
algebra explicitly refer to relations structured this way. The
situation is similar to arithmetic where pupils learn how to add/
multiply numbers represented in a very specific notation. So the
arithmetic principle would say ..."the entire content of arithmetic is
represented in one and only one way. Namely as explicit sequences of
digits in numbers". Presumably arithmetic principle would prevent some
from reinventing roman numerals:-)

#10

Tegiri Nenashi wrote:

Quote:

On May 3, 5:04 pm, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:

... and never bring up,
say, just what the Information Principle really means.

..."the entire information content of the database is represented in
one and only one way. Namely as explicit values in column positions
(attributes) and rows in relations (tuples)."?

It is obsolete.

Seriously, I think it is aimed at cowboys who try to invent new data
management systems without studying what relational model is about. It
is about attributes and tuples because both relational calculus, and
algebra explicitly refer to relations structured this way. The
situation is similar to arithmetic where pupils learn how to add/
multiply numbers represented in a very specific notation. So the
arithmetic principle would say ..."the entire content of arithmetic is
represented in one and only one way. Namely as explicit sequences of
digits in numbers". Presumably arithmetic principle would prevent some
from reinventing roman numerals:-)

Consider it a restatement of the principle of separation of concerns.