Re: How to normalize this?

From: Erwin <e.smout_at_myonline.be>
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!

The 1992 paper you pointed to contains/points out the formal foundation for what I informally called "carrying over". Page 2, lemma 1, "pullback rule".

And it implies that you have to look at all the (and only those) relation schemas that are the "target" of an IND, to see if any FDs can be inferred/carried over to the "source" of the IND.

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

Original text of this message