Databases and Systems

282
To create a database for a specific laboratory protocol, the main tasks are to give
names to the Materials and Steps of interest, and to describe the data to be reported in
each Step.
Steps are generally obvious, because they correspond to the actual work being
done in the laboratory protocol. The main subtlety is ensuring that Steps correspond
to useful points of contact between the laboratory and the computer. In our running
example, possible Steps include ones reporting (i) that a library has been constructed,
(ii) that a clone has been picked and plated, (iii) that sequence-template has been
prepared from a clone, (iv) that sequence-template has been loaded onto a sequencing
machine and run, (v) the results of a sequencing-run, e.g., base-calls, quality
indicators, and chromatographs, (vi) the results of vector stripping and quality
screening of sequencing results, (vii) the results of assembling sequences, and (viii)
the results of analyzing sequence-assemblies.
Many Materials are equally as obvious, because they correspond to the major
reagents employed in the protocol, e.g., libraries and clones, or the major data
produced by the protocol, e.g., sequence-reads and assemblies. As with Steps, the
main danger is excess: Materials should only be defined for things that are really
worth tracking. Limitations in our current software push strongly in the direction of
parsimony. The mechanism mentioned above for connecting Step-data to Materials
only works for Steps operating directly on a Material; it does not work transitively
over related Materials. While it is easy to get the base-calls for a sequence-read, and
a list of all sequence-reads for a given clone, and a list of all clones picked from a
library, the software offers no special help for getting all base-calls for all sequencereads
for a given clone or library. A second limitation is that LabFlow (see later
section) only supports workflows in which a single kind of Material marches through
a protocol. The effect of these limitations is to encourage database designs in which
multiple real-world material are elided into a single database-Material. In our
example, it would probably be best to represent libraries as Objects (not Materials),
and to merge clones and sequence-reads into one Material; assemblies would
probably remain as separate Materials. The end result is a database with just two
kinds of Materials: sequence-reads and sequence-assemblies.
To recapitulate, the database for our running example would have just two kinds
of Materials, sequence-reads and sequence-assemblies, and many kinds of Steps,
each operating on one Material. One of the possible Steps listed earlier, namely, the
one reporting on library construction, must fall by the wayside, since we have
decided to represent libraries as Objects, not Materials; data on library construction
would be stored as fields of these library Objects. The most obvious, practical
shortcoming of this example database is that without a clone Material, we lose the
most natural means of coordinating multiple reads from the same clone. In the
database as given, one would probably coordinate multiple reads per clone in the
context of sequence-assemblies; this may be workable but is certainly not ideal.