Re: Fails Relational, Fails Third Normal Form

Op donderdag 12 februari 2015 10:52:57 UTC+1 schreef Nicola:
> From the requirements? I'm not sure I grasp what your point is.
> Do you mean that turning some requirements into FDs is difficult (you
> would not be alone: Stonebraker says that "mere mortals do not
> understand FDS")?

He's right.

> Or that FDs (and even MVDs, JDs, etc) comprise only a
> tiny fraction of real system's set of requirements, so it's not worth
> bothering?
>
> > It reminds me of a joke my Economics professor told the class about
> > three professors stuck on a desert island devising a way to open a can
> > of beans. The Economist's solution was simple, "First, assume a can
> > opener".
>
> FDs do not come out of void, they follow from your requirements. They
> are just a formal version of a very special (and relatively simple) type
> of requirement. I don't arbitrarily decide to assume that {desert
> island} -> {can opener}, unless you tell me that there cannot be two can
> openers in the same desert island, in the world of desert islands you
> are interested in.

There you have it. When people tell you "there can only be one can opener on any given desert island", then what do you see ?

A table {desert island, can opener} with (a.o.) a key "desert island", or A relation schema of whatever set of attributes in which you must add the FD desert island -> can opener ? Where this then tells you "the identity of a desert island is a determinant factor to the identity of the can opener that is on it" or "the relation over {desert island, can opener} is a function from desert island to can opener" ?

Some would call the former "jumping to conclusions". I doubt I'd join that crew.

>
> > On second thought, though, it's cause for optimism. If a Ruby script
> > and a grad student can generate a correct design, then it is a
> > tractable problem.
>
> Computationally, database design problems are (highly) intractable in
> general. But in practice many problems can be solved. For example,
> finding the keys of a schema (given the FDs) is an inherently hard
> problem, but for schemas with up to a few tens of attributes or so, only
> in few cases you are not able to find them in a reasonable amount of
> time. On the contrary, finding all the minimal covers is much less
> practical, even when there are not many of them.
>
> > What remains is a convenient syntax for capturing
> > the "pesky FDs", something that is the purview of academia.
>
> FDs are a special type of first-order formulas. I can imagine defining
> an English-like syntax for them.

Hmmmmmmmm.

"The projection on {desert island, can opener} of the join of all tables in the database, represents a function from desert island to can opener."

I've never seen anything like that, certainly not in requirements, and certainly not coming from the average user population that is supposed to produce them ...

And besides, avoiding redundancy was only a relevant topic in database design as long as there were no feasible ways to control the redundancies, e.g. via ASSERTIONs. Those days are gone. Received on Thu Feb 12 2015 - 12:57:50 CET