On Formal IS-A definition

#21

On 6 mei, 09:00, "Mr. Scott" <do_not_re... (AT) noone (DOT) com> wrote:

Quote:

"Tegiri Nenashi" <tegirinena... (AT) gmail (DOT) com> wrote in message

news:0b2f71d0-34b5-4661-a8f6-21a40cdb9989 (AT) n37g2000prc (DOT) 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.- Tekstuit oorspronkelijk bericht niet weergeven -

- Tekst uit oorspronkelijk bericht weergeven -

The first is a violation of BCNF.

Well. I suspect you knew that too, and were just trying to make a
point wrt the original question. Which, I must admit, I don't
understand very well where it is headed, or why it was asked in the
first place.

"Has-a" and "Is-a" are relationship types. As such, they occur in
contexts of informal modeling such as ER and UML class diagram
drawing. Inclusion constraints occur only in contexts of _FORMAL_
modeling where one is _effectively specifying ALL the details of some
database definition_. As opposed to the context of informal modeling,
where it is the _deliberate intention_ to make abstraction of some of
the details.

#22

<<QUOTE
"Erwin" <e.smout (AT) myonline (DOT) be> wrote

On 6 mei, 09:00, "Mr. Scott" <do_not_re... (AT) noone (DOT) com> wrote:

Quote:

"Tegiri Nenashi" <tegirinena... (AT) gmail (DOT) com> wrote in message

news:0b2f71d0-34b5-4661-a8f6-21a40cdb9989 (AT) n37g2000prc (DOT) 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:

QUOTE

No, it's not. Both schemes are in BCNF.

<snip>

#23

On 6 mei, 14:14, "Mr. Scott" <do_not_re... (AT) noone (DOT) com> wrote:

Quote:

QUOTE"Erwin" <e.sm... (AT) myonline (DOT) be> wrote in message

news:9fc21a72-6865-4a73-9183-a897275b6fdf (AT) 37g2000yqm (DOT) googlegroups.com...
On 6 mei, 09:00, "Mr. Scott" <do_not_re... (AT) noone (DOT) com> wrote:

"Tegiri Nenashi" <tegirinena... (AT) gmail (DOT) com> wrote in message

news:0b2f71d0-34b5-4661-a8f6-21a40cdb9989 (AT) n37g2000prc (DOT) 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 -

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-

Quote:

{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.

#24

On 6 mei, 14:51, Erwin <e.sm... (AT) myonline (DOT) be> wrote:

Quote:

On 6 mei, 14:14, "Mr. Scott" <do_not_re... (AT) noone (DOT) com> wrote:

QUOTE"Erwin" <e.sm... (AT) myonline (DOT) be> wrote in message

news:9fc21a72-6865-4a73-9183-a897275b6fdf (AT) 37g2000yqm (DOT) googlegroups.com...
On 6 mei, 09:00, "Mr. Scott" <do_not_re... (AT) noone (DOT) com> wrote:

"Tegiri Nenashi" <tegirinena... (AT) gmail (DOT) com> wrote in message

news:0b2f71d0-34b5-4661-a8f6-21a40cdb9989 (AT) n37g2000prc (DOT) 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 -

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.- Tekst uit oorspronkelijk bericht niet weergeven -

- Tekst uit oorspronkelijk bericht weergeven -

Or let me put it differently.

If it is indeed true that the given example satisfies BCNF, then I
must conclude that normalization as the-formal-method-as-we-know-it,
fails to detect and eliminate this kind of redundancy.

And if normalization as a formal method fails to detect and eliminate
this kind of redundancy, then it is pretty darn useless and we can
just as well stop teaching it.

#25

"Erwin" <e.smout (AT) myonline (DOT) be> wrote

On 6 mei, 14:14, "Mr. Scott" <do_not_re... (AT) noone (DOT) com> wrote:

Quote:

QUOTE"Erwin" <e.sm... (AT) myonline (DOT) be> wrote in message

news:9fc21a72-6865-4a73-9183-a897275b6fdf (AT) 37g2000yqm (DOT) googlegroups.com...
On 6 mei, 09:00, "Mr. Scott" <do_not_re... (AT) noone (DOT) com> wrote:

"Tegiri Nenashi" <tegirinena... (AT) gmail (DOT) com> wrote in message

news:0b2f71d0-34b5-4661-a8f6-21a40cdb9989 (AT) n37g2000prc (DOT) 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-

Quote:

{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:

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. .

#26

"Erwin" <e.smout (AT) myonline (DOT) be> wrote

On 6 mei, 14:51, Erwin <e.sm... (AT) myonline (DOT) be> wrote:

Quote:

On 6 mei, 14:14, "Mr. Scott" <do_not_re... (AT) noone (DOT) com> wrote:

QUOTE"Erwin" <e.sm... (AT) myonline (DOT) be> wrote in message

news:9fc21a72-6865-4a73-9183-a897275b6fdf (AT) 37g2000yqm (DOT) googlegroups.com...
On 6 mei, 09:00, "Mr. Scott" <do_not_re... (AT) noone (DOT) com> wrote:

"Tegiri Nenashi" <tegirinena... (AT) gmail (DOT) com> wrote in message

news:0b2f71d0-34b5-4661-a8f6-21a40cdb9989 (AT) n37g2000prc (DOT) 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 -

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.- Tekst uit oorspronkelijk bericht niet
weergeven -

- Tekst uit oorspronkelijk bericht weergeven -

<<QUOTE
Or let me put it differently.

If it is indeed true that the given example satisfies BCNF, then I
must conclude that normalization as the-formal-method-as-we-know-it,
fails to detect and eliminate this kind of redundancy.

And if normalization as a formal method fails to detect and eliminate
this kind of redundancy, then it is pretty darn useless and we can
just as well stop teaching it.

Quote:

QUOTE

Well that argument is just plain stupid. Should you stop wearing your
seatbelt just because some collisions are so severe that people are
seriously injured or die even though they are wearing one?

#27

On May 6, 1:39*am, Erwin <e.sm... (AT) myonline (DOT) be> wrote:

Quote:

On 5 mei, 22:56, Tegiri Nenashi <tegirinena... (AT) gmail (DOT) com> wrote:

On May 5, 12:41*pm, Erwin <e.sm... (AT) myonline (DOT) be> wrote:

... Not in the same sense that relation algebra prevents
graph databases because relation algebra does not understand graphs.

This is very imprecise statement. I'll embark upon your typo and
suggest that relation algebra (http://en.wikipedia.org/wiki/
Relation_algebra) does exactly that. It manipulates binary relations
that are essentially adjacency matrices representing direct acyclic
graphs.

Yes. *And I know about transitive closure and the concept of
generalized transitive closure too, thank you.

I was referring to deMorgan/Peirce/Tarski relation algebra, which has
nothing to do with relational algebra. Kleene star is a natural
operation for the former, while its reincarnation in relational model
in the form of Transitive Closure looks like an afterthought. It is
not even total.

Quote:

... the IP is the single one principle that "proves" (note
the quotes) (a) that the relational model can be used to represent
_ANY_ information, iow that the relational model has a certain quality
of "completeness", and (b) that it allows a simpler form of
manipulation than would be possible in any model that is based on some
type of "graph algebra".

I was implying that relation algebras are perfect abstractions for
modeling graphs. Relational model? Hardly.

Quote:

Another small point is that there is a school of thought which says
something about a connection between relation algebra and first order

Here this terminology slip again: do you mean relation algebra or
relational algebra? Relation algebra can express any (and up to
logical equivalence, exactly the) first-order logic (FOL) formulas
containing no more than three variables. This may be the reason why it
never enjoyed wide adoption, and eventually lost to more successful
Frege's predicate calculus.

Quote:

logic, thereby excluding transitive closure as a possible operator of
RA because transitive closure requires recursion and recursion is
excluded by FOL. *I don't really understand their point, or why they
are trying to make that point, because imo (generalized) transitive
closure is a sine qua non for "expressive completeness". *Without
transitive closure, certain queries are provably unanswerable, and so
TC is needed. *I find that statement about the link with FOL rather
vacuous for that reason.

Again, my impression is that transitive closure doesn't fit into
relational model. Kleene star, on the other hand, is natural
operation, because it is converse's "long lost fraternal
twin" (Vaughan Pratt).

As far as Information principle is concerned, here is my attitude:
"Relational algebras should be defined with purely equational
postulates". Removing the suffix "al" in the first word, this is
literally the same how Tarski put it.

#28

On May 5, 11:00*pm, "Mr. Scott" <do_not_re... (AT) noone (DOT) com> wrote:

Quote:

"Tegiri Nenashi" <tegirinena... (AT) gmail (DOT) com> wrote in message

news:0b2f71d0-34b5-4661-a8f6-21a40cdb9989 (AT) n37g2000prc (DOT) 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.

#29

paul c wrote:

Quote:

Bob Badour wrote:
Reinier Post wrote:

[something about a definition of is-a]

Quote:

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.

I was taught about relational database theory without any
mention of 'Clinton' or 'information principle'. Shit happens.
I don't smoke, either. My definition is of "is-a" is crystal
clear, unlike the information principle, but I do think I invoked
just that principle as an argument to justify the definition.

A reference to 'Clinton' would be most appreciated.
(Google isn't particularly helpful, as expected.)

--
Reinier

#30

On 6 mei, 22:02, Tegiri Nenashi <tegirinena... (AT) gmail (DOT) com> wrote:

Quote:

On May 6, 1:39*am, Erwin <e.sm... (AT) myonline (DOT) be> wrote:

On 5 mei, 22:56, Tegiri Nenashi <tegirinena... (AT) gmail (DOT) com> wrote:

On May 5, 12:41*pm, Erwin <e.sm... (AT) myonline (DOT) be> wrote:

I was referring to deMorgan/Peirce/Tarski relation algebra, which has
nothing to do with relational algebra. Kleene star is a natural
operation for the former, while its reincarnation in relational model
in the form of Transitive Closure looks like an afterthought. It is
not even total.

OK. Now I see what you meant by "that typo of mine". It wasn't a
typo. I deliberately used the term "relation algebra" to denote any
algebra that operates on relations. I did try to follow the link you
gave, but it produced an http 404, or some such.

I know an algebra is nothing more than just a set of operators, so I
understand that anyone can define any algebra he(/she) likes (I also
understand why it takes an extremely bright mind to define one that
turns out to be useful), I am even aware of the consequences to the
extent that I have written myself in several places that "there is no
such thing as _the_ relational algebra", but I do not know how many
relation(al) algebras have been defined, let alone that I would know
the details of all of them.

Quote:

I was implying that relation algebras are perfect abstractions for
modeling graphs. Relational model? Hardly.

Are you suggesting that even with generalized transitive closure being
included in the RM, there are still certain graph things that are
impossible to do with the RM ?

Quote:

Again, my impression is that transitive closure doesn't fit into
relational model.

I have seen the comment that "TC was added to the RA in an ad-hoc
fashion after the unanswerability of some queries with Codd's algebra
was proved.". I think I also understand how the formulation/
definition of the generalized version of TC was much the same kind of
response when it was proved that even with "regular" TC, queries such
as "how many distinct paths exist between a and b" were still
unanswerable. But does that warrant the conclusion that "(G)TC
doesn't fit" ? I'm hesitant to answer that with a "yes".

Quote:

As far as Information principle is concerned, here is my attitude:
"Relational algebras should be defined with purely equational
postulates". Removing the suffix "al" in the first word, this is
literally the same how Tarski put it.

Sorry. My skills and knowledge are lacking to discuss such matters.
Which I regret.