Re: Surrogate Keys: an Implementation Issue
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Mon, 07 Aug 2006 11:40:25 GMT
Message-ID: <JEFBg.36170$pu3.473067_at_ursa-nb00s0.nbnet.nb.ca>
>
>
> 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.
>
> 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.
>
> 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.
>
> 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.
Date: Mon, 07 Aug 2006 11:40:25 GMT
Message-ID: <JEFBg.36170$pu3.473067_at_ursa-nb00s0.nbnet.nb.ca>
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.
>
> 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.
>
> 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.
>
> 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.
Why not write it off? One must consider each of the issues you mentioned during design.
None of these issues have anything to do with anything Selzer wrote, which leaves me scratching my head wondering how you consider any of them relevant to the prior discussion. Received on Mon Aug 07 2006 - 13:40:25 CEST