Intro

I have collected Q&A topics since about 2010. These are being put onto this blog gradually, which explains why they are dated 2017 and 2018. Most are responses to questions from my students, some are my responses to posts on the Linkedin forums. You are invited to comment on any post. To create a new topic post or ask me a question, please send an email to: geverest@umn.edu since people cannot post new topics on Google Blogspot unless they are listed as an author. Let me know if you would like me to do that.
Showing posts with label concepts. Show all posts
Showing posts with label concepts. Show all posts

2020-04-23

Concept Modeling vs. Conceptual Data Modeling

George McGeachie posts (LinkedIn, 2020 April 22)
To Fabian Pascal: Broadly speaking, I agree with your three levels [conceptual, logical, physical], but please don't assume that my view of 'data modelling' is limited to logical database design. "Conceptual" modelling is better described as "Concept" modeling (see the works of and ), so people don't mentally tag the word 'data' on the end (Conceptual Data Modelling). Where do we stop modelling 'Concepts' and start modelling 'Data'? It's probably somewhere in the top level of representation, before Logical Database Design.

To which Everest responds:

Thanks, George. I like that. I never did like the phrase "data" modeling because. at the heart of it we are not modeling data, we are modeling "things" in the user domain. Now I can say we are modeling "concepts" in the user domain. Modeling "things" suggests only nouns, whereas modeling "concepts" can include constraints, "business" rules, modifiers, roles, subsets, etc. Thus, concept modeling can be very rigorous, richer, and detailed (as in ORM). But we can recognize that this is a prelude to modeling "data" as it would ultimately be manifest in a "logical" data model. Perhaps that helps me better understand what Fabian keeps saying when distinguishing "conceptual" from "logical" data modeling... and his "logical" is (his version of) relational/RDM which is already a step toward implementation (I would argue) simply because it is clustering "attributes" into (1NF) relations.

2018-01-02

Definitions of concepts should start with their supertype. Why not?

Andries van Renssen -posts on LinkedIn. 
A good definition of a concept should build on the definition of more generalized concepts. This can be done by two parts of a definition:
1. Specifying that the concept is a subtype of some other more generalized concept.
2. Specifying in what respect the concept deviates from other subtypes of the same supertype concept.

Such kind of definitions have great advantages, such as:
‑ The definition of (and the knowledge about) the supertype concept does not need to be repeated, as it is also applicable ("by inheritance") for the defined (subtype) concept.
‑ The definition implies a taxonomy structure that helps to find related concepts that are also subtypes of the same supertype (the 'sister‑concepts'). Comparison with the 'sister‑concepts' greatly helps to refine the definitions. Furthermore, the definitions prepare for creating an explicit taxonomy.
‑ Finding the criteria that distinguishes the concept from its 'sister concepts' prepares for explicit modeling of the definitions, which prepares for computerized interpretation and the growth towards a common Formal Language.
--Thus, why not?