On May 12, 6:26*pm, Tegiri Nenashi <tegirinena... (AT) gmail (DOT) com> wrote:
This definition of IS-A differs from the one I previously gave in this
thread ("IS-A is an isomorphism between domains of entities"). The
two uses correspond to the 'is' of identity and the 'is' of
predication, resp (see Korzybski). For example:

// 'is' of identity
Flower = [x: Name]
Rose
Violet

// 'is' of predication
FlowerColor = [x : Animal, y : Color]
Rose, Red
Violet, Blue

Aren't those terms still used in UML, e.g.
http://en.wikipedia.org/wiki/Class_d...Relationships?

I messed up 'aggregation' and 'association' there. Let me try again:
a lack of unique constraints imply aggregation, a unique constraint on
x denotes the composition of y from x, and vice-versa for a unique
constraint on y. Unique constraints on both implies a binary
association relation. For example:

// aggregation
StudentClass = [x : Student, y : Class]
John, Math
John, Biology
Mary, Math
Mary, History

// composition, unique constraint on y
SubjectModule = [x : Subject, y : Module]
Math, Geometry 1
Math, Algebra 1
Biology, Evolution 1

// association, unique constraint on (x, y)
DepartmentHead = [x : Department, y : Professor]
Physics, Frank
History, Susan

Will do, as soon as I can. There's just too much to read and too
little time.

On May 13, 10:07*am, Nilone <rea... (AT) gmail (DOT) com> wrote:
Another mess. I apologize.

I don't think 'is' of identity belongs in a relation. Domains and the
elements in them are orthogonal to relations over them.

If a is a finite subset of b, and we assume CWA, then we can enumerate
it in the RM and use referential constraints to enforce it.

Although I'm interested in infinite domains, OWA and subset
expressions, I'm tired of the taste of my own foot.

On May 13, 1:07*am, Nilone <rea... (AT) gmail (DOT) com> wrote:
That one didn't make sense: isomorphism is an equivalence [relation],
and we are after an order. Homomorphism might do.

I don't understand: 'IS-A' is a binary relation, what are the things
you relate to with 'IS-A' in your examples?

Association is easy: it is unconstrained binary relation between two
things. It doesn't have to be reflexive, irreflexive, symmetric,
asymmetric, antisymmetric, transitive, total, trichotomous, or
whatever.

I still struggle to understand what are the things that you are trying
to relate to. Are they relation attributes, attribute sets, or
something else?

On May 13, 5:35*pm, Tegiri Nenashi <tegirinena... (AT) gmail (DOT) com> wrote:
Right, I didn't keep in mind that you said you wanted to define
subsets, and wavered between notions of IS-A. I didn't distinguish
between subset relations and abstraction (e.g. the employees in a
department vs employees as persons), subsets of relations (as implied
by referential constraints), or relations over subsets (e.g. a
marriage relation in a heterosexual society). Also, subset relations
over infinite domains may yield either finite or infinite ranges.

In this example, I forgot the difference between domains and relations
and I tried to express a domain (flowers) as a unary relation. Then I
got confused with the domain of the x attribute of FlowerColor, since
I thought I wanted to use the unary relation as its domain. The
Animal domain you see in there resulted from an incomplete rewrite (my
first example used animals), but when I tried to correct it in my
subsequent post, I couldn't resolve x : Name in Flower with x : Flower
in FlowerColor and then I realised my mistake. The symbols we use for
things don't equate to the things themselves.

I agree.

The form of your question allows me to answer on a different level
than intended, and I choose to do so. I want to relate to abstraction
in all its forms, and understand how to make and use abstractions
correctly.

Nilone wrote:

I am referring to the notions of E/R model and IS-A I've
detailed here before, from the textbook by Silberschatz et al.:

http://www.db-book.com/

This is one way of looking at it, I suppose. It is similar,
but not quite equivalent to the notions Silberschatz et al. use.
They avoid considering tuple-valued domains. Instead, they
define entities (to be precise: entity sets) as relations identified
entirely by their own attributes, and relationships (to be precise:
relationship sets) as relations defined entirely by their foreign
key attributes, which foreign keys are all primary keys of
entities. Definied in this way, entities and relationships
are particular types of relations in relational schemas.
However, this definition only applies to E/R diagrams in which
all attributes and identifications have been fully specified,
not to incomplete ones in which foreign key relationships may
be specified prior to the entity's identifying attributes.

It is not a mistake, but a modeling decision. One may wish to express
that two relations share a common part, prior to or independent of the
exact attributes of that part. For instance, in an E/R model we may
wish to express that both persons and companies have addresses, that
these addresses are the same type of entity, and that addresses are
not atomic domain values, but tuples in a relation, prior to specifying
any further details of addresses. In a Silberschatz et al. E/R model,
this can be expressed by making Address an entity (set) and Person and
Company relationship (set)s. These models are subsequently elaborated
into relational models by detailing the exact attributes of all entities
and relationships concerned. In more general techniques such as ORM
we don't need to categorize all relations as either relationship
(set) or entity (set), but can specify arbirary identification
relations between relations. The identification relations become
foreign keys once all attributes have been specified in full.

Similarly, in an E/R or ORM (or similar) model one may wish to say
that a particular relation has the same primary key as some other
relation, whether or not that primary key has been specified
any further. That is IS-A.

I've been on a short vacation. I'm not sure how to explain these things
effectively. The ideas aren't exactly new, mine, unusual, or rocket
science, but when I bring them up here people tend respond by saying
I'm a "moron" who "can't reason abstractly", etc. so something must be
wrong with what I say about them.

--
Reinier

On May 22, 12:26*am, r... (AT) raampje (DOT) lan (Reinier Post) wrote:
My studies this year include Operating System Concepts by Silberschatz
et al (a different et al, though). They wrote quite comprehensively.

Entities, in general, contain identifying attributes (e.g. SSN) and
non-identifying attributes (e.g. birthdate). It sounds as if they
include both identifying and non-identifying attributes in the same
"relation". If so, I disagree with that approach. As I see it, the
identifying attributes define one relation, and each non-identifying
attribute defines a relation from the identity of the entity to the
identity of another entity (e.g. a date).

I, too, think that entities and relationships define relations, but I
equate an entity with its identity only, and view all other attributes
as observations (more relations) upon the entity, not components of
it.

I don't understand the reason for this qualification.

I can understand that two entities can share a part, but when two
relations share an attribute, that just means they describe the same
domain.

I interpret this as:

Person = [ ... ]

Company = [ ... ]

Address = [ ... ]

PersonAddress = [ x : Person, y : Address ]

CompanyAddress = [ x : Company, y : Address ]

which says very little about how to implement it in SQL.

I suspect "relational models" here means "SQL schemas". I disagree
that the model as described can be called relational, in the
mathematical sense of the word relational.

I'll have to study ORM properly some time.

I often find that I learn much in trying to explain contradicting
thoughts. I appreciate the discussion, whether we agree or not.

This group, like the mathematics it values, tends to distinguish
sharply. However, I keep in mind the relation between observer and
observation, and don't incorporate such observations into myself as an
entity, nor do I make such dispositional observations anymore. They
contradict my point of view and interfere with learning.

Nilone wrote:

[...]

Yes, of course: the primary key of a relation rarely contains
all of its attributes.

(Using 'relation' for what Date would call 'relvar'.)

I think I get it.

You basically factor out all primary keys of entities
(i.e. entity sets, relvars in Date's terminology).
This turns IS-A into a subset relation on them.

It makes perfect sense to me except that I don't quite see
the reasons for constraining models in this way.

Just a technicality: in E/R diagrams in which primary keys
haven't yet been specified, the entities and relationships that
are indicated strictly speaking aren't, if entity- and
relationship-ness is defined in terms of primary keys.

Why? For that they must share not just any attribute, but a key,
and furthermore, be mustually IS-A (e.g. always hold the exact
same sets of values for that key).

Yes, that's perfectly reasonable, but Silberschatz et al.
do make that decision, by assuming primary keys on all relations,
and using not entities themselves but their primary keys
in relationships. Which leads to the technicality above.
Your way avoids the technicality, directly corresponds to the
actual E/R model, postponing the translation to a relational model
as a later step; all clear advantages. A disadvantage is that
entity-valued attributes raise some eyebrows among certain
relational purists. In all I think the differences are minor.

[...]

I mean 'relational models' in some mathematical sense
(the one I've helped teach was by Debrock)
which will indeed be converted to SQL schemas when implemented
in an SQL database. What would be un-relational or un-mathematical
about them?

This is Silberschatz, I'm not 100% sure ORM's IS-A is the same thing.
I'm no expert on ORM.

--
Reinier

On May 22, 9:14*pm, r... (AT) raampje (DOT) lan (Reinier Post) wrote:
If you say "the primary key of a /table/ rarely contains all of its
attributes", I'll agree. However, considering persons for example, I
view the relation that identifies an entity as a person as distinct
from the relation between a person and his/her name.

Although you see me factoring out primary keys, I believe I only
unpacked conflated relations. I don't think it constrains a model at
all, but rather it makes our assumptions explicit.

This seems to conflate the model with its implementation.

I think our difference here depends on our different understandings of
the term 'relation'. Mine corresponds roughly to relationships in E/R
diagrams, except I view EVERYTHING as relationships / relations.

I believe mine corresponds to a relational model, which gets
translated into an implementation model such as SQL later.

Such entity-valued attributes allow us to climb to higher abstraction
levels. Without them, higher order relations become a mess of
redundant definitions. If you describe a dog or car or person or
chair or anything, do you reiterate its defining characteristics every
time?

Look at http://en.wikipedia.org/wiki/Turing_...mal_definition.
First it defines a (one-tape) Turing machine as a 7-tuple and
describes the heading of the relation, then it defines the 3-state
busy beaver as an instance of that class. However, in this post I can
refer to the 3-state busy beaver without reiterating its definition.
Furthermore, I can refer to *it* without reiterating its name.

Anything that can be said about the entity describes it, so what about
the thing itself? Korzybski equates it to a relation over the various
descriptions of it. In order to express that relation, we need what
you call entity-valued attributes. Otherwise, we'll be stuck
describing bits forever.

I may have jumped the gun since the given description ("Address an
entity (set) and Person and Company relationship (set)s") seems too
vague to work from. Also, can you verify that Person and Company refer
to relationship (set)s? I think I need an example for further
comment.

Nilone wrote:

It does constrain your models: they are always 'unpacked'.

I agree, and I explained some advantages and disadvantages.

But you'll need to start somewhere. I suppose you also have domains.
If your entities form somains you'll presumably want to distinguish between
'atomic' and 'complex' domains, or between 'value' and 'entity' domains,
or something like that. Silberschatz avoids that.

I don't quite understand the relationship (in an informal sense)
between your domains and your entities.

No, they don't, as Silberschatz's solution shows.

No, Silberschatz reiterates its primary key attributes.

Natural language is a lot more liberal than relational database logic.

There is no such thing as 'the thing itself' - the idea that there is
is a fallacy that appears to permeate a lot of writing on logic.

This is a possible way out. Brian Selzer likes to defend this view here.
I believe Russell would also subscribe to it but I haven't read much
Russell. I don't see how we need this in relational modeling.

We don't need to express such a "universal" relation at all.
The idea that objects can be uniquely determined in this way is a
fundamental fallacy. All identification is relative to a domain model.
It suffices to express relations in the amount of detail
required for the problem(s) at hand. Identification of objects
will be relative to the resulting model (schema). This is not because
we're lazy, it's because object identification is fundamentally like that.

These descriptions aren't vague at all, they are mathematical criteria
in terms of primary keys, which I have stated. It is impossible
to 'verify' whether Person or Company are entity sets in general,
because it depends on the range of possible situations the schema
is designed to capture; I was merely assuming this by way of illustration.

--
Reinier

On May 27, 1:44*am, r... (AT) raampje (DOT) lan (Reinier Post) wrote:
In that sense, I agree. Do you think it constrains expressivity?

Tegiri helped me to see that a domain corresponds to a unary
relation. In a practical system, I expect a dbms to create a database
with a basic set of domains, or to act as if those domains exist, but
in theory, we don't need any primitive types.

I see entities as the elements of a domain, independent of any
particular attribute or representation of them. For example, by the
number 2, I mean the successor of the object referred to as 1, not the
digits we use to represent it in any particular encoding.

Sorry, I don't get it based on what you explained so far. May I
request that you enumerate Silberschatz's solution in this context?

Without entity-valued attributes, we have to keep inventing surrogate
identifiers, which creates a new attribute where we only wanted
identity; or re-use a tuple that uniquely describes the entity, which
leads to the explosion of composite keys.

That conflates an entity with a particular attribute of it. By doing
that, we reiterate redundantly and lose the ability to annotate an
entity's attributes.

I reject noumena, but see a phenomenon as the thing itself. Does that
make sense?

I only find it useful as a point of view. In a system where new
relations can be defined, we can't define entities formally since we
have no fixed set of attributes that describe them fully.

I agree that we don't need to express such "universal relations".
However, doesn't this contradict the description of "entities (to be
precise: entity sets) as relations identified entirely by their own
attributes" from your previous post?

I want entity-valued attributes to express relations in general, not
to express "universal relations". We don't need to equate the
identity of an object with a user visible representation of that
identity as an attribute. My idea of a relation corresponds to a 6NF
relation but excluding the representation of the objects related.

One way or another, I confused myself again, since I don't know what
you mean here, even after rereading our previous posts.

PS 1: While formulating a reply, I tried to express the logical
difference between surrogate primary keys and OIDs, and I couldn't do
so. If anyone can help, I'll appreciate it.

PS 2: My apologies for all the 'It seems' in my last few posts. I
still try to write in E-prime, but haven't gotten used to it yet.