Re: two nasty schemata, union types and surrogate keys

From: Roy Hann <specially_at_processed.almost.meat>
Date: Tue, 22 Sep 2009 07:48:23 -0500
Message-ID: <E46dnYt4Z9oKWiXXnZ2dnUVZ8u2dnZ2d_at_pipex.net>



Bob Badour wrote:

> Roy Hann wrote:
>
>> Brian wrote:
>>
>>
>>>>>>Whatever. What is in the database is supposed to be true.
>>>>
>>>>>>Says who?
>>>>
>>>>>Everyone who advocates the closed world assumption.
>>>>
>>>>The closed world assumption doesn't tell you anything about what is
>>>>actually in the database; it tells you how you are entitled to
>>>>manipulate what you find in the database. I hinted at that in
>>>>my first post when I wrote "All that matters is that we can make the
>>>>inferences that we should be entitled to make from the assertions."
>>>
>>>You're wrong, of course, but don't take my word for it. According to
>>>Date in /An Introduction to Database Systems, Eighth Edition/, page
>>>161: 'the Closed World Assumption (also known as the Closed World
>>>Interpretation) says that if an otherwise valid tuple--that is, one
>>>that conforms to the relvar heading--does /not/ appear in the body of
>>>the relvar, then we can assume the corresponding proposition is
>>>false. In other words, the body of the relvar at any given time
>>>contains /all/ and /only/ the tuples that correspond to true
>>>propositions at that time.' So the closed world assumption tells us
>>>that what is actually in the database is supposed to be true, while
>>>what is not is supposed to be false.
>>
>> Far be it from me to contradict Date, but there is no way on earth that
>> he intended us to take that to mean "Garabage In, Garbage Out" doesn't
>> apply to databases.
>
> Um, note the word "assume" in the quoted passage above. He doesn't say
> it is false only that we can assume it is. Also note the phrase
> "supposed to be". He doesn't say it is, which we have no way of
> validating from the dbms, only that it is supposed to be.

I flatter myself that I understand that completely. However we (me and Brian) seem to be talking about two different things. Brian has started talking about how a DBMS has to work, and I am talking about the assorted fantasies, lies, and honest-to-God truths end-users shovel into databases. Databases <> DBMSs.

This gets important when we start designing systems for people to use, because anyone who undertakes that task imagining that the software must somehow ensure the database is a wonderland of infallible truths will end up with unusable and very expensive junk. I've seen it happen a couple of times, at great public expense.

-- 
Roy
Received on Tue Sep 22 2009 - 07:48:23 CDT

Original text of this message