Vol. XI, No. 3

Winter, 1999

This is intended to be the first in an irregular series of articles. The aim of this series is to assist scholars who need to oversee the creation of databases but who know that they must venture into unfamiliar territory to do so. We hope to demystify the process a bit and to give some assistance to those who must enter the computer world, despite feeling unprepared.

Some years ago I was invited to stop in on a project in Greece. When I did so, I found project personnel using a database that I thought was very badly designed. Being a guest, I kept my silence until I discovered that the problems were worse than I had at first realized and that a serious risk was being needlessly run. I spoke up-and stayed on to fix the problems.

The particular problem that stirred me to action was a simple one. Anyone who examined any of the data on screen could, accidentally or intentionally, alter any and all the data visible on screen at the time. Worse yet, even an unintentional change, which might occur quite accidentally while moving the cursor about the screen, was immediately permanent and irreversible. That is, one could only change the data back to the original if one recognized that an inadvertent change had occurred, knew what the original entry was, and re-typed the original data. Nothing could just undo the change. At that project, nobody could look at the data without putting its integrity at risk. The particular problem I found was not terribly unusual; finding some significant problem with a database is distressingly common.

Why are problems so common? I would answer that question with more questions. How do project directors go about the task of computerizing parts of their projects? How do they find the right person to do the work, and how do they evaluate the job that has been done-much less a job still in progress? When a photographer or a draftsman is hired, the results are fairly easy to see, and those results come quickly. On the other hand, computerizing excavation material or a catalog for a collection is a process that may bear no visible fruit for a long time, and even when something is available for examination, evaluating the result is difficult and will take still more time. How, after all, does one judge a database, especially if one is not proficient with computers?

Given the difficulties here, it seems that some suggestions regarding a general approach to creating a computer database may be helpful. So here are some recommendations for those who need to have a database of some sort created for a project-whether an excavation or a catalog-and who are unsure of the right questions to ask, much less the right answers.

1. Try to learn something about database design yourself. Even a fairly routine book about almost any database program will include a helpful discussion of database design; the ADAP web site leads to two discussions of database design issues (CSA/ADAP Introduction to Databases and CSA/ADAP Archaeological Database Discussions); some CSA Newsletter articles may be helpful; and there are many other sources, including J. Penny Small's APA-published booklet on database design, How to Choose a Database.
2. Having tried to learn something about databases, take stock and appraise your level of understanding fairly.
3. Find out which of your project personnel has computer skills and talk to them about your computing needs.
4. Talk to colleagues you know and trust to get recommendations and advice.
5. Try to find an example of the kind of database you need, and try to imagine how your data would fit.
6. Examine, specify, and explain the needs you have for your system. Your database specialist should know what you expect of the database, what kinds of information you want to store and retrieve, what kinds of forms you will need, what kinds of questions you will ask.
7. Think about what you want to include and what you might leave out of the database, at least at the outset.
8. Try to find a database specialist who knows something about archaeology or object catalogs, not just computers. No matter who the database specialist is, spend time with him or her explaining the way records are kept for your project, how they are generated, how they are stored, what you do with the information, and so on. Explain again and again what you will do with the fruits of his or her labor.
9. Be sure your potential database specialist has real database experience, not just general computing experience. A web designer, for instance, is not necessarily prepared to build a database just because he or she can design a web page-even if that web page uses databases to store and retrieve information.
10. Seek out an advisor if possible, someone who knows archaeology and computers, in whom you have confidence, and who will talk with the database specialist early in the project to make sure the basics are going well-and return, on a regular basis, to check on progress.
11. Do not permit your database specialist to determine your computer hardware. If he or she only works with MACs and you have PCs, or vice versa, don't switch computers. Switch specialists.
12. Make sure that the database program being used is a well-known and widely-used one. Do not let someone convince you to use software that is supposedly superior but does not have a reasonable market share. If good software does not sell, it does not survive.
13. Ask the "dumb" questions and encourage the database specialist to do the same of you. Very often the seemingly silly questions bring out the most profound problems because they display the most serious misunderstandings. You and the database specialist must be able to ask those apparently ridiculous questions of one another if you are to understand one another fully.
14. In general, do not accept "That can't be done" as a final answer to any request you have made about data retrieval. "That can't be done" usually means "I don't know how to do that," and those two sentences obviously mean very different things.

These simple bits of advice are not sufficient to take anyone through the creation of a database, but they may help prevent some early problems and start-up anxieties. Future articles will take up some other potential pitfalls. In the meantime, feel free to contact CSA for help with specific database design problems.

-- Harrison 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, issues surrounding databases, or the Archaeological Data Archive Project, consult the Subject index.

Next Article: Bryn Mawr Electronic Resources Review

Table of Contents for the Winter, 1999 issue of the CSA Newsletter (Vol. XI, no. 3)

Table of Contents for all CSA Newsletter issues on the Web