Re: Surrogate Keys: an Implementation Issue

Dan wrote:
> <snip>
>
> > >>
> > >>His problem goes a lot deeper than his assumption about examples. The
> > >>real root of the problem is his belief that he has a valid point to make.
> > >
> > > It is a valid point.
> >
> > Only if you make the fundamental mistake of pretending a non-key is a key.
>
> No. There is a fundamental difference between a unique proposition
> (tuple) as taken simply from the mathematical definition of a relation
> as a minimum criterion for identity of a proposition, and the
> definition of a functional dependency that determines a primary key or
> candidate key. While most make the assumption that the two types of
> identity are equivalent, the assumption is fundamentally flawed, IMO.
> Often it might be the case that they are indented to be the same, but
> it is not guaranteed to be universally so.

I'm confused by this Dan. Ignoring the fact that a mathematical tuple is subtly different to an RM tuple, you are correct in saying a proposition's identity is determined by every single one of its attributes. However, a key is defined as an attribute that, once specified, will determine all of the other attributes in the proposition, and hence is a wholly sufficient identifier by itself. Are you distinguishing between the identity of a proposition as a whole and a satisfactory alias for that whole identity? If so, I think that's a fruitless distinction and cannot currently see a situation where it would be of any use.

>
> So there are several issues that could be at play here. There is the
> gap between internal and external predicate over domains, or
> alternatively the gap between the universive of discourse and a strict
> symbolic interpretation. Moreover, the difference between a unique
> sentence taking all attribute values into consideration and the
> approach of analyzing functional dependences, which isolates the set of
> attributes into determinant sets and the set of attributes being
> determined is a subtle distinction, but one that has major implications
> nonetheless. Both of these can lead to confusion over whether we are
> more interested in the fact as a proposition being unique and
> discernable from different facts, or whether we are interested more in
> properties about some symbolic representation of a conceptual entity
> being more important, the representation revolving around a key
> construct.

Only if one thinks conceptual entities have anything to do whatsoever with the logical model, which imo, they absolutely should not - and certainly don't in the RM.

This is why I currently rate ORM and its emphasis that these are _sentences of communication_ with which we are dealing, and not symbolic and ephemeral manipulation of entities. The latter are best left to the insides of our heads.

>
> To some degree from a strictly literal standpoint, key dependencies are
> a hack job that are disabused. There is no proscription against having
> two determinants of different value functionally resolve to the same
> attribute/property values across a proposition, nor is there a
> proscription that in the cases where they do resolve to the same
> determined values, they are the same thing in the conceptual space with
> different identifying names. Whether this results in different literal
> identities or an equivalency must often be judged on a case by case
> basis.
>
> Equivalency plays a big part in this, and of course this is different
> than comparing and determining equality of identity by comparing all
> properties of an element. If you need some concrete abstract fat to
> chew, take equivalence of boolean expressions as a starting point and
> ask yourself whether two truth tables that have the same values but are
> use different logical expressions are the same or equivalent.

That's a good distinction in my book. equality and equivalency. often confused in these discussions. All best, Jim.

>
> Alphabetic case is another case in point. By strict standards, only
> one symbolic representation (including case) should be used as a key,
> but most implementations certainly don't accomodate this easily and
> usually for those that are truly purists, a CONSTRAINT xxxx CHECK
> (variable = UPPER(variable)) is necessary in order to meet an ideal.
> These are just off the top of my head examples, but there seems to me
> to be plenty of evidence that writing off these issues to poor design
> and bad taste instead of recognizing the theoritical validity of such
> conditions might be a bit premature.
>
> - Dan
Received on Mon Aug 07 2006 - 14:20:34 CEST