Re: Role of functional dependencies in database design

Op donderdag 12 februari 2015 22:43:24 UTC+1 schreef Nicola:
> In article <>,
> Erwin <> wrote:
>
> > My question, and what I would like to understand is : what exactly is the
> > available input (its semantics and in which possible syntactic forms does it
> > appear, and where) that allows this "discovery" to be made ? I think JKL's
> > post where he used the word "pesky" expressed the very same concern.
>
> Formally, FDs are axioms. As such, *within* the formal system they are
> given facts, but the discovery must happen *outside* the formal system.
> Hence, the available input cannot be described formally (or, if it can,
> it will be in a different formal system that will have its own axioms).
>
> You don't have any difficulty with the process of "discovering" keys, do
> you? I don't see the process of "discovering" other constraints as
> intrinsically different.
>
> > >
> > > >> 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
> >
> > Well, there you have it. If you think that this sentence indicates an FD
> > {L,T} -> {room}
>
> Of course not.
>
> > The correct conclusion here is the FD {room,T} -> {L}.
>
> Yes.
>
> > But before spotting
> > that, I first had to twist the requirement into "only one lecturer can be in
> > any given room at any time". Or "if two observations of a lecturer being in
> > a room at time T, both involve the same room and the same time T, then they
> > involve the same lecturer". But (knowing what the FD turned out to be and
> > looking back on the natural language formulation) I find those alternatives
> > only slightly less convoluted than your original.
>
> I said not to take this example too seriously ;) The point of a
> hypothetical specification in natural language is that you should not
> bother with the mathematical formulation of the corresponding FD,
> because the system would take care of it. My example may fail miserably
> in being higher level compared to the corresponding FD, but that does
> not mean much. If you had a program that takes as input the sentence "no
> two teachers can teach in the same room at the same time" and outputs
> the schema Teaches(room, time, teacher) with key {room, time} as
> output, would you be satisfied? :)
>
> Nicola
>
> --- news://freenews.netfront.net/ - complaints: ---

I probably would.

For what it's worth : "no two teachers can ..." immediately makes me think of a certain RENAME/JOIN combination that then in turn immediately makes me conclude "aha, a key".

But my mental process in that regard is probably heavily influenced by the work I've done on constraint enforcement. Give me a database [design] and I immediately start looking for all possible [data] faults (and their defining relational expressions). But somehow for keys, that's not the process I follow. I just wonder "what makes this thing unique". It's probably just too deeply instilled, but it works without FDs. Received on Thu Feb 12 2015 - 23:11:07 CET