Over the last three decades ERP, CRM, and Analytical systems have evolved. However the way in which those systems store that data has not. In fact in those 3 decades there has been no change in the way that ERP, CRM, and Analytical systems store data.
Over the last three decades ERP, CRM, and Analytical systems have evolved. However the way in which those systems store that data has not. In fact in those 3 decades there has been no change in the way that ERP, CRM, and Analytical systems store data.
Generally speaking, modern day ERP and CRM systems are based upon data that has been modeled into a 30 + year old data model called OLTP (RDS – 3rd Normal Form). OTLP stands for On Line Transactional Processing.
Generally speaking, modern day Analytical Systems are based upon data that has been modeled into a 30 + year old data model called OLAP (Star and Snowflake Schemas). OLAP stands for On Line Analytical Processing.
ERP and CRM systems store data based upon business processes as they occur with little thought into how it can be analyzed. Because of this, these systems are not compatible with modern day analytical systems.
Analytical systems take the data from the ERP and CRM systems and change the data into a different format (OLAP) for processing. However, data that has been converted into the OLAP data model for analytical processing is not compatible for OLTP.
Therefore the real issue at hand is:
- ERP and CRM systems do not support analytical processing or reporting.
- Analytical processing requires data to be converted into a different format (or Data Model) that is not compatible with ERP and CRM (OLTP) based systems.
In addition to ERP, CRM, and Analytical systems; there is a need to analyze unstructured data. Unstructured data is data that has not been organized and typically comes from several different sources. This data is modeled into a completely different format than OLTP, and OLAP systems and is called Big Data.
Why is data modeled into different formats you ask? What we have been told over the years is it is based on the need of the system. If it is a transactional based system then data needs to be modeled into the OTLP data model. If you need Analytical support, then model it into the OLAP data model. And if the data you need to analyze is unstructured, then model that into a Big Data format.
I personally describe this as the “data culture”. I use the word “culture” because those who design these systems only work within their profession. You do not see OLTP data modelers working on OLAP data modeling systems and vice versa. The same can be said in general for those working in the Big Data arena.
The cause and effect of this is what has created the data culture we now live in. For example data starts at the source. The people who create these source systems model data into an OLTP format. Since someone else does the data analytical support, they only focus on a 30 + year old methodology OLTP.
The next person who consumes this data must take what is already created in the source system, and model that to suit their needs. Over time, this person accepts the fact that they will always be modeling OLTP data into OLAP data. This then becomes the culture of data.
However what is needed is for a data modeler to come up with a methodology supported on a solid data model that provides support for all of these data needs. This data modeler must understand the needs of all three data models: OLTP, OLAP, and Big Data.
Over 8 years ago, the Spider Schema Data Model was created to provide an easier way to model OLTP data into a supported OLAP data model with the advantages of the OLTP data model. Over the last 8 years this data model has been proven out and is: faster at data processing, uses less storage space, is more flexible, and provides full support for not only OLAP, but OLTP, and Big Data.
To learn more about the Spider Schema data model, go to http://spider-schema.info on the World Wide Web.
