Role of functional dependencies in database design

So, the question is: what is the role of FDs (and possibly other types of dependencies) in database design? My personal take:

In general, I don't think that it is possible for them to inform the design activity since the early stages or that they should be used as the main design tool. I do think, however, that when a system is understood sufficiently well (e.g., by means of a conceptual design), they offer an aid (are my schemas well-designed according to certain criteria?) and insight (allowing us to possibly find alternative ways to design a database, for example).

>> Nicola wrote:
>> 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.

> Erwin wrote:
>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" ?

At an early stage, you probably cannot say: it might also be that desert island and can opener should be represented as two relation schemas (for which we have identified no attributes yet) related through a one-one or one-many relationship. My point here is simply that FDs are not invented, they are discovered.

>> FDs are a special type of first-order formulas. I can imagine >>
defining
>> an English-like syntax for them.

(Not that it would necessarily be a good idea, I should add.)

>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."

Well no, like this certainly no :) Maybe something along these lines (paraphrasing the given-when-then constructs existing in some testing tools):

given two lecturers L1 and L2 and a time T when L1 is teaching at time T and L2 is teaching at time T then L1 and L2 are in different rooms

(this is absolutely off the top of my head: don't take it as a serious attempt).

>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.

Could you provide a small example?

Nicola

• news://freenews.netfront.net/ - complaints: news_at_netfront.net ---