Follow @DBDebunk Follow @ThePostWest


Revised 3/25/18

"To the question “How relevant is data modeling in the world of NoSQL?” I give the following answer.

The main purpose of data modeling is to understand the business, some application domain, some users world. The model becomes a representation of that world -- the "things" in it, the relationships among those things and any constraints on those things or relationships. A secondary purpose is to build a database to contain information which pertains to and describes that domain."

"Generally we speak of the model coming first, then the implementation, and finally, the data gets collected and stored according to the model. Hence, the business data model should not be concerned with issues of physical stored representation, or the transformations/manipulations/constraints which are imposed to facilitate implementation in some data (storage) management system. That could be a relational DBMS, or a NoSQL tool".

" ... increasingly the data already exists in some form. Which leaves us with the task of figuring out what it means, what it represents -- that is, understanding the data as it represents some user domain. NoSQL tools are often designed to deal with existing data and to process it more efficiently (that may be an oversimplification!). Either way, you must understand the business in order to make sense of the data." 

--Gordon Everest, LinkedIn.com

I have written extensively on the three levels of representation and four types of model and I won't repeat it here -- readers can refresh their memory if necessary[1,2]. Everest's comments are at best ambiguous with respect to the levels and models (e.g., by data modeling he means business modeling, and his "business data model" lumps together business model and data model). It is to avoid such ambiguities and the resulting confusion that I recommend the three-fold terminology of conceptual modeling, logical database design and physical implementation, eschewing data modeling[3]. Here I will rely on my earlier writings to address strictly the issue of data modeling in the NoSQL context raised by Everest.

• NEW: 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 FUNDAMENTALS page, see the ABOUT page. The 2017 and 2016 posts, including earlier posts rewritten in 2017 are relabeled. As other older posts are rewritten, they will also be relabeled, but in the meantime, use Blogger search for them. 
• 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 work. 

 
@THE POSTWEST

• The Dystopia of Western Decadence, the Only Acceptable Racism, the Myth of the “Palestinian”

------------------------------------------------------------------------------------------------------------------

Out of the trio of terms I recommend, logical database design is the only one which might properly be referred to as data modeling -- provided data professionals understood it correctly: it consists of using a data model in the true sense of the term -- a formal theory of data -- to formalize informal conceptual models as "computable" formal logical models for database representation[4]. But, unfortunately, they don't have a good grasp of it.

Two of the three components of a data model -- structure and integrity -- provide the formal database representatives corresponding to the informal elements of conceptual models that jointly comprise logical models (of course, these components cannot be defined independent of the third (manipulation) component).

The RDM, for example, fulfills this function as follows:

Structure

• Relations represent entity groups;

- tuples represent (facts about) entities;
- attributes represent entity properties;

Integrity

• Constraints represent relationships:

- among properties;
- among entities;
- among entity groups.

Many data professionals belabor under the misconception that the RDM supports only uniqueness (PK) and referential (FK) constraints. But the latter represents relationship among groups, and the former only one type of relationships among entities. In fact, distinct from conventional wisdom, the RDM properly understood also supports relationships among properties, and other types of relationships among entities (e.g., functional dependencies and aggregate)[5]. They are not supported by SQL DBMSs, and in the absence of foundation knowledge, practitioners are unaware of them.

Because business models are independent of physical implementation, Everest believes that either NoSQL tools or RDBMSs can be used for data management, but that the former "process data that exist in some form" more efficiently than the latter. However, such efficiency, if any, is achieved by trading off physical independence (PI)[6] for it: programmers have direct access to the physical level, producing applications that are brittle, vulnerable to physical changes. RDBMS software supports PI and translates logical data requests by applications to physical hardware access, insulating applications from the physical level.

In a data modeling context it is important to distinguish between two kinds of NoSQL tools, and to understand that not all "processings" are created equal, with different implications for data management practice.

• Schema-less NoSQL systems, which handle arbitrarily structured existing data lack a data model. Their attraction is skipping business and data modeling altogether. You can do the former, but you can't formalize the results as logical models and have a DBMS enforce integrity and guarantee logical and semantic correctness[7]. Such systems often depend on a pattern matching language facility (e.g., awk) to find data that matches some user-defined format and then manipulate it in some ad-hoc way.
• NoSQL systems that require a specific data structure (e.g., key-value) lack the attraction of "handling existing data in some form", but support a data structure that is much inferior to the n-ary relation for integrity enforcement and data manipulation purposes.

"Processing" in neither case benefits from the critical advantages of a true RDBMS (system-guaranteed logical validity, semantic correctness, declarative and decidable data languages, logical independence, and so on), or of even the lesser ones of a SQL DBMS. NoSQL systems permit computationally complete languages (CCL), which are expressively more powerful than relational data languages (enabling them to represent a broader range of business models), but they are often incapable of having a powerful DBMS to manage data, are necessarily procedural (the programmer has to specify everything step by step), and logical consistency is difficult to enforce, especially during system recovery. These are the very problems of pre-relational DBMSs that the RDM was intended to eliminate. They who forget the past...

Constraints are not "imposed to facilitate physical implementation in some data (storage) management system" (and neither is manipulation): they are logical and enforced by a RDBMS to ensure logical database consistency with the relationships specified in the business model[8] (not the NoSQL physical notion of copy consistency!). 

In fact, most NoSQL products are merely storage management systems, never rising to the level of database management systems. Not exactly equivalent alternatives to RDBMSs, as Everest implies (is this why he calls them tools, not DBMSs?) But in the absence of foundation knowledge, all this is lost on data professionals.

Note: Check out the comments to Everest's post -- hard to know whether to laugh or cry.


References

[1] Pascal, F., Data Model: Neither Conceptual, Nor Logical, Nor Physical

[2] Pascal, F., What Is a Data Model?

[3] Pascal, F., Levels of Representation: Conceptual Modeling, Logical Database Design and Physical Implementation

[4] Pascal, F., Business Modeling for Database Design: Formalizing the Informal

[5] Pascal, F., Relationships and the Relational Model

[6] Pascal, F., Physical Independence, Parts 1 and 2 

[7] Pascal, F., Logical Validity and Semantic Correctness

[8] Pascal, F., Business Rules, Predicates, Integrity Constraints and Database Consistency