Re: On formal HAS-A definition

Nilone wrote:

>On May 8, 2:12 pm, r..._at_raampje.lan (Reinier Post) wrote:
>> Nilone  wrote:
>> >It looks to me like tuples are being equated with entities.
>>
>> When justifying the definition of IS-A in the E/R-model: yes.
>
>What do you mean?

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/

> I'm thinking:
>
>- E/R model entities and attributes are elements of domains
>- E/R model relationships are relations over domains
>- Tuples are the elements of relations over domains of entities
>- IS-A is an isomorphism between domains of entities
>- HAS-A is a monomorphism between domains of entities

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.

>So when it looks like an entities are equated with tuples, I wonder
>why. I believe it's a mistake to do so, but perhaps I'm missing
>something.

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.

>> >A relation is not a domain.
>>
>> THat is irrelevant for the IS-A I'm discussing.
>
>My apologies for jumping to conclusions. I would like to understand
>the IS-A you're discussing. I'll continue reading.

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