Follow @DBDebunk Follow @ThePostWest


The Web is chockful of unnoticed/unquestioned pronouncements by novices or self-taught "experts", that are (1) wrong, or (2) gobbledygook. Attempts to demonstrate the lack of foundation knowledge underlying these misconceptions are usually dismissed as "theory, not practical", attacked as "insulting ad-hominem", or ignored altogether, regardless of the amount and quality of supporting evidence and logic. Practitioners who cannot discern such misconceptions and understand their practical implications are insufficiently prepared for a professional career in data management. They cannot associate problems with their real causes and come up with proper solutions, which explains the industry's "cookbook approach" and succession of fads. What about you?

This is another batch in the Test Your Foundation Knowledge of online statements reflecting common misconceptions due to lack of foundation knowledge. Can you debunk them? Which of the two categories, (1) or (2), do they fall in? If not, check out the recommended references.

Comment: The kind of clueless exchange leading nowhere that takes place in the absence of foundation knowledge. See if you learned anything from it, then check out the references.

• 08/09/19: Following my series of posts on data sublanguage (Parts 1-4), I have revised for consistency the corresponding section of paper #2 in the Understanding the Real RDM series, Logical Access, Data Sublanguage, Kinds of Relations, and Database Redundancy and Consistency, which is available for ordering from the PAPERS page.

• The Key to Relational Keys: A New Perspective. 
• THE DBDEBUNK GUIDE TO MISCONCEPTIONS ABOUT DATA FUNDAMENTALS, my latest book, is available to order here (Reviews: Craig Mullins, Todd Everett, Toon Koppelaars, Davide Mauri).
• Logical Symmetric Access, Data Sub-language, Kinds of Relations, Database Redundancy and Consistency, paper #2 in the new UNDERSTANDING OF THE REAL RDM series, is available for ordering here.
• Interpretation and Representation of Database Relations, paper #1 in the new UNDERSTANDING OF THE REAL RDM series, is available for ordering here.

• To work around Blogger limitations, the labels are mostly abbreviations or acronyms of the terms listed on the FUNDAMENTALS page. For detailed instructions on how to understand and use the labels in conjunction with the that page, see the ABOUT page. The 2017 and 2016 posts, including earlier posts rewritten in 2017 were relabeled accordingly. As other older posts are rewritten, they will also be relabeled. For all other older posts use Blogger search. 
• Following the discontinuation of AllAnalytics, the links to my columns there no longer work. I moved the 2017 columns to dbdebunk and, time permitting, may gradually move all of them. Within the columns, only the links to sources external to AllAnalytics may work.

• @DBDdebunk on Twitter: will link to new posts to this site, as well as To Laugh or Cry? and What's Wrong with This Picture posts, and my exchanges on LinkedIn.
• @The PostWest blog: Evidence for Antisemitism/AntiZionism – the only universally acceptable hatred – as the (traditional) response to the existential crisis of decadence and decline of Western (including the US)
• @ThePostWest Twitter page where I comment on global #Antisemitism/#AntiZionism and the Arab-Israeli conflict.

“1. You fill in a form.  The content is registered in a database. The format has changed, something didn’t. How do you call what didn’t change: data, information or ...?

2. Same situation as above. You make a model of the XML message that brings your input to the database, XSD. You make a model of the database, DDL. How do you call these kind of models? Are these models?
3. Same as above. You make a model of that what didn’t change. So it’s abstracted of the format. How do you call this model?
4. In the form was asked for date of birth. This is used to see if you’re an adult and it’s allowed to sell you liquor. How do you call the answer to the question: is it allowed to sell liquor? How do you call the modelling of the answers, if you abstract from concrete form?
DIKW is not precise and much too vague.”

“Michael Mueller i was triggered by the word ‘datamodel’ at the start of your blog in combination with the use of the word ‘truth’. Ambiguous words. So to understand your blog, i like to know what you mean with it, here.”

“I would argue that data modeling emulates the representative data, and that data are the facts - not the truth.  How those facts are interpreted or utilized is based on perspective, again not truth. Perspective.”

“I struggle with the word "truth" because when it is used to represent multiple opinions or perspectives, it implies that truth is relative - which I disagree with fundamentally. Truth is ... period.  So rather than say that data holds multiple truths, I believe it is only accurate to say that how each entity views the data and its relevance is based on their perspective or interpretation of the data, leaving it subject to conflicting views. I would argue that data can never say what data never said. So when modeling data it is imperative that we hold it in its native form and have the functional experts help us model and curate the data into information, thereby documenting the varying perspectives and capturing the assumptions. Have I offered sufficient clarity?”

“Truth? Reality?”

“Well, I think a complete re-thinking of data modeling will take years. And yes I am not prepared to do it.”

“Data modelling and glossary management should go hand in hand. You don't need to agree on a single definition of "customer"! Instead, a good data model would accept the fact that there are multiple valid definitions of "customer". It depends on the purpose! You would then need to label all those definitions differently. This way, they can become part of the same business model.”

“Ahh, truth is subjective. Humankind tend to see things differently from one each other. Witnesses standing next to each other, testifying differently. Each of them convinced that this is the truth. I sometimes wonder if a singular truth is possible. I should have written truths in the title.
Consistency - all parts fit together. Each witness is consistent in their truth, most of the times consitency is the source of the deviations.”

“Well I use data modeling as a general term. Conceptual, logical and physical are special concerns. Conceptual as abstract for communication with users, just the Business Objects, the keys and few improtant attributes. This can generate a logical model. Which then has to be filled with more attributes, entities and relationsships in order to fulfill system design purposes. This then can generate a physical model - which is today - at least for relational DBs - not very different.
It is funny: physical is quite fix in publications, logical is mostly fix, but conceptual has a wide range of defintions. It is the most abstract of them and capturing a topic is hard.”

“Many people are afraid to model because you are modelling your own view of things. It is a step to expose yourself and make yourself vulnerable.”

“You are right that it is time to forget generics, be multi-specific instead!”

                            --Data modeling and truth and reality



References

Don't Confuse/Conflate Database Consistency with Truth

Understanding Conceptual vs. Data Modeling Parts 1-4

Conceptual Modeling Is Not Data Modeling

Understanding Data Modeling Parts 1-5

Data and Meaning Parts 1-4

What Meaning Means Business Rules, Predicates, Integrity Constraints and Database Consistency