Re: ID field as logical address

On Jun 1, 9:42 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> "Kevin Kirkpatrick" <kvnkrkpt..._at_gmail.com> wrote in message
>
> news:a5076075-7ae9-4ab1-abf0-297ae601eb06_at_n21g2000vba.googlegroups.com...
>
>
>
>
>
> > On Jun 1, 2:27 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> > > "Kevin Kirkpatrick" <kvnkrkpt..._at_gmail.com> wrote in message
>
> > >news:895891d5-fe55-478d-81d7-e984bc37fff9_at_r13g2000vbr.googlegroups.com...
>
> > > > On Jun 1, 11:39 am, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> > > > > "Kevin Kirkpatrick" <kvnkrkpt..._at_gmail.com> wrote in message
>
> > > > >news:670a228b-b752-47eb-b2e4-68c966c449d9_at_s31g2000vbp.googlegroups.com...
>
> > > > > > What is the poor HR person to do when Mary Smith returns from a
> > > > > > week
> > > > > > long Vegas trip and reports that she'd gotten married on Monday
> > > > > > and
> > > > > > divorced on Friday?
>
> > > > > That should be obvious: issue two updates in succession, one for
> > > > > each
> > > > > event.
>
> > > > Am I reading that right? You think the data entry person should
> > > > enter, as a fact to the database, "Mary Smith is currently Married",
> > > > at a time when Mary Smith is definitely not married?
>
> > > Yes, you're reading that right. The data entry person should enter, as a
> > > fact into the database, "Mary Smith got Married", at a time when it is
> > > true
> > > that Mary Smith got Married, and then "Mary Smith got Divorced" at a
> > > time
> > > when it is true that Mary Smith got Divorced.
>
> > Sorry, I misinterpretted the relation {L, F, Stat} to indicate
> > "The person with last name <L> and first name <F> is currently <Stat>"
>
> > It seems like you intended the relation to mean:
>
> > "The person with last name <L> and first name <F> got <Stat>"
>
> That's an interesting way to express the "meaning" of a relation, but the
> verb tenses are wrong.
>
> The "meaning" of the relation {L, F, Stat} is:
>
> "The person that has up to now had last name <L> and first name <F> has up
> to now been <Stat>."
>
> The "meaning" of an update {L, F, Stat, 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> now has last name <L'> and first name <F'> and is
> <Stat'>."
>

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.

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?

> 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. But you do make the point that transition constraints allow for incorrect inferences when meaningful observations from the UoD are not exposed in the data model. 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 maritalstatus  "transition constraint" is unnecessary (simple rules about allowable chronological histories of marital statuses are trivially enforced).

>
> > > The database has to be
> > > informed that a marriage occurred and then that a divorce occurred,
> > > since it
> > > is not just states that are being constrained, but changes of state.
>
> > "The database has to be informed that a marriage occurred"
>
> > I thought the UoD was limited to a person's current marital status
> > (hence the single relation {L, F, Stat}).  Is the fact that "a
> > marriage occured" part of the UoD?  If so, how is this fact
> > represented in the data model?- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

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
2) False inferences.

I think I now better understand the "mystic" charges others have leveraged towards Brian's approach to database theory. His approach would seem to assume a mystical "shadow world", wherein a virtual 'Mary Smith' lives as a 'Single' person in the database, and remains 'Single' right up until she gets 'Married' by the data entry person at 8:00 a.m. (and subsequently "Divorced" by the same data entry person a few seconds / keystrokes later). The mentality treats the 1's and 0's stored in the humming box not as simple, structured recordings of observations of the real world, but as real entities that themselves need to obey the laws of our real world directly. Received on Sat Jun 06 2009 - 00:05:15 CEST