Re: ID field as logical address

On Jun 5, 8:53 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> "Kevin Kirkpatrick" <kvnkrkpt..._at_gmail.com> wrote in message
>
> news:1aa37bb4-cf9a-47b8-8fb4-3447ef4968cc_at_o20g2000vbh.googlegroups.com...
>
> <snip>
>
> > Let me first address the excess vebiage surrounding the {L,F} key.
> > The fact that {L,F} has been chosen as the only key for the relation
> > at hand, coupled with the assumption of competent data modeling, means
> > we are operating in a UoD where {L,F} is the most reasonable key per
> > data modeling principles. How can this be? Perhaps this is a UoD
> > where all employees of a company are internally and forever refered to
> > by unique hired names (coerced into uniqueness by disambiguation
> > policies such a middle initial inclusion, if need be) rather than
> > current legal names. Or, more plausibly, the UoD may be a highschool
> > classmate database, where {L,F} refers to the names of each
> > individual's official high-school record, and either
> > 1) the high-school in question had disambiguation policies in place
> > for all names; or
> > 2) it's a simple historic fact that no duplicate names exist for the
> > classes being tracked.
>
> Noise and more noise. Complain all you want about the choice of key. The
> fact remains that no transition constraint can be effectively written or
> enforced whenever any prime attribute can be the target of an update.
> Moreover no transition constraint that prohibits updates to prime attributes
> can be effectively written or enforced under Date and Darwen's
> databases-as-collections-of-relvars paradigm because there's no way to
> determine whether a particular assignment was the result of a delete and an
> insert or an update.

So basically, transition constraints require immutable prime attributes and immutable prime attributes require transition constraints. This may be true - the thing is, I contend that neither one is needed (and if they seem to be, then the data model is off).

> There are a myriad of examples I could have used but
> they would have required a lot more explanation or expertise in subjects
> that are not germane to database theory, furthermore, it just so happens
> that Date in /Introduction/ uses a similar example when introducing the
> concept of transition constraints.
>
>

I'll review that example - I just can't conceive of a real-world case where constraints need to refer to attributes which are not themselves in the data model. Such constraints seem to violate the mantra, "The DBMS can't enforce truth, only consistency."

>
>
>
> >Having gotten that off my chest, let's jump into the unusual world
> >fostered by "transition constraints". A data entry person will adhere
> >to the transition constraints policy, and following the data modeler's
> >advice, do 2 updates to set Mary Smith's marital status correctly.
> >Let's assume a 1 minute lag between updates, and look at what the
> >updates mean (per Brian's definitions above).
>
> >At 8:00 a.m., according to the meaning of an update, the data entry
> >person should assert:
>
> >"The person that had up to 8:00 a.m. had last name Smith and first
> >name Mary and had up to 8:00 a.m. been Single now has last name Smith
> >and first name Mary and is Married."
>
> >She should submit this fact to the database, then reload her data
> >entry form in order to assert at 8:01 a.m.:
>
> >"The person that had up to 8:01 a.m. had last name Smith and first
> >name Mary and had up to 8:01 a.m. been Married now has last name Smith
> >and first name Mary and is Divorced."
>
> >Do I have the intended meaning of both of these updates correct? If
> >so, would you agree that both assertions are falsehoods about the real
> >world?
>
> I see what you're driving at, but at the time immediately prior to the first
> assertion, what the database asserted about the real world was false and had
> been false for about a week. As a consequence every possible update would in
> fact be a falsehood about the real world, as would the result of many
> database queries during that time.
>

You're equivocating on the word "falsehood". There is a vast difference between a database returning a false statement about the real world (the results of any query of any database are only as accurate as the observations recorded therein), and users asserting something they known to be untrue. I would consider it a catastrophic failure of the data model if, for the database to function, the end users needed to lie.

>
>
>
>
> >> In the same way, the "meaning" of a delete {L, F, Stat} is:
>
> >> "The person that had up to now had last name <L> and first name <F> and
> >> had
> >> up to now been <Stat> no longer exists."
>
> >> and the "meaning" of an insert {L', F', Stat'} is:
>
> >> "There exists a person that has last name <L'> and first name <F'> and is
> >> <Stat'>."
>
> >> Just one point I need to make about these "meanings:" formally, in a
> >> fixed
> >> Universe, existence must be in fact a predicate, not a quantifier. To
> >> have
> >> existed is to have become actual; to exist is to still actually be.
> >> Distinguishing existence from being permits the quantifier, "there is" to
> >> range over all kinds of things, including things that have a past,
> >> present
> >> or possible locus in time as well as things that are independent of time.
>
> >> > But I'm still confused... at the time it was true that "Mary Smith got
> >> > Divorced", and the database tuple changed from {"Smith", "Mary",
> >> > "Married"} to {"Smith", "Mary", "Divorced"}, doesn't that imply that
> >> > it was no longer true that "Mary Smith got Married"?
>
> >> "Mary Smith got Divorced" implies that "Mary Smith got Married" as a
> >> consequence of the transition constraint that prohibits Single people
> >> from
> >> getting Divorced.
>
> > It implies no such thing. Perhaps {Mary ,Smith , Divorced} was
> > inserted.
>
> I think you're wrong: since it is common knowledge that every person starts
> out single and since single people can't get divorced, then only married
> people can get divorced, and since only married people can get divorced,
> then obviously, everyone who is divorced must have at some point gotten
> married--even if that fact isn't recorded in the database.
>

Obviously, as a consequence of common knowledge, we can infer that if Mary Smith is divorced then she was married at some prior time in her life. However, I was responding to your statement that the history of Mary's marital statuses could be inferred "as a consequence of the transition constraint". In that light, it seemed you were claiming, "Given a current tuple <Mary, Smith, Divorced>, one could use the transition constraint to infer that tuple <Mary, Smith, Married> had been recorded at some prior time." That is the false inference to which I alluded.

> <snipped false conclusion drawn from false premise>
>
> > If the UoD is concerned about whether
> > Mary Smith got Married while being tracked by the database, then the
> > data model ought to expose a history of marital statuses, period. And
> > it goes without saying that in such a revised model, the marital-
> > status "transition constraint" is unnecessary (simple rules about
> > allowable chronological histories of marital statuses are trivially
> > enforced).
>
> First of all, the UoD is not sentient, so it cannot be concerned about
> anything.

Apologies for the sloppy wording. I simply meant that if 'Mary Smith got Married' is a meaningful piece of information within the UoD, then the data model ought to allow such information to be tracked explicitly.

> Second, the point of the transition constraint is to keep garbage
> out, but storing the histories of marital statuses would clutter up the
> database with irrelevancies, which are in my opinion just another kind of
> garbage.

I disagree. In all of the database modeling I've done, I have yet to encounter a situation where some attribute X is so important that we can use it as a basis for rejecting some proposed value for attribute Y, but so un-important that we don't want to store it in the database. It seems obvious to me that if "prior marital status" is sufficient grounds for rejecting an asserted "current marital status", then "prior marital status" is a part of the UoD and should be exposed in the data model.

> Third, even if there were a reasonable way to eliminate the need
> for the marital-status transition constraint, in no way does that prove that
> there is never any need for transition constraints. Even Date and Darwen,
> as evidenced by their "RM Very Strong Suggestion 4," acknowledge the need
> for transition constraints.
>

Well, yes... proving negatives is impossible. On the other hand, you need only provide *one* example where no reasonable alternative to transition constraints exists (and, of course, where transition constraints will not require end users to lie to the database).

> <snip>
>
> > I must say, given the freedom to pick any example to illuminate the
> > value of "transition constraints", it's telling that you have chosen
> > one which trivially leads to both:
> > 1) Requirements that people assert falsehoods in order for the
> > database to function
>
> As indicated above, that would be required even without the transition
> constraint.

Say what? If {F, L, Stat} models the predicate "The employee hired with unique name <F> <L> is <Stat>", then the data entry person who updates Mary Smith's marital status from "Single" to "Divorced" at a time that she is divorced is *not* asserting a falsehood.

If prior marital statuses were part of the UoD, and statuses were modeled with something akin to:

MAR_CURR {F, L, Stat}: "The employee hired with unique name <F> <L> is <Stat>"
MAR_PRIOR {F, L, Prior_Stat}: "The employee hired with unique name <F> <L> had prior status <Prior_stat>"

then non-sensical marital status transitions could be prevented *and* the database could be updated from the state:

MAR_CURR: {<MARY, SMITH, SINGLE>}
MAR_PRIOR: {} to the state:

MAR_CURR: {<MARY, SMITH, DIVORCED>}
MAR_PRIOR: {<MARY, SMITH, MARRIED>}

with no need for lying to the database.

>
> > 2) False inferences.
>
> Also debunked above.
>
> <snipped inane ad-hominem attack>- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
Received on Tue Jun 09 2009 - 01:07:59 CEST