Chapter Three: Incorporating Agrodiversity Data into the PLEC Database
Introduction
After the PLEC Biodiversity database is up and running it can be expanded to
include related data. Related data will primarily fall into the category of agrodiversity
data, but can also include socioeconomic surveys (see China Agrodiversity Database),
GPS coordinates (see chapter six), etc. An Access table must be created to hold data
before they can be linked to the database. Next, at least one of the fields within the new
table must be linked to the database through a relationship. For instance, if the new table
contains information on management techniques in plots, it can be linked to the plot
number field in the Plot Description table. Once the relationship is created, the new table
becomes part of the database and can be sorted, summarized, and analyzed in queries,
forms, and reports. This chapter will explain how agrodiversity data can be organized
into a table and linked to the main database. Converting qualitative data into categorical
or quantitative data is also discussed. The Amazonia Management Database will be used
as an example. This chapter, however, should act as a guide for the reader to create
unique agrodiversity tables that reflect the data available to a specific cluster.
Relationship, Scale, and Categorization
In the PLEC Amazonia Management Database, management information is
collected on more than one scale. General data on the management of an entire sample
area, including data on seed broadcasting and vine removal, are linked by sample area
number to the Sample Area table. Specific management data on species in a particular
plot are linked to the database via the plot ID field in the Species Data table. Data should
be organized according to scale before creating tables. If data are about a single species
and vary from plot to plot, they should be linked to the Species Data table. Data on
management techniques that encompass an entire sample area, for instance plowing or
irrigation, should be linked to the Sample Area table. Data regarding a specific species
that does not vary from plot to plot or farmer to farmer can be linked to the Species List
table. Organizing data according to scale will make for clearer and less redundant
relationships (see box 3.1).
14
Databases can store just about any type of data. However, for quantified or
discrete data numerous summary and analysis options are available, while qualitative data
offer fewer statistical options.
Incorporating qualitative data, especially management
data, into a database requires categorization or quantification. In Amazonia, for example,
Fernando Rabelo has recorded extensive descriptions of seed dispersal and seedling
transplanting by farmers in their fallows. While these descriptions are an important part
Box 3.1: Scope and Relationships
Scope
General
General
Types of Data
Data describing
management practices in
the whole sample area
including watering,
plowing,etc.
Link
Tables
SampleAreaID
Sample Area
Table
Data describing
management practices in
plots including weeding,
fertilizing, etc
PlotNumber
Plot
Description
Table
er
mb
Pl
Specific
Specific
Data describing
management
practices for
specific species
u
otN
SpeciesID
Species List
Table
This figure outlines how data can be grouped according to scope and linked to tables in the
Agrobiodiversity Database. It should be noted that the scope of the data can vary depending on how
the data is recorded. For instance, data on fertilizing can be collected on either the plot or sample
area level. Data describing management practices for specific species should be linked to two tables
the Plot Description Table (or Sample Area Table) through the plot number (or SampleAreaID) and
the Species List Table through the species ID.
15
of the Amazonia cluster’s work, they cannot be entirely incorporated into the database
because paragraphs or even sentences cannot be summarized or analyzed in a database.
For this reason, qualitative or descriptive data are categorized as yes/no, multiple choice,
or quantified data. In the case of transplanting and broadcasting, there are two Yes/No
columns in the Fallow/Forest Management table of the Amazonia Management Database.
The transplant and broadcast columns distinguish between fallows where farmers do or
do not broadcast and/or transplant.
With these distinct groupings, analysis can be
performed to compare these two management techniques in relation to any other data in
the database. It is important to note that these techniques can be broken down and
divided into categories of specific types of broadcasting (throwing or selective
placement) or transplanting (bare root or root ball).
Some qualitative data can be
quantified. For instance, weeding and watering cycles can be recorded as ‘weeding per
year’ or ‘watering per month’ and entered into the database as numbers. Depending on
the quantity and quality of data, management tables can encompass a wide range of
specific management techniques on multiple scales. See the Amazonia Management and
Yunnan Agrodiversity Databases on the CD for examples of categorizing management
and socioeconomic data.
Designing a Management Table
Once the data are organized by scope and structured into discrete or quantitative
categories, a management table can be designed. To give an overview of the process the
Amazonia Fallow/Forest Management table will be used as an example. It may be
helpful to open the Amazonia Management Database’s Fallow/Forest Management table
in design view (click once on the table and then select the design icon on the right side of
the window) in order to follow the example.
The necessary components of a new table are (a) the relationship field and (b) the
primary key. The relationship field is the column that will link the table to the database.
The Fallow/Field Management table contains management information for each sample
area. Therefore, each entry into the table is a description of a specific sample area. The
obvious link between this new table and the rest of the database is the Sample Area ID in
the Sample Areas table. By adding a Sample Area ID column to the new management
16
table, each entry can reference the information in the Sample Area table and the rest of
the database through the Sample Area ID of the sample area being described in the new
table. The relationship field can be connected to the database from the relationship
window (see chapter one). The primary key is the field that uniquely identifies each
record stored in the table. The most important point to remember when selecting a
primary key field is that no two values can be the same. In the case of the Amazonia
Management Database, the Sample Area ID was selected as a primary key. Since each
sample area will be only one row in the table and will never be repeated, the Sample Area
ID is the best choice for the primary key. Frequently, as in this example, the relationship
and primary key fields are the same, but this is not always the case.
Once all the fields are categorized and the primary key and relationship fields are
selected, a new table can be constructed (See chapter one for instructions for designing
new tables). The table on the next page provides a brief overview of the process for
converting management information into a database. It should be noted that any of fields
described in the table could be subdivided to include more specific data. For instance,
the timber field can be changed from a Yes/No field to a Number field to incorporate the
quantity of timber extracted. Furthermore, if data are available, the timber field can be
removed and a new table can be created with multiple fields describing the timber
species, quantities, as well as extraction and management methods. Adding management
tables to the database allows one to accurately represent the significant or unique
management practices in the sample area or plot.
When constructing these tables,
important questions to be addressed are: What are the most significant management
practices in this sample area or plot? What are the unique practices in the sample area or
plot? How can these practices be quantified or categorized? Can any of the categories be
further divided to include relevant sub-categories? Finally, the nature of management
and socioeconomic data allows for infinite quantities of tables and fields. While an
extremely large set of tables and fields may be tempting, it is important to recognize the
limits of available data and resources.
17
Observation
Forests and fallows have three
basic purposes.
Field Name
(as in database)
Purpose
Data Type
(as in table design window)
Text
Some
farmers
thin the Thinning/Year
Number
vegetation in their fallows or
Single
forests.
Some farmers remove vines Vines/Year
Number
from their fallows or forests.
Single
Some
farmers
broadcast Broadcasting
Yes/No
economically valuable seeds in
their fallows or forests.
Some
farmers
transplant Transplanting
Yes/No
economically
valuable
seedlings in their fallows or
forests.
Some farmers create gaps in Gaps
Yes/No
their fallows or forests to
facilitate natural regeneration.
Timber is extracted from some Timber
Yes/No
fallows and forests.
Fruits are harvested from some Fruits
Yes/No
fallows or forests.
Some farmers hunt in their Hunting
Yes/No
fallows or forests.
Some farmers plant crops in Crop
Yes/No
their fallows or forests.
To complete the table add the relationship and primary key field
The management data must be
linked to the database through
a relationship.
SampleAreaID
Number
Long Integer
Description
(as in table design window)
Will this be used as an agricultural
field, enriched forest, or is it a
forest (FO)?
How many times will the
vegetation be thinned per year?
How many times will the farmer
remove vines per year?
Does the farmer broadcast seeds in
the area?
Does the farmer
seedlings in the area?
transplant
Does the farmer create gaps in the
area?
Does the farmer extract timber
from the area?
Does the farmer harvest fruits from
the area?
Does the farmer hunt in the area?
Does the farmer plant crops in the
area?
The SampleAreaID of the sample
area in the Sample Area table
18