Re: How to normalize this?

On Tuesday, May 7, 2013 4:20:58 PM UTC+2, Erwin wrote:  

> Am I allowed to interject my own tentative answers here ?
>
> Does it [introducing the IND] introduce redundancy ?
>
> Yes. Because the IND now causes the A->B FD to "carry over" to R.
>
> Does it changes the keys of R ?
>
> Yes. Because that IND has been "carried over".
>
> Is it still a good database design ?
>
> No, unless in the case when I very deliberately want to retain the redundancy in the database, as a sort of "four-eyes" check on the actual assertions that are being made in the database update process[es].
>
> The constraint (the IND, that is) that is needed to "control this redundancy" is a proposition that says "for any A value in R, the corresponding B value found in R must be as can also be found in the corresponding tuple from S, which must exist."
>
> An S updater might have asserted "A value is 3 and corresponding B value is 7".
>
> An R updater (or, depending on how you look at it, the entire overall database update process) is now "double-checked" by forcing him to also specify the B value 7 whenever he inserts the A value 3. Forcing him to sort of "confirm his awareness of the nature of that IND".
>
> In all other cases, I would remove the redundancy.

I essentially agree with all you say, but please note that the point about the key is a delicate one: it means that now to determine the keys of a relation schema you need to look at the whole database schema! Received on Tue May 07 2013 - 17:12:25 CEST