Re: On formal HAS-A definition

Nilone wrote:

>On May 22, 12:26 am, r..._at_raampje.lan (Reinier Post) 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/

[...]

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

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

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

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

>> Definied in this way, entities and relationships
>> are particular types of relations in relational schemas.
>
>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 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.

>> 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.
>
>I don't understand the reason for this qualification.

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.

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

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

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

>> 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'll have to study ORM properly some time.

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

-- 
Reinier