Over the past month I have been working on the design of an operational data store. As time moved on, the model grew in complexity as the business requirements grew. From the start, I was convinced that my efforts would result in a compact design that fit nicely on a single page. Then I woke up to the reality that the data model had become too complex for a one-pager.
I am a firm believer in the use of subject area views to segment a large data model into smaller diagrams that are easier to read and comprehend. I could go as far as saying working with views is the norm for me. Seldom do my database designs boil down to readable standard letter or legal size page. The exception would be conceptual data models that paint big pictures of business data needs.
Planning my dissection of the model into subject areas, I thought it would be a good time to talk about creating subject areas. Numerous times I have put these guidelines into standards documents. Note that these are guidelines and not standards. The end result of any effort to subset a data model into smaller components needs to convey the identical message of the full model in the newly created subject areas. This requires data modeler skills that are beyond a simple set of standards.
- Spaghetti on Paper– If your relationship lines resemble a corn maize, it is time to create subject areas. Complex business rules become complex relationships in the database design. Life is not as simple as textbook modeling exercises. Your subject area technique needs to revolve around untangling the relationships by grouping business rules that tell a story to your business clients.
- Can’t See the Forest for the Trees– If your entities propagated and grew faster than bamboo, chances are you can’t see the ground they were planted on. Your audience gets lost in the underbrush. To capture the audience’s attention and draw them into your design, it is good to keep entities to 20-30 per page.
- Godzilla that Ate the Model– Just as Godzilla destroyed Tokyo in the 1950s horror movies; expanding business areas can wreak havoc in your design. Sub setting the data model by business subject areas is a good option. I like to color code entitles by business area. It makes a growing business area subject area easier to spot.
- Drowning in the Sea of Details– Everyone has an area of expertise and responsibility. A robust design can cross many departments, job roles, and areas of expertise. Don’t leave your clients drowning in a sea of complexity. Often segmenting business processes and areas into different subject areas is a life saver.
- Micro Modeling – Passing out the model, everyone immediately reaches for their reader glasses. Eyes squint and the pages are held at arm’s length. There is no doubt that the model does not belong on a single page. If you don’t have the ability to print it on a bigger sheet of paper, it is time to create subject area views.
This is not meant to be a comprehensive list but illustrates that creating subject areas requires the skills and background off a data modeler. The objective of a data model is to tell the story of the business application from a data point of view. Written words are translated into graphical entities and relationships. Just like written specifications, your diagram needs to be clear and understandable. There is no written rule that it needs to be on a single diagram. Often it requires several diagrams.
Modeling Global User Community President
Follow ERwin online through Twitter, Facebook, and LinkedIn.