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