Re: Base Normal Form

mAsterdam wrote:
> Nice to hear from you :-)
>
> 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.
> >
> > 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.
>
> There is a function for every candidate key. That is the somewhat
> confusing difference here, no?

Not to me. It is easier for me to teach and to view multiple sets of candidate keys as multiple functions as well. When you teach someone how to determine a candidate key, you typically teach it by describing a function anyway. You can use language such as primary and alternate functions if you like.

> [snip]
>
> > Every database relation, if defined to require a candidate key, can
> > then be modeled as a function. Yes.
>
> So "a function" here should be /functions/.

It can be modeled as many relations as well since a database relation has unordered columns and a mathematical relation has them ordered. If you model with a function (of your choice) you need not additionally talk about having a candidate key -- your mathematical model incorporates this database concept.

Sure you can model with a mathematical relation and then talk about some other concept of a candidate key if you prefer, but I prefer to have a nice clean mathematical model that is so easy to understand. I suspect that most people who have not done any data modeling before will have an easier time with the concept of a mathematical function than the concept of a mathematical relations. Talking about input-function-output is also very intuitive. All digital data are stored in functions if they are to be retrieved again.

Additionally, the concept of a foreign key pops right out as a function mapping an attribute of one function to a "key" (by whatever name you like) of another.

All models are flawed, of course, but some are useful (George Box?) and I have found that modeling data as functions (relations with candidate keys) as well as modeling processes/methods/functions as functions aligns very well with how people think.

I don't ever model data in the abstract, but only in the context of one or more applications. Rather than a data vs process mindset, I see these as two sides of the same coin and showing how cleanly data is modeled with functions help with that wholistic approach.

I doubt I said that very well and anyone reading "wholistic approach" might jump in with discussions of decoupling (and I have opinions about that too but I'm headed to the big city for the weekend, so too-da-loo for now.) Cheers!
--dawn

> [snip]
>
> > 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.]
Received on Fri Jul 08 2005 - 18:18:23 CEST