Re: We claim that delete anomality is due to table not being in 3NF, but...

From: paul c <toledobythesea_at_oohay.ac>
Date: Fri, 31 Oct 2008 03:05:58 GMT
Message-ID: <qCuOk.5245$fF3.2496_at_edtnps83>


Hugo Kornelis wrote:
> On Wed, 29 Oct 2008 22:59:25 GMT, paul c wrote:
>

>> Hugo Kornelis wrote:
>> ...
>>> Functional dependencies stem from reality. Whether or not you choose to
>>> include B in your model does not change the situation where, apparently,
>>> C depends on A through some intermediary B (that is not in the DB).
>>>
>>> In a DB that stores PersonID and EyeColour, one might argue that the
>>> actual dependency goes back to the parents of the person and their
>>> genetic patterns - but those will typically not be stored, and yet the
>>> EyeColour still depends on PersonID.
>>> ...
>>
>> Assuming you're saying it's improper to depend on any notion of absolute 
>> reality, I think I'd agree.  Doesn't a db aimed toward aiding some 
>> present function necessarily stand for a very fractional/partial (or 
>> even distorted) reality?  Eg., if it's not fractional it's probably 
>> unwieldy and untoward.  Seems to me that the EyeColour dependency hints 
>> at this - when the purpose of a particular set of tables isn't concerned 
>> with dna, one likely ignores blood lines.  Further, I suspect that no db 
>> ought to introduce fd's that aren't patently implicit in the user's 
>> requirements/biz rules/application intent.  In the USA, I gather that an 
>> address that is complete enough for a mailman to deliver to, along with 
>> a city and a state will determine zipcode, yet I suspect there are many 
>> tables in non-postal db's that have a column set such as (Customer, 
>> unit, streetaddress, city, state, zip).

>
> Hi Paul,
>
> This is cdt, not alt.philosophy. I was not after an existential
> discussion on absolute reality. :)
>
> You're reading way more into my example than I intended. The point I
> tried to make is that functional dependencies are not determined by what
> is or is not stored in the database, but by how entities and their
> interactions in reality. The DB is a model of reality and changing the
> model won't change reality.
>
> I already considered the example pretty bad when I wrote it, and now
> that I see what you read into it, I'm really embarassed...
>
> Best, Hugo

Sorry Hugo, consider it my fault entirely. In order to keep my reason short, I'll just blame it on the grape. Maybe one day, I'll figure out a way to put it better than I did.

best,
p Received on Fri Oct 31 2008 - 04:05:58 CET

Original text of this message