Re: Base Normal Form

dawn wrote:
> mAsterdam wrote:

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

Hm... I was with you until the last sentence. I never liked the "primary key" thing. It forces an arbitrary decision at a time when you really don't know enough yet.

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

Ah the "naming" trick. It takes care of associating values to the right part of the header - and it invites language.

This is the schism point of database and set theory.

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

In my experience: yes.

> Talking about
> input-function-output is also very intuitive. All digital data are
> stored in functions if they are to be retrieved again.

Here we differ. The notion of storing something in a function seems alien. A function to get something (return it) - ok. A function to set something - state, side effects come to mind. A function to store something in. Huh?

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

Same here. (Holistic this side of the pond)

[snip]

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