Re: On formal HAS-A definition

On May 27, 1:44 am, r..._at_raampje.lan (Reinier Post) wrote:
> Nilone wrote:
> >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'.

In that sense, I agree. Do you think it constrains expressivity?

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

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 don't quite understand the relationship (in an informal sense)
> between your domains and your entities.

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.

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

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.

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

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.

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

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

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

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.

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

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

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. Received on Fri May 28 2010 - 15:20:11 CEST