Related Links

Web Seminars

I am co-authoring a book dedicated to the high-level data model. We agree that this model has certain characteristics, such as: 1) it represents a broad business area; 2) this model is a level above a logical data model; 3) it contains less than 200 boxes, such as Customer, Product and Order; 4) the audience is usually the business user, not a technical audience; and 5) each box can represent dozens of entities on the logical and physical models. However, where we have a difference in opinion about what to call this high-level model.

The Challenge

The name for this type of model needs to convey its importance yet simplicity. What name do you give for this type of model? Do you ever show attributes on such a model?

The Response

I refer to this high-level model as a “subject area model,” yet this type of model has many other names. In fact, our Challengers use 20 different names for this type of model. Figure 1 shows the percent of respondents that call this model a particular name, with “conceptual data model” receiving 59 percent of the votes. Also included in this chart is a listing of other names for this type of model. I wish I could include all 40 pages of responses to this challenge in this column, but instead we will focus on the top five key points:

1. The audience and purpose of the model should dictate its name. Both Cliff Longman, CTO, and Phil Stuart, data analysis and design consultant, recommend first identifying the audience and purpose of the model and then choosing an appropriate name. Donna Burbank agrees: “The key is to use a language that the end user understands when communicating the details of the model to your audience.”
2. Roughly half of respondents (51 percent) show major attributes on the high-level model. Many Challengers, including Barb Chapman, information architect, and Barry Williams, data modeler, mention they at times will include attributes on the high-level model. Barry shows key attributes to add substance to the model: “At times, I will capture attributes in the form of facts on a dimensional high-level model.” Sai Koduri, senior technical architect, recommends only showing business natural keys. Mike Nicewarner, business analyst, recommends capturing the attributes and using functionality within the data modeling tool to hide them on the high-level model.
3. The word “data” or “information” is necessary in the name. A number of Challengers, including Norman Daoust, business analysis consultant and trainer, and Lee LeClair, senior system engineer, suggest including “data” or “information” in the model’s name. Norman says, “We can’t call it just a business model since it only represents one cell of the Zachman Framework, not the entire row.” Hannah Davies, strategic designer - data, says data is needed in the name to distinguish this model from other models, such as process models.
4. We need to recognize both a very high-level model and a high-level model. Respondents Karen K. Manhart, IT principal data architect, Mona Pomraning, enterprise data architect, and Richard Leach, data architect, mention there is a very high-level model and then a model underneath this, which equates to the model we are focusing on for this challenge. A very high-level contextual model followed by a conceptual model maps nicely to the Zachman Framework.
5. The terms conceptual and semantic are ambiguous. Stephen Pace, senior consultant, echoes many Challengers by emphasizing that words like “conceptual” and “semantic” are immediate barriers to open business discussions. Gordon Everest, professor emeritus, says, “What is an ‘unconceptual’ model? Conceptual means ‘in the mind’ or a ‘generalization.’ The opposite would be real or concrete. So is a conceptual model less real or less concrete? I don’t think so, and therein lies a dilemma.” Eric Nielsen, enterprise architect, feels similarly: “We find the term ‘conceptual’ is too often perceived as abstract, academic or theoretical by both business folks and developers.”

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.