The Rise of NoSQL and NoSQL Data Modeling

With NoSQL data modeling gaining traction, data governance isn’t the only data shakeup organizations are currently facing.

The rise of NoSQL databases is changing the landscape of data modeling. In 2016, Forrester stated that “NoSQL is not an option — it has become a necessity to support next-generation applications.”

And industry has begun adoption, with  queried for Forrester’s 2016 survey having already implemented or beginning to implement NoSQL technology.

But to determine NoSQL, and NoSQL data modeling’s growing reach, we must first consider its predecessor.

The Growing Need for NoSQL Data Modeling

SQL (Structured Query Language) is a traditional programming language used to manage data in a relational database. It has been widely adopted because it helps to maintain the referential integrity, constraints, normalization and structured access for data across disparate systems.

These factors are important for data modelers who work to define and analyze data requirements needed to support business processes within the scope of corresponding information systems within organizations.

However, the business landscape is changing. Organizations are generating and have access to astonishing amounts of data that must be managed, including harnessing it, storing it, analyzing it and getting it to the appropriate stakeholders so strategic decisions can be made.

Of course, these processes require inserting and/or querying data from underlying databases. And because of today’s competitive and overwhelmingly digital business environment, the agility of these processes is key, or opportunities will be missed and costs will go up.

Despite its prominence, the inflexible SQL database does not lend itself to agility. Therefore, the more malleable NoSQL database is gaining traction. This approach gives organizations the ability to store enormous amounts of unstructured data from disparate sources, scaling to petabytes of information from across the world.

A Radical Shift but Modeling Fundamentals Remain

NoSQL provides high performance with high availability. As I’ve already mentioned, it scales easily and offers rich query language in addition to flexible storage, although not stored in tables with keys and relations. But NoSQL and NoSQL data modeling is radically different, even counterintuitive, and not what traditional database administrators and data modelers are used to.

But the discipline of data modeling always starts with the fundamental question: what do I want to achieve with this information? Then you determine the queries you need to run and how frequently you’ll change, create or delete data.

In the NoSQL world, there are no data normalization or storage rules. In fact, denormalization and duplications often are encouraged to make queries faster, which makes business operations more efficient.

In addition, joins are rarely supported and are instead the responsibility of the application. Therefore, you should think this through before applying your data because application joins are expensive and will impact query times.

Data modeling is especially helpful here, and you need to know how you’re going to use your data and its characteristics so you can reference them at run time.  

NoSQL Modeling with erwin DM NoSQL

Because organizations are beginning to transition to NoSQL databases due to their many benefits, NoSQL data modeling had to be addressed. That’s why erwin has developed an extension of erwin Data Modeler called erwin DM NoSQL.

We want to help our customers use the most current database technologies while maintaining the integrity, quality and governance of their underlying business-critical information.

Here’s how data modeling works with erwin DM NoSQL:

• Import your erwin models (XML) into erwin DM NoSQL (https://www.myerwin.io).
  • You can export your erwin models using erwin DM.
  • In future releases, erwin DM automatically will push your erwin models to erwin DM NoSQL.

• Convert your erwin models into MongoBD models.
  • We provide three conversion options: 1) normalized (similar to traditional SQL), 2) denormalized (all tables are embedded as much as possible), and 3) custom (you choose what to embed and what to make a reference).
  • Be careful with the normalized conversion process, as it probably will result in slower queries. This option has a lot of reference collections (similar to SQL relations), which is not the preferred MongoDB (NoSQL) approach – hence the slower queries.
  • Clone your converted models, and edit them as you see fit.
  • At any point, you can export your scripts to create and populate these collections with sample data, editing your models based on the results.
  • During this process, you can collaborate with others, using the built-in notification system.
• Once you have the final MongoDB model, you can freeze the edits to share with developers so they can use it in production system.
• We call the above iterative process Query-Optimized Modeling^TM.

Experience how easy NoSQL Data Modeling is for yourself. Click here to take erwin DM NoSQL for a free spin.