Dear All, 

I would like to share my two cents over this topic.

From a traditional recordkeeping perspective, I think a database might not a record, as it is a set of dynamic data. It can be updated permanently, modified and so on. It becomes a record when it is close, when all the data inside are frozen and nobody can alter them. It will be regarded "as is" for ever. That would be a classical record, as a paper record is frozen in its informational content and structure. 

On the other hand, as Natasha pointed out, there are databases clearly defined as being public records. As an example, it is hard to say that the car registry database is not a record. It has all the definitions of the record, being compiled as a legal task of a public office and serving as evidence for the cars registered in a certain area. But, indeed, it is "open", i.e. new data can be added, and the existing data being amendable. 

From my point of view, the time concept is changed, and so the technology for creating records. A paper record was frozen for good, because it was impossible to track any change in order to see how the information looked like at a certain moment in time. With databases, it should be considered that a certain data to be frozen for a limited period of time (as long as that data is valid). If an address for a person recorded  in a bank client database is changed, that data can be updated, as long as the original data are retained somehow/logged, in order to prove that at moment X, the information Y was available into the system. 

The key, IMHO, is to prove that a decision or an action that was taken at a GIVEN moment was based on a CERTAIN information. If the data are updated without any  trace, no one can prove it was not a good/wrong decision or action; it cannot serve as a trace for full time, but as a trace for the current time. 

Bogdan Popovici
National Archives
Romania




> -----Original Message-----
> From: Records Management Program [mailto:[log in to unmask]]
> On Behalf Of Toner, Alex John
> Sent: 17 decembrie 2014 17:06
> To: [log in to unmask]
> Subject: Re: [RM] A Database is not a Record
> 
> - Todd Johnson wrote " I am curious to know if anyone has successfully deleted
> data out of tables from an ERP system such as PeopleSoft or SAP."
> - Natasha Khramtsovsky wrote "If you use it in the course of your normal
> regular business activities...then it's your record."
> - Steve Whitaker wrote "...a database is an information asset."
> 
> 	Kudos to Ken for initiating this intriguing thread. Whether or not a
> PeopleSoft (PS) database meets traditional record definitions, in some cases it
> must be considered as important as the record output itself and may
> necessitate a broader characterization of traditional RM considerations.
> 
> Working within the Office of the University Registrar at The University of
> Pittsburgh, we utilize PS to matriculate, process, manage, and produce student
> academic information, perhaps most important of which are academic
> transcripts. Transcripts are required to be permanently retained.
> 
> The datasets and tables behind the application used to generate the transcript
> output (the record) are vital to our operations. We cannot produce the record
> without the data tables – and the queries and interface used to properly
> aggregate said data – thus, our PS database is a singularly important
> information asset.
> 
> Prior to PS and earlier electronic systems, hardcopy transcripts were
> microfilmed for permanent retention. We access and use these reels and fiche
> regularly in our daily business to fulfill requests. More recent transcript
> requests (2005 and on) are compiled from PS data, which by default is required
> to be permanently retained. No thought is given to data deletion (presumably
> ever) as no other official academic transcript evidence exists outside of PS.
> 
> While PS aggregates data from tables to compile a fixed output, in academic
> scenarios the datasets, tables, and application interfaces are what’s most
> important in terms of RIM. As we continue to matriculate students we must be
> able to produce a fixed transcript, but the virtual data is what’s of most
> consequence. In terms of the management and preservation a “fixed record”
> would receive, those characteristics may need to be applied to the database
> itself.
> 
> Not sure that I articulated that as well as I would have liked... The point being,
> this is an awesome topic because academic institutions using student
> information systems need to seriously consider, if they haven’t already, long
> term RIM implications regarding database content. If they don’t, 10, 20, 30, 40
> years from now, today’s students will have a hell of time requesting a
> transcript.
> 
> Alex J. Toner
> Archives & Records Manager
> Office of the University Registrar
> University of Pittsburgh
> G-3 Thackeray Hall
> Pittsburgh, PA 15260
> P: (412)624-0054
> F: (412)624-9782
> [log in to unmask]
> www.registrar.pitt.edu
> 
> List archives at http://lists.ufl.edu/archives/recmgmt-l.html
> Contact [log in to unmask] for assistance To unsubscribe
> from this list, click the below link. If not already present, place UNSUBSCRIBE
> RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
> mailto:[log in to unmask]

List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
To unsubscribe from this list, click the below link. If not already present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
mailto:[log in to unmask]