Chapter 6 Before Your Expedition Begins
6.1. Essential Skills and Insights for Your “Expeditions”
Data modeling is a journey into lands of the unknown. A journey of exploration, discovery, and mapping. Every capable discoverer knows that there are certain things you must keep with you at all times. Here are my best bets on concepts you should keep in your “mental backpack,” wherever your modeling efforts take you.
The priorities are:
- Structure
- Content.
Remember that structure is top priority, but the combination of structure and content is what meaning is made of.
Today, the demand for a 3-layered modeling approach is more important than ever before. When relational modeling was dominant, everything melted into a pot of “table soup,” which was called a variety of things such as entity-relationship, conceptual, logical and more. This is no longer an option, since many projects are now being based on physical models without tables.
The distinction between the business layer (i.e. concept models) and the solution layer is that the business layer is a map of reality, whereas the solution layer is a design artifact effectively scoping a particular IT solution (probably containing a number of generalizations and/or other design decisions).
One of the ongoing discussions is that of how to draw a line in the sand between data models and business rules. First of all, business rules “fit into” the concept and data models. From an overall perspective, all those “if...then...else...” rules contain business concepts in the formulations of both the conditions and consequences. Having said that, there is still the issue of whether any given specification is at the data model level or at the business rule level. The transitions can be quite subtle and difficult to notice as you go. My recommendation is:
If a specification contains actual data in the text, then it is a business rule. For example, “...greater than five business days...” is a rule, not a part of the data model. A 3-layer data model architecture is the way to go, not least in NoSQL:
Tables are in the wrong place, if they participate in data models. They are basically external views (in the ANSI-SPARC terminology), designed to represent data in a user interface (e.g. a screen, a form, a grid). Such applications are where tables excel, just look at Excel. Using tables in physical representation is a possibility, but just one among many (like aggregates, key-values and graphs).
The purpose of all this effort is to create business value. Put that idea on top in your backpack! This is ultimately why data modeling is important. Since businesses are run by humans, they are somewhat “fluffy.” This is why it’s critical to understand and apply cognitive and psychological findings. Learning is a big part of data modeling; psychologists have been busy for over 50 years. Being “fluffy” also means that issues such as uniqueness and identity can have exceptions in the real world. So be flexible!
The “I” in IT stands for information, and that is our business. Getting information across is the essence of communication. We must be proficient in getting our structure and content inside people’s heads. We build maps of the information landscape and, being the discoverers, we help our peers to navigate a complex context.
When you look back at what happened within database and data modeling history, it is an astounding hindsight that the discipline is still so new! The pioneers spent a lot of time and effort on learning to stand up and stand still, just like Bambi on ice. I have never seen a specification of the non-functional requirements of a data modeling solution. That is why I included it in this book.
Pointers are all right, as long as they are not physically bound. Graph databases deserve more credit.
Properties of a business type are all at the same “location in the conceptual space,” by definition. This indicates that the business object types are the “landmarks” of the data model, resembling an “information landscape.”
Chen did it right with his entity-attribute-relationship models. It is a shame that these models never grew into maturity. Much effort has been spent on understanding normalization and on taking it into eight layers of “normal forms.” Seems to me that a number of issues are being put into the normalization melting pot. It remains unclear that if normalization is the answer, what was the question, again? The key question(s) in data modeling should be concerned with exploring and mapping structure, meaning, identity and uniqueness.
Cognitive computing (including semantics and machine learning) is rapidly evolving, within metadata capture and automated data modeling. This could change the “Analyze” phase of the closed loop:
Automated discovery of relationships is the “next big thing” in data modeling, and graphs are excellent for visualizing relationships.
Never forget that one size does not fit all. However, property graphs are the most independent representations that can span the whole spectrum of physical paradigms on the table today—with or without tables. Data today is highly dimensional; in the context of data modeling, this means that it is full of relationships. That is where graphs excel.
Especially in concept mapping, the data modeler should have a degree of artistic freedom to find his or her own style. The important thing is that the messages are delivered to the readers, as effortlessly and reliably as can be. Play around with layout, styles, colors, fonts, images, and the lot. The goal is to fascinate and then mesmerize you audience.
Here I have played around a little with gradient fillings and shadows to get a more modern style:
Have fun!