Re: Base Normal Form

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.

Every database relation can be modeled as a mathematical relation. Every database relation that has a candidate key can be modeled as a mathematical function as well. David asked about tables, which imply a column ordering and (perhaps) are more lax about typing. A table can also be modeled with a mathematical relation. Unlike a database relation, a mathematical relation does have (column) ordering in (row) tuples. A table with a candidate key can be modeled by a function as well. A table in "Base Normal Form" is one that can be modeled by a function.

> 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. If every definition of a database relation requires it to have at least one candidate key, then all database relations, but not all tables (which do not have such a requirement), and not all mathematical relations can be modeled with mathematical functions.

> that means that every relation is a function according
> to you. And yet, at the same time, you say:

Every database relation, if defined to require a candidate key, can then be modeled as a function. Yes.

> > A function is a specific type of relation where a
> > relation might not be a function at all.

Every mathematical function is necessarily a mathematical relation.

> So you seem to be contradicting yourself.

Did that clarify? Does it make sense? Do you accept it?

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 suspect that is what David is getting at when talking about "tables in base normal form". It's just a function, brother. ;-)

It isn't hard to comprehend the differences between a mathematical relation and a relation as defined by the relational database community, although I'll admit it can be confusing. If I explain data modeling to somone not predisposed to talk about "relations" then I can just talk about sets and functions and they get it. A function takes in a URL and gives you a web page. It takes in a state abbreviation and gives you a state name. It takes in an SSN and gives you a name. It can be thought of as a set/object as well as a function/actor.

Then we can add in operators (which are, of course, functions) and types (sets) and move on to logic (two-valued, please!).

[Then temporal matters and metadata discussions and so on. After that we can discuss where the real complexity comes in -- with data stored in a human language, determined, entered, searched for, and interpreted by humans.]

Cheers! --dawn

> -- Jan Hidders
Received on Fri Jul 08 2005 - 05:37:52 CEST