On Apr 20, 3:03*pm, r... (AT) raampje (DOT) lan (Reinier Post) wrote:
Well, let's approach this question from math perspective. I suggest
the "is a" is some [partial] order between a pair of relations, so it
has to honor 3 laws:

R < R

R < S & S < R -> R = S

R < S & S < T -> R < T

One can prove that the order defined via join satisfies all them. The
first one follows from join idempotence,

R ^ R = R

the second one from join symmetry,

R ^ S = S ^ Y

and the third one from join associativity

given:
1. R ^ S = R
2, S ^ T = S
------------
R ^ T = (R ^ S) ^ T = R ^ (S ^ T) = R ^ S = R

There are two more idempotent symmetric relational algebra operations
(one is D&D <AND>) that give rize to some other order relations.
However, there is the strong reason to suspect that the order defined
by join is the most important one (and, therefore, is candidate to
represent "is a"). This is because the order introduced via
generalized union (or relational algebra projection) coinsides it!

So, you are suggesting that your definition gives rize to yet another
order relation? Can you prove its three defining properties?

On Apr 21, 8:44*am, Vadim Tropashko <vadim... (AT) gmail (DOT) com> wrote:
Some typo corrections.

R ^ S = S ^ R

typo: <AND> is natural join; I meant <OR>

To recoup: there are four idempotent symmtric relational algebra
operations:
natural join, generalized (or inner) union, outer union (aka D&D
<OR>), and inner join, giving rise to four orders, only three of which
are distinct. (The fact that inner join being non-associative still
give rize to some order is rather subtle).

Your definition seems to be consistent. In QBQL notation it asserts
that

r < s & r#s < r#s`

the first condition is lattice order that I describe before. The
second part is functional dependency expressed in terms of partitions.
Here are partial order properties expressed and verified as QBQL
assertions:

r < r & r#r < r#r`. -- reflexivity
r < s & r#s < r#s` & s < r & s#r < s#r -> r = s. -- antisymmetry
(r < s & r#s < r#s` & s < t & s#t < s#t`) ->
(r < t & r#t < r#t`). -- transitivity

Vadim Tropashko wrote:

[I've removed some empty lines]

Certainly. But these properties don't uniquely determine the order.
I haven't checked it, but I bet the definition obtained by
adding the second clause satisfies them as well.

[...]

Not strong enough. Without the second clause, you're talking about
aggregation, or in Silberschatz et al.'s terms, a weak entity: an entity
(the "whole") being used to identify another (the "part").
The "is a" relationship is more restricted in that the "whole"-"part"
relationship is one-to-at-most-one.

I gave the three defining properties.
I'm not sure why you're asking for an alternative.

--
Reinier

On Apr 22, 2:26*pm, r... (AT) raampje (DOT) lan (Reinier Post) wrote:
I have meant proving reflexivity, symmetry and transitivity. However
in the followup message I figured that out, so your "is-a" relation is
indeed an order. More importantly, I don't quite follow your
definition. Suppose you have two relations

Circles = [centerX centerY radius]
0 0 10
10 0 20
;

Ellipses = [centerX centerY axisX axisY]
0 0 10 10
10 0 20 20
0 10 10 50
;

these don't match your definition. Or perhaps you want to correct the
"radius" attribute name to match say "axisX", then I still fail to see
how it would match your definition.

Tegiri Nenashi wrote:
True.

It wouldn't. Remove radius from Circles or add it
to Elliupses, and these two particular instances will match,
but in general it still won't be a case of "is-a" because
in general, the same Circle may correspond to
different Ellipses, which my second clause forbids.

I also gave the rationale for restricting "is a" in this way:
it doesn't involve any reasoning about domain values.
(Except reasoning involving equality.)

I didn't invent this notion of "is a", I have it from
a textbook and I believe it is pretty standard.

--
Reinier

Reinier Post wrote:

PS: that is why Ellipse "is a" Circle will not hold.
But Circle "is a" Ellipse will hold if Circle is given
an axisX and axisY that always have the same value.

--
Reinier

On Apr 23, 3:27*pm, r... (AT) raampje (DOT) lan (Reinier Post) wrote:
I still don't follow. First, let's reiterate that we are considering
the case when both relations have different set of attributes: if
attribute set is the same, then subtyping is trivially subset
relation. In a way we are after generalization of subset onto
arbitrary pair of relations.

Again, I have a problem with Circles and Ellipses. First, if one
removes the Radius attribute from a circle, then it becomes a Point!
Second, why would I add redundant attributes to a Circle? If the idea
is to make both relations to have the same set of attributes, then we
go back to the previous paragraph: I'm interested to see a convincing
example of two relations with different sets of attributes that fits
your definition.

Tegiri Nenashi wrote:

[...]

Yes. In my textbook, the subtype must have all attributes of the
supertype, but it can have more. This is fairly standard.

Yes, but you can rename it to axisX, although that isn't a very
logical name unless you know you're going to create an Ellipse
as a ass, and even then it might as well be called axisY.
But this is just a manifestation of a general issue: there is no unique
"true" relational model of circles or eLlipses, or of anything else.

Person: first name, last name, date of birth
Citizen: first name, last name, date of birth, country of citizenship

I've done some student instructions with that textbook and I still
use the same ER modelling technique for myself; I've noticed that
this is-a comes up pretty often, and that it is helpful, i.e. many
modelling errors I see can be explained in terms of "is-a being overlooked"
or "is-a being modeled incorrectly". It is also fairly common in tools.

--
Reinier

On Apr 25, 3:02 pm, r... (AT) raampje (DOT) lan (Reinier Post) wrote:
Does "is-a" come up because it follows naturally from the design
process? Or does it come up the same way that Object Oriented comes
up these days in programming discussions ie being shoe-horned into
the conversation whether needed or not?

How is this is-a concept "helpful" as you claim? For example, I
can't imagine myself every creating a database with the separate
Person and Citizen tables above.

And what happens if we simply banish "is-a" from our thinking and
vocabulary entirely? Are those modelling errors eliminated? What
do we lose by sacrificing this hierarchical notion?

KHD

On Apr 25, 5:57*pm, Keith H Duggar <dug... (AT) alum (DOT) mit.edu> wrote:
Perhaps both Person and Citizen don't have to be physical tables (as
you implied)? They are relations. Let me borrow a better example from
wiki.postgresql.org/images/9/91/Pguswest2008hnd.pdf
, page 12. Ignoring all the modeling nonsense on the preceding and
follow up pages, this example is quite insightful. I would design this
schema as the two physical tables: Carnivores and Herbivores. The
Animals relation is generalized union of Carnivores and Herbivores and
would be better physically represented as a view, while Omnivores is
natural join, which is another view.