National EMSC Data Analysis Resource Center
When you are collecting data in a database, you need a unique identifier for each of the individual items you are collecting. This identifier is usually called a variable or database element. The identifier is called a variable because the data it contains (the data element) can vary depending on the individual record.
For example, suppose you were collecting information about the color of pediatric patient's eyes for a research project. You may create a variable named "Eye Color " which could have values of "Blue," "Green," or "Brown." These values are text values for the "Eye Color" variable. A variable could also store numeric values such as 1 for blue eyes, or 2 for green eyes, etc.
It is important to define the variables and what type of data elements they contain in a manner that will help those who are analyzing your data to be able to quickly identify the type of information they are reviewing.
When creating variables it is strongly suggested that you create a variable that has meaning to you - so you don't always have to look up and remember what the variable means.
For example, suppose we decided to call our "Eye Color" variable "EC" because it was short and simple. When you or someone else reviews your database later, it could be difficult to remember what "EC" means.
The variable should also be easy to use (as in typing) and easy to remember, but still meaningful.
For example, "Prfmc_Msr_1a" vs "PerfMeasure1a." The variable "Prfmc_Msr_1a" is difficult to type and you may have to remember that "Prfmc_Msr" was an abbreviation for Performance Measure.
You should also build a standard "naming convention" for your database variables.
Some good practices for naming variables are:
You should be aware that variables can store different types of information. This can vary between different software applications. Always consult your database software for the variable types specifically setup for that particular software application. Below are some of the common types followed by an example usage:
No matter how clear you think your definitions are, it always helps to have a road map or resource that you or someone else can view to see how you'd like to setup the database OR how to interpret the database. A data dicitionary is the answer!
Common definitions to include are: