Re: [ddlm-group] Adding a DDLm attribute for uniqueness

> I think there may be a way to approach uniqueness that resolves enough issues to make it worthwhile. I suggest we view 'uniqueness' through a functional lens, so what we really mean when we say values of a dataname are unique is that there is a one-to-one mapping from that data name to the keys of the category (of course, there is already a one-to-one mapping from the keys to the dataname by definition of "key").

... to be a description of something new.  In fact, it seems to be meant as a definition of what we typically mean by "unique".  It’s a pretty natural one, for it is equivalent to identifying the property of being “unique” with what would be described in relational terms as being a candidate key.

I then take that to serve as context for a proposal to define a new and slightly different kind of definable relationship between data items, which I’ll refer to as Hester-uniqueness, given by:

>  So if we explicitly specify the datanames whose collective values are unique for a given value of our 'unique' data name, we have specified 'uniqueness' in a way that is immune to expansions changes in the category key. We are also not limited by relationships involving keys.

And that brings Herbert’s objection into focus for me: applying a Hester-uniqueness constraint to a category can denormalize that category in the relational sense.  In the event that the set of data names that are required to specify Hester-uniqueness for some attribute is permitted to be a proper subset of a candidate key of the category, applying such a constraint can break second-normal form.  In the event that the set of data names that are required to specify Hester-uniqueness for some attribute is not required to be a (possibly-trivial) superkey of a candidate key, applying such a constraint can break third-normal form.  Yet, forbidding those possibilities leaves us effectively at the uniqueness definition we started with.

Whether such constraints are enforced in a given relational database representation is not really the issue.

With that said, and now having given the matter some thought, it does not seem unreasonable on its face to provide for defining more than the two(-ish) candidate keys that DDLm already affords.  This is, for me, a question of defining data more completely.  I don’t see robustness against key expansion to be a significant issue.  The matter of handling unknown values of items belonging to a candidate key does bear some thought, but there are several possible approaches, including "validator’s choice".  Inasmuch as DDLm does not already offer the feature, however, there does remain a cost / benefit question around adding attributes to DDLm for this purpose.  I’m generally inclined to prefer descriptive attributes to methods for defining data, but it is not clear to me how much benefit would be gained from new uniqueness / candidate key attributes.

Regards,

John