Re: 4NF is Where It Is At! [WAS Re: 1:1 relationships]
Date: Mon, 12 Feb 2001 23:23:20 -0500
Message-ID: <3a88b908_1_at_news1.prserv.net>
Jan Hidders wrote:
> Ah, I think I am beginning to see your point. But I am not really sure
> what a "functional *in*dependency" is. Is it really the same as a
> multi-valued dependency? Note that the absence of a functional
> dependency is not the same as a multi-valued dependency. Can you give
> me a (formal or informal) definition of a functional independency?
It'll have to be informal ...
I'm thinking of non-key "a" (say, home_address) and non-key "b" (say, current_salary) each of which have a relationship to key "k" (person_identifier, say) but where the "a"'s relationship to "k" is different, and independent of, "b"'s relationaship to "k".
In other words, f(k) -> a, the function "f" which applied to an instance value of "k" gives me the current corresponding value of "a" is different (g(k) -> b) to that which gives me "b". In the earlier posting, I gave "f" the more meaningful name "lives_at", and "g" the name "earns".
> Just to get this straight. What I meant was that there are two
> functional dependencies 'name -> address' and 'name -> phone-number'.
> Are you really suggesting to split the relation just because these two
> functional dependencies are semantically different? (I hope you are now
> asking yourself what it exactly means to be 'semantically different'.
> :-))
My original example cited current_address and current_phone-number as the historically classical example of two attributes having the /same/ relationship to the key (v. current_salary with a very different relationship to the key) ... except that the surge in cell phones make that no longer true :-(
> ... because in standard normalization
> theory dependencies are anonymous. ...
On the face of it, I'm not sure I accept this, but I probably need to think about it a bit. On the face of it "dependency" implies a relationship between (at least) two things which I would think requires each end of the relationship *and* the relationship itself to be well-defined to be able to work with it all. Please feel free to explain what you meant ...
And, to come full circle, I long ago accepted the above "f" v. "g" formulation of 4NF as equivalent to the Date version (which, to be honest, worries me a bit 'coz it seems to use far too many words for what is supposed to be a formalism rooted in mathematics). To try to connect the two: If two non-key attributes have different relationships to the key, then we have an MVD situation and resolve it by splitting 'em apart!
Also, FWIW, I vaguely recall formualtions of the other NFs with similar notation to what I've offered for 4NF.
> > Actually, I think far too little time is spent promoting the need to
> > *strongly* define the elements before even thinking of normalisation.
> > Since normalisation is ultimately an attempt to objectively decode
> > the attribute definitions and what they mean in the way one attribute
> > relates to another, I think that *that* is *really* "where it's all
> > at".
>
> I'm not sure I totally agree with this. In an ideal world you only can
> start normalization if you already know exactly what the relationships
> between the attributes are. On the other hand, when normalizing you are
> making (more or less) these relationships explicit in the table
> structures, ...
I see this as the "science" of normalisation. And it can *only* embody the *facts* formulated in the definitions of the data attributes and their relationships.
> ... and seeing them that way may lead to more insight into what
> these relationships exactly are. But perhaps that is what you mean.
And this is the "art" of data modelling, the *really* stimulating part, the part where I get to sate any creative tendencies I might have :-) ... and, dare I suggest, the bit that comes with experience? It's where we compensate for the eternal imprecision of the human language(s) in which the definitions are originally formulated.
For example, if I see a table at the "many" end of a one-to-many relationship, I *start to suspect* that I've missed another hanging off the other side. That is, I tend to expect tables with either zero or two *only* "many" ends connected to them (well, at least by the time I get to 5NF!?). And from this observation, I may (or may not) be able come up with questions to assert it as a legitimate circumstance ... *or* I may identify something that was missed in the original. With that latter insight comes a rework of the definitions, and the justification for refining my normalised model.
HTH ... Barry J. Received on Tue Feb 13 2001 - 05:23:20 CET