Re: database systems and organizational intelligence

"Laconic2" <laconic2_at_comcast.net> wrote in message news:vM-dnfgxwLmtOCndRVn-uQ_at_comcast.com...
>
> Having said that code and data have some things in common, I think it's
> important to note how startling the differences are:
>
> All of the best descritpions of the parsing of code that I have seen break
> code down into a tree structure. All of the best descriptions I have seen
> of the structure of data break data down (or assemble it) into a
> relational structure. I know you differ with me on this last point.
That's
> an ongoing difference between you and me.

Is it possible this description is more structural than germane? A simple example: an A/P check that pays our utility bills. It is data. It has properties. It was created by code under the auspices of business rules using other data. To describe its storage structure may or may not describe what it is, what it's used for, how it was created, how it relates to my bank balance, and a myriad other business functionality. On the other hand, its storage structure may offer some insight to its nature.

> In order to work meaningfully with data from a relational perspective,
it's
> first necessary to put it into "normal form" (generally called "1NF").
> Some people in this forum are adamant that unnormalized data is
> "excommunicate and anathema". That's too doctrinaire for me. But I'm far
> from accepting your challenge that the RDM is doing more harm than good to
> IT.

Don't you think this is true only insofar as describing how one _can_ store it and retrieve it? So, the RDM is a perfectly acceptable model for its limited functionality, but by no means the only acceptable model. I sense it looses some desirability when it distracts from its primary function.

> No one has, AFAIK, done a good job of reducing code to a "normal form".
The
> closest thing, afaik, is the metadata that describes triggers and
> constraints.

An astute point! I guess the RDM is, therefore, not the end-all for describing data structure and storage. :-)

Bill Received on Sat May 29 2004 - 15:23:29 CEST