Re: Normalization by Composing, not just Decomposing

"Jan Hidders" <jan.hidders_at_REMOVETHIS.pandora.be> wrote in message news:gKldc.65103$2I5.4217884_at_phobos.telenet-ops.be...
> 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:
>
> http://citeseer.ist.psu.edu/ozsoyoglu87new.html
> 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?
You
> > 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
attributes
> > 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:
>
> http://cs.ulb.ac.be/cours/info364/relnormnotes.pdf

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