Re: How to normalize this?
From: Jan Hidders <hidders_at_gmail.com>
Date: Wed, 1 May 2013 23:07:54 +0200
Message-ID: <51818429$0$6322$e4fe514c_at_dreader35.news.xs4all.nl>
>> On 2013-05-01 13:08:38 +0000, Erwin said:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> There we probably differ. It might be that each class was introduced
>>
>> because of certain clients that we had in the past, but that does not
>>
>> logically exclude the possibility that at some point in the future we
>>
>> have for a brief period no clients of that class. In that case we would
>>
>> not want to lose the link between age and that class. So a separate
>>
>> age-class table would be a good design here.
>>
>>
>>
>> -- Jan Hidders
Date: Wed, 1 May 2013 23:07:54 +0200
Message-ID: <51818429$0$6322$e4fe514c_at_dreader35.news.xs4all.nl>
On 2013-05-01 16:08:17 +0000, Erwin said:
> Op woensdag 1 mei 2013 17:38:17 UTC+2 schreef Jan Hidders het volgende:
>> On 2013-05-01 13:08:38 +0000, Erwin said:
>>
>>
>>
>>> Op woensdag 1 mei 2013 11:20:47 UTC+2 schreef Jan Hidders het volgende:
>>
>>>> On 2013-04-30 22:17:44 +0000, Erwin said:
>>
>>>>
>>
>>>> And I would argue that in practice the different>> components usually
>>
>>>> turn out to be independent facts anyway. The fact>> that they have
>>
>>>> different underlying dependencies already sort of hints>> at that. But
>>
>>>> if you have a realistic example that would show otherwise,>> that would
>>
>>>> be interesting.
>>
>>>
>>
>>> Not sure if I'm thinking of the same kind of thing as you, but I'm
>>
>>> thinking of CUSTOMERs that have an AGE, where AGE determines [some kind
>>
>>> of] COMMERCIAL _CLASS.
>>
>>>
>>
>>> AGE and COMMERCIAL_CLASS don't become facts that are "independent" from
>>
>>> there being a CUSTOMER to begin with.
>>
>>
>>
>> There we probably differ. It might be that each class was introduced
>>
>> because of certain clients that we had in the past, but that does not
>>
>> logically exclude the possibility that at some point in the future we
>>
>> have for a brief period no clients of that class. In that case we would
>>
>> not want to lose the link between age and that class. So a separate
>>
>> age-class table would be a good design here.
>>
>>
>>
>> -- Jan Hidders
> > :-) > > You responded only to the piece of which I wrote myself : > > "Bad example. pls disregard." > > Does the "_there_ we probably differ" imply then that you agree with the rest ?
To some extent. I certainly agree with the observation that when reasoning about update anomalies and redudancy we should take all database constraints into account, not just functional dependencies. But I still don't follow you where you state that in OP's original example this is necessarily an issue. It could be, theoretically, but I doubt it happens often in practice.
- Jan Hidders