I was raised in an industrial Midwestern city in the midst of the steel and auto industries. My father owned a neighborhood bar in the shadows of the foundries. Many of his patrons were patternmakers. They were the men who built the patterns from which train wheels, overhead cranes and steel auto components were cast.
In an interview for a data architect position, I explained to my future manager that data modeling is largely about recognizing patterns in data. His response was that I would find that the data needs of his organization were unique and that this methodology of using patterns would be inapplicable. I was hired. He was wrong and I was correct.
Data architects are patternmakers as were the men sitting on the barstools in my dad’s tavern. We use different tools and technologies. The results are the same. We build reusable patterns that are used to improve productivity in producing our end products. The ability to recognize, formulate and reuse components is one of those key traits that I listen for in interviews with perspective team members.
Much has been written about data modeling patterns, the use of reusable data model components, and industry data models. They are all variations on the “not starting from a blank sheet of paper” methodology; i.e. the use of patterns.
Here are three of the most prominent patterns I have seen in my years of data modeling. They are my holy trinity of data modeling patterns. I can say with confidence that almost 100% of my data modeling exercise include implementations of these structures. I am definitely not a “start with a blank sheet of paper” type of guy.
- The human-machine interface
My data modeling mentor on my first consulting assignment emphasized that this would be the most important modeling concept I would use in my career as a data architect. He was correct. I stand by his statement 25+ years later when I speak to newbie data designers.
Core entities and relationships between a person, a process and a product/service are strikingly similar whether you are manufacturing a tire, shipping a package, or underwriting an insurance policy. The attributes and related entities may differ but the core pattern carries across industries.
- Parent-child hierarchies
Our society organizes us into hierarchies in many ways. Family units, geographical boundaries, and product components and parts are just a few. Hierarchies are something that people can easily identify. They are good points to start a data design discussion. Everyone likes to contribute and understands the deliverables.
I have developed my pattern on how I handle parent-child relationships. My method is driven largely from my use of industry models over the years. The power of these structures is the management of relationships across and within hierarchies in a consistent, easy to understand manner.
Data modelers are consensus builders in addition to patternmakers. A supertype-subtype structure is a good way to build consensus. People like to categorize things. The problem arises when one person’s view of categorization does not match another person’s view. That is where data architects can build consensus by guiding the discussion by modeling common characteristics that drill down to entities with differentiating characteristics.
There is great value in getting people to see generalization-specialization patterns in data. Reusable structures and components result in this type of analysis. Well-designed hierarchies span applications, lines of business and units in the enterprise. Data architects must develop a pattern for modeling super-subtype structures in their designs.