Re: On formal HAS-A definition

Nilone wrote:

>On May 22, 9:14 pm, r..._at_raampje.lan (Reinier Post) wrote:
>>
>> 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.
>
>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.

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

>> 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.
>
>This seems to conflate the model with its implementation.

I agree, and I explained some advantages and disadvantages.

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

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.

>> 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.
>
>I believe mine corresponds to a relational model, which gets
>translated into an implementation model such as SQL later.

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

>> A disadvantage is that
>> entity-valued attributes raise some eyebrows among certain
>> relational purists.  In all I think the differences are minor.
>
>Such entity-valued attributes allow us to climb to higher abstraction
>levels. Without them, higher order relations become a mess of
>redundant definitions.

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

>If you describe a dog or car or person or
>chair or anything, do you reiterate its defining characteristics every
>time?

No, Silberschatz reiterates its primary key attributes.

>Look at http://en.wikipedia.org/wiki/Turing_machine#Formal_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.

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

>Anything that can be said about the entity describes it, so what about
>the thing itself?

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.

>Korzybski equates it to a relation over the various
>descriptions of it.

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.

>In order to express that relation, we need what
>you call entity-valued attributes. Otherwise, we'll be stuck
>describing bits forever.

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.

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

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