Re: Base Normal Form
Date: Sat, 09 Jul 2005 04:11:22 +0200
Message-ID: <42cf324a$0$93322$e4fe514c_at_news.xs4all.nl>
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?
>
> 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.
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/.
>
> It can be modeled as many relations as well since a database relation
> has unordered columns and a mathematical relation has them ordered.
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.]Received on Sat Jul 09 2005 - 04:11:22 CEST