Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence


We systemize tacit knowledge into explicit knowledge

Blog Enabling Operational Excellence

Posts Tagged ‘conceptual data model’

Concept Model vs. Data Model

John Zachman says you can (and probably should) develop each of the following three kinds of artifacts to “excruciating level of detail”. 1. For the business management’s perspective (row 2), a conceptual model (roughly CIM in OMG terms). 2. For the architect’s perspective (row 3), a business logic design (roughly PIM in OMG terms). 3. For the engineer’s perspective (row 4), a class-of-platform design (roughly PSM in OMG terms). Because each is a different kind of model, there is a transform from one to the next. One implication is that it is possible to make a clear distinction between analysis (CIM) and design (PIM).   Another implication is that concept models and logical data models are clearly distinct. Unfortunately, many people blur the line between them. That’s wrong.
  • A concept model is about the meaning of the words you use, and the business statements you make assuming those meanings. It’s about communication.
  • A logical data model is about how you organize what you think you know about the world so it can be recorded and logically manipulated in a systematic way.
I started my career in data. It took me as much as 15 years of intense work on business rule statements (1990-2005) to fully appreciate the difference. But now I am very clear that concept models do need to be developed to excruciating level of detail in order to disambiguate the intended business communication. Most businesses don’t do that today. They jump in at data design (conceptual, logical or even physical). And they unknowingly pay a big price for it. By the way, a good concept model can be readily transformed into a first-cut logical data model – just as Zachman says. ~~~~~~~~~~~~~~~ www.BRSolutions.com

Continue Reading 1 Comment

Moving the Goalposts for Data Models … Deliberately

A practitioner recently said this: “Even if we assume that a technical methodology might exist to generate a complete and correct data model from a set of articulated business rules / facts, in my opinion this approach just moves the target from the data modeling area to the need to verify the articulation of business facts / rules for completeness and correctness.” Exactly! And why would that be a problem?! Here’s an additional advantage: The core concepts (concept model or fact model) of an operational business area are very, very stable. Don’t believe it? As proof see http://www.brcommunity.com/b594.php (short case study, well worth a quick read). The problem with current data modeling practices is that a large gap often exists between the business view of things (operational business things) and the ‘data’ view of those things – even when trying to keep to a ‘conceptual’ view. This gap gives business-side people a ready excuse to drop out. But data modelers alone can’t provide the necessary business know-how for a robust, complete model. The problem is so big, it’s hard to see. Current data model practices evolved bottom-up, from database designs. (I believe I can speak with some authority here. I was editor of the Data Base Newsletter, 1977-1999, and wrote three books related to the matter in the late ‘70s and early ‘80s.) It’s time for us to approach the problem top-down. There is a natural way to build concept systems – it starts with basic business communication. The standard for such an approach already exists – SBVR. (For discussion see BRCommunity’s SBVR Insider section.) We’re already living and working in a knowledge economy … We need to start acting like it!

Continue Reading

More on Concept Model vs. Conceptual Data Model

As part of a continuing dialog, I recently asked these questions: What does the term “conceptual data model” really mean? Is it the best term for what is meant? To me, it sounds like “conceptual data model” might be about “conceptual data”. Surely not(?). What exactly then? (Some of my thoughts on the matter: http://goo.gl/8GX5o.) A practitioner responded with the following 3-part challenge below. With each challenge is my response. Challenge part 1: Which of the following, if any, would you see in a conceptual data model: primary keys, foreign keys, abstract keys, constraints, nulls, non-nulls, 1:1s, 1:Ms, optionality, cardinality, etc.? My response: Wrong approach. Bad definition practice one three counts. 1. Things should be defined in terms of their essence, what they are, not in terms of what are allowed or disallowed. 2. Suppose none of the above were allowed. You’d end up simply with a description of what the thing is not, not what it is. Since you can’t possibly list everything it’s not, the definition is woefully incomplete. 3. The list attempts to describe something in terms of an implementation or design of the thing, not in the thing’s own terms. That’s simply backwards. Challenge part 2: So let’s turn the question around. What would be the minimum types of objects you need to explore a concept, produce a mini model, and convey knowledge about the concept and its relationship to other concepts? My response: To develop a concept you need: 1. A concise definition for the concept, which distinguishes the concept from all other concepts and conveys its essence to the business. 2. A business-friendly signifier (term) for the concept that has only that one meaning (or is properly disambiguated by context). 3. A set of facts that indicates the place of the concept within a structure of other concepts (e.g., classification, categorization). 4. A set of verbs that permits the business to communicate unambiguously about how the concept relates to other concepts (e.g., customer places order). 5. A set of structural rules for the concept and its relations to other concepts, as needed. Why the verbs? Because you can’t write sentences without verbs and business rules can always be written in sentences. ‘Requirements’ should be too(!). Challenge part 3: When you are finished do you call that a ‘conceptual data model’? My response: You notice that I didn’t say anything, directly or indirectly, about “data”. That term is irrelevant. Taking away “data” leaves “conceptual model”. But that term suggests what the model is made of (concepts), not what it is about. Of course the kind of model we’re talking about is made up of concepts – it’s certainly not made of physical material (e.g., wood, plaster, etc.) or through use of math (some formula). That leaves “concept model” (also sometimes called “fact model”). Bingo. Is there a standard for this kind of model? Indeed there is: SBVR (Semantics of Business Vocabulary and Business Rules). See the SBVR Insider section on www.BRCommunity.com for more information.

Continue Reading 2 Comments

What Exactly is a ‘Conceptual Data Model’ … and Why in the World is It Called that, Not Just ‘Concept Model’?

I’m kicking off 2012 with a couple of things I just don’t get. Here’s the second one: What exactly is a ‘conceptual data model’? Why in the world is it called that instead of just ‘concept model’?  ~~~~~~~~~~~~~~~ Did you ever pause for a while to ponder the meaning of the term “data”? Most of us don’t. The term is so familiar and pervasive we simply take it for granted. For IT professionals, “data” is about as basic as it gets. Taking terms for granted, unfortunately, is the surest path to confusion. It’s the deep assumptions about the terms lying at the very heart of a subject matter that usually trips us up. So let’s take a moment to examine the meaning of “data”. Just so you know where this is headed, I’m embarking on a full frontal assault on the term “conceptual data model”. I’ve disliked that term for years. I think we should kill it off once and for all. Why? Three fundamental reasons:
  • No business person would naturally say “conceptual data model” in everyday business conversation. If we mean something by “conceptual data model” that business people should be able to talk about, then why have a name for it they can’t easily understand? Jargon just makes things harder.   
  • I believe what you really mean when you say “conceptual data model” is simply “concept model”. If “conceptual data model” doesn’t mean that, then what in the world does it mean?! 
  • “Concept model” has recently been adopted by SBVR 1.1 replacing “fact model”. The SBVR reasoning for the switch is directly related to this discussion, but I’ll save it for some other post.
Why Not “Conceptual Data Model” The Wikipedia entry for “data (computer science)” says, “… information in a form suitable for use with a computer. The entry adds, “Data is often distinguished from programs … data is thus everything that is not program code.” Now let’s substitute “… information in a form suitable for use with a computer” for “data” in “conceptual data model”. The result of the substitution is “conceptual information (in a form suitable for use with a computer) model” or simply “conceptual information model”. What exactly does that mean? As far as I can tell, not much at all! By all rights we should be permitted to terminate the analysis there. In IT the Wikipedia definition is what “data” has meant for well over half a century. If you’re interested and have the patience, however, let’s be charitable and look more broadly at the term “data”. See the footnote[1] (long). Skip it if you like – it leads nowhere and life is short. As the footnote indicates, any attempt to make sense of “conceptual data model” through fair-minded dictionary analysis of “data” leads to nonsense or a dead end. So the term “conceptual data model” must have an origin all its own. Indeed it does – one definitively IT-based. Reviewing the Wikipedia entry for “conceptual data model” we find the synonym “conceptual schema”. “Conceptual schema” is a technical term dating at least from the 1970s. I can vouch for the overall accuracy of the Wikipedia entry since I wrote several books touching on the subject in the 1970s. Ironically, Wikipedia provides a great definition for “conceptual data model”: a map of concepts and their relationships. Bingo! So why all the mumbo jumbo? Why not just say “concept model”?! Let’s toss “conceptual data model” and be done with it!
[1] Definitions of “Data” in Merriam-Webster Unabridged Dictionary 1a: … SENSE-DATUM  : an immediate unanalyzable private object of sensation *a sharp pain, an afterimage …* Surely that’s not what a “conceptual data model” is about. 1b(1) material serving as a basis for discussion, inference, or determination of policy *no general appraisal can be hazarded until more data is available*   Most meanings of “material” are physical (e.g., metal, wood, plastic, fiber), however one [1b(2)] is not: something (as data, observations, perceptions, **ideas**) that may through intellectual operation be synthesized or further elaborated or otherwise reworked into a more finished form or a new form or that may serve as the basis for arriving at fresh interpretations or judgments or conclusions (emphasis added). For the sake of argument, let’s assume that “data” in “conceptual data model” is meant as “ideas”. So “conceptual data model” then becomes “conceptual idea(s) model”. What exactly are “conceptual ideas”? Or more precisely, what ideas are not conceptual?!? So in the very best case, this definition of “data” results in the awful signifier “conceptual idea(s) model”. 1b(2) detailed information of any kind  You can go through the various definitions of “information” if you desire, but I’ve already asserted that “conceptual information model” is nonsense. This whole matter can’t be all that hard(!).

Continue Reading 2 Comments