Data Modeling Is Like Aspirin

I am delighted to be writing this blog where we will address some tough issues on how data modeling relates to emerging technologies and other disciplines. Trends like data warehousing, business intelligence (BI), Service Oriented Architecture (SOA), Agile modeling, domain-driven design, and others are posing some serious challenges for the data modeler. I guarantee you the opinions expressed here will not be sugar-coated. In the next blog, we will address Data Modeling and SOA, following that Agile modeling. 

Data Modeling is Like Aspirin

20 years ago aspirin was dismissed as a harmful drug. Now it is considered a miracle drug capable of reducing the risk for certain ailments such as strokes and blood clots. The same drugs that once disparaged aspirin are now professing that they are “aspirin-compatible!” So too has it been with data modeling.

Some have said that Object Modeling replaces data modeling (just as, they say, the Object Oriented DBMS subsumes relational) because it unifies data and function in classes. But all software consists of data and programs. At the logical level, this means that all software consists of data and processes. Data and process are distinct but related phenomena. They deserve the distinct but related disciplines of data and process modeling. Each needs to be understood in its own right and in its interaction to the other. Data modeling has survived as a key discipline in all software development. Dimensional modeling is a useful discipline, suitable for certain forms of query and reporting. Dimensional modelers have said it is better to teach dimensional modeling to novices right out of college so their thinking is not tarnished by traditional data modeling. This advice has bred many dimensional-only modelers who do not understand the fundamental principles of data modeling. Give a child a hammer and everything looks like a nail. Give such modelers some data and everything looks like a star. The world is not a star. Functional dependency is a principle of data modeling. For example, according to dimensional modelers, rapidly changing dimension data is best placed in the fact table. However, its functional dependency is on the dimension, not the fact. To put it in the fact makes it more difficult to analyze the changes to the dimension in its own right apart from the fact. The principles of data modeling apply to all forms of data modeling. Object Role Modeling has declared its superiority to ER modeling. Indeed, it is a fine discipline for modeling data and business rules. However, the resulting diagram is so large and cumbersome as to make it impractical for representing the data in any large business domain, even if that domain is divided into manageable increments. One capability of a model must be its ability to communicate. Agile Modeling is very practical. Agile modelers have declared that you do not need a detailed logical data model and that a domain model will suffice together with a physical model. A domain model is a conceptual data model with no attributes but (surprisingly) with quite normalized entities. It is not a precursor to the physical model. In this regard, Agile modelers are throwing the baby out with the bathwater. Contrary to the Agile viewpoint, the detailed logical model provides many benefits, among them improved requirements, greater reuse of assets, reduction in maintenance, improved data quality, reduced data redundancy and a quality database design.

Data modeling has a solid base that has matured over the years. Data modeling is not like the axe I have at home, which is the original axe that George Washington used to chop down the cherry tree – except it has had 19 new heads and 57 new handles! Data modeling has been enhanced. It now supports more forms of abstraction, allows for more properties for the data objects it supports, contains business rules as an object in their own right, supports constraints across relationships and enables a stronger transition to the physical model – among other enhancements. But these are all founded on the stable base of data modeling and its principles, first defined by Dr. Peter Chen in 1976. Data modeling, in the form of ER modeling, is here to stay. We should be proud of it.