Re: Base Normal Form
Date: Fri, 08 Jul 2005 22:42:27 GMT
Message-ID: <njDze.140582$cB4.7393318_at_phobos.telenet-ops.be>
dawn wrote:
> Jan Hidders wrote:
>
>>dawn wrote: >> >>>Jan Hidders wrote: >>> >>>>It's really not a good idea to confuse the concept of >>>>relation and function. >>> >>>I definitely agree! >> >>And yet that seems to be the consequence of what you are proposing. I >>could be wrong but I interpreted your suggestion as that every relation >>with a candidate key is a function.
>
> Yes, that is what I am saying, but I'll try to say it better.
Ok. That might well solve it because basically my point was that your terminology was too sloppy for my taste.
> Every database relation can be modeled as a mathematical relation.
Agreed. From a mathematical point of view it doesn't make much sense to
> Every database relation that has a candidate key can be modeled as a
> mathematical function as well.
Sure. But let me emphasize once more that *every* database relation has at least one candidate key. This is not up for discussion, it's a simple mathematical fact. I suspect that the case that you are overlooking is the one where that candidate key happens to be the set of all columns, in which case the function you would associate with it is probably the function that maps each tuple to itself.
>>Since every relation has at least >>one candidate key
>
> I don't have a handy list of all definitions of "relation" handy, but I
> thought that some such definitions did not require candidate keys,
> although I suspect most modern ones do.
It doesn't have to be required, it usually follows from the fact that the relation is a set.
I have no problem with statements like "I can model every relation with a candidate key CK as a function that maps a value for the CK to a tuple of that relation". But for me that is very different from saying that the two concepts are the same. Such a formulation also does more justice to the fact that there might in fact be several candidate keys which all define different functions.
> In spite of the fact there are different definitions for "database
> relation" and "mathematical relation" I still think it helps to teach
> the basics of data modeling by starting with language,
> deriving/creating appropriate predicates and corresponding tables, then
> modeling these as functions. Functions seem easier for people to grasp
> than relations, so I start with sets & functions.
I've heard similar arguments before from people who think that when you explain normalization you should first explain things under the assumption that there is only one candidate key. That one-key assumption also seems to be hovering in the background of your terminology. In my experience there is always a backlash once you get to the 3NF and BCNF because there you have to deal with more than one candidate key. That means that the student then has to make two big conceptual jumps at once: understanding >1 cand. keys, and BCNF.
Note by the way that the link between functional dependencies and interpreting relations as functions is very close. If the relation R(A,B,C,D,E) has the dependencies AB->C and BD->E and ABD->C the I wouldn't say it represents a function, I would say it represents three functions.
- Jan Hidders