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.
Colin Campbell
| #
Sorry Ron, I think the term “data” is unique, totally relevant and requires defining.
To my narrow way of thinking, “data” sits in a data base and no where else; it is a pure creature of the IT world. The business/real world deals with “information” , not data. That is why I said “data sits in a data base” because information based on agreed concepts, and a slippery creature of the real world, is commonly collected and herded into data bases where it is caged and converted into “data”, and subsequently, that data must be translated back into information based on agreed concepts for inclusion in reports, query responses etc required by the non-IT world.
So a “conceptual data model” may be a meaningful and useful tool for those IT people involved with designing and building data bases, but it is not a tool I would want to include in the business tool box. Leave data to the data base keepers. The rest of us use information built with concepts that can be modelled.
Joost J van Griethuysen
| #
I agree very much with the point you are making.
However, A conceptual schema is not a conceptual data model.
The real authority on what a Conceptual schema is the ISO Technical Report TR 9007, in which the actual conceptual schema concept has been defined. A summary of the report can be found in my paper “The Orange Report ISO TR9007 (1982–1987)
Grandparent of the Business Rules Approach and SBVR” April 2009 published on the BR Community Site .
Kind regards,
Joost J van Griethuysen