Re: ID field as logical address

"Kevin Kirkpatrick" <kvnkrkptrck_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. 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.

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

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

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

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

> 2) False inferences.

Also debunked above.

<snipped inane ad-hominem attack> Received on Sat Jun 06 2009 - 03:53:46 CEST