[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Archiving information within databases
Mr. Wood,
I'm having a problem with the notion that a dynamic database while
dynamic is not a record while a "fixed" database a record. The data
base is "fixed" at every intermediate state until a data field changes
and the data base assumes a new fixed state. Why is the final fixed
state a record and the intermediate fixed states are not? Why would
the final fixed state become the record when the important information
(historical) might be (for example) calculations of rate or direction
of change in certain data fields or the correlation of change in two or
more data fields? Seems to me all the final fixed database is is
one snapshot at one instant of time one could call "the end." However,
the database itself does not give any context or structure. One cannot
tell from the database, for instance, why the data fields were chosen,
how the data was collected, how the data was entered, what caused changes
in the fields, how the data was analyzed or how it was presented.
Even if one had snapshots of the database at all given states why, or better
yet what, is this a record of? Data fields? I would contend
(and do) that the only record is the document(s) or reports(s) structured
from the data in the database. If one needs to present these documents
or reports to a court in litigation one presents the compilation not the
database. Under the Uniform Rules of Evidence, rule 803(6) states
that "computer records" are "data compilations". That is, data that
has been given structure and context. Rule 1001 defines original
computer records as that data which has been given structure and "any printout
or other output readable by sight shown to reflect the data accurately,
is an 'original.'" I say structured because I don't think the court
would let one come in with a data "dump" that was unstructured and had
nothing to do with how the "data" had been manipulated and presented.
I have tried to think of an analogous situation in the world of paper documents
and would offer the following (since this started of as an archival and
not a records management question). One could consider a filing system
a "dynamic" database. Over time the "data" stored in a filing category
will change. One year the correspondence file is "FY 1999", the next "FY
2000." Each year the previous years data is purged. In FY 2010
the unit in question ceases to exist. The FY 2010 records then become
the "final fixed" database. Is this really a representation of the
historical change in this database. I know this does not map exactly
but it gives the general flavor of the point I am trying to make.
Unless some summary of the correspondence files was made (e.g., received
from, sent to) one would have little to work with in a historical sense
given the final fixed correspondence file. As an archivist I think
Mr. Van der Ven would be more interested in having all (or a selection)
of the data compilations that were structured to help analyze a problem
or give administrative or management direction to the end user. These
documents would give the context, content and structure that we normally
look for in an archival document. By making the database the "record"
one takes on the almost insurmountable problems of also archiving the database
application, the operating system used, the user interface employed, the
external environment interface employed, documentation on purging criteria
and reports or other internal documents output from the system as well
as any applications (e.g., report writers) used to produce those documents.
Then one can start to discuss how all of these get refreshed and
migrated ad infinitum. Oh, and don't forget about archiving the database
server and the net-server and the optical disk drive and the....The forgoing
lengthy diatribe is mine only and should not be construed as legal advice
or any advice at all...For entertainment uses only. Dick King, University
of Arizona
"Wood, Thomas" wrote:
The data in a ledger MIGHT be fixed, but then so
might the data in a
database, at some point. Both are likely go through an active lifestage,
in
which the data is "dynamic," and both may eventually become a "fixed,"
inactive record.