Re: Multiple specification of constraints

"Tony" <andrewst_at_onetel.net.uk> wrote in message news:c0e3f26e.0403030728.8691f83_at_posting.google.com... > "Marshall Spight" <mspight_at_dnai.com> wrote in message news:<ivg1c.169860$uV3.728400_at_attbi_s51>...
> > "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
news:c225fl$rob$1_at_news.netins.net...
> > > > If I enter my Date
> > > > of Birth as 01-Jan-1972 (which it isn't), there is no conceivable
> > > > constraint that will say "Error: lying about your age! And I know
you
> > > > are a Taurus!"
> > >
> > > Yes -- and that shows that data type constraints are but one aspect of
data
> > > integrity.
> >
> > I might point out a terminology issue here. In general, I have not seen
> > the word "integrity" (in a data management context) used to describe
> > the issue of whether the data matches what it is supposed to match
> > in the outside world. The word is used only to refer to the internal
> > consistency of the data.
> >
> > The larger problem you mention, getting the external predicate
> > and the internal predicate to be linked in some way, is insoluable,
> > and so we don't talk about it too much.

>
> Quite.  Even the most integrated system can't prevent a programmer
> from putting prompt A next to input field B, unless field prompts are
> forced to be equal to the underlying column name and cannot be
> modified, like DATE_SKULL_FRAC instead of "Date of Skull Fracture".
>
> So, because database consraints can't prevent this situation that
> nothing can prevent, Dawn calls them flawed.  Hmm...

It does seem that DBA's spend a lot of time trying to figure out how to prevent programmers from doing this or that. One or more software applications written with the teamwork of all participants addressing how to get the most integrity in the stored data seems like a less flawed strategy than having DBAs figure out how to block programmers who figure out how to get around the walls built by the DBA. I realize that not all projects sound like the latter, but I suspect many do.

Even though you cannot ensure that the data coming into a system is sound, if you take 100 software development teams and have them write applications to meet the same data requirements (no UI specified), there will be some variance in the quality of the data captured that is due to the way the applications were written, right? So, you cannot prevent garbage coming in, but you can encourage quality input.

--dawn Received on Wed Mar 03 2004 - 19:42:40 CET