Many personal computers have database software which provides the functions for building a shell collection catalogue and the preparation of reports, labels, listings from the data. Todays database software uses relational database techniques which permit the linking of data records and give improved cataloguing, retrieval and report production features.
The first key decision in planning such a shell database is to decide the scope of the database. If you collect just one shell family or two, eg Conidae and Olividae like me, then you can plan a database which includes completed data on all cones and all olives and then have a second database with details of your collection. This allows you to not only list details of your collection but to have information on the family of shells and to list the species which you are missing etc.
If you collect all families and species, then the amount of work entering data for all the shells will be a lifetime task. Use the data structures below but only load the data for the species which you have in your collection.
A second decision is the description field for the shell entity. If you limit yourself to 255 chars then you can ask the database engine to search through the descriptions for selected words eg blue cones. If you choose the longer description, with a memo field, then you will probably be unable to search within the descriptions. Decide why you want descriptions and how much data you are prepared to enter.
My experience across several stages of development, has shown that the best data structures are:
Shell Species Entity Database with an entry for each distinct shell type in terms of family, genus, species, subspecies, color form, author etc This is the master database with a specific unique no(shell no) allocated by the system to each entry
Many texts would advise you to define the shell record down to the level of species and subspecies but I would suggest that you go further and include named color forms if you have a specialised collection.This will give you the opportunity to describe color forms from the different geographies in the master database..
Collection Specimen Entity Database with an entry for each individual shell in a collection Each entry for a specimen contains the shell no used in the main database to describe the shell type.
With these two databases, you can have more than one specimen, or none, for each shell record. You can ask the software to create a join and the system will then synchronise and maintain the two databases in harmony. Just watch that you set the delete rules to avoid deletion of the master shell record when you delete a collection record.
You can design a form or screen to enter the shell species data and your collection data from one screen. You can find out how many shell specimens are in your collection for a given species or color form; you can display all the available species data associated with each specimen: you can list your collection, print labels of all sizes; or generate a list for specimens in your collection of a species with sizes etc to try to identify that shell with the missing label!
If you have entered into the shell species database, the details of the complete family or genus, then you can print want lists and begin to have a source of useful data about your chosen specialist shell families.
If you are starting out then I advise version one of your database to be limited to one species or a small subset of your collection. You can add more data later.
My next phase of development (version 2) was to add a Synonyms Entity Database with an entry for each synonym used in the shell families. Each entry contains a shell number link to the master species database. You can have more than one synonym or none for each shell type. Look up a shell and you see all the synonyms. Search on synonym and you find the shell
This proved to be a real bonus when I was travelling and I could unravel all the names local dealers were using to make their specimens unique. But a synonyms database is only of real value if you have loaded data on the complete family or genus.
With a master database of all conus species, subspecies and color forms together with synonyms and collection details, I was able to take my knowledge with me on my portable PC Thinkpad and this served me well for several years.
The ability to take digital pictures is now becoming more common, so I decided that it would be nice to have pictures of the specimens in my collection and maybe get some pictures of the family species members which I was missing. Then I could refer to the database on my travels when internet access to the web shell picture galleries was not available.
Most database applications will allow you to define a picture file and include it in your collection database entry as a field so that each time you look up a specimen the picture is there on the screen. Just watch what size of picture you include since a copy is stored in the database file.This was a great addition to my collection catalogue records(version 3). A picture is worth a thousand words and I was able to show my collection to my friends on my travels.
I could even define a picture field in the master database and capture a picture of the species which I did not have in my collection from copyright free resources on the web. So I ended up with a picture in the master database of the shell and a picture of each specimen in the collection database
This was very successful for I could compare my collection specimen with one available for exchange or sale or I could validate any new species that I was being offered.
The one restriction was that while one picture for each specimen in the collection was sufficient, I began to want more than one picture of a species in the master database. Having color forms entries in the main database was a great advantage since at least, I could have one picture for each subspecies and named color form
Given that I focus on just two families, I have now added in version 4 a prices entity database with prices of specimens. It allows me to enter a the price for a specimen of a given size quality and location. I started by adding the prices of the species which I had on my want list and gradually built a reasonable set of price references for my specialist families.
Recently, in version 5, I began to add a Visual Basic program which takes exported copies of my databases and creates automatically webpages, one for each cone entry, with pictures and details of my collection specimens. These shell pages together with index pages provide a powerful reference, identification and catalogue retrieval tool. To do this, I had to separate my pictures into a picture entity database with an entry for each picture, including its file location/name and links to the specimen and species master databases
Decide your initial scope. Plan an overall design and add data as you build experience. Complete each version before adding more entities.
Keep it simple...if you just want a catalogue then you just need a master record database and a collection database with pictures in your collection database
If in doubt, make the data field as wide as you need; the pictures dictate the size of storage space.
To enter data about a family choose a good publication with a definitive list of species. Don't cry if ,like me, you have just finished an Olividae database according to Petuch and Sargent in "the Atlas of Living Shells" to find Tursch and Griefender produce a new work "Oliva Shells" which redefines the world of Oliva
The data fields will have to be keyed for each species or color form.Where possible use drop down lists for ensuring the quality of repetitive content such as family names, geography areas, etc.
|My Shell Species Database.|
|Record No||Numeric||allocated incremently by the system|
|Common Name||Alpha(75)||popular name for the shell|
|Geographic Range||Alpha(255)||description of countries, oceans etc|
|Geography||Alpha(30)||drop down list of standard ocean geos|
|Size Range Desc||Alpha(255)||notes on size|
|My Collection Database|
|Collection No||Numeric||allocated incremently by system|
|Shell Record No||Numeric||link field to master record database|
|Catalogue No||Alpha(15)||used to identify specimen on label, shell etc|
|Date Catalogue||Date||allocated by computer|
|Storage Reference||Alpha(35)||physical location|
|Quality||Alpha(15)||beach, F+ etc|
|Status||Alpha(10)||eg hold, exchange sell etc|
|Size(mm)||Numeric||alpha for families that require 2 dimensions|
|Description||Alpha(255)||details about specimen|
|Collection Details||Alpha(255)||collected in sand at 1 metre etc|
|My Synonyms Database|
|Synonym No.||Numeric||allocated incrementally by system|
|Shell Record No||Numeric||link to master record database|
|Synonym Type||Alpha(25)||usually synonym; flexibility for other name types|
|My Prices Database|
|Price No||Numeric||allocated by system|
|Shell Record No||Numeric||link to master database|
|My Pictures Database|
|Picture No||Numeric||allocated by the system|
|Shell Record No||Numeric||link to main database|
|Collection Specimen No||Numeric||link to collection database|
|Collection Location Info||Alpha(200)||.|
|Attribution||Alpha(80)||any author rights|
This web page was last updated on 31 August 2003 Copyright of all images remains with the originator and the British Shell Collectors Club and may not be copied without their expressed permission Copyrightę 2003 British Shell Collectors' Club All rights reserved.
Return to the top