|
|
|
|
When information is changed in an archaeological database, do we need to know that a change was made? To know what the original information was? To know who changed the information? Sometimes those things are important, and some people were reminded of that at the last annual meeting of the Archaeological Institute of America. During the workshop on pottery, someone noted that changes on index cards in a pottery catalog are usually made so that the original entries can still be read after the changes have been made. It was agreed that knowing the original entry could be beneficial. In the discussion that ensued, I argued that preserving original data in an electronic database would be very simple, as simple as crossing out the old and entering the new in a paper catalog.
As I prepared work on an excavation database for this summer, I decided that preserving past information should be considered in that context. I was working with FileMaker Pro® and tried to create a system that would track any changes the excavator wanted to track. For instance, if the excavator wished to know if there had been a change to the earliest or latest date assigned to the pottery sherds from a specific context, that change would be recorded.
The simplest method of tracking changes seemed to be adding a corrections table for each data table; for instance, the data table with the information about excavation pottery would need a companion table for corrections. Each correction would be recorded in the corrections table with the following items: information category, old information, new information, date of change, and person entering the change.
I was able to create a system in FileMaker that would accomplish this. The user, selecting an edit process, would make any changes, and the computer would track certain of the changes, entering the new data into the file and entering the information about the change into another file. The result provides a record of changes, as hoped. I asked Susan Jones to try the same process with Access®, and she was able to create a similar procedure with that database management system.
Using this system, the data in the pottery table would always be the latest, most current version of the data. In addition, however, the corrections table would have a list of all corrections, and any user could choose to see the pottery information with or without the list of corrections - including the date of each correction and the person responsible. A true history of the data would be available at any time.
There is one problem with such a system; it demands discipline on the part of the users. If they circumvent the editing procedures and change the file without using them, which they certainly can do, the changes will not be tracked. Used properly though, the system results in a clear presentation of the current data and the history of those data.
-- H. Eiteljorg, II
To send comments or questions to the author, please see our email contacts page.
For other Newsletter articles concerning the use of electronic media in the humanities, or issues surrounding the use and design of databases, consult the Subject index.
Next Article: Using AutoCAD with Medieval Architecture
Table of Contents for the Spring, 1998 issue of the CSA Newsletter (Vol. XI, no. 1)
Table of Contents for all CSA Newsletter issues on the Web