Re: 4NF is Where It Is At! [WAS Re: 1:1 relationships]

From: Barry <BarryJJ_at_ATTGlobal.Net>
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 :-(

When I teach normalisation (my understanding of it, at least ;-), I'd cite the (historical, again) example of a friend who moved across the street, changing address *but* able to retain the original phone# since he was still connected to the same switch. This leads to interesting discussions (well, for me at least!) on the importance of data definition, the nuances it might embody, and how it plays out during normalisation ...

> ... 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 ...

In the meantime, I can't help but feel the real issue is the branch of mathematics used to state the proposition. And that was my albeit-gratuitous reference to relational algebra v. relational calculus. As I remember it, you can state the same thing either way but that might not be obvious to the casual reader given the different notational styles of those mathematical branches.

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

Original text of this message