Re: Base Normal Form
Date: 12 Jul 2005 02:57:08 -0700
Message-ID: <1121162228.113616.139680_at_g14g2000cwa.googlegroups.com>
mAsterdam wrote:
<snip>
> >>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.
Most modeling in the early stages results in the modeler identifying a primary key, whether or not that is an implementation concept in the target database. Web pages are all stored with a primary key (the URL) and all those tabbed paper folders that are still used at (most? all?) doctor's offices and elsewhere have a primary key. It might even be more awkward for people to consider all CKs equal than to think of one as the primary "lookup" key. And, yes, I'm "mixing" process and data again ;-)
> >>[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.
Using language for headers is fine and dandy, but if you have a model that permits synonyms, first giving each attribute a unique ordinal and then redefining the ordinals can be useful at times. Dutch and English numbers are the same, for example. The similarity of one relation to another is evident when naming the attributes with numbers. Only naming them with numbers would be poor form, however, and in most SQL-DBMS tools, it is a bad idea to create your table with attribute names that are numbers.
But the fact that there is application software in production today that includes attributes that can optionally be identified in the software with an ordering is not a bad thing. Having a logical order to attributes (such as the order in which the attributes are listed in a CREATE TABLE statement) must have some consequences of which I am not aware given all of the blanket statements about how awful it is.
Perhaps the issue is in implementation? What happens when we rename the attribute "3" to "2"? That is likely where the concerns come in. Is that just like renaming the attribute from LAST_NAME to lastName or is the implementation model tied to the ordinals in the logical model? I work with an old model that does tie the logical model to the implementation model, which many of us have been taught is a bad thing. But I can see no problems at all stemming from this. This ordinal then becomes the only fixed "name" for an attribute and can have many other logical names, but you can't just change the ordering without changing the relation. And, surprisingly enough, the sky isn't falling ;-)
> > 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.
Storing? Who said anything about storage? [as my colleage, mAsterdam, might tell you ... laughing]
We model data throughout our software applications -- in the UI, in the db schema, in rules, with all messages. I don't care about storage, but I care about the API to whatever services I need to use and the results they product. What functions do I need to call, passing in what objects and getting what results and data in return? I don't need to think in terms of creating a table, but in terms of using a service that makes the system remember information. What input do I need to send to what function to get the desired results?
In the case of a lookup function or a remember-this function, it makes sense to pass in a key that is matched with a value. Store this under this handle so I can get it back again.
> 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?
Storing & Retrieval oare sets and gets. The addition of the word "in" in that last one that isn't relevant. I don't model what the data are stored "in".
> > 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)