Re: A real world example
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Thu, 17 Aug 2006 04:08:56 GMT
Message-ID: <sZREg.49400$pu3.584038_at_ursa-nb00s0.nbnet.nb.ca>
>
> Brian, it's not that key constraints are insufficient,
> it's that the key constraints you declared in the
> example are insufficient. As I've been saying all
> along: the design is lacking.
>
> I first dealt with questions like this almost 20 years
> ago. The requirement was that "the system should know"
> that what is, today, for example, known as "American
> Airlines Flight 3" was previously known as "Pan American
> Flight 3" and before that "TransWold Airlines Flight 1."
>
> Surrogates - i.e., system generated "uniquifiers" - were
> part of that solution -- but I know better, now. And
> I grant you: modern SQL products are hard pressed to
> meet the need. But, if you think about it, there's no
> reason to expect that changing a value constrained as
> a key value should be as simple as an SQL UPDATE and
> there's no reason to expect the underlying model to
> provide convenient support for something that would
> make some developers' lives easier. Thinking like
> that is part of the reason that commercial DBMSs are
> such a mess.
Date: Thu, 17 Aug 2006 04:08:56 GMT
Message-ID: <sZREg.49400$pu3.584038_at_ursa-nb00s0.nbnet.nb.ca>
J M Davitt wrote:
> Brian Selzer wrote:
>
>> "J M Davitt" <jdavitt_at_aeneas.net> wrote in message >> news:qFPEg.76061$Eh1.21923_at_tornado.ohiordc.rr.com... >> >>> Brian Selzer wrote: >>> >>>> "JOG" <jog_at_cs.nott.ac.uk> wrote in message >>>> news:1155685450.575606.117120_at_b28g2000cwb.googlegroups.com... >>>> >>>> >>>>> Brian Selzer wrote: >>>>> >>>>> >>>>>> "JOG" <jog_at_cs.nott.ac.uk> wrote in message >>>>>> news:1155662126.381260.226850_at_m73g2000cwd.googlegroups.com... >>>>>> >>>>>> >>>>>>> Brian Selzer wrote: >>>>>>> [big snips for clarity] >>> >>> >>> [more snips for more clarity] >>>>> It is important to see that "Me now" is a completely different entity >>>>> to "Me over my whole lifetime". The temporal issue is irrelevant, all >>>>> that matters is to recognise they are just different entites. I know >>>>> this is initially seems an obtuse philosophical point, but it has >>>>> _real_ consequences for how to model those entities. >>>> >>>> I see the difference, but I can't see how you can shrug off the >>>> temporal issue. They must have a common property because they're >>>> related. I would argue that "Me now" is part of "Me over my whole >>>> lifetime." >>> >>> If some sort of temporal continuity is important, the >>> design must include features that meet the requirement -- >>> but some naively suggested surrogate key isn't the answer... >> >> If you've read the rest of my argument, then I ask you: how can you >> possibly use a temporal attribute to make the tuples in the database >> instance preceding a change correspond to tuples in the database >> instance succeeding a change?
By mapping some other stable attribute to the unstable attribute recording the duration of the mapping. For instance.
>>> [snip] >>> >>>> In an earlier post, I used the terms, "individual" and "universal" >>>> to describe these categories of properties. Individual properties >>>> define the essence of something and remain constant throughout its >>>> lifetime. Universal properties depend on the state of the universe >>>> during that lifetime. Universal properties are the only ones that >>>> can change. >>> >>> >>> ..even if you proclaim that your made-up value is an >>> "individual property." >>> >>> All this... >>> >>> >> That's not the case at all. I see exactly how to fulfill them. The >> point is: I shouldn't have to. I should be able to define declarative >> constraints to ensure the integrity of the data.
The problem is not Selzer's declarative constraint but his expectation that the dbms will automagically do things no user ever instructed it to do. Data management has not yet advanced to the point of reading minds.
That means not only
>> within each database instance, but also between two successive >> database instances because the model allows a database to be updated >> and describes how it happens, that is, updates are set-based. Now, if >> an update involves more than one tuple, and that update depends on the >> current database instance, then there should be a way to correleate >> the tuples in the current database instance with those in the proposed >> instance. I've shown that candidate keys as defined are not >> sufficient. Can you think of another way? I shouldn't be able to >> compromise integrity with an ad-hoc update.
>
> Brian, it's not that key constraints are insufficient,
> it's that the key constraints you declared in the
> example are insufficient. As I've been saying all
> along: the design is lacking.
>
> I first dealt with questions like this almost 20 years
> ago. The requirement was that "the system should know"
> that what is, today, for example, known as "American
> Airlines Flight 3" was previously known as "Pan American
> Flight 3" and before that "TransWold Airlines Flight 1."
>
> Surrogates - i.e., system generated "uniquifiers" - were
> part of that solution -- but I know better, now. And
> I grant you: modern SQL products are hard pressed to
> meet the need. But, if you think about it, there's no
> reason to expect that changing a value constrained as
> a key value should be as simple as an SQL UPDATE and
> there's no reason to expect the underlying model to
> provide convenient support for something that would
> make some developers' lives easier. Thinking like
> that is part of the reason that commercial DBMSs are
> such a mess.
Hear! Hear! Received on Thu Aug 17 2006 - 06:08:56 CEST