Introduction to Data Modeling for Physiology: The Human Endocrine System

Research in data modelling of human physiology is at an early stage.  The BioPAX¹¹, which first met in 2002, is a collaborative effort to create a data exchange format for biological pathway data.  The Open Biomedical Ontologies¹⁰ project is a focus point for modelling of information for shared use across different biological and medical domains.  This includes the OBO Ontology Browser, which lists a number of different vocabularies.  There is a vocabulary for human development anatomy and another for human disease.  Systems Biology Markup Language¹² (SBML) is another project focussed on computer-readable format for representing models of biochemical reaction networks.  In a project closely related to the example in this paper Van Durme et al have created a Glycoprotein-hormone Receptors Information System²².

See the page Resources for Research in Medical Computing on this site for more discussion on research in this area.

Goals for the Data Model

It is important to understand your goals before creating a data model.  Otherwise, you are likely to go in circles and have contrdictions emerge.  My goals for this data model are

1. It should be capable of being a simplified representation of the human endocrine system, including most of the known hormones that make up this system.
2. It should be able to be used to help people learn about the human endocrine system.  It is an increasing trend to make to make basic medical data freely available over the Internet so their could be a wide range of people may want to make use of this data.  It should not only be able to viewed over the Internet, other software should be able to access the data over the Internet.
   
3. It should be able to reference other data models, in particular, chemistry data models for chemical descriptions of hormones.  Because problems in biomedical sciences don't exist in isolation from one another.

Logical Model

The first step in developing a data model is to look at the data in isolation from any particular technology.  A starting point is the browse over the data to model.  From Purves et al³ you can see that there are a number of basic components of the human endocrine system.  A list of components are the secreting tissues or glands is

• Anterior pituitary
• Posterior pituitary
• Hypothalamus
• Pineal
• Thyroid
• Parathyroids
• Thymus
• Adrenals
• Pancreas
• Ovaries
• Testes

• Secreting tissue or gland
• Name of the hormone
• Chemical nature
• Targets
• Important properties or actions

The next step in logical data model is to determine what the entities are.  According to Patrick and Elizabeth O'Neil in Database Principles, Programming, and Performance⁴, an entity is 'a collection of distinguishable real-world objects with common properties.'  I will divide our entities up into

• Anatomical components (Anterior pituitary, Pancreas, etc)
  
• Hormones (luteinizing hormone, etc)
  
• Chemical nature (peptide, steriod, etc)
  

To define the data model we need to define attributes of the entities.  An attribute is a data item that describes a property of an entity or a relationship between two entities.  The diagram below shows the entities and the attributes.

The names of the entities are shown at the top of the boxes and the attributes are shown underneath.  There are several relationships here:

There are several types of model.  Two common types are entity-relation (ER) and universal modeling language (UML) model.  O'Neil and O'Neil describe entity relation models⁴ and Booch, Rumbaugh, and Jacobson⁷ describe UML if you wish to read further about these modeling techniques.  Actually, the model here is simple enough to be described by either type of model.  I created the diagram above as a UML model using the freely available Omondo UML Eclipse plug-in⁶.  You could have drawn it with a number of other tools, including Microsoft Visio or IBM Rational Software Architect.  The logical model should be considered in isolation from the technology used but the tools tend to be developed around specific technologies.  That can be an advantage when changing the model later and keeping it synchronized with the implementation.

There are several important points to note about the model:

• The names of hormones, anatomical components, and chemical natures should be unique and determined by their names.  We want to avoid situations where we have data items that are not unique.  For example, suppose that we had an anterior pituitary component and a general pituitary component.  Then there could be overlap between data items ('rows').  We don't have to uniquely determine the data items by their names and, in fact, we will use an ID field in the implementation.  If we wanted to globalize our data by translating the names into different languages we would also need the ID or some other key to identify them.
• All the attributes of the entities, aside from the relations (if we call them attributes), are simple types (all strings, actually).  Because each data item is unique and all the attributes are simple types we can say that our model is in first normal form.  This has important implications for implementation, in particular, storing data in a relational database.  There are other normal forms but I will not go intto them here.
• The many to many target relation between hormone and target will require decomposition for a relational database.  This would be a mapping table with two fields, a hormone reference and an anatomical component reference, to specify the target relation.  However, in other implementations, such as XML and object oriented programming languages, the relation can be implemented as a multi-valued attribute on the hormone entity.
  
• I have added an attribute for a picture of the molecule and anatomical component and for the chemical structure of hormones.  This will be the location of a file on disk.  This data is sometimes stored as binary large objects (BLOB's) in databases.  That may be important in some cases but not always.