Subsections

The CISP database

This chapter firstly defines the `domain of discourse', the information to be recorded in the database, and the discusses the structure of the database in the light of the concepts discussed in the previous chapter. Throughout this guide the following conventions are used: table (relation) names are given in SMALL CAPITALS, field (or column) names are given in a fixed space font and allowed entries for a restricted field in bold type.

Criteria for inclusion

The database is to include all `early medieval inscribed stone monuments from Celtic-speaking regions' defined as follows:

Rule: If in doubt, include -- it is better to include things not strictly within the remit than to omit things that should be covered.

Doubtful inscriptions and lost stones

N.B. `Lost' refers to stones not inscriptions. If the stone is extant but the inscription is no longer visible (whether through extreme wear or because the inscribed portion has been broken and lost) it is `doubtful' only if the extant descriptions and illustrations are unreliable.

`Lost' stones are those which have been described and/or illustrated by a credible authority but whose current whereabouts are unknown (stones which have been destroyed, stolen, or mislaid). They are described as normal and the current location is given as `lost'. The dating parameters for their loss are noted (see the LOST table below).

If there is doubt that the inscription on a lost stone was genuine, for instance if the description is ambiguous or fantastical, then the stone and its inscription are listed as normal and `doubtful' is recorded in the inscription table. The same goes for extant stones if there is doubt that visible scores (a) are artificial, (b) represent lettering, or (c) date to the early medieval period.

The structure of the CISP database

The CISP database is comprised of a primary group of five tables, each in a one-to-many relationship with another table in a hierarchy. These tables form the core of the database. As it is an explicit aim of the project to examine these monuments in their wider context, the first primary table is the SITE table. Each site is given a primary key in the form of a five letter code. Any one site, however, can have more than one stone--there is a one-to-many relationship between sites and stones. The stones are, therefore, recorded in a separate table (STONE), and linked via the site's primary key. Similarly, any one stone can have more than one inscription and thus we have another one-to-many relationship and a third table (INSCRIP). Similarly, any one inscription can have more than one reading, and an authority can provide us with more than one interpretation of a reading. This gives us the fourth and fifth tables (READING & TRANSLAT).

For each of these primary tables there are some related subsidary tables. For example, a site may be known by more than one name. CISP will record the most commonly used name in the SITE table. Alternative names, if any, are stored in a separate table, ALT_NAME. This allows a site to be accessed using any of the possible site names. Figures 2-5 show the five main tables, and their relationship to the other primary tables, and their subsidiary tables.

Figure 2: Tables related to the primary SITE table
\includegraphics[width=\textwidth]{findes1.eps}

Figure 3: Tables related to the primary STONE table
\includegraphics[width=\textwidth]{findes2.eps}

Figure 4: Tables related to the primary INSCRIP table
\includegraphics[width=\textwidth]{findes3.eps}

Figure 5: Tables related to the primary READING and TRANSLAT tables
\includegraphics[width=\textwidth]{findes4.eps}

In addition to these five main tables and the subsidiary tables, there are a large number of simple and hierarchical look-up tables. These perform the functions discussed above (see page [*]); all are listed in the next chapter and the hierarchical tables are discussed in detail.

Figure 6: General structure of the CISP database
\includegraphics[width=0.75\textwidth]{findes5.eps}

We have, therefore, five primary tables which have a set of related secondary tables and look-up tables. These tables form the core of the CISP database. There are a number of other tables -- it is helpful to divide the database into three groups or subsystems (see Figure 6). These are the core, bibliography and image subsystems.

The bibliography subsystem has one primary table, BIBLIOG which will contain all the references to published sources and systematic archives such as sites and monuments records. This table is connected to four of the primary tables via a series of linking tables (see page [*]). It is also connected to the NAME table and the IMAGE table. These linking tables contain, as well as the necessary linking information, further data such as specific page numbers, and an indication of the value of the reference, `major discussion' or `passing mention'. Finally, the CORPORA table forms an alternative link between the INSCRIP and BIBLIOG tables and allows the retrieval of inscriptions by their standard reference numbers such as those in Macalister Macalister:1945,Macalister:1949. Figure 7 illustrates the relationships.

Figure 7: The bibliographic subsystem
\includegraphics[width=\textwidth]{findes6.eps}

The IMAGE table stores images of sites, stones and inscriptions. This table has a many-to-many relationship with three of the primary tables and the bibliography table, and is therefore linked to them via intermediate linking tables. Lastly, the CISPARCH table records information about the CISP archive including photographs, rubbings and correspondence. This table is linked to the SITE, STONE, and INSCRIP tables via further linking tables. Figure 8 illustrates these last relationships.

Figure 8: The image subsystem
\includegraphics[width=\textwidth]{findes7.eps}

Although this data structure is complex, it allows for flexible data retrieval, and for future expansion of the project. For example, no changes to the structure of the database would be required in order to add runic and Anglo-Saxon inscriptions to the system, although some of the terms in the look-up tables might well need expansion. Portable artefacts could be added by creating an artefact table in parallel to the STONE table, or more detailed recording of decoration or form could be added by creating further tables also linked to the STONE table.

Data definition strategy

Tables in the CISP database consist of three basic types of fields. The first group are relatively short but unrestricted fields such as place names, measurements, or readings of inscriptions. The second group are fields with a very restricted range of entries controlled by look-up tables. The final group of fields are memo or very long string fields. Database purists dislike this type of field as it is unstructured and can lead to poor efficiency in data retrieval. In the case of the CISP database, it was felt that there were many cases where free form text was necessary, and an even more complex data structure would be counter-productive. In these situations, some information is stored in a structured format in restricted fields, and some in a memo format. For example, the STONE table has two logical (yes/no) fields, cross and other_carve which record whether a stone has an inscribed cross and/or other carved decoration. If the answer is yes, further structured details are stored in the INSCROSS and/or DECORATN tables, and a fuller, free text description is entered into the DECOR_NOTES memo field.

Database implementation

Hardware and software

The above data schema is a theoretical construct derived from the information CISP wishes to record. This schema is independent of software or hardware platforms, it can be implemented using different RDMSs on different types of computer. As a result, the database can be moved (`ported') from one computer package to another with relatively few problems.

The primary obstacle to data transfer between systems is that different packages have different methods for storing data. For example, and paradox store long text (memo) fields in a separate computer file. These memo fields are of unlimited length whereas other strings are limited to 256 characters. Microsoft access can store strings up to 64kbytes as part of the main table.

The database was originally implemented using Visual dBASE 5.5 on a Pentium 133mhz PC.1 One copy of the Visual dBASE client-server bundle of computer programs was purchased which includes a program to help ease data transfer between different database systems.

The data entry application

The complex nature of the CISP database necessitated the construction of a data input application which was written by the author using Visual dBASE's `object orientated' programming language.2 Currently, only a single site/stone addition/browsing capability has been implemented. This application speeds up data entry, and helps minimise errors by the automatic creation and linking of primary keys wherever possible. The application allows the user to easily navigate around related sets of tables.

Database dissemination

It has been decided to mount the first release of the database on UCL's Oracle database server which will be accessible via a relatively simple database application accessible through the Web.

No decisions have been made as to the method by which the full and final version of the CISP database is to be disseminated. This is to keep the options open given the rapid development of computer technology, particularly the Internet. There are a number of possible options currently available, none of which need be exclusive.

Mike Gahan 2000-10-18