Re: Base Normal Form

Gene Wirchenko wrote:
> On 12 Jul 2005 02:57:08 -0700, "dawn" <dawnwolthuis_at_gmail.com> wrote:
>
> [snip]
>
> >It is easy enough to model a database relation with a set theory
> >relation, so this is not a problem, but when db relational theorists
> >get all preachy on this unordered point, it amuses me.
>
> Be careful about that amusement. Sometimes, it is because the
> other people know more about the situation than you do. Surely, you
> have heard the saying "Ignorance is bliss."?

I'll grant that my amusement could be due to ignorance. Will you grant that it might not be? I would suggest my amusement has more to do with an interest in watching how language is treated. When a relational theorist insists that columns be unordered, it is due to using a different definition of "relation" than what a mathematician uses, right? Do you think I am ignorant of the change in the definition of "relation" between mathematics and relational database theorists, ignorant of the reason that the change was made, ignorant of just how important it is to avoid logical ordering of logical columns, or what? I have learned a lot from this list and don't plan to stop learning, so please set me straight on this one, Gene.

> [snip]
>
> >So, remind me, what precisely is the problem with ordering the
> >attributes in relations? It results in ... because ... ???
>
> If you say that the ordering is significant, then
> (a,b,c)
> and
> (a,c,b)
> are different. If you go purely by the name, they are the same. (I
> have omitted the types for simplicity. Assume that they are the
> same.)
>
> This does not look like much, but consider a join. Now, you have
> to define which order the columns are in the join. Make sure you do
> it right, or you could end up with A join B and B join A resulting in
> different orderings.

I don't say that ordering is significant AT ALL, but I do say that using the term "relation" and then insisting that tuples be unordered is redefining the term, thereby muddying terminology and notation unnecessarily, in my opinion.

> [snip]
>
> This is rather basic stuff, Dawn. You claim to have studied the
> material. Is your axe not ground enough yet?

You aren't reading me quite right yet, brother. I have no axe to grind; I have problems to solve. One of them is how to build bigger-bang-for-the-buck software. I have several interests in this regard. One area is the way that data are modeled from user interface to persistence interface and everything else (e.g. validation, constraints, business rules).

There are reasons for decisions that have been made in defining relational theory and reasons why so many people use SQL as the api to persisted data. But are there times when using the same model of data throughout an application might be a good idea, rather than using a different API and different models for the UI and the database? If so, what are our options for how to model these data and what are the pros and cons of each? These questions and more...

Sifting out the best practices (such as discussions of "functional dependencies") from the religion in relational theory (such as the most common defs of 1NF taught to our college students) is one approach I'm taking. Every time there is a term with multiple definitions, particularly if the defs are mutually exclusive, I might initially be frustrated, but eventually I settle on "amused," perhaps as a coping strategy.

But I will admit that I have more questions than answers. smiles. --dawn

> Sincerely,
>
> Gene Wirchenko
Received on Tue Jul 12 2005 - 22:41:28 CEST