Re: How to normalize this?
Date: Tue, 7 May 2013 08:27:25 -0700 (PDT)
Message-ID: <113e0c60-c5a7-4273-92c4-6e46d6578954_at_googlegroups.com>
Op dinsdag 7 mei 2013 17:12:25 UTC+2 schreef nvitac..._at_gmail.com het volgende:
> 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!
Remaining question might be whether there are any other rules that could also cause "possible inference/carrying over" ... I can certainly see things getting complicated there. Received on Tue May 07 2013 - 17:27:25 CEST