Is there reasonable disagreement on what 1NF, 2NF and 3NF mean? Or is
the variety of contradictory in-print definitions of Normal Forms due
to sloppy thinking, slopping writing, or plain old ignorance from
authors? Also, where can I find an accurate, concise (less than 3
sentences for each NF), and easy-for-any-IT-person-to-understand,
definition of Normal Forms 1 through 3?

My understanding of NFs 1 through 3 is as follows. I look forward to
being corrected--but hopefully in a polite, constructive, professional
manner. I'm leaving out any mention of relations and relvars here,
because I don't expect the typical IT person to know what those are
(although it can be argued, convincingly I think, that they should):

1NF:
1) No multivalued attributes (e.g. every attribute in every
tuple should be atomic)
2) No repeating groups of attributes are allowed (e.g.
SKILL_1, SKILL_2, SKILL_n are out)

Many common definitions I've read in books on database design miss
point #1 completely. Is that because #1 is not part of 1NF, because
the authors are "protecting" the reader, or because of author
ignorance on what it is for something to be in 1NF?

2NF:
1) Must already be in 1NF
2) Every non-key attribute must rely exclusively on the
key, e.g. no Functional Dependencies.

Here's something I really need clarification on. Is it the case, or is
it *not* the case, that 2NF "only applies" in cases where there is a
composite key? This is my understanding, but it may be dead wrong. If
so, I need to know sooner or later. I have seen this point glossed
over or missed by various authors, some even using the words "fully
dependent" when perhaps they should have used "Functionally
Dependent"; meaning they either don't know what a functional
dependency is, or they're trying to "protect" the reader (and that may
or may not be legit given the context and one's proclivities).

3NF:

1) Must already be in 2NF
2) No transitive dependencies. All non-key attributes must
rely exclusively on the key.

I would like some concise and clear definitions of functional and
transitive dependencies, because 2NF and 3NF sound similar to me.

Pet peeve:

I dislike the mantra, "the key, the whole key, and nothing but the
key" to characterize Normal Forms 1 through 3. What is evidently
intended as a helpful mantra seems to give a false sense of
understanding. I'm all about some mnemonics, but understanding must
preceed the mnemonic, right?

Finally, what are some good books out there on database design for
neophytes and experienced folks alike that gets the theory correct
while not getting mired in what relational databases *could* be. I
read a really great book by Fabian Pascal, the title of which escapes
me, which I need to go and buy--believe it had the word Practitioner
in it.

I want to be faithful to relational theory as much as possible while
getting work done with products currently on the market. I believe
Fabian Pascal stated that theory was immensely important for practice;
that it was not about a bunch of curmudgeonly academics bickering
about how many angels can stand on the head of a pin. Is he correct?
While it's essential that methodologists and theorists are out there
visioning what databases can or should be, practitioners have to get
projects completed with existing resources.

Thanks very much.

Dana

On Aug 7, 6:58*am, dana <dana_at_w... (AT) yahoo (DOT) com> wrote:
Start here:

http://www.bkent.net/Doc/simple5.htm


David Fitzjarrell

On Aug 7, 4:58*am, dana <dana_at_w... (AT) yahoo (DOT) com> wrote:
http://en.wikipedia.org/wiki/Database_normalization is about as good
as it gets.

<snip>

Screw that (a professional phrase) and get Tom Kyte's book.

Pascal is quite correct, but he has a tendency to blame the wrong
people, which comes off as elitist to me. For example, if you are a
practitioner, and you use a product that doesn't perfectly follow all
aspects of relational theory as he sees it, then it is your fault. If
he says anywhere anything about practitioners having to get projects
completed with existing resources, in a positive context, please point
out exactly where, so I can apologize appropriately. It could be I've
missed something he's said since he pissed me off decades ago with
this, by berating some poor schmuck online who certainly didn't
deserve it.

First thing that comes up in google fabian pascal practitioners:
http://www.wilshireconferences.com/i...ews/pascal.htm

Then there's this gem: http://www.dbdebunk.com/page/page/1464397.htm
Be very careful, your preexisting views will color that one.

jg
--
@home.com is bogus.
http://www.usn-it.de/index.php/2009/...py-pool-empty/