Abstract

The manner by which a biologist collects, stores, and understands the relations between data is often completely different from the way a computer analyst views data. Even though databases are supposed to be relationally designed (i.e. built on relations between the data entities), this usually never happens. In real life, the biologist starts collecting data for a scientific purpose and then contacts a computer analyst (CA) in the IT department to help develop a database for the data collection schema after it has commenced. From a brief discussion with the biologist, the CA designs and implements a table structure (database). The product then gets turned over to the biologist, and it is now up to the biologist to understand the relations that the CA had in mind when developing the database. The database will not be the helpful tool it was intended to be; instead, it is often a troublesome data storage system that the biologist is stuck with in the future. To make matters worse, the database is rarely documented and if/when the CA leaves/retires from the organization no one will completely understand the database structure.\Thus, what is a relational database design? Is it (1) a design that promotes the relations and business rules of the collected data, or (2) a normalized relational design that the Computer Analyst creates from theories he/she has read about in a computer book? Most databases are constructed based on (2). However, this makes most databases hard to work with if not useless to most biologists. So how can this be changed? To construct a database that will be successfully used, concepts from both (1) and (2) must be included when designing the database structure. This presentation will focus on how this can be achieved.

PDF Preview