In my quest for creating a database that allows me to track individual gulls and the markers that they are fitted with (rings, wing tags, and so on), I have been trying to come up with a new database structure to accommodate this.
I started out by finding out what it was exactly that I wanted the system to be able to do:
- Define an individual bird
- Keep track of any number and any kind of combination of rings that a bird is fitted with
- Keep track of ring damage, ring loss, ring replacement, and ring re-use
- Ability to enter the same type of ring multiple times
I realized that this translated into the following entities:
- An individual bird
- One or more markers that the bird is fitted with
- A history of when markers are fitted, damaged, lost, replaced, or re-used
- A history of when a bird is observed
Or in other words: A bird is fitted with markers (one or more rings, wing tags, and so on). These markers possibly degrade over time and may even be lost and/or replaced by another set of markers. Markers can also be retrieved from dead birds and re-used on other birds. All these events should be logged, as well as the observations of the bird during its life time (during which it might be fitted with multiple sets of markers).
Complicated ringing scenarios
Things were made difficult by some complicated scenarios in the way birds are ringed. Some examples:
- A bird can initially be fitted with one ring and have another ring added later.
- Same as the first scenario, but now the original ring is replaced by another ring.
- A bird is fitted with multiple rings, one of them is lost, another ring is added while the other remaining ring is refitted to the other leg.
- Two identical rings (same type, color and code but from different projects) are fitted to two birds of the same species.
- A bird is fitted with multiple colored rings without inscription.
The challenge was to find a way to record all these events and at all times be able to see which rings the bird is currently fitted with and be able to display information showing when the rings were fitted.
After trying out various ideas, I realized that the only solution is to record each individual bird and each individual marker as separate entities. By creating database relationships it is then possible to assign one or more markers to a bird or even multiple birds. Defining whether a marker is currently still fitted can be tracked by a “yes/no” state.
The following videos show how each of the above scenarios are entered, using FileMaker Pro 12 Advanced.
Note: the design shown is merely to proof the concept; it lacks useability and additional functionality.
Scenario 1. A bird is fitted with one ring and has another ring added later
In this scenario, 2 different rings are fitted on different occasions. The result is a bird wearing 2 rings.
The following video shows the following steps:
- Adding the individual bird
- Adding the marker (the ring that is to be fitted)
- Adding the marker event (the ring being fitted)
- Adding the second marker and the second event
Notice how the markers and events are related to the bird.
Scenario 2. A bird is fitted with a ring which is later replaced by two other rings
This scenario demonstrates how to mark a ring as the ring that a bird is currently fitted with, and how to mark a ring that a bird used to be fitted with.
Scenario 3. A bird is fitted with multiple rings, one of them is lost, another ring is added while the other remaining ring is refitted to the other leg
This scenario demonstrates tracking rings that are lost, replaced and re-fitted to another leg.
Scenario 4. Two identical rings (same type, color and code but from different projects) are fitted to two birds of the same species
This scenario demonstrates the possibility of logging different birds (but of the same species) wearing identical rings.
Scenario 5: A bird is fitted with multiple colored rings without inscription
In this scenario, a bird is logged with 2 color rings without inscription and one metal ring.
This concept seems to be working very well and holds its own in every scenario that I throw at it.
I will keep it as the main foundation for now and will start adding other functionality to it. I will have to see though how the useability holds up when I start adding other features. I won’t commit to anything yet, so any feedback or advise is welcome.
The challenge now is to keep the whole workflow user friendly. Because the database will eventually hold many thousands of different rings and birds, it is important that linking the different entities is done with ease.