On Formal IS-A definition

#31

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

Quote:

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

news:88f215e4-8651-44cb-8d58-07b8dbea4a08 (AT) 37g2000yqm (DOT) googlegroups.com...
On 6 mei, 14:51, Erwin <e.sm... (AT) myonline (DOT) be> wrote:

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

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

- Tekst uit oorspronkelijk bericht weergeven -

Normalization was invented with the specific purpose of eliminating
redundancies such as that from the example you gave.

If BCNF still allows designs that contain/involve such reduncancies,
then the only possible conclusion is that normalization has failed to
achieve its stated goal. And please don't give me the argument that
normalization was already known not to be able to eliminate all
redundancies. The known situations in which this occurred are way
more "exotic" than what you presented as an example here, and that
remains true even if I cannot give a precise, formal and scientific
definition of what "exotic" means in this phrase.

And if we must acknowledge that BCNF has failed to achieve its stated
goal, then it must be either ditched or improved. In either case,
BCNF as we know it right now can be stopped talking about. Just like
2NF and 4NF can be stopped talking about because they are irrelevant
intermediate steps toward the normal forms that are (usually
considered as being) way more important.

#32

On May 6, 9:10 pm, Bob Badour <bbad... (AT) pei (DOT) sympatico.ca> wrote:

Quote:

If one is interested specifically in subtypes of supertypes, a proper
subset of a type with a proper superset of operations is a proper
subtype of that type. Thus, circle values are a subtype of ellipse
values and ellipse variables are a subtype of circle variables.

There is no subtype relationship between ellipse variables and circle
variables (in either direction).

Consider a procedure in an imperative language that is passed a
reference to a circle variable. Most generally the variable can be
used as an "in-out" parameter, meaning that the variable is both read
and written by the procedure. An ellipse variable can only be
substituted for out-parameters.

#33

Nilone wrote:

Quote:

On May 3, 11:49*pm, r... (AT) raampje (DOT) lan (Reinier Post) wrote:
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.

Exactly: it's a relationship, not an entity,
while IS-A is supposed to relate two entities.

--
Reinier

#34

On 7 mei, 01:13, David BL <davi... (AT) iinet (DOT) net.au> wrote:

Quote:

On May 6, 9:10 pm, Bob Badour <bbad... (AT) pei (DOT) sympatico.ca> wrote:

There is no subtype relationship between ellipse variables and circle
variables (in either direction).

Look for a (very old) post by Jan Hidders on this subject.

Strange as it may seem, it explains very well what is actually meant
by this weard claim that a variable can be considered as being a
subtype of another variable.

Even I understood it, at the time I was reading that particular post.

#35

On 7 mei, 01:18, Erwin <e.sm... (AT) myonline (DOT) be> wrote:

Quote:

weard

"weird", of course.

#36

Reinier Post wrote:

Quote:

paul c wrote:

Bob Badour wrote:

Reinier Post wrote:

[something about a definition of is-a]

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

http://www.youtube.com/watch?v=j4XT-l-_3y0

and

http://en.wikipedia.org/wiki/Monica_Lewinsky#Scandal

#37

David BL wrote:

Quote:

On May 6, 9:10 pm, Bob Badour <bbad... (AT) pei (DOT) sympatico.ca> wrote:

If one is interested specifically in subtypes of supertypes, a proper
subset of a type with a proper superset of operations is a proper
subtype of that type. Thus, circle values are a subtype of ellipse
values and ellipse variables are a subtype of circle variables.

There is no subtype relationship between ellipse variables and circle
variables (in either direction).

Consider a procedure in an imperative language that is passed a
reference to a circle variable. Most generally the variable can be
used as an "in-out" parameter, meaning that the variable is both read
and written by the procedure. An ellipse variable can only be
substituted for out-parameters.

Ellipse variables are a proper subset of the variables where one might
store a circle. It has a proper superset of the operations permitted for
circle variables allowing one to also store a non-circular ellipse values.

Saying that one cannot apply circle value operations to ellipse
variables demonstrates nothing more than a confusion between values and
variables. One can apply all circle variable operations to ellipse
variables.

#38

Bob Badour wrote:

Quote:

David BL wrote:

On May 6, 9:10 pm, Bob Badour <bbad... (AT) pei (DOT) sympatico.ca> wrote:

If one is interested specifically in subtypes of supertypes, a proper
subset of a type with a proper superset of operations is a proper
subtype of that type. Thus, circle values are a subtype of ellipse
values and ellipse variables are a subtype of circle variables.

There is no subtype relationship between ellipse variables and circle
variables (in either direction).

Consider a procedure in an imperative language that is passed a
reference to a circle variable. Most generally the variable can be
used as an "in-out" parameter, meaning that the variable is both read
and written by the procedure. An ellipse variable can only be
substituted for out-parameters.

Ellipse variables are a proper subset of the variables where one might
store a circle. It has a proper superset of the operations permitted for
circle variables allowing one to also store a non-circular ellipse values.

Saying that one cannot apply circle value operations to ellipse
variables demonstrates nothing more than a confusion between values and
variables. One can apply all circle variable operations to ellipse
variables.

P.S. Sorry about the confusing cardinality switches. I've been burning
the candle at both ends and I am over-tired.

#39

On May 7, 7:18 am, Erwin <e.sm... (AT) myonline (DOT) be> wrote:

Quote:

On 7 mei, 01:13, David BL <davi... (AT) iinet (DOT) net.au> wrote:

On May 6, 9:10 pm, Bob Badour <bbad... (AT) pei (DOT) sympatico.ca> wrote:

There is no subtype relationship between ellipse variables and circle
variables (in either direction).

Look for a (very old) post by Jan Hidders on this subject.

Strange as it may seem, it explains very well what is actually meant
by this weard claim that a variable can be considered as being a
subtype of another variable.

Even I understood it, at the time I was reading that particular post.

Ok, found it back in 2001. It depends on what is meant by
"substitution". I agree that in a correct program already written one
may replace any circle variable with an ellipse variable and nothing
really changes. Of course the ellipse variable only ends up holding
circle values in the context of that program.

For practical reasons I consider substitutability to have more to do
with what type coercions are allowed during function.procedure calls
in imperative programs.

However, more to the point, there is a sense in which the premise
behind subtype = subset is violated. Even though I think it's odd, if
we choose to treat variables as values (by considering a variable to
be an address value within some address space), and we have two
functions to read/write variables (aka dereferencing pointer or
address values)

read(address)
write(address, value)

Then although we can consider the ellipse variables to have a superset
of the functionality, it is not true that that they represent a
subset in the address space. A procedure that expects to be passed
circle address values may balk when given ellipse addresses instead.

So in the rule:

subtype = subset of values + superset of the operators

there is a sense in which only the second half is satisfied when
considering the question of whether an ellipse variable is a subtype
of a circle variable.

#40

David BL wrote:

Quote:

On May 7, 7:18 am, Erwin <e.sm... (AT) myonline (DOT) be> wrote:

On 7 mei, 01:13, David BL <davi... (AT) iinet (DOT) net.au> wrote:

On May 6, 9:10 pm, Bob Badour <bbad... (AT) pei (DOT) sympatico.ca> wrote:

There is no subtype relationship between ellipse variables and circle
variables (in either direction).

Look for a (very old) post by Jan Hidders on this subject.

Strange as it may seem, it explains very well what is actually meant
by this weard claim that a variable can be considered as being a
subtype of another variable.

Even I understood it, at the time I was reading that particular post.

Ok, found it back in 2001. It depends on what is meant by
"substitution". I agree that in a correct program already written one
may replace any circle variable with an ellipse variable and nothing
really changes. Of course the ellipse variable only ends up holding
circle values in the context of that program.

For practical reasons I consider substitutability to have more to do
with what type coercions are allowed during function.procedure calls
in imperative programs.

You mention imperative programs. Imperative programs are precisely those
for which the only operations on variables are assignment and reference.
The operations on the referenced values are operations on values not
operations on variables.

Coercion has nothing to do with it.

Quote:

However, more to the point, there is a sense in which the premise
behind subtype = subset is violated. Even though I think it's odd, if
we choose to treat variables as values (by considering a variable to
be an address value within some address space), and we have two
functions to read/write variables (aka dereferencing pointer or
address values)

read(address)
write(address, value)

Then although we can consider the ellipse variables to have a superset
of the functionality, it is not true that that they represent a
subset in the address space. A procedure that expects to be passed
circle address values may balk when given ellipse addresses instead.

Exactly! Ellipse variables are a proper subset of circle variables.