NoSQL Data Modeling

Data modeling for RDBMS has been a well-defined discipline for many years. Techniques like logical to physical mapping and normalization / de-normalization have been widely practiced by professionals, including novice users. However, with the recent emergence of NoSQL databases, data modeling is facing new challenges to its relevance. Generally speaking, NoSQL practitioners focus on physical data model design rather than the traditional conceptual / logical data model process for the following reasons:

  • Developer-centric mindset – With flexible schema (or schema-free) support in NoSQL databases, application developers typically assume data model design responsibility. They have been ingrained with the notion that the database schema is an integral part of application logic.
  • High-performance queries running in massive scale-out distributed environments – Contrary to traditional, centralized scale-up systems (including the RDBMS tier), modern applications run in distributed, scale-out environments. To accomplish scale-out, application developers are driven to tackle scalability and performance first through focused physical data model design, thus abandoning the traditional conceptual, logical, and physical data model design process.
  • Big and unstructured data – With its rigidly fixed schema and limited scale-out capability, the traditional RDBMS has long been criticized for its lack of support for big and unstructured data. By comparison, NoSQL databases were conceived from the beginning with the capability to store big and unstructured data using flexible schemas running in distributed scale-out environments.

In this blog post, we explore other important mindset changes in NoSQL data modeling: development agility through flexible schemas vs. database manageability; the business and data model design process; the role of RDBMS in NoSQL data modeling; NoSQL variations that affect data modeling; and visualization approaches for NoSQL logical and physical data modeling. We end the post with a peak into the NoSQL data modeling future.

Development agility vs. database manageability

One highly touted feature in today’s NoSQL is application development agility. Part of this agility is accomplished through flexible schemas, where developers have full control over how data is stored and organized in their NoSQL databases. Developers can create or modify database objects in application code on the fly without relying on DBA execution. The result is, indeed, increased application development and deployment agility.

However, the flexible schema is not without its challenges. For example, dynamically created database objects can cause unforeseen database management issues due to the lack of DBA oversight. Furthermore, unsupervised schema changes increase DBA challenges in diagnosing associated issues. Frequently, such troubleshooting requires the DBA to review application code written in programming languages (e.g., Java) rather than in RDBMS DDL (Data Definition Language) – a skill that most DBAs do not possess.

NoSQL business and data model design process

In old-school software engineering practice, sound business and (relational) data model designs are key to successful medium- to large-scale software projects. As NoSQL developers assume business / data model design ownership, another dilemma arises: data modeling tools. For example, traditional RDBMS logical and physical data models are governed and published by dedicated professionals using commercial tools, such as PowerDesigner or ER/Studio.

Given the nascent state of NoSQL technology, there isn’t a professional-quality data modeling tool for such tasks. It is not uncommon for stakeholders to review application source code in order to uncover data model information. This is a tall order for non-technical users such as business owners or product managers. Other approaches, like sampling actual data from production databases, can be equally laborious and tedious.

It is obvious that extensive investment in automation and tooling is required. To help alleviate this challenge, we recommend that NoSQL projects use the business and data model design process shown in the following diagram (illustrated with MongoDB’s document-centric model):

design_process

Figure 1

  • Business Requirements & Domain Model: At the high level, one can continue using database-agnostic methodologies, such as domain-driven design, to capture and define business requirements
  • Query Patterns & Application Object Model: After preliminary business requirements and the domain model are produced, one can work iteratively and in parallel to analyze top user access patterns and the application model, using UML class or object diagrams. With RDMS, applications can implement database access using either a declarative query (i.e., using a single SQL table join) or a navigational approach (i.e., walking individual tables embedded in application logic). The latter approach typically requires an object-relational mapping (ORM) layer to facilitate tedious plumbing work. By nature, almost all NoSQL databases belong to the latter category. MongoDB can support both approaches through the JSON Document model, SQL-subset query, and comprehensive secondary indexing capabilities.
  • JSON Document Model & MongoDB Collection / Document: This part is where native physical data modeling takes place. One has to understand the specific NoSQL product’s strengths and weaknesses in order to produce efficient schema designs and serve effective, high-performance queries. For example, modeling social network entities like followed and followers is very different from modeling online blogging applications. As such, social networking applications are best implemented using Graph NoSQL databases like Neo4j, while online blogging applications can be implemented using other flavors of NoSQL like MongoDB.

RDBMS data modeling influence on NoSQL

Interestingly enough, old-school RDBMS data modeling techniques still play a meaningful role for those who are new to NoSQL technology. Using document-centric MongoDB as an example, the following diagram illustrates how one can map a relational data model to a comparable MongoDB document-centric data model:

mongodb_mapping

Figure 2

NoSQL data model variation

In the relational world, logical data models are reasonably portable among different RDBMS products. In a physical data model, design specifications such as storage clauses or non-standard SQL extensions might vary from vendor to vendor. Various SQL standards, such as SQL-92 and the latest SQL:2008 as defined by industry bodies like ANSI/ISO, can help application portability across different database platforms.

However, in the NoSQL world, physical data models vary dramatically among different NoSQL databases; there is no industry standard comparable to SQL-92 for RDBMS. Therefore, it helps to understand key differences in the various NoSQL database models:

  • Key-value stores – Collections comprised of unique keys having 1-n valid values
  • Column families – Distributed data stores in which a column consists of a unique key, values for the key, and a timestamp differentiating current from stale values
  • Document databases – Systems that store and manage documents and their metadata (type, title, author, creation/modification/deletion date, etc.)
  • Graph databases – Systems that use graph theory to represent and store data as nodes (people, business, accounts, or other entities), node properties, and edges (lines connecting nodes/properties to each other)

The following diagram illustrates the comparison landscape based on model complexity and scalability:

nosql_comparisons

Figure 3

It is worth mentioning that for NoSQL data models, a natural evolutionary path exists from simple key-value stores to the highly complicated graph databases, as shown in the following diagram:

nosql_evolution

Figure 4

NoSQL data model visualization

For conceptual data models, diagramming techniques such as the Entity Relationship Diagram can continue to be used to model NoSQL applications. However, logical and physical NoSQL data modeling requires new thinking, due to each NoSQL product assuming a different native structure. One can intuitively use any of the following three visualization approaches, using a document-centric data model like MongoDB as an example:

  • Native visual representation of MongoDB collections with support for nested sub-documents (see Figure 2 above)

Pros – It naturally conveys a complex document model through an intuitive visual representation.
Cons – Without specialized tools support, visualization results in ad-hoc drawing using non-uniform conventions or notations.

  • Reverse engineering selected sample documents using JSON Designer (see Figure 5 below)

Pros – It can easily reverse engineer a hierarchical model into a visual representation from existing JSON documents stored in NoSQL databases like MongoDB.
Cons – As of this writing, JSON Designer is available only on iPhone / iPad. Furthermore, it does not include native DB objects, such as MongoDB indexes.

json_designer

Figure 5

  • Traditional RDBMS data modeling tools like PowerDesigner (see Figure 6 below)

Pros – Commercial tools support is available.
Cons – it requires tedious manual preparation and diagram arrangement to represent complex and deeply nested document structure.

power_designer

Figure 6

In a future post, we’ll cover specific data model visualization techniques for other NoSQL products such as Cassandra, which is based on the Column Family structure.

New NoSQL data modeling opportunities

Like any emerging technology, NoSQL will mature as it becomes mainstream. We envision the following new data modeling opportunities for NoSQL:

  • Reusable data model design patterns (some product-specific and some agnostic) to help reduce application development effort and cost
  • Unified NoSQL model repository to support different NoSQL products
  • Bi-directional, round-trip engineering support for (data) model-driven design processes and tools
  • Automated data model extraction from application source code
  • Automated code-model-data consistency validation and consistency conformance metrics
  • Strong control for application / data model change management, with proactive tracking and reconciliation between application code, embedded data models, and the actual data in the NoSQL databases

8 thoughts on “NoSQL Data Modeling

  1. Frank Lai

    This is interesting. Schema-free really means flexible schema and data modeling is still required to implement an application easy to maintain and upgrade.

    Shifting responsibility from DBA to application developers gives great scalability. However, embedding data model in the code makes it harder to understand and maintain applications among a team of developers.

    Without proper data model governance, NoSQL databases can easily become data dump land. The faster it grows, the quicker it reaches that stage.

    Reply
  2. Gordon Ko

    NoSQL is still relative new for many developers. How to bring the traditional domain-specific data model into this NoSQL structure can be a challenge work. This article summarizes and provides several useful approaches to solve the problem. Would like to see more articles from the author or others to discuss the details.

    Reply
  3. Sam

    This is an excellent article, especially in the context of NoSQL databases. I have been exploring this topic for some time and this is, by far, the most informative piece I have read. The main theme I took away was that it requires a vey different mindset for a seasoned data modeling professional to work on a new technology like NoSQL. Furthermore, I agree that certain old school techniques are still valuable in the new era if they are applied properly.

    Reply
  4. Jeremie

    I like this article a lot.
    I was wondering what set of tools, open source or commercial you faced, regarding your data modelling opportunities.
    It seems all still very customised and private at the moment.

    Reply
    1. Donovan Hsieh

      Hi Jeremie – Glad to know that you like this article. As for NoSQL data modeling tools (either commercial or open source), the short answer is that so far we haven’t not found one that is useful for our need. Imho, there are several reasons why that is the case:

      (1) Disparity of data models across different NoSQL, e.g., Document centric MongoDB/Couchbase and Column Family (CF) oriented Cassandra/Hbase, are just 2 examples. Even within the same CF sub-category, there exist notable model differences. For example, Hbase’s CF is based on sparse multi-dimensional sorted map (see page 11 of http://www.softlock.net/default.aspx?DocSN=DMSGETATTACHMENT&AttachmentID=340), which is different than that of Cassandra (see http://www.ebaytechblog.com/2012/07/16/cassandra-data-modeling-best-practices-part-1/#.VICqvtLF8kQ).

      (2) High level of difficulty in implementing intuitive NoSQL data model visualization.

      (3)Since NoSQL is still in early stage of maturity, there is no clear indication for profit in commercialization of data modeling tool.

      Regards,
      -Donovan

      Reply
  5. Pingback: New thinking needed in IT to make NoSQL data modeling process work - Computer Parts For Sale

  6. Wayne Kurtz

    Very good, well thought-out article. I do have one suggested correction however. In paragraph three you are comparing programming languages to DDL, I think your comparison works better if you compare it to the combination of DDL and DML (data manipulation language). SQL is a declarative language where you define a shareable structure in DDL which can then be manipulated by a team of developers using DML. The DML is a means of validating the DDL. If the DML can produce the expected results then this validates the data structure expressed in the DDL. If not, then the DDL needs to be changed and the data refactored.

    It is possible to create conceptual and logical models of the data you are working with using the capability of most commercial data modeling tools (proprietary and/or open source) as long as the tool has a repository, supports relational algebra and allows you to model atomic data elements, and various collections of those data elements. Once you master this data modeling skill then all database architectures (SQL and NoSQL) become alternative implementation options which can be selected based on how well they meet your requirements. If you drive data modeling from the physical layer you will inevitably encounter the “loss of information” phenomenon.

    Reply
  7. Ted Hills

    Hello Donovan,

    I heard you speak at EDW 2015 in Washington, DC, and have learned of your interest in data modeling for NOSQL databases. I am introducing a new modeling notation that breaks through the barriers traditional E-R notations have when it comes to nested structures and complex types. This will benefit SQL database modeling too. I’d be very happy if you read my introductory article published by Dataversity: NO E-R: Why Modeling NOSQL Databases Must Go Beyond Entity-Relationship Modeling, and How to Get There. I’d be interested in your thoughts on the notation.

    I believe COM notation will take data modeling to the next level of power and sophistication.

    http://whitepapers.dataversity.net/?option=com_categoryreport&task=viewabstract&pathway=no&title=50268&frmurl=http%3a%2f%2fforms.madisonlogic.com%2fForm.aspx%3fpub%3d569%26pgr%3d1022%26frm%3d1756%26autodn%3d1%26src%3d10908%26ctg%3d410%26ast%3d50268%26crv%3d0%26cmp%3d16674%26yld%3d1%26clk%3d6160158064684959875%26embed%3d1

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *