The information below serves as a brief primer to help you better understand the database terms you’ll most often encounter.
Relational Databases. Relational databases became the database of choice across business and industry in the 1980s. This database approach is based on work done by Dr. E. F. Codd at IBM in the late 1960s. Essentially, the relational database model is based on the concept of a table (also called a relation) in which all data is stored. Each table is made up of records (horizontal rows also known as tuples) and fields (vertical columns also known as attributes).
Each table can be identified by a unique name and that name can be used by the database to find the table behind the scenes. As a user, all you need to know is the table name in order to use it. This ease of interaction for the end user is what really helped the relational database model gain wide acceptance over the hierarchical and network models of databases. In the hierarchical and network models, the user had to have an understanding of how the data was structured within the database in order to retrieve, insert, update, or delete records from the database.
SQL (Structured Query language). SQL is the language of choice for most modern multi-user relational databases. This is due to the fact that SQL provides the syntax and idioms (language) you need to talk to (query) relational databases in a standardized, cross-platform/product way (structured).
SQL provides predefined procedures so that you can use any value in a table to relate to other tables in a database. This helps explain why, odds are, you use a SQL relational database at your company.
The most common SQL databases in manufacturing are Microsoft’s SQL Server and Oracle’s MySQL. (But this may be changing. See the “SQL or NoSQL” sidebar.)
Historians. Production data, such as production runs, recipes, shifts, products, schedules, etc., are typically stored in relational SQL databases. Process data, however, is typically stored in a time-series database or historian.
In a historian, unlike a relational database, the principal connection among the data stored in it is time. For example, a historian would store the temperature readings from a temperature probe every second, so that an operator could see the temperature trend and determine if the process is running as expected or if action should be taken.
A historian is not deigned to handle relational data very well and, likewise, a relational database is not meant to handle vast amounts of unstructured data as a historian can. This is why both technologies have a place in a manufacturing IT infrastructure.
