From my step dad. Some thoughts on information processing versus the
structure of information. Insightful. Interesting.

With an example related to normalization.

---------- Forwarded message ----------
Date: Thu, 21 Mar 2002 12:59:00 -0500
From: WaltWoolfolk
To: cdent@burningchrome.com
Subject: Re: [Fwd: [PORT-L] Naming and "Robust" Hyperlinks [was: [PORT-L]
    Available  PORT              tools] (fwd)]


Had no response. It's odd how some ideas don't compute, don't register,
never make it past the eye or the ear at all, unless they're already there
in the brain in some way. For example, Murray likely would immediately
apprehend the doctrine of strict uniqueness, but the authors of "robust"
hyperlinks, even right after reading it probably don't have a memory of it
- it's so foreign to the process-mind it never even registers long enough
to to be thought about.

I didn't realize even you had not understood it correctly until now. As
good a thinker as you are, you might become an even better thinker,
particularly about information systemics, if you were to deliberately
cultivate a more balanced position on the process/structure spectrum.
Suppose there is a thinking spectrum and one of its dimensions is
represented by the ability to mentally accurately represent processes, at
one end, and structures, at the other end of the spectrum. That is, If the
real world really does manifest both, then it is smart to learn to see
both, if one can, in the interest of better systems design. The information
'processing' industry within which you learn and work has always had a
strong process bias. Like racism, anyone who remains in the field for very
long gets saturated by it. You learn and work within a field that
systematically selects for people who are really good at one thing. One has
to conciously educate oneself more broadly in order to see the world more
completely. In this case, it means paying attention to the static structure
of information in addition to the processes that can operate on that
information.

A not un-common error in trying to learn normalization theory and, by
implication, in trying to teach it (including in some textbooks), is to
take a process approach to it. Possibly this is what you are experiencing.
The definitional scheme Codd chose for the normal forms supercificially
suggests a process:  we start with 1NF, then 2NF is defined as 1NF plus an
additional constraint, 3NF as 2NF plus an additional constraint, and BCNF
as 3NF plus an additional constraint. This form of definition, often used
by mathematicians, was not meant and does not work as a way to do
normalization. There is no real or implied process in the form of the
definitions of the normal forms. One does not (successfully) design a
database by first modeling the information in 1NF, then successively
adjusting it to 2NF, 3NF, BCNF. Rather, the idea is to model the structure
of the information directly in BCNF. When attempting to convey what BCNF
means, sometimes it's better to start with the fully expanded version of
the definition, with no embedded names of definitions of 'lower' forms. The
non-procedural approach to normalization bypasses the need for experiece
with data retrieval. Non-programmers can learn it as easily or more easily
than programmers. The same thing applies up to a point with the relational
operators. They are used to inform the SQL parser what set of information
is needed and the parser figures out how to get it from the underlying
physical records and files.

Does it grok? W