A database system includes a number of pre-prepared reports, which can be automatically produced. The reports are the output from the sampling programme. In this section, we shall deal only with one type of report, namely the reports specifying the quantitative content of the database, that is the number of records of each type, who collected the data where and when (the administrative reports). The database reports for wider distribution, the primary output from the database will be dealt with in Section 6.8.
The administrative reports are mainly for the internal evaluation of the sampling programme. They are used to modify the sampling programme in order to make the best use of the limited resources available. Furthermore, the administrative reports can be used to compute the average costs of samples for the different fleets at different locations, when combined with the accounting records of the sampling programme. One could include the costs of sampling in the catch effort database, but the costs of sampling should be kept distinct from the fisheries statistics.
When an interview form is filled in, it will contain information on who (the enumerator) filled in the form and who entered the data into the computer. This information is needed for the subsequent validation (and, if applicable, correction) of data.
The database will thus be able to produce tables, which summarises the activities of all enumerators and encoders. The database contains a look-up table with all the particulars of the entire staff of the sampling programme. A person becomes an authorised staff member of the data collection programme, by being included in the table of staff members. Only authorised persons can enter data in the database.
Apart from reports on the staff activities, the administrative reports comprises summaries of data collection activities, such as:
Number of interviews by fleet, month, province (or landing place).
Number of frame survey samples by province (or homeport) by month and fleet.
Number of vessel registrations by province (or homeport) by months and fleet.
Number of species composition samples by commercial group, fleet, month, province (or landing place).
Number of biological samples (e.g. length frequency samples).
To make the full use of these samples for the improvement of stratification, the administrative reports should also indicate the weight and value of landings represented by the samples.
The user who wants to apply the data for non-standard (e.g. research) purposes is not satisfied with the pre-prepared reports. She/he will need the data structured a specific way, to allow for some specific processing. It is the experience of the author that in practice the database system never contains all the reports you need. It is more or less impossible to predict every request for a report from every user. The skill to extract of data from the database is the primary skill you need to make full use of the database. Although this skill is often considered restricted to “computer experts” it is recommended that also other users acquire the basic skill to extract data.
In order to do this, the database user must master the SQL language. This is the tool by which you can extract data from a database, and by which you can do the first processing of the data, such as summation, grouping, calculating averages, etc. The part of SQL dealt with here, deals only with the creation of “Queries” (SQL contains a lot more than the query).
This section is by no means an attempt to teach the universal database language, SQL. The interested reader is referred to one of the many textbooks on SQL (e.g. Stephens et al. 1997). This section is to inform the reader with no or little background in database theory about the existence of SQL, and to give brief some idea of what the SQL is.
A query in SQL is most often constructed the following way (SQL-words are in capitals):
SELECT | |
(The columns you want in the table) | |
FROM | |
Where the data should come from, (from one or several Tables) | |
WHERE | |
(The subset of data, say, only data from 1 Oct 1996 to 30 Sep 1997) |
You may furthermore add: “GROUP BY” in case you want to sum or average over a group, say, a fleet.
One good reason for knowing some SQL is that it puts the user in a position to define exactly which data she/he wants. Should the knowledge of SQL and the database not be sufficient to complete the job, the user will be competent to complete the job with a little help from a “computer expert”.
We illustrate the SQL by a simple (hypothetical) fisheries database with only three tables. One table is an input data table “Landings” and there are two look-up tables “L_Species” and “L_Vessel_Register” (see Table 6.6.1).
Table 6.6.1 Tables of hypothetical data for demonstrating a fisheries database.
Table: Landings
Landings_ID | Species_Code | Landings_Kg | Vessel_Code | Date_Of_Landing |
1 | SAR | 2 | HP17 | 11-Jan-98 |
2 | TPR | 3 | HP17 | 11-Jan-98 |
3 | SCR | 1 | HP17 | 12-Jan-98 |
4 | LOB | 4 | HP17 | 12-Jan-98 |
5 | GRP | 3 | QN19 | 12-Jan-98 |
6 | SAR | 6 | QN19 | 13-Jan-98 |
7 | KMC | 11 | HP83 | 13-Jan-98 |
8 | TPR | 2 | HP83 | 15-Jan-98 |
9 | TBR | 2 | QN01 | 15-Jan-98 |
10 | SQU | 3 | QN01 | 15-Jan-98 |
11 | LOB | 5 | QN01 | 16-Jan-98 |
12 | CUF | 1 | QN01 | 16-Jan-98 |
13 | GCL | 7 | HP17 | 16-Jan-98 |
14 | CRP | 15 | HP17 | 17-Jan-98 |
15 | LOB | 5 | HP17 | 17-Jan-98 |
16 | LOB | 8 | HP83 | 17-Jan-98 |
17 | LOB | 2 | HP83 | 17-Jan-98 |
18 | WSH | 4 | HP83 | 19-Jan-98 |
19 | CUF | 2 | QN01 | 18-Jan-98 |
20 | MAC | 6 | QN01 | 18-Jan-98 |
21 | SAR | 8 | HP17 | 19-Jan-98 |
22 | WSH | 5 | HP17 | 19-Jan-98 |
23 | TRV | 10 | HP83 | 19-Jan-98 |
28 | TPR | 5 | HP83 | 19-Jan-98 |
29 | CUF | 11 | QN01 | 20-Jan-98 |
30 | TBR | 8 | QN01 | 20-Jan-98 |
31 | TRV | 12 | QN01 | 20-Jan-98 |
32 | SCR | 4 | HP83 | 20-Jan-98 |
33 | SCR | 10 | HP17 | 20-Jan-98 |
Table: L_Species
Species_Code | Name_of_Species | Price_Per_Kg |
CUF | Cuttlefish | 4 |
GCL | Giant Clam | 15 |
GRP | Grouper | 21 |
KMC | King Mackerel | 17 |
LOB | Lobster | 40 |
RSN | Red Snapper | 10 |
SAR | Sardine | 6 |
SCR | Swimming Crab | 23 |
SNL | Snail | 12 |
SQU | Squid | 14 |
TBR | Threadfinned bream | 5 |
TPR | Tiger Prawn | 32 |
TRV | Trevally | 3 |
TUN | Yellowfin Tuna | 11 |
WSH | White Shrimp | 23 |
Table: L_Vessel_Register
Vessel_Code | Name_of_Vessel |
HP17 | Viet Nam Star |
HP83 | Bien Dong |
QN01 | Halong 408B |
QN19 | Bac Bo explorer |
The table “Landings” contains the total landings (“Landings_Kg”) by species and by vessel (“Species_Code” and “Vessel_Code”, respectively) and the date landed (“Date_Of_Landing”). The look-up table “L-Species” converts the 15 species codes of this example, into 15 species names (“Name_Of_Species”) and it contains the price per kg, which is thus assumed to remain constant. Eventually, there is the vessel register, “L_Vessel_Register”, which in this hypothetical example contains only 4 vessels.
The Landings-table has a key field, “Landings_ID”, which is a unique number for each record. This unique number is used to secure the integrity of data, For example, landings_ID 16 and 17 are both with LOB (Lobster) landed by vessel HP83 on the 17th January 1998. The reason could be that two different merchants bought lobsters from HP83 on the 17th January.
The “Landings_ID” values are arbitrary numbers created by the database system. Had the “Landings_ID” not been there, there would have been two records with the same keys (“Species_Code”, “Vessel_Code” and “Date_of_Landing”) and a relational database would not accept it.
Table 6.6.2.a. Queries of hypothetical demonstration fisheries database (presented in SQL language and resulting table).
Query 1: (SQL)
SELECT
Landings.Species_Code,
Landings.Landings_Kg,
Landings.Date_Of_Landing
FROM
Landings;
Query 2: (SQL)
SELECT
Landings.Species_Code,
Landings.Landings_Kg,
Landings.Date_Of_Landing
FROM Landings
WHERE
Landings.Species_Code = ‘LOB’;
Query 3: (SQL)
SELECT
Landings.Species_Code,
Landings.Landings_Kg,
Landings.Date_Of_Landing
FROM
Landings
WHERE
Landings.Species_Code IN
(‘LOB’,‘TPR’,‘SCR’,‘WSH’)
AND
Landings.Date_Of)_Landing >
#1/12/98#;
Query 1
Species_Code | Landings_Kg | Date_Of_Landing |
SAR | 2 | 11-Jan-98 |
TPR | 3 | 11-Jan-98 |
SCR | 1 | 12-Jan-98 |
LOB | 4 | 12-Jan-98 |
GRP | 3 | 12-Jan-98 |
SAR | 6 | 13-Jan-98 |
KMC | 11 | 13-Jan-98 |
TPR | 2 | 15-Jan-98 |
TBR | 2 | 15-Jan-98 |
SQU | 3 | 15-Jan-98 |
LOB | 5 | 16-Jan-98 |
CUF | 1 | 16-Jan-98 |
GCL | 7 | 16-Jan-98 |
SCR | 15 | 17-Jan-98 |
LOB | 5 | 17-Jan-98 |
LOB | 8 | 17-Jan-98 |
LOB | 2 | 17-Jan-98 |
WSH | 4 | 19-Jan-98 |
CUF | 2 | 18-Jan-98 |
KMC | 6 | 18-Jan-98 |
SAR | 8 | 19-Jan-98 |
WSH | 5 | 19-Jan-98 |
TRV | 10 | 19-Jan-98 |
TPR | 5 | 19-Jan-98 |
CUF | 11 | 20-Jan-98 |
TBR | 8 | 20-Jan-98 |
TRV | 12 | 20-Jan-98 |
SCR | 4 | 20-Jan-98 |
SCR | 10 | 20-Jan-98 |
Query 2:
Species_Code | Landings_Kg | Date_Of_Landing |
LOB | 4 | 12-Jan-98 |
LOB | 5 | 16-Jan-98 |
LOB | 5 | 17-Jan-98 |
LOB | 8 | 17-Jan-98 |
LOB | 2 | 17-Jan-98 |
Query 3
Species_Code | Landings_Kg | Date_Of Landing |
TPR | 2 | 15-Jan-98 |
LOB | 5 | 16-Jan-98 |
SCR | 15 | 17-Jan-98 |
LOB | 5 | 17-Jan-98 |
LOB | 8 | 17-Jan-98 |
LOB | 2 | 17-Jan-98 |
WSH | 4 | 19-Jan-98 |
WSH | 5 | 19-Jan-98 |
TPR | 5 | 19-Jan-98 |
SCR | 4 | 20-Jan-98 |
SCR | 10 | 20-Jan-98 |
Query 4: (SQL)
SELECT
Landings.Species_Code,
L_Species.Name_of_Species,
Landings.Landings_Kg,
Landings.Date_Of_Landing
FROM
L_Species
INNER JOIN Landings
WHERE
Landings.Species_Code IN
(‘LOB’,‘TPR’,‘SCR’,‘WSH’)
AND Landings.Date_Of_Landing
> #1/12/98#;
Query 4
Species_Code | Name_of_Species | Landings Kg | Date Landing |
SCR | Swimming Crab | 15 | 17-Jan-98 |
SCR | Swimming Crab | 4 | 20-Jan-98 |
SCR | Swimming Crab | 10 | 20-Jan-98 |
LOB | Lobster | 5 | 16-Jan-98 |
LOB | Lobster | 5 | 17-Jan-98 |
LOB | Lobster | 8 | 17-Jan-98 |
LOB | Lobster | 2 | 17-Jan-98 |
WSH | White Shrimp | 4 | 19-Jan-98 |
WSH | White Shrimp | 5 | 19-Jan-98 |
TPR | Tiger Prawn | 2 | 15-Jan-98 |
TPR | Tiger Prawn | 5 | 19-Jan-98 |
Note that “IN” (Queries 3 and 4) is used to express the condition that a field value belongs to a pre-specified set of values. Note further the character “#” is used to signal that numerical characters refer to a date.
Query 5 (see Table 6.6.2.b) extends and modifies Query 4. It illustrates the calculations and the “AS”-command. The species code has been removed, and the price per kg has been added. The query also makes a calculation, namely the value of the landings “Landings.Landings_Kg*L_Species.Price_Per_Kg AS Value”. The “AS” command is used to give a new name to a variable. Note the expression “INNER JOIN .... ON ....” in Query 5, which links the records with the same species code in two tables.
Query 6 (see Table 6.6.2.b) extends Query 5. It joins Query 5 with the vessel register and adds the columns with the vessel codes.
Query 7 (see Table 6.6.2.c) simplifies Query 6, to facilitate the introduction of the concepts in Query 8.
Query 8 (see Table 6.6.2.c) extends Query 7. It illustrates the “GROUP BY”-command and the “SUM”-function. It groups the records by vessel, and computes the sum for each vessel.
Query 9 (see Table 6.6.2.c) extracts data from another query (Query 8), not from the tables. It computes the sum of all vessels. This works because each query creates its own table.
This example of SQL represents only a small fraction of the SQL commands and functions. The commands presented here are not given a comprehensive explanation. It is hoped, however, that the reader has been given the impression that SQL is a very powerful tool for data manipulation. To be able to utilise a relational database fully, an advanced user must master SQL.
Table 6.6.2.b. Queries of hypothetical demonstration fisheries database (presented in SQL language and resulting table). Continued.
Query 5: (SQL)
SELECT
L_Species.Name_of_Species,
Landings.Landings_Kg,
Landings.Date_Of_Landing,
L_Species.Price_Per_Kg,
Landings.Landings_Kg*L_Species.Price_Per_Kg
AS [Value]
FROM L_Species
INNER JOIN Landings
ON Landings.Species_Code =
L_Species.Species_Code
WHERE Landings. Species_Code IN
(‘LOB’,‘TPR’,‘SCR’,‘WSH’)
AND Landings. Date_Of_Landing>#1/12/98#;
Query 5
Name_of_Species | Landings_Kg | Date_Of_Landing | Price_Per_Kg | Value |
Swimming Crab | 15 | 17-Jan-98 | 23 | 345 |
Swimming Crab | 4 | 20-Jan-98 | 23 | 92 |
Swimming Crab | 10 | 20-jan-98 | 23 | 230 |
Lobster | 5 | 16-Jan-98 | 40 | 200 |
Lobster | 5 | 17-Jan-98 | 40 | 200 |
Lobster | 8 | 17-Jan-98 | 40 | 320 |
Lobster | 2 | 17-Jan-98 | 40 | 80 |
White Shrimp | 4 | 19-Jan-98 | 23 | 92 |
White Shrimp | 5 | 19-Jan-98 | 23 | 115 |
Tiger Prawn | 2 | 15-Jan-98 | 32 | 64 |
Tiger Prawn | 5 | 19-Jan-98 | 32 | 160 |
Query 6: (SQL)
SELECT
L_Species.Name_of_Species, Landings.Landings_Kg,
Landings.Date_Of_Landing,L_Species.Price_Per_Kg,
Landings.Landings_Kg*L_Species.Price_Per_Kg AS [Value],
Landings.Vessel_Code
FROM L_Vessel_Register
INNER JOIN (L_Species
INNER JOIN Landings
ON Landings. Species_Code = L_Species. Species_Code)
ON L_Vessel_Register.Vessel_Code = Landings.Vessel_Code
WHERE Landings.Species_Code IN (‘LOB’, ‘TPR’, ‘SCR’,‘WSH’)
AND Landings.Date_Of_Landing>#1/12/98#;
Query 6
Name_of_Species | Landings_Kg | Date_Of_Landing | Price_Per_Kg | Value | Vessel_Code |
Tiger Prawn | 2 | 15-Jan-98 | 32 | 64 | HP83 |
Lobster | 8 | 17-Jan-98 | 40 | 320 | HP83 |
Lobster | 2 | 17-Jan-98 | 40 | 80 | HP83 |
White Shrimp | 4 | 19-Jan-98 | 23 | 92 | HP83 |
Tiger Prawn | 5 | 19-Jan-98 | 32 | 160 | HP83 |
Swimming Crab | 4 | 20-Jan-98 | 23 | 92 | HP83 |
Swimming Crab | 15 | 17-Jan-98 | 23 | 345 | HP17 |
Lobster | 5 | 17-Jan-98 | 40 | 200 | HP17 |
White Shrimp | 5 | 19-Jan-98 | 23 | 115 | HP17 |
Swimming Crab | 10 | 20-Jan-98 | 23 | 230 | HP17 |
Lobster | 5 | 16-Jan-98 | 40 | 200 | QN01 |
Table 6.6.2.c. Queries of hypothetical demonstration fisheries database (presented in SQL language and resulting table).
Query 7: (SQL)
SELECT
Landings.Landings_Kg,
Landings.Landings_Kg*L_Species.Price_Per_Kg AS[Value],
Landings.Vessel_Code
FROM L_Vessel_Register
INNER JOIN (L_Species
INNER JOIN Landings
ON Landings.Species_Code = L_Species.Species_Code)
ON L_Vessel_Register.Vessel_Code = Landings.Vessel_Code;
Query 7
Landings_Kg | Value | Vessel_Code |
2 | 12 | HP17 |
3 | 96 | HP17 |
1 | 23 | HP17 |
4 | 160 | HP17 |
3 | 63 | QN19 |
6 | 36 | QN19 |
11 | 187 | HP83 |
2 | 64 | HP83 |
2 | 10 | QN01 |
3 | 42 | QN01 |
5 | 200 | QN01 |
1 | 4 | QN01 |
7 | 105 | HP17 |
15 | 345 | HP17 |
5 | 200 | HP17 |
8 | 320 | HP83 |
2 | 80 | HP83 |
4 | 92 | HP83 |
2 | 8 | QN01 |
6 | 102 | QN01 |
8 | 48 | HP17 |
5 | 115 | HP17 |
10 | 30 | HP83 |
5 | 160 | HP83 |
11 | 44 | QN01 |
8 | 40 | QN01 |
12 | 36 | QN01 |
4 | 92 | HP83 |
10 | 230 | HP17 |
Query 8: (SQL)
SELECT
Landings.Vessel_Code,
SUM(Landings.Landings_Kg) AS [Total Kg landed],
SUM(Landings.Landings_Kg*L_Species.Price_Per_Kg) AS [Total
Value]
FROM L_Vessel_Register
INNER JOIN (L_Species
INNER JOIN Landings
ON Landings.Species_Code = L_Species.Species_Code)
ON L_Vessel_Register.Vessel_Code = Landings.Vessel_Code
GROUP BY Landings.Vessel_Code;
Query 8
Vessel_Co de | Total Kg landed | Total Value |
HP17 | 60 | 1334 |
HP83 | 46 | 1025 |
QN01 | 50 | 486 |
QN19 | 9 | 99 |
Query 9:(SQL)
SELECT
Sum([Query_8].[Total Kg landed]) AS [Sum Kg landed],
Sum ([Query_8].[Total Value]) AS [Sum of Value],
Count(*) AS [Count Samples]
FROM Query_8;
Query 9
Sum Kg landed | Sum of Value | Count Samples |
165 | 2944 | 4 |