Re: data & code

"mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message news:40b659c1$0$561$e4fe514c_at_news.xs4all.nl...
> Dawn M. Wolthuis wrote:
> > mountain man wrote:
> >> x wrote:
> >>> Alfredo Novoa wrote:
> >>>>Dawn M. Wolthuis wrote:
> >>>>>Very good. So, mountain man's "Organizational Intelligence"
> >>>>>is the set of all data?
> >>>>It is the set of all the bytes in the hard disk :-)
> >>>Or perhaps the bits in all devices, wires, media, brains, etc.
> >>>in the past, present and future ? :-)
> >>The theory is restricted to "computerized OI" but you raise an
> >>interesting issue introducing time. You see, the current theory
> >>assumes the relationship between truths in set theory (RDBMS
> >>storage of data) and the truths operationally engineered between
> >>this data and the external world (via a user interface).
> >>
> >>In time, the world changes, and without doing anything, the
> >>data at the heart of any implementation instance of the relational
> >>model, loses its integrity, because there is no dynamic built into
> >>the fundamental (RM) model.
> >
> > This is a bit of a tangent, but quite related to your thought above -- I
was
> > just going back to what I thought were the basics a few decades ago,
> > including use of Master files, Transaction files, History files, and
others.
> > In any post-transaction logs or history files, data from the Master was
> > often DUPLICATED on purpose. This makes complete sense in that the
Master
> > has information at that point in time and can change and we want to have
a
> > record of the actual transaction as it took place. I think some of this
is
> > lost on newbies who are blindly applying normalization techniques, not
> > recognizing that data in "Master Profiles" (to update the term) is
dynamic,
> > while data related to "Transaction Documents" must duplicate that data
at
> > that point in time in order to preserve it for analysis and accurate
> > historical information.
> >
> > Is there anything within relational theory that addresses this other
than
> > hoping that the designer will recognize the difference between the term
> > "Marital Status" in the Master files and the same if important
information
> > related to a transaction? Is there even any way to partition types of
> > relations into, perhaps updated versions of, Master, Transaction,
History,
> > ...? --dawn

>

The above does look interesting.

Another approach is testing the integrity of the data by engineering comparisons between elements of data held in the organizations database and independent *reliable* sources or authorities.

Potential database update streams may thus be indentified.

Pete Brown
Faslls Creek
Oz Received on Fri May 28 2004 - 18:38:52 CEST