[BiO BB] RE: Normalization WAS: database design question

[Svensson, B.A.T. (HKG)]

On Tue, 2004-03-02 at 16:50, Michael Gruenberger wrote:
> I don't quite understand your reasoning: You claimed that normalization
> has no practical use and that is because it's hard to understand?!

That's not what I tried to say; Applying the theory makes things
more complicated then they are. In short: it's a waste of time
in everyday work.

Also my apologizes that I forgot to mentioning/stress my point:

I don't suggest to through out the baby with the water. By
no means /learning/ the theory is no waste of time, however
trying to /apply/ the theory in everyday work is a) a waste
of time and b) a misunderstanding of the concept to be used.

It might be a bit to though for a beginner to first start
out with these subjects, there are other things that first
better be learned (i.e. principles op pf programming, etc)
then the these issues will, in time, be solved by them self.

However the original question was about why normalization
equals a good design. As already stressed by Jordi, this
can't be held as a simple truth. 

Except for the answers already provided: high normalization
optimize storage efficiency and insert/update speed, while
low normalization address optimization of reading speed,
but makes inserts/update a more complex task.

Related with these problems is that any extreme normal from
will create difficulties on its own. To low and updates becomes
a night mare for a database programmer, to high and the very
most simplistic query approaches monstrous constructions.

I most case one needs to find a balance between these two
factors, because pulling toward one end will only create
problem in the other end. I think BCNF (Boey-Codd Normal
Form) tried to address these issues, but can't tell for sure.

However, this balance is found with experience (system stress
testing) and commons sense judgment - no data decomposition
course will teach you how top do this for a particular real system.

One way to work around this is to enforce a list of constraints
protected with a set of additional triggers in the database,
but even this has an tendency to make otherwise a simple data
model become a dinosaur in its implementation. And in addition
nothing comes for free a performance hit will be put on top
on this - sometimes it might be worth it, other times not.

There is no way to establishing what is meant with a good design.
This is depending on the project requirements, and in the end it
up to the designer and users of the system to judge on it.

In any case normalization theory wont tell you how to deal with it,
and at the end of the day it wont even tell you if you made any good
decisions what so ever.

> Normalization is not meant to simplify database design, but rather to
> formalise it and to give guidelines as to what works and what doesn't.


> I completely agree with Jordi, normalization just becomes part of your
> 'inner feeling' of what works and what doesn't after you've done it a
> couple of times. Of course it isn't applicaple in all cases, but it
> surely is better than no guidelines at all, especially for people who
> have never designed a database before and who are looking for some
> guidelines to point them in the right direction. And there are ways to
> explain normalization in simple terms and with good examples.

I do not object this.

> So if you are saying normalization hasn't got any practical use,
>  what would you suggest to a newcomer to database design?

To learn the theory, and then forget it.

Data decomposition can be taught from the the books, however
there is no book that tells you how to decompose a real problem
in general, since decomposition can be done in several ways fore
the very same data set, i.e. how to decompose is dependent on the
question you want to ask to the data set.

For a new comer, I do not think learning abstract things like
relational algebra and normalization theory is the best end to
start at. Programming and design is difficult as it already is,
mainly because it does not reflect the way we humans normally
solve a problem (that's why for instance programming is tricky
to learn in the first place).

But in any case; design&programming is a skill learned, and it
takes many years to get them. Nobody would suggest that anybody
can be a surgeon just because everybody can walk into the closets
store and by a knife - but it seams like most people believes
anybody can do database development just because the platforms
is available. That's is simply not the case.

So what do I suggest? Well, we all seams to tend to forget all
the difficulties and troubles we had to go through when we once
had to learn to learn to walk.

One may get oneself a good education, either by study your self,
or by formal education, and then add on some few years of practical
experience, or just buy the knowledge from somebody who knows how
to do it. That's my advice, because it does not exist a simple
way to learn these things in "24 hours" or "7 days" courses,
that's just a illusion.


> On Tue, 2004-03-02 at 15:29, Svensson, B.A.T. (HKG) wrote:
> > 2nd order tensors calcus in fluid mechanics is also "easy"
> > once you get used with the concept. However the difference
> > we talking about here is that tensor calcus is simplifying
> > the task of understanding the problem, while normalization
> > theory does not, rather the opposite.
> > 
> > Any student of computer science who has been forced to do
> > formal deduction with horn clauses know that this is the
> > most rigorous and silly way to conclude the most trivial
> > and obvious facts, and as a matter of fact normalization
> > theory is based on this kind of logical reasoning.
> > 
>