Re: Normalization by Composing, not just Decomposing

From: Dawn M. Wolthuis <>
Date: Fri, 9 Apr 2004 16:03:28 -0500
Message-ID: <c5733q$n47$>

"Jan Hidders" <> wrote in message news:gKldc.65103$
> Dawn M. Wolthuis wrote:
> >
> > Do you HAVE a description of any type of normalization or other data
> > modeling theories related to PICK?
> That's what the Arenas & Libkin paper was. I know the math is tough but
> that's to a large extent because normalization in such data models is
> inherently more complex then in the relational model.

OK, I read it rather than skimming it and I have a few parts where I'm not tracking with the notation, but I mostly followed the mathematics this time, and this does take care of one aspect of what I care about -- thanks!

> Explaining it in
> detail would take more time than I have. If you want things to be
> simpeler then I suggest you stick to the NFNF relational model. See, for
> example:
> although that is not a very good paper, but it contains more references
> if you want them. If you can find them look at the Fischer and Van Gucht
> paper, and the Roth, Korth and Silberschatz paper.

Yes, I have read at least one such.

> And if that is too dificult for you,

Don't mis-diagnose laziness ;-) .

> just stick to the usual
> dependencies (functional, multi-valued, join), which would basically
> mean you are just dealing with the good old flat relational model. Or,
> for starters, perhaps even just the functional dependencies.
> I had the impression from you attempted formalization of your
> denormalization rule, that this is what you were doing anyway. I just
> hope you realize that this is just a very tiny tip of a really huge
> iceberg. .. I'm sure you can come up with a nice pun on the word "pick"
> here somewhere .. ;-)

There have been plenty of those over the history of PICK (including one of my favorite names for a book -- The PICK Pocket Guide)

Yes, agreed on the iceberg. PICK is not a "database management system" per se, doesn't have strong typing nor declarative constraints and just plain doesn't follow many of what are assumed to be best practices for a database system..

> > But there is nothing that tells you to put them back together, right?
> > can obey all the rules of normalization and have a set of N resulting
> > relations when someone else also has a normalized set of the same
> > but with N-500 relations, right?
> Only if you normalize in a very naive way, i.e., splitting off offending
> FDs one by one. The usual algorithm that gets you to 3NF in one step
> (the one using the minimal cover) splits as little as possible. See for
> example sheet 46 on:

Another good link -- thanks! --dawn Received on Fri Apr 09 2004 - 23:03:28 CEST

Original text of this message