The other day I had a frustrating conversation with a longtime friend and fellow developer related to metrology database design. My company built a system called Metrology.NET™ and designed it to work with any database on the market. The frustration came from my friend’s inability to understand objects and states of objects disconnected from a table design in a database. This led me to think about how the world is changing and how we as automation engineers need to adapt.
One of the new trends in data storage, to include metrology data storage, is the migration from traditional SQL based data access of relational table structures to a more modern NOSQL design. These databases are designed to store massive amounts of data and are more scalable, but the interactions with the data are different. Moving away from the table row model, these databases store relevant data together based on the object model, so we must think of them in terms of the Object Model.
Many of these NOSQL databases store information in name value pairs, where the value can be complex hierarchical information like XML. This new paradigm in database schema is more dynamic, allowing for the storage of dissimilar data in the same location. This facilitates the ability to support data models as they expand over time. If you need more fields or a custom field in your database, just add it to the object and the database figures out how to store it best.
So, this brings us back to the object model. Simply stated, an object model is the collection of properties comprised to define the object, as well as how each object interacts with other objects in the system. For example, we can take a piece of test equipment and represent it as an object. We can define the manufacturer, model number, serial number, asset number, description and options as properties of that item.
Though this is an over simplification, in a NOSQL database we can store the object in the database and allow the database to figure out the most efficient way to store the data related to the equipment. There is no need to explicitly design a manufacturer table. We can ask the database to give us all unique manufacturers for the equipment; there is no need to design a model table, because we can ask the database to give us all unique instances of a model where manufacturer = Fluke.
The big advantage to all of this is how we transact with the data in our database. Now we can standardize on an object model without regard to how the database stores the data in the database or even what database it is using. A standardized object model also allows seamless migration back and forth between SQL and NOSQL databases. Hence the frustration with my earlier conversation; stop thinking in terms of what fields need to be stored in what tables. It really doesn’t matter anymore. Instead think of the problem in terms of object model and properties.
So this brings us to stateless REST transactions with the database. REST stands for REpresentation State Transfer. For this article we are representing a piece of equipment (the Fluke 87) as an object with a set of properties. If I want to save the data in the database, I can send the data to the server using a POST transaction. If I want to read the data from the server, I would use a GET transaction. In each transaction, the operation is stateless, meaning I can save or update the data without any previous calls to the server. I can take the data offline, update it and send it back the following day. And I am not limited to one thing at a time; I can work with several objects all at the same time.
REST transactions are taking the software world by storm. Because it is such a simple and secure means of communication between the client and server, applications are quicker and easier to develop. Its uniform interface of HTTP verbs (GET, PUT, POST, DELETE) has become a standard for network communications.
Over the coming years, you will hear me talk a lot about REST transactions and Object Models. These are extremely powerful tools and concepts allowing us to build better and better metrology systems and services. We can focus on the object model and its data elements and properties, spending less time on database table layouts and building more robust solutions. REST communications allow us a simple and easy way of transacting with our data. Concerns about where and how the data is stored are things of the past. If the company IT decided tomorrow they want to change every database in the company, it has no effect on applications using REST calls.
