Re: ID field as logical address

"Brian Selzer" <brian_at_selzer-software.com> wrote in message news:yk0Vl.18154$%54.10435_at_nlpi070.nbdc.sbc.com...
>
> "Kevin Kirkpatrick" <kvnkrkptrck_at_gmail.com> wrote in message
> news:a5076075-7ae9-4ab1-abf0-297ae601eb06_at_n21g2000vba.googlegroups.com...
>> "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?
>

The fact need not be represented because it is implied. The transition constraint that enumerates the changes in marital status that are allowed also augments the "meaning" of each tuple. Single implies that no marriage occurred; Married and Divorced both imply that at least one marriage occurred.

The arguments against implementing transition constraints seem to fall into two categories: The first and most often expressed is the fact that users screw up and there has to be a way to fix those screw ups, and sometimes the transition constraints get in the way. The second is the one you've expressed, which is that there may be a delay in issuing an update that is long enough so that more than one change to the thing in the Universe could have occurred.

The first argument can be answered by providing a mechanism for differentiating between a transition and a correction. The simplest mechanism is to just require that an explanation be given when the database update is a correction. The explanation could be recorded as tuples in a separate relation or as components in the same relation. Transition constraints could then be written so that they return True whenever an explanation is provided in the same database update.

The second argument can be worked around by simply providing an explanation in the same way as a correction, but I would argue for issuing successive updates, since the database did not reflect what had actually been the case since the start of the delay, so it is more important in my opinion that the order in which events occurred be preserved, so the transition constraints could be checked in the same order that the events occurred. Received on Tue Jun 02 2009 - 15:48:06 CEST