The Database Structure


These five sets of information are transformed into the database structure illustrated in Fig. 9. The relationship between the data file and the contents of the database are best described by explaining this structure. In Fig. 9 the squared boxes represent the names of tables, the rounded boxes indicate the fields that comprise those tables and the lines represent common columns used when joining different tables during data retrieval.

The PERSON table

The PERSON table forms the core of the database, and all the individuals about whom there is information have a single entry in this table. Each person is assigned a unique identification number, PERID, which is created when the data are loaded into the database. This number is only used within the database and has no relevance to the final publication. The other information in this table relates to the gender of the individual, PERSEX, as recorded in the name field; the volume in which the individual has been or is to be published PERVOLUME; and the homonym, PERHOMON, which comes from the final brackets field. Finally, the table includes the publication identification number, PERPUBID, which is a running number for a particular name in a specific volume. This is added to the database prior to the final publication process. It is used when indicating that two people who are separately attested may be the same person as explained below.

The NLINKS table

The NLINKS table forms the link between the person and details about their name. The primary name comes from the name field, but secondary names come from the final bracket field. Each name is given a separate row in this table. Each row comprises the person's identification number, PERID, a sequence number, NLSEQ, for the names associated with that person and a sorting form of the individual's name, NAMID. The transliterated Greek is converted into its sort value and is stored as uppercase with all the accent flags removed. It is this field that controls the overall order of the eventual publication. The transliterated name is stored in the field NLRESTNAME, or restored name field, and this is the text actually used in producing the publication. It will be noticed that since there can only be Greek names in the data file name field there is no percentage ("%") flag to indicate that the word has to be treated as Greek, whereas in the final bracket, where words can be Greek or English this flag is necessary. However, for final bracket names the "%" is removed when stored in the NLRESTNAME field.

The type of name is stored in the NLTYPE field, be it primary or secondary, and if secondary then whether it is an editorial, or orthographical variant, or some variation of dialect. Within the data file these differences are signified by two exclamation marks, which indicate where the secondary name differs from the primary name. This information is stored separately in the fields NLORCH, NLORCH2 and NLORCH3, although, only occasionally does a name have more than one variation and in the publication, in these cases, the whole name is published. There are a number of conventions used in the publication that are stored in the database, and one is that letters within square brackets indicate a restoration. In the case of people with two Greek names which are linked by, e.g. ó kaì, then the relevant code is stored in the field NLMULT (Table 7 gives the current list of link values). The reliability, NLRELY, of the name is also stored.

The NLCOMM table

The NLCOMM table contains other information relating to a secondary name, linked to the NLINKS table by the fields PERID and NLSEQ. The field NLTEXT contains the comment, such as the initials of the scholar responsible for a particular suggestion regarding the names, or specific references concerning the immediately preceding data.

The REFERENCE table

The REFERENCE table contains information about the publications that refer to the original inscription, papyrus, etc. Each book title has a book number, BKNUM, and is linked to the BOOKS table, which is a list of all the publications. The PERID field links the reference table to the PERSON table. The chapter, page and line numbers, REFCHAP, REFTEXT, and REFLINE of the reference are also stored. As there are often several secondary references there is a sequence number, REFSEQ, to indicate the publication order while the field, REFSEP, indicates the type of separator between references (Table 8). The field REFCFSQB indicates whether there should be a "cf." and/or square brackets around the last part of the reference, which indicate information restored in the original.

The BOOKS table

The BOOKS table has the list of authorised references and contains an abbreviated form of the publication title, BKID, which is what is stored in the data files, as well as the full form of the reference, BKFULLREF. Also stored are the patterns used in the publication, BPAT1 and BPAT2 which specify how a publication is to look when finally published (Table 9). The REFCOMM table contains comments about a specific reference, in the field REFTEXT, and it is linked to the REFERENCE table by the fields BKNUM, PERID and REFSEQ.

The RESIDENCE table

The RESIDENCE table contains the information relating to the place or places a person is known to have come from. Apart from the PLACEID and PERID fields, which link the table to the PLACES and PERSON tables respectively, the field RESTYPE indicates the type of residence (i.e. primary or secondary). There is always only a single primary place, but there can be several secondary ones, which are associated with a separator, RESSEP, which indicates whether the secondary place is "as well as" (= and) or "instead of" (= or) the primary place. There is also a field for the reliability, RESRELY, and the qualifier field, RESQUAL, which indicates whether the location is "near" or "in the region of" a particular place.

The PLACES table

The PLACES table is the authorised list of places and holds the cross-reference information that links the PLACECODE, which is the location phrase used in the place field in the data files, with the PLACEID which is the identification number used in the database. Places are basically broken down into a four level hierarchy, the island, ISLID, the town, TOWID, the deme, TOWDEME, and the polis, POLIS. There is a fifth field, MISCELL, which holds any other miscellaneous information that is relevant. Table 10 gives several examples of this hierarchy. Not all the fields are necessarily known or indeed relevant to a particular location, but the keyword usually represents the lowest level of knowledge about the individual's location. The PLACES table also contains the volume, ARID, (or area id.) in which a place has been or will be published. Places form the second sorting key in the eventual order of the publication.

The PERIOD table

The table PERIOD stores the dates assigned to a person, identified by PERID. The actual date is stored in two forms, a publication form, in PERDATE, and as a numerical interpretation, in PERMINDATE and PERMAXDATE. The latter two are used in sorting the entries for the final publication, while the former is reformatted and used in the published volume.

The PSTATUS table

The PSTATUS table contains any status information known about an individual, identified by PERID, in the field STATUS. The reliability of the information is recorded in the field STATRELY, and because it is possible for an individual to have more than one status a sequence number, SEQNO, records the order in which they are to be published.

The RELATIVES table

The RELATIVES table links people who are known to be related, and stores the parent, PERID1, the child, PERID2, and other details such as the type, RELTYPE, for instance adopted or natural, the reliability, RELRELY, and finally the publication order, RELSEQ. During loading a program is designed to examine the relationship data; it takes the names from the name fields and the names from the third sub-field of the final brackets field and attempts to match parents and children. However, sometimes this is not possible, so any individuals who cannot be so linked are given an entry in the RELATIVES table with the value zero in the parent or child field, as appropriate, with the name stored as an entry in the RELCOMM table. The field RELTEXT holds the name of the relative, while the fields PERID1, PERID2 and RELSEQ link this row to the row in the RELATIVES table. In this comment table the field RELTYPE, indicates which relation the name represents, i.e. P (parent) or C (child).

The SAME_AS and SEE_ALSO tables

The SAME_AS and SEE_ALSO tables indicate whether an individual is thought to be the same as someone else, or whether reference should be made to another person and only the two fields PERID1 and PERID2 are necessary. If three names are thought to be the same person, then this will generate only two entries in the table, the third entry will only be linked to the first name.

The PERCOMM table

The final table PERCOMM records the attribution information stored in the last part of the final brackets field in the data file.

Previous | Contents | Next



Email lgpn@classics.ox.ac.uk



Home  

Project  

Publications  

LGPN Online  
Background  
Searches  
Downloads  
Statistics  

Greek names  

Image Archive  

Contact  

 

Classics at Oxford  

University of Oxford  

British Academy 

AHRC