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.
Tags: concept model, conceptual data model, data, data models, definitions, fact model, SBVR, verb concepts, verbs
Ronald G. Ross
Ron Ross, Principal and Co-Founder of Business Rules Solutions, LLC, is internationally acknowledged as the “father of business rules.” Recognizing early on the importance of independently managed business rules for business operations and architecture, he has pioneered innovative techniques and standards since the mid-1980s. He wrote the industry’s first book on business rules in 1994.