Download simple biogeography

Extending the
biogeographical model
Africamuseum
6 (7?) June 2013
Workplan
 Continue with database constructed so far
 Add fields for


Authority (name of the author, date, parentheses)
Classification



Fields for different ranks
Synonymy
Sources
Fields for classification
 Add fields to ‘species’ table for the main ranks:





Kingdom
Phylum (=division)
Class
Order
Family
 Alternative: separate table

Split taxonomy in genus/species, and family and above
 Problem: not properly normalised, not good solution
for long-term management of taxonomic register
Add field for authority
 Add field for authority in the species
table


One text field, not structured further
Too complex to be split up in separate fields
 Optionally, add field for reference to
original description

Ideally as a link to the sources table
Add table sources
 Fields




ID (=primary key, autonumber)
Author
Year
Reference
Relations with sources table
 Add ‘SourcesID’ link in Species table
 Add ‘SourcesID’ link in Distribution table
 Create relations between


Sources and Species table
Sources and distribution table
Add synonymy
 ‘Self-referential’ table


Record in table refers to other record in same table
Needs status of the taxon described in the record
 Create new fields:


AcceptedID
TaxonStatus (optionally link to separate table)
 Create relation:

AcceptedID link to ID of taxon table
Relations diagram - synonyms
One-to-many relationships
 E.g. species in family: each species
belongs to one, and only one family
 Implement by listing the Primary Key of
the ‘one’ side as a field in the table of
the ‘many’ side
 ‘Foreign Key’ points at the right record in
the ‘one’ side of the relationship
One-to-many relationships
(Many) species in
(one) family
(Many) places/localities
in (one) country
Many-to-many relationships?
 Problem: we don’t have a ‘one’ side,
there is no single record to refer to
 Can not be implemented directly in SQL
 Needs extra table


To split up many-to-many in two one-tomany relations
Extra table takes pointers to both sides of
the relationship
Many-to-many relationship
 Example: ‘sources’ versus ‘species’

Source = literature, report, database…
 One source refers to several species
 A species is referred to in many sources
 Create many-to-many table

Split the one many-to-many relationship in
two one-to-many relationships
Many-to-many relationship
Relations diagram - complete
Present structure:
Philosophy
 Structure has to be as simple as possible
 But not any simpler!!
 Present structure is good short-term solution,
but not long-term

Needs better alternative to represent classification
and hierarchy
Hierarchy: flat table
 Every rank in the hierarchy is
represented by a field in the table
 Simplest solution


Easy to create
Easy to query
Hierarchy: flat table
Hierarchy: flat table
 Problems

not normalised!
Not a real problem if a quick-and-dirty solution is
all that is needed
 Difficult to maintain hierarchy in the long term
 ‘Standard’ problems with non-normalised
database

 Possible conflicting information, inefficient storage…

Cfr MASDEA; too simple
Hierarchy: normalised tables
 Every rank is represented by a separate
table
 Not very difficult to write a query to
regenerate flat table
 Every taxon can have additional
information

Extra fields with description…
Hierarchy: cascading tables
Hierarchy: normalised tables
 Avantages


Easy to maintain and query
Normailised, possible to add information at any level of the
hierarchy
 Drawbacks

Ranks are hard-wired on the structure of the database




New rank would require change of the structure of the database
And probably of the user interface, web interface…
Number of tables
Lot of functionality duplicated
Taxonomic reality
 Ranks used depend on the taxonomic group


Botany: mainly infra-specific; zoology: mainly on
higher levels
Many of the ranks are only sparsely used
 Needs for a more flexible system
 Much of the functionality is the same across all
ranks


‘parent’, synonymy
Authority, description…
‘Open Hierarchy’
 Possible to define new ranks without having to
rewrite the structure of the database
 All taxonomic names are stored in a field in a
single table; other fields indicate parent and
rank
 Many-to-one relation: a single parent, several
descendants

Include ID of parent in the record of the
descendant
Open Hierarchy
 Avantages


Completely normalised
Flexible
 Drawbacks

Difficult to query classification


Queries of the type ‘all species of the Echinodermata’…
Solution:



Recursive query
‘calculated field’
program
Synonymy
 Every taxon can have several synonyms;
in principle, only one valid name for any
synonym

Many-to-one relation: one valid name, many
synonymous names
Include ID of the valid name in the record of the
synonymous name
 Other fields for the type of synonymy…

Rest of the taxonomic model
 Ranks should be in a separate table


Information on the level of the rank can be
added
Possibility of extra quality control
Rank of a parent as compared to rank of
descendants
 Rank of siblings should be same

Combine with rest
 Previous work on geography and sources