Re: data & code
Date: Thu, 27 May 2004 15:25:34 -0500
Message-ID: <c95is9$foa$1_at_news.netins.net>
"mountain man" <hobbit_at_southern_seaweed.com.op> wrote in message
news:W2qtc.13719$L.2694_at_news-server.bigpond.net.au...
> "x" <x-false_at_yahoo.com> wrote in message
news:40b60683$1_at_post.usenet.com...
> > "Alfredo Novoa" <alfredo_at_ncs.es> wrote in message
> > news:e4330f45.0405270706.27fe875a_at_posting.google.com...
> > > "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> > news:<c94fck$sls$1_at_news.netins.net>...
> > >
> > > > 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 Received on Thu May 27 2004 - 22:25:34 CEST