Attributes in OpenMRS
- Joshua Nsereko
Meaning of the word "Attribute"
Literally, the word "attribute" is a noun and means a quality or characteristic that someone or something has. For example, a person can have a name, address, mobile number and weight, among others. All these are attributes of a person.
In computing (with reference to Java Programming Language), the term "attribute" is used to refer to (a) variable(s) exposed in a Java class and the columns in a database table. An attribute is generally a property of a property.
Every attribute must have a data type in its declaration, which specifies the size and type of values that can be stored in an variable. Data types can be Primitive (Integer, Character, Boolean, and Floating Point.) or Non-primitive (Classes, Interfaces, and Arrays.)
For example, considering the Java class below,
public class MyClass {
int x = 5;
String y = "three";
}
we can deduce that MyClass has attributes x and y (with datatypes int and String respectively) which can be included in the database table as columns. While inserting columns in the database Table, the data type of the attribute must also be specified, otherwise exceptions will occur.
In core OpenMRS, attributes exist and every attribute corresponds to an AttributeType, which defines, among other things, whether it is required, whether it may repeat, and how it is serialized and deserialized for storage. These attribute types are intended for use in cases that would involve adding custom columns to the base table.
However core code does not refer to a specific OpenMRS attribute, because any attribute of a table needed by core should instead be added to the core data model directly.
The need for improvement of Attributes and Atribute types in OpenMRS started when @dkayiwa noticed the extensibility of the EAV pattern in our obs table along with several requests from implementations for implementation specific adjustments to the data model. For example, Tanzania wanted to record the “ten cell” for each person – a convention specific to that region for identifying clusters of homes. He thought, could we apply the extensibility of obs to our person object. So, we created a person_attribute table along with an person_attribute_type table to define custom “attributes” of person that would be an alternative to adding a new column to the person table (since not everyone wants or needs a “ten cell” attribute for person).
Thereafter, we decided to created more tables in OpenMRS where we add “_attribute” to a domain object (like Person, Visit, Location, among others). This approach of adding an x_attribute table (where x represents a domain object) has been repeated for several other domain objects (like Person, Visit, Location, Provider and Concept) for the same purpose. Actually, the attribute definitions are stored in x_attribute_type and the actual values for each x are stored in x_attribute.
If you take a look at the om.rs/dm data model browser, you can see these attribute tables as an example. The purpose is to allow local extensions to the data model without having to modify the shared (core) data model. https://openmrs.atlassian.net/wiki/display/docs/Developer+Documentation