Re: Newbie - what's all this BCNF stuff anyway?

Seth Brewer wrote:

> I know that was defined in the beginning, but I have found myself in the
> postion where a client has assured me something like "We will never have a
> teacher teaching more than one subject." Then, a week later that very same
> person says "I was trying to enter Prof. Jones as a Math teacher and a
> Science teacher, but I keep getting some kind of error." This is usually
> just after the database has been populated with a few hundred thousand
> records or so and hours have been spent on front-end coding.

That's a problem with the front-end design process -- differentiating between what the client wants and what he needs.

If you give them what they want, even though it's what they ask for, you still take the blame if it's not what they need.

> I've been doing some extensive searching on google and read a whole lot of
> stuff. One thing I've noticed which I find interesting is that nearly every
> article I've found relies heavily on IDENTITY columns in their examples.
> It's seems that if Celko's statement...
>
> "Then along comes the relational model. It is based on sets; a set is a
> completed whole, without any ordering to it. No sequences! Very abstract!
> Programmers did not know how to cope, so the vendors exposed the physical
> implementation [IDENTITY column] and called these things "features" and
> locked their products to particular architectures."

I think there may be some element of truth to this, but it also trivializes and dismisses a lot.

> ...is true (and I have absolutly no reason to even sugest that it isn't) we
> seem to have gotten to a state where even if the IDENTITY column could be
> physically removed from [insert common dbms here], the DBA at large would be
> lost without it.
>
> So this is where I am after all this:
>
> 1. I have to buy a book. Probably one by C.J. Date(?) which includes a whole
> lot about BCNF, normalization algorythms, and decomposition.

Date's book is great, of course. I also like the Elmasri & Navathe book, and have taught using it with good results. It's less rigorous than Date, and therefore more readable. But Date is more of the definitive source. And Celko's "Data & Databases" is also a good read.

> 2. I'll try to avoid the use of IDENTITY columns whenever and wherever I
> can.

And at the risk of sounding like a programmer who doesn't know how to cope, there are a lot of good reasons to use them (but they don't justify overusing them).

> 3. I'll hang out in this newsgroup a lot.

I'm not very active here, but I do read this ng all the time. There are some very good people here whose stuff is always worth a read.

> 4. I'll buy more coffee.

Goes without saying.

Larry Coon
University of California
larry_at_assist.org
and lmcoon_at_home.com Received on Mon Nov 25 2002 - 18:46:23 CET