FREE DM Review Site Registration!
Sign-up today and access DM Review on the Web!

Your FREE registration entitles you to:
FREE email newsletters

FREE access to all DM Review content

FREE access to web seminars, resource portals, our white paper library and more!

   

Publisher reserves the right to serve qualified requesters only.

Broken Shells

Design Challenge

I was about to go for a run on the beach when my four-year-old daughter asked, "Daddy, can you bring me back some shells? It's okay if the shell is chipped or missing a piece, but I don't want any shell pieces." Although it was easy for her to distinguish a chipped shell from a shell piece, I had a much more difficult time separating the two while jogging along the beach. Where do we draw the line between a chipped shell and a shell piece? That is, at what point does a shell change so dramatically that it is no longer a shell but now a piece of a shell?

After returning home completely shell-less, I started thinking about how this shell story relates to a challenge we sometimes have to face in capturing requirements. William Kent in Data and Reality raises a similar dilemma on replacing parts in a car. If you replace the windshield wipers, it is still the same car. But what if you replace the car engine and car body? Is it then still the same car? In your organization, if a customer moves to a different location, is it a new customer? If not, is there anything about a customer that could change (name, tax identifier or even gender) that could turn an existing customer into a different customer? What about a product, employee or any other concept important to your organization?

The Challenge

Have you ever had to analyze or model a concept in your organization where enough changes could occur to create a completely new concept? How did you handle it?

The Response

Norman Daoust, requirements modeler, uses the term "morphing entity" to describe a concept that changes to the point where it becomes a new concept. Morphing entities can be addressed through a combination of learning the business perspective and identifying those entity properties that must never change.

Learning the Business Perspective

A department or business area can create morphing entities based on entity lifecycle or level of granularity. Janus Camarata, information architect, says that oftentimes when you define a concept there are other concepts with closely related definitions. "The challenge is then to determine where does one concept end and another one begin."

Bruce Baum, global data architect, says that in the power generation industry, "If the gas turbine (i.e., engine) is replaced in a power plant, is this a new plant? Unfortunately, it is often a matter of one's perspective. Sales may count this as a new plant (boosts the count of plants sold, which is a key metric for sales), while engineering or service says it is still the same plant, just with a new component."

Baum gives another example of the importance of perspective, "When is a country not the same country but a new country? Think of the former East and West Germany. Did the physical land change? No, but the defined geopolitical boundaries certainly did. Some guidelines should be stated from the perspective of the business, not IT, as part of any database design that clearly identifies when a new instance of an object should be created."

Identifying Entity Properties that Cannot Change

Dave Hay reminds us that Aristotle also struggled with the morphing entity issue, realizing there is a distinction between accidental attributes whose values do not affect the identity of the entity and fundamental attributes whose values are crucial to the identity of the entity. Steve Turnock, database engineer, supports this distinction through this story, "When I was working for the Department of Corrections, it was very important to correctly identify repeat customers. As you might imagine, mistaken identity could result in a life-and-death situation. The key we came up with for a customer identifier was a hash code created by the state police based on analysis of fingerprints. All other attributes of a customer are considered variables."

Daoust discovered in one organization that when one department needed a new account category, they just updated an old entry they no longer used by changing the name, definition and code of the item. "I was shocked when I heard of this, but it was too late to do anything about that occurrence. To prevent the situation from recurring, we made the critical data items (name and code) for each entry add-only, so they couldn't be changed. This prevented anyone from reusing the same entry to represent a different concept."

If you would like to become a Design Challenger and have the opportunity to submit modeling solutions, please add your email address at http://www.stevehoberman.com/. If you have a challenge you would like our group to tackle, please email me a description of the scenario at me@stevehoberman.com.


Steve Hoberman has worked as a business intelligence and data management practitioner and trainer since 1990. He is a Certified Business Intelligence Professional (CBIP), having achieved mastery level certification in data analysis and design. He is a popular and frequent presenter at industry conferences, both nationally and internationally.  Hoberman is a columnist and frequent contributor to industry publications, as well as the author of  Data Modeler's Workbench and Data Modeling Made Simple (available for purchase through the DM Review bookstore). He is the founder of the Design Challenges group, inventor of the Data Model Scorecard and a recognized innovator and thought leader in the field of data modeling. He can be reached at me@stevehoberman.com.

Graeme Simsion's latest book is out! Data Modeling Theory and Practice. Here's a link where you can read more about the book and purchase it at a discounted price.

For more information on related topics, visit the following channels:



Industry Vendors