Re: database systems and organizational intelligence

From: Dawn M. Wolthuis <dwolt_at_tincat-group.com>
Date: Wed, 26 May 2004 10:27:52 -0500
Message-ID: <c92d2o$q00$1_at_news.netins.net>


"Laconic2" <laconic2_at_comcast.net> wrote in message news:vM-dnfgxwLmtOCndRVn-uQ_at_comcast.com...
>
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> news:c92552$lnf$1_at_news.netins.net...
> > Also,
> >
> > A user querying "the data" need not know whether the vocabulary they are
> > using is for stored data or derived data (user-defined function, for
> > example).
> >
> > Data are stored in functions (any relation with a candidate key can be
> seen
> > as a function) and code is based on data and functions.
> >
> > Code can be stored as data, just as any document can
> >
> > Data is used to specify code (such as in a declarative language)
> >
> > Metadata is code or specifies code and is, as the word suggests, also
data
> >
> > Business Rules specify code as data
> >
> > The biggest difference I can see is that stored data (including Rules)
> have
> > both IT professionals and end-users as stewards of that data, while most
> > other data and code have only the IT professionals as stewards.
> >
> > Otherwise, code and data seem to be two sides of the same coin.
>
> 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.

Perhaps there is a clue, a sign, a hint in there somewhere ;-)

> I know you differ with me on this last point. That's
> an ongoing difference between you and me.

Yes, but you still seem to be reasonably intelligent anyway, and one flaw doesn't alter my perception.

> 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.

2nd & 3rd normal forms have moved the industry forward. But then we put it in a strangle hold (I've never put those two words next to each other before, so I hope that gives the right picture)

> 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.

Functional dependence, one helpful aspect of relational theory, is very much a part of discussions about coupling and cohesion, right? The word "functional" is another clue that when we are working with data, we are also working with functions. Data + Functions = Code? (all terms would need to be more precise for that to be meaningful, I realize).

>
> I also have some comments on "stewardship", but that's another story.

I first used the term "trustee" instead of "steward" -- would that be preferable? --dawn Received on Wed May 26 2004 - 17:27:52 CEST

Original text of this message