|
|
|
The Earth Systems Database was originally designed as a means of storing and analysing floral and vertebrate data used in my PhD thesis. Today it contains additional geological information used in my GIS-based databases, as well as modern climate, sedimentological and ecological data used in constraining and understanding the position of climate proxies in climate space.
The principle structure of the database is shown below. For each of the major elements there is a web page outlining the basic information included (see menu, left). Examples of the principle data entry forms (e.g. Locality, Taxonomy, etc.) are included as thumbnail images that can be clicked on to access a more legible version of the image. For the time being I've only included a cursory outline of what each part of the database contains. For more information researchers are directed to my PhD thesis, which includes a detailed description of the database and all the fields it contains.
|
|
LEFT: The basic structure of the Earth Systems Database (click here for a larger version: 40kb)
|
|
Several general lessons about databases, especially databases of global extent are presented as follows (see also Markwick & Lupia, 2002). (1) A database needs to be comprehensive enough to address the questions asked of it, but at the same time simple enough to be useable. A common problem is that databases, especially when designed by committee, tend to try and do too much, and as a consquence become unwieldly. (2) Database Flexibility: because needs change, database structure needs to be so designed that additional information/tables/types of data can be added with the minimum of effort. A modular approach, with numerous lookup tables of different information seems to work most efficiently with data being changed only once in one table and then the results permeated throughout the whole. (3) Attribution: - this is a data issue, but worth mentioning here; all data must be properly referenced and qualified. Once data is stored within a database it tends to look similar (in terms of it's provenance, reliability etc.) and so compilers must include distinctions at the time of entry. (4) Each table must have a unique identifier that can then be used to link records between tables. It is adviseable that this does not incorporate any meaning, for the reason that such meaning may change as more information is accumulated. A simple sequential number works well in the databases I have designed.
|
|
