Related Links

Web Seminars

Your coworker calls you with a data modeling emergency. There needs to be a single definition for Customer in the data warehouse, yet he was provided with three different definitions. Each definition was provided by a well-respected business expert and is accurate within that business expert's area.

The Challenge

He needs you to recommend a solution he can use to come up with a definition that satisfies all three business experts. What would you recommend?

The Response

The tactic to get to a single Customer definition would require three main activities: seek help from the business, get the complete picture and capture it on the model.

Seek Help for a Complete Picture

It would be difficult to consolidate these three definitions into one without the help of a business owner or data steward. Jan Kamil, data warehouse analyst, would recommend asking, "Who owns the Customer data? That's the party who has to come up with or agree to a definition. If there's no definitive answer to that question, then it's time for tough love. Bribe all three experts with food, lock them in a room with you and don't let anyone out until an inclusive definition has been agreed to by all parties."

William Delaney, investment systems analyst, would recommend a complete analysis of Customer. "It would make sense that there are other business areas or stakeholders within the organization who also have yet another definition of Customer. I would propose a complete analysis of Customer and the current definition of Customer as perceived by each of the business units and stakeholders." Tom Bilcze, data architect, said, "I would first start with one-on-one discussions with each of the experts. After these exercises are complete, the analyst presents a homogenized definition formulated during the one-on-one interview process to each of the three experts."

Part of getting the complete picture involves understanding how customer data is stored in each of these three areas today. Gordon Everest, professor emeritus, recommended asking the question, "Does machine-stored Customer data already exist in each of the three areas? If not, the tactic is much simpler. If Customer data exists in one or more tables in each area, then we have the dual problem of combining data (rows) as well as combining definitions (columns)."

Based on the results of the detailed analysis, there are three ways to model this: subtype, go generic or abstract.

Subtype

Marc Bratman, application development manager, said, "I would define a Customer entity and then three subtypes for the Customer, each defined by the different business experts." A good approach to doing this, as summarized by Krishnan Seshadri, data architect, is, "Define Customer in the broadest of terms, preferably tied to the wording in the organization's mission statement. Then emphasize each business unit's view of the Customer by comparison/contrast and examples." I have found a very useful way of locating a common generic definition is to go to Google.com and type "Define: Customer." Tim Klein, data warehouse architect, recommended, "If there is little overlap or the required subtyping is too extensive, then the Customers are not the same entity and need separate names and definitions."

Go Generic

Anna-Mari Mollentze, IT engineer, suggested a generic definition, such as, "A Customer is any person or entity who interacts directly or indirectly with any business system, thus it can be a client in the marketing or sales departments, a supplier in procurement or an employee in HR." Brent G. Wilke, data warehouse architect, said, "You should try and find a 'merged' definition using the information from all three business experts before this meeting. By merged definition I mean pull out the unique terms in each definition and see if you can incorporate these unique terms into one definition."

Abstract

Dave Hay, industry expert, believes a more abstract approach should be taken. "I never have Customer as an entity or a table. I have Party that may be either a Person or an Organization. Each Party may be a Customer in an order. In addition, each Party may be a Customer in a marketing relationship. The point is that each of the definitions is for a different thing. The fact that there are multiple definitions for Customer means that the term should be thrown out." Michael Smilg, data administrator, offers a similar approach. "I would recognize that there is no such thing as a single definition of customer that would meet the needs of all three areas. Instead, the data warehouse should recognize that a Customer might have multiple roles and rigorously define and manage the distinctions across those roles."

If you would like to become a design challenger and have the opportunity to submit modeling solutions, please add your email address at 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 is one of the world's most well-known data modeling gurus. He taught his first data modeling class in 1992 and has educated more than 10,000 people about data modeling and business intelligence techniques since then. Steve is known for his entertaining, interactive teaching and lecture style (watch out for flying candy!), and organizations around the globe have brought Steve in to teach his Data Modeling Master Class, which is recognized as the most comprehensive data modeling course in the industry. Steve is the author of "Data Modeling Made Simple," "Data Modeler’s Workbench" and "Data Modeling for the Business (Technics Publications). He is the founder of the Design Challenges group and inventor of the Data Model Scorecard.