CASE STUDIES

8.1 Introduction

This final chapter gives some examples of how databases have been used in various projects, the aim being to present a reasonably wide range of applications. Most of the projects described are of small- to medium-scale, both in terms of personnel and equipment and in terms of geographical area covered.

8.2 Plant list and distribution database

An example of a database used to store plant names and broad regional distributions is the LEAP (The List of East African Plants) database. This database was established because of a perceived need for a species-level database of vascular plants for Uganda, Kenya and Tanzania. The database is kept at the East African Herbarium, Nairobi, and is revised at intervals (Knox and Berghe (1997).

The database consists of the main LEAP table and a Higher Classification table. Both these tables are linked by the field Family. In addition, there are three other tables (a Source table, a Synonym table and a Recipients of LEAP table) but these are not linked to the main table.

The data structure of the main LEAP table is shown in Table 8.1: fields 1 to 12 are about the names and numbers of plants and follow a phylogenetic sequence, from Family to Variety (where known); fields 17 to 21 are concerned with geographical distribution according to 21 floral divisions; and the remaining fields deal with other factors, as listed in Table 8.1.

The data structure of the Higher Classification table can be seen in Table 8.2. This gives another phylogenetic sequence, from Division down to Family, this last field providing the link with the main LEAP table. The taxon numbers (Dnum, Cnum etc.) can be used to generate a phylogenetic listing, or to manipulate the LEAP table in other ways. For example, division numbers can be used to select angiosperms only, and class numbers can be used to select just monocotyledons. It is clearly an advantage to have all the information in the Higher Classification table separate from the main LEAP table, in order to avoid much repetition and to make data storage more compact.

(Tables 8.1 & 8.2 about here)

At present the LEAP database contains information on over 13 000 species, subspecies and varieties. One of the chief uses of the database is for herbarium management and for planning related field research. However, it is also a valuable tool for other biological research, as indicated in the next case study.

A copy of LEAP may be obtained from the East African Herbarium (see Appendix for contact address).

8.3 Ethnobotanical database (Uganda)

Although this database is still in the planning stages, its intended structure has been described (Höft and Schmitt, 1996). The chief aims in setting up the database, which has been supported in its development by the People and Plants Initiative, are to store information on useful plants in the Rwenzori region of Uganda, and to catalogue an associated herbarium collection.

The database consists of 11 tables, including three of the LEAP tables as the source of scientific names. The three LEAP tables are mentioned above (i.e. the main LEAP, Higher Classification and Synonyms tables) while the other eight tables are shown in Table 8.3 (for Genera, Family, Specimen, Collection site, Collector, Helper, Parish and Ethnobotany).

(Table 8.3 about here)

8.4 Ethnobotanical database (Guiana Shield)

This database is at an early stage of development, and may not yet be its final form. However, its foundation structure has been described (Johnston and Hall, pers. comm.). The aim of the database is to provide information on useful non-timber plants of the Guiana Shield (comprising the countries Guyana, Surinam and French Guiana) and to highlight the conservation value of the region's plant life.

The 18 fields within the database are described in Table 8.4. A taxonomic code (field 3) has been included in order to allow the records to be sorted in a particular taxonomic order. Fields 8, 9 and 10 are for recording plant uses according to the three levels given in the Economic Botany Data Collection Standard (see Chapter 4). The database also includes a field (No.11) for dividing plants into one or more of eight categories (Edible, Construction, Technology, Medicinal, Commerce, Timber, Mythological and Others) and a field (No.12) for recording calculated species-use values (Phillips & Gentry, 1993a, 1993b), where such information is available. A separate field (No.13) is used for noting which ethnic groups use the plant in question. The other fields in the database are for recording information on distribution, habitat, forest type and growth form.

(Table 8.4 about here)

At present, the database does not include information on the different uses and methods of preparation of plant material as documented by individual helpers. Such information may be incorporated in extra fields at a later stage, as may details on herbarium specimens.

The database currently contains records on over 9000 species; for 900 of these it has been possible to classify them according to the plant use categories, as indicated in Figure 8.2.

(Figure 8.2 about here)

8.5 Tree species mapping

This example illustrates how a database can be used to compile distribution data according to grid-squares and then pass these data to a mapping program. In this case study, this was done in order to provide distribution maps of individual species for a book on the trees of Natal and part of Cape Province, South Africa (Pooley, 1993). The chief requirement was that the distribution of each species should be shown on 1/4 degree maps; that is, where lines of latitude and longitude have been divided by four, giving 16 squares per whole degree square. This has been found to be a convenient way of presenting tree distributions in this region. An example of the type of map required is shown in Figure 8.3.

(Figure 8.3 about here)

A major problem appeared at an early stage: how could all the information on the individual species and the 1/4 degree squares in which they were recorded be stored in a compact and efficient database? If a new record was created for every square in which a species was found then this would lead to a very large number of records, as some 800 species and some 250 squares were involved. In addition, since the database would need constant revision as new information became available, it would be necessary to check constantly to see whether specific grid-squares were included or not for a particular species. All this would lead to a cumbersome database.

A solution was found by means of "data chaining". All the data on squares where a species was found were stored, in a chain, in a single field (called Grid). For example, distribution data for one species of tree might appear under the field Grid as follows:

2631DD + 1 2632CC 1 2632CD 1 2632DD + 1 2730BC + 1 2730BD + 1 2731AC 1 2731AD 1 2731BB + 1 2731CA + 2 ...etc.

Here the references for specific grid-squares are listed (2631DD, 2632CC, 2632CD and so on), together with a count (1,2,3 etc.) indicating the number of records made for particular squares. The symbol "+" was used to show that at least one of the records was based on an herbarium specimen.

The chief advantage of this method of recording distribution is that the data on plant names are keyed-in only once (or perhaps not at all if a database such as LEAP is available). The grid-square data can then be entered in a chain. It is then a simple matter to add extra distribution data as and when they become available. Thus a new record from a listed square will increase the count by one, a herbarium specimen might require a "+" to be added and a record for an unlisted square would mean that a new grid reference would be included.

Unfortunately, standard database packages do not provide an easy means of chaining data in this way, and therefore special programs were written to deal with grid-square entries, as indicated in the flow diagram in Figure 8.4, and to arrange the grid-square data in a logical order on the computer screen (i.e. according to their sequence on a map of the study area). Should you wish to carry out a similar operation, expert help will probably be required.

(Figure 8.4 about here)

Special programs were also written to present the distribution data in map form. Maps were first printed at a scale of 1:5000, and then given to various experts on the trees of the region to check for any obvious errors. Then, once all the maps had been checked and corrected, they were printed at a scale of 1:30 000. These small maps appear in the field guide alongside the illustrations and descriptions of particular trees.

An obvious advantage of storing the distribution records in a database of this kind is that they can be updated at intervals, and hence revised maps can be produced quite easily for new editions of the book.

8.6 Fire and grassland management

A database was set up in 1991 by the Natal Parks Board to store data on grassland fires in the Natal Drakensberg mountains of South Africa (A. Walls, pers. comm.). The study provides an example of a database connected to a GIS package. This allows good quality maps to be printed, say of burnt areas or areas needing to be burnt, in addition to direct outputs from the database, such as tables.

The Natal Parks Board have developed a fire management plan for this grassland region. The total area of about 250 000 ha has been divided into fire compartments ranging in size from 400 to 1000 ha. Each compartment is burnt every two years according to a schedule of early, mid-season and late burns. Thus, for example, each compartment receives a late burn every six years. These are referred to as scheduled burns. However, unscheduled fires occur from time to time owing to fires set by local people (referred to as arson) and to planned burns that get out of control (referred to as runaway fires). The main purpose in establishing the database was to store all the data on fires in an efficient manner and in a form that would be convenient both to staff in the field and to the planning unit of the Natal Parks Board.

The database takes the form of three tables linked by the fields Compartment Number and Fire Number (Figure 8.5). By storing the information in this way it is only necessary to enter the basic geographical data once (i.e. the Drakensberg Compartment table). In addition, when an individual fire covers more than one fire compartment the details relating to the fire itself are entered just once (Fire Event table) and only data about the extent of burning are entered into the compartments involved (Fire Compartment table).

(Figure 8.5 about here)

An example data entry form should make this last point clear (Figure 8.6). Each data entry form is based on a particular fire event. All the entries about the fire event (dates, times, weather) are stored in one table while the entries on the, in this case, two compartments burnt (area burnt etc.) are stored in another. This separation into two tables is done automatically by the computer, making data entry efficient. When entering data, a replica of the data entry form appears on the screen. Again, this helps to make data entry convenient and efficient.

(Figure 8.6 about here)

Output from the database takes two main forms: tables and maps. Both of these can either be viewed on the screen or printed. When a map is required, a selection is first made from the database and then transferred to a separate GIS package. This package contains the basic map form of the study area and allows the user to shade or colour-in the fire compartments in any combination. A typical map is shown in Figure 8.7.

(Figure 8.7 about here)

8.7 Woody plant classification

This case study provides an example of how a database can be used to prepare data in a form suitable for transfer to a multivariate analysis package (see Chapter 1).

The topic described here -- woody plant classification -- formed part of a broad study carried out by Goodman (1990) in Mkuzi Game Reserve, KwaZulu Natal (South Africa), an area of sub-tropical bush and grassland. The overall aim of the study was to attempt to answer the question: What determines the number and relative proportions of large herbivores that can live together in an area?

As a first step to tackling this question, basic descriptions of soils and vegetation were carried out. One important requirement was a classification of vegetation types, and in order to make the classification as objective and flexible as possible multivariate methods were employed.

To collect the data for the multivariate analyses, stratified random sampling was used: the reserve was divided into 12 strata (based on land types) and then sample plots were selected at random within the strata. Each plot measured 20 x 50 metres and observations, measurements and samples (relating to geology, soils and vegetation) were taken from a total of 118 plots. The basic sampling design is shown in Figure 8.8.

(Figure 8.8 about here)

For woody plants, each species (out of a total of 162 preselected species) present in a plot was recorded, together with an estimate of its percentage cover in the plot. All the data for all the plots were then entered into a database (although a spreadsheet would also be suitable for this application) in which the fields were the 162 species and the records were the 118 plots. An example of a small part of this table is shown in Figure 8.9. The role of the database (or spreadsheet) is crucial as it provide a means of storing the table (or file) of data and making it available in a form suitable for transfer to a multivariate package.

(Figure 8.9 about here)

Multivariate analysis itself is an involved subject, beyond the scope of this book. However, it is interesting to see one of the main results in this particular case, as presented in Figure 8.10. This shows that the woody species fall into groups depending on soil type (on a gradient of clay to sandy soils) and soil depth (on a gradient of deep to shallow soils). By using further multivariate methods, 25 vegetation types were defined, based on six major divisions; these vegetation types were then used as a basis for mapping the woody communities in the reserve.

(Figure 8.10 about here)

8.8 Land-use planning

8.8.1 The study

This database study was carried out by the authors of this book at the University of Natal during the 1980s, and provides an example of the use of a database for presenting land-use options. All the data in this study were stored according to grid-squares; this is a convenient method of organising geographically-based data from many sources and for making simple maps. The method has its limitations, however, in that continuous features (such as soils or vegetation) have to be assessed according to the dominant types present in the grid-squares, and maps can only show approximate positions and boundaries.

The information for this study came from an area of some 23 000 ha in KwaZulu-Natal, South Africa, that had been chosen for a rural development project. During the planning stage of this development project, a great deal of information was collected on geology, topography, soils, water resources, current land-use, potential land-use, settlement patterns and infrastructure. This information, along with other data collected for the study, came from a number of sources and, as mentioned above, it was convenient to store all the data according to grid-squares.

For this study, a grid-square size of 250m x 250m (6.25 ha) was selected. Aerial photographs of the study area (1:10 000 scale) were then overlain with a grid of 250m x 250m squares, and a simple coordinate system was used to identify each square (see Figure 8.11). All the information was then extracted from the various maps and aerial photographs according to this grid-square format, recorded on data entry forms and entered into a flatfile database. The final database consisted of over 3500 records with a data structure as shown in Figure 8.12.

(Figures 8.11 and 8.12 about here)

The examples which follow show how various land-use queries can be answered, at least in part, by manipulation of this database. The manipulations themselves serve as further indications of what can be done with a database, and can be applied in many different situations.

8.8.2 Selection of specific sites for crops

In this example a question was raised about suitable areas for growing various herbs and spices. In the event the inquiry was not carried further. However, the procedure that would have been followed is described below and demonstrates the sequence of such a selection. One species in particular was known to favour sun-facing slopes, specific soil types and fairly low elevations that would minimise misty conditions; it was also known to benefit from limited irrigation. Accordingly, the following criteria could be listed as a basis for a database selection.

(a) Elevation has to be less than 300m

(b) Aspect has to be basically north (the study area being in the Southern Hemisphere)

(c) Soil has to be XXXX (no need to be specific) or YYYY

(d) An indication that at least some surface water will be available.

These conditions should satisfy the physical needs of the plant. However, human settlement and grazing factors also have to be taken into account, resulting in two extra requirements, as follows:

(e) Households have to be at low density

(f) Grazing has to be absent

The command clauses (see Chapter 6) in this particular selection are as follows:

(a) SELECT <STUDY_A> WHERE Elevation LT 300 SAVE RESULT 1

In other words, RESULT 1 will contain only those records from the original database (STUDY_A) which have an elevation value of less than (LT) 300m. RESULT 1 is saved as a temporary file and used for the next selection, the result of which (i.e. RESULT 2) is used for the next selection, and so on until RESULT 4 is reached (see below). This process successively reduces the number of records, until only those relatively few meeting all the criteria are left.

(b) SELECT <RESULT 1> WHERE Dominant Aspect = N OR Dominant Aspect = NE OR Dominant Aspect = NW

SAVE RESULT 2

(Note that as any north aspect is acceptable, North (N), North East (NE) and North West (NW) must be included)

(c) SELECT <RESULT 2> WHERE Dominant Soil = XXXX OR

Dominant Soil = YYYY

SAVE RESULT 3

(d) SELECT <RESULT 3> WHERE Rivers = p OR Springs GE 3

SAVE RESULT 4

In (d), the requirement for adequate water supply for irrigation is stipulated: the grid-square as recorded in the database must either have a perennial river running through it or a spring(s) with flow greater than or equal to (GE) category 3.

RESULT 4 will contain those records of the original database which have satisfied all the stipulated physical conditions. There is a possibility that at any of the stages (a) to (d) the search will have found no entries which fulfil the set requirements. Obviously should this occur the result will indicate that nothing significant has been found and that a reappraisal of the, possibly too strict, conditions can be made. This is the main reason for a stepwise selection process (see also the example in 8.7.4).

However, assuming that a reasonably large number of records are present in RESULT 4, it is then possible to complete the selection process by taking into account the human and grazing factors. This step may be phrased as a single query, although two different fields are concerned. That is:

(e) SELECT <RESULT 4> WHERE Households LT 5 AND Grazing = 0

SAVE FINAL

In this last selection the combined effects of low density of households and no grazing are accounted for jointly, while in three of the previous four selections one or other of the conditions had to hold (e.g. one of the north facing aspects), not all together. The difference between using AND versus OR illustrates the way such questions need to be phrased in a database to get the desired answers. Successive individual queries (a) to (e) do, however, mean that at least one aspect of all of these factors will be present in the result (i.e. FINAL). Thus an example record in FINAL might give the following result:

Elevation: 185 (metres)

Dominant Aspect: NW

Dominant Soil: YYY

Rivers: p

Households: 5

Grazing: 0

This record shows, for example, that where Rivers were "p" Springs may or may not have been "5". The important fact is that one of these needs is satisfied.

8.8.3 Siting of new schools: calculations of distance

A question was raised about siting additional schools in the study area so that no child should walk more than one kilometre to school each day. This type of question had not been anticipated when the database had been set up and no measurements to the nearest school (or any other infrastructure for that matter) were included in the individual grid-square records. It would of course have been possible to measure all these distances from a map and enter these data under an extra field, or fields. However, this would have been a most time-consuming and laborious exercise.

An alternative (and much faster) method was to calculate these distances from the relative positions of the grid-squares. As each grid-square record contained a reference number (eg. 06538; that is, position 65 horizontally and 38 vertically on the grid) the distance to another square can be taken as simply the number of 250m units separating them. The calculations were performed by taking the difference between the two horizontal references and then, independently, doing the same for the vertical references. The larger of the two calculated numbers is the distance in 250m units between the grid-squares, although a minor inaccuracy will arise for diagonal distances. Thus, for example, grid-squares referenced 06538 and 07341 will produce values of 73-65=7 and 41-38=3, the approximate ground measurement being the larger of the two values multiplied by 250m (i.e. 7x250=1750m or 1.75km).

Although the basis of these calculations is simple enough, the computer programming needed to perform the operations is more complex and beyond the scope of this book. In essence, a program was written that looked through the entire database, and for each square first checked for a school within that square. Then, if none was present, it searched in ever increasing circles around the square until a school was found (see Figure 8.14). The distance of the square from the school was then calculated by the method described above. Schools within 3km of the boundary of the study area were incorporated into the database to allow for households at the edge of the study area. At the end of this operation a new database was formed containing all the distance calculations. One way of presenting this type of information is in map form, showing in this case distances of each square from a school.

The main purpose of mentioning this example is to illustrate another way of manipulating a database, sometimes extracting information that was not considered at the beginning of the project. This example could have relevance to botanical projects -- for instance looking at the distances between trees in a forest in studies of pollination, or studies of tree damage in relation to distance from settlements.

8.8.4 Siting of rural service centres

This provides a further example of a stepwise database selection (as in 8.8.2), but incorporates distance calculation based on the principles described above. That is, in addition to distance to a school, the nearest distance of each grid-square to a reasonably good road, a reliable water source and good soil was also calculated. The results of these calculations were added to the database as separate fields called Dist_School, Dist_Road, Dist_Water and Dist_Soil (the actual criteria for selection of suitable, roads, water and soils need not be mentioned here).

The example in this instance was aimed at finding suitable places within the study area for siting rural service centres (i.e. small villages containing a clinic, a training centre, village industries, shops, etc.). Criteria for positioning these service centres were considered and it was decided that they should be established:

(a) on ground with slopes of less than 20%

(b) at elevations exceeding 300m

(c) within 2km of a primary or secondary road

(d) not further than 2km from a reliable water source

(e) within 500m of soils suitable for gardens

(f) where the buildings should occupy ground of low agricultural potential

(g) where primary and secondary schools should not be more than 2km distant

As regards criterion (b), residents of the area were known to fear low-lying ground for historical reasons of strategic defence, and because of the risk of flooding; hence the selection of higher land for the service centres.

A stepwise approach was taken so that the effect of each criterion could be assessed in turn. Where the criterion resulted in very few records being selected it could be modified to be less restrictive. For example, if slopes of less than 10% had been tested and led to only 25 grid-square records being selected, there would be little chance of obtaining a result after all the selections were completed. One might then be justified in relaxing the criterion to, say, slopes of less than 20% rather than less than 10%.

In simple query language the steps were as follows:

(a)SELECT <STUDY_A> WHERE Slope LE 20; SAVE RESULT 1

(b)SELECT <RESULT 1> WHERE Elevation GE 300; SAVE RESULT 2

(c)SELECT <RESULT 2> WHERE Dist_Road LE 2; SAVE RESULT 3

(d)SELECT <RESULT 3> WHERE Dist_Water LE 2; SAVE RESULT 4

(e)SELECT <RESULT 4> WHERE Dist_Soil LE 0.5; SAVE RESULT 5

(f)SELECT <RESULT 5> WHERE Land Potential GE 4; SAVE RESULT 6

(g)SELECT <RESULT 6> WHERE Dist_School LE 2; SAVE RESULT 7

In these steps the conditions LE and GE refer to "Less than or Equal to" and "Greater than or Equal to", and the numbers which follow these conditions are specific criteria (such as 20% slope, 300 metres and 2km). Land potential GE 4 = greater than or equal to category 4; i.e. land of low potential.

(NB In this example of the classification of land potential, the higher number reflects land of poorer potential.)

The various steps in the selection process are shown in Figure 8.13, which also shows the number of records selected at each stage.

(Figure 8.13 about here)

As can be seen in Figure 8.13, only a very small number of grid-squares (282 or 3.3% of the study area) fulfilled all the conditions needed for the siting of the service centres. When these squares were positioned on a map of the study area five suitable sites were identified; that is where a small cluster of squares were present providing enough space for a service centre to be built. It so happened that two sites chosen independently by other workers coincided exactly with the database-chosen sites. This was a good test of the ability of the database to answer specific land-use questions. The main advantage of the database was that it was able to provide an answer quickly and with reasonable accuracy (given the limitations of the grid-square recording system).

8.8.5 Bees, trees and bee-keepers

In this example an investigation was made of the bee-keeping potential in the study area and whether it would be worth obtaining honey processing equipment for the community. The question arose because of a tree planting exercise in the study area. One of the tree species planted was known to provide pollen suitable for honey production throughout the year. The question was whether the trees could support a large enough number of bee-keepers to warrant purchase of the processing equipment. An attempt was made to provide a preliminary answer by using the database.

The first step was to enter the information on the tree species (T3) into the database. An extra field, called T3_Pollen, was added to each record in the database so that data on the number of trees could be included. It was considered that at least 150 trees per grid-square had to be present to provide sufficient pollen for bees throughout the year. Accordingly, the first selection was as follows:

SELECT <STUDY_A> WHERE T3_Pollen GE 150; SAVE RESULT H

This step isolated all grid-squares where honey production (RESULT H) could be sustained easily; in other words, bees would need to fly only very small distances (some 100m-200m) to reach the pollen.

At this stage an extra field had been added to the database, recording the number of homestead owners in each grid-square who wished to participate in the bee-keeping venture. This field was called Farm_Honey. A minimum estimate of the number of potential bee-keepers was obtained by the following selection, in which the condition was set that there was at least one willing participant present per grid-square:

SELECT <RESULT H> WHERE Farm_Honey GE 1

Only 74 people were selected, considered too few to make the project worthwhile. However, a different picture emerged when the flying abilities of bees were taken into account. Experts on the matter pointed out that bees could easily travel more than 250m from the hive to a good pollen source and were capable of still greater distances (i.e. 500m and even 750m, an extreme for the type of bee in question). Therefore, using the same method as described above (section 8.7.3), a new database was formed containing distance calculations; and from this database, a new field called Dist_Honey was then added to the main database. A diagram of the search procedure is shown in Figure 8.14.

(Figure 8.14 about here)

With these two extra fields incorporated, a search could be made for willing participants in grid-squares at three levels of distance from pollen sources. These stepwise selections are given below:

(a) SELECT <STUDY_A> WHERE Farm_Honey GE 1 AND Dist_Honey LE 250; SAVE RESULT a

(b) SELECT <STUDY_A> WHERE Farm_Honey GE 1 AND Dist_Honey LE 500; SAVE RESULT b

(c) SELECT <STUDY_A> WHERE Farm_Honey GE 1 AND Dist_Honey LE 700; SAVE RESULT c

In the first selection all potential bee-keepers within the square containing a pollen source and within one grid-square away were chosen. This gave a total of 122 people. The second selection produced a result of 301, and in the final selection over six hundred potential bee-keepers were found.

It can be noted in passing that database packages often offer aids for simple arithmetic. One of these, SUM (or ADD), could be used to obtain totals of all potential bee-keepers rather than just the grid-squares where at least one was present. Hence the following type of command clause could be given, shown here for RESULT a:

SUM < Farm_Honey IN RESULT a> GIVING TOTAL_a

After these initial results were obtained from the database it was decided to pick two hundred applicants for the bee-keeping trials. A final modification was to place some limit on numbers of bees likely to feed off each pollen supply. This could be done by restricting the number of bee-keepers in each grid-square to a maximum of five. The largest number of potential bee-keepers per grid-square was seventeen, but in most cases there were only two or three.

The example described here illustrates that extra fields can be added to a database in order to deal with questions that were not considered when it was first established. It is as well to be aware of this type of growth of the database at the onset of a project.

8.8.6 Modifying the database for a study of tree growth

In the previous example extra fields were added to the database, but now the opposite process will be discussed -- that of reducing the size of the database. For instance only part of the study area may be required, or only a limited number of fields need to be retained. The procedures for doing this have already been described in Chapters 6 and 7.

Suppose that a forester wishes to set up a database to assist in a tree-planting programme in the study area. The forester would probably want to retain information on elevation, aspect, slope, soils, erosion, roads and settlement but would be unlikely to need all the other information. Accordingly, the following database statement could be made, in which the command PROJECT saves only the fields that are specified:

PROJECT <STUDY_A> BY Orthophotograph, Ref, Elevation,

Dominant Aspect, Slope, Dominant Soil, Erosion Potential, Land Potential, Road_1, Road_2, Road_3, Households;

SAVE TREE_DB

This new database (called TREE_DB) would then be available for further changes -- for example some new fields could be added. But first a command such as REORG (Reorganise) might be used. This command is often available in a database package to permit adding new fields, editing existing field definitions and deleting superfluous fields. In this particular case the command:

REORG <TREE_DB>

might produce a display on the screen as indicated in Figure 8.15.

(Figure 8.15 about here)

The cursor would be positioned immediately after the last field with the invitation to enter a new field. Several new fields might then be entered, such as:

(a) Number and name of tree species 1 planted in year 1, called (say) T1_1 and T1_Name

(b) Growth (average) of these trees in year 2,3 and 4 called (say) G1_2, G1_3 and G1_4

(c) Numbers of trees remaining in each year (say) R1_2, R1_3 and R1_4

(d) Similar fields for tree species 2 and average growth over the same period.

As each field is specified, the database package would require instructions from the user regarding the form of data entry (alphabetical, whole numbers, decimal numbers etc.). When the new fields have been specified and the EXIT function used, some delay would occur because all records in the existing database would need to be reorganised. A new record from the database might then look like that in Figure 8.16.

(Figure 8.16 about here)

As can be seen in Figure 8.16, the new fields will be present, but contain no data. Alphabetic fields will be left blank, whole number fields will be shown as zero and decimal number fields will be shown by 0.0. All the records in the database, irrespective of whether the grid-squares are planted with trees or not, will display the changed form. Once the new data have been entered, it will be up to the user to perform a SELECT and SAVE operation in order to eliminate unwanted records. For example, a selection could be performed on records where T1_1 NE 0 and T2_1 NE 0 (i.e. Not Equal to zero). This would select only the records where the particular trees were present.

8.8.7 Alternative method of obtaining tree database

An alternative, but equally favourable, method of obtaining the same database described above would be to construct a totally independent database of just the tree growth statistics but containing the same grid reference numbers as in the main database (STUDY_A). A record from such a database (called say TREE_GRO) would then look like the one in Figure 8.17.

(Figure 8.17 about here)

The next step would be to join the database TREE_GRO with the original database STUDY_A, using the following command:

JOIN <STUDY_A> <TREE_GRO> MATCHING Ref

SAVE RESULT

This would produce the identical database to the one built up by adding extra fields. The join operation would combine all fields from both databases (STUDY_A and TREE_GRO) where the reference numbers matched (and any records where no agreement was found would be eliminated). Following the join operation, the new database would be copied and renamed (say to NEW_TREE).

Finally, it may be helpful to give an example of what could be done with the database NEW_TREE (or with the identical database TREE_DB). Suppose that tree growth is considered good if after 2 years it exceeds 8%, after 3 years 15% and after 4 years 20%. In order to discover the characteristics of such grid-squares the following query could be put to the database:

SELECT <NEW_TREE> WHERE G1_2 GT 8 AND G1_3 GT 15 AND G1_4 GT 20

LIST <RESULT> BY Ref, Elevation, Dominant Aspect, Slope, Dominant Soil

The results would then be listed on the screen in a table with five columns and as many rows as there were grid-squares which satisfied the selection criteria. A table of this kind is shown here (Table 8.5). If need be, these results could be printed as they stand, or presented in map form (see next section).

(Table 8.5 about here)

8.8.8 Road planning -- production of maps

A description of computer mapping procedures is beyond the scope of this book. However, it may be of interest to give some indication of what can be done as regards mapping the results of a database selection.

A question was raised about the suitability of roads in the study area for transporting timber. Both primary and secondary roads were known to be adequate, whereas tertiary roads (rough tracks) were often unsuitable when steep. Accordingly a database selection was made of roads in the study area as follows:

SELECT <STUDY_A> WHERE Road-1 GT 0 OR Road-2 GT 0 OR (Road-3 GT 0 AND Slope LE 4)

In this selection a search was made for the presence (i.e. Greater Than 0) of primary and secondary roads (Roads 1 and 2) and for the presence of tertiary roads of gentle slope (Slope Less Than category 4). The grid-squares which satisfied these criteria were then plotted out in map form as shown in Figure 8.18.

(Figure 8.18 about here)

Many other selections were also mapped in this way and were often useful for planning purposes. However, sufficient examples have been given from this land-use study to show that a database may be used for many different purposes. Some of these purposes were quite unforseen at the outset of the project, and only presented themselves once the data were organised into a coherent form suitable for rapid analysis: in other words, once the data were contained in a database.

BACK