Re: On formal HAS-A definition

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

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.

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

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

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

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

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 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. Received on Mon May 24 2010 - 14:23:58 CEST