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

From: Hugo Kornelis <hugo_at_perFact.REMOVETHIS.info.INVALID>
Date: Fri, 31 Oct 2008 00:23:53 +0100
Message-ID: <i7gkg4tfcp09te5vir9ilrgh2ugm106mur_at_4ax.com>


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 Received on Fri Oct 31 2008 - 00:23:53 CET

Original text of this message