(Shows the relationship between tables in the database. Crow’s feet indicate one-to- many relationships. Tables coloured pink are look-up tables.)

The primary table is Survey Visit which records details of each time a visit has been made to a site to do geophysical survey work. Note that two visits to the same site at different times count as separate survey visits. The Survey Technique table records details about each geophysical technique used (resistivity, magnetometry, etc.) on each survey visit. Hence, a single survey visit may generate a number of entries in the survey technique table. The other table of note is Report which contains details of all the reports written on survey work including, via report_summary, a summary where available.

If the above diagram is as clear as mud to you, here is a very poor attempt at explaining it (relational database experts, please don't read any further!):

Each yellow rectangle represents a table in our database. Each table records details of one of the entities, or things, we are interested in. For instance the reports table contains an entry for every report our database knows about; the survey visit table one entry for each time we've been out to do a survey. Each such entry is made up of a group of fields where each field specifies is related to an attribute of the entity we wish to record. For instance, for reports we have fields for the report title and report author amongst other things.

The black "crow's feet" linking tables together specify one to many relationships between the entities in the different tables. For example on one survey visit we may use several different survey techniques (resistivity, magnetometry, etc) hence the one to many relationship between survey visit table and survey technique table. Also, whilst we usually write a report on each survey visit we make, sometimes we return to a site several times and write one report summarising the work done on all visits, hence the one to many relationship between report table and survey visit.

There are also a couple of lines without "crow's feet" linking tables, for instance report and report summary. This shows a one to one relationship between the two tables (each report has exactly one summary). In an ideal world the two tables could be merged into one but for efficiency with our database implementation certain fields are isolated into separate tables to make querying faster.

For further information on what fields we use for each table look at the database’s Data Dictionary.