With this article, I intend to share my learning and experiences of modeling data using AWS DynamoDB. While writing this article, the following have been assumed:

• a viewer/ reader understands the NoSQL database basic concepts
• has basic understanding of AWS DynamoDB. If not, please visit the documentation at this link

Design Best Practices

I had been working in both relational databases (RDMBS) and NoSQL databases (both MongoDB and DynamoDB). Having completed online workshops/courses from MongoDB univeristy worked in MongoDB a lot, I assumed that DynamoDB would also be same (keeping in view that both fall in to Document based NoSQL database type). However, it was a surprise for me to understand the way DynamoDB handles relations, indexes and queries etc. Also, the data modelling in DynamoDB is quite different than in MongoDB. The preferred approach for data modelling in DynamoDB is to have a single table for all the entities of your application.This was a big paradigm shift for me to think “N” number of application tables/entities as one DynamoDB table with all the relations ( 1:1 one to one, 1:M one to many, M:N many to many). I’ll try to describe some of the best practicing I have been following and found useful to the viewer.

A developer or data modeler must carefully refer the following steps during data modelling exercise. Please note that these steps are not that easy to digest and implement as these appear to be ( based on my experience, you may be a quick learner than me) . Also, the data modelling exercise is an iterative process. You will have to undergo the following steps ( or by skipping one or the other step) multiple times in a loop.

Write down all the entities in your application

Write down all the possible entities of your application in a spreadsheet table or you may want to use a plain paper for that. For example, for a basic employee management application, possible entities could be “employee”, “department”, “project”, “roles”, “users” etc. The number of entities could depend upon the complexity of the application. You should also write down primary key ( covering one attribute or set of attributes in the entity) from that table. The objective of having primary key is to uniquely identify each record in the table. Once, this step is complete, let us move the next step.

Write down all the possible relationships in your application

In this step, find out all the relationships between different entities. For example, there could be some entities with no relations among them. While in other entities, there could be “one to many” or “many to many” relations. Write down all these relationships along with the fields/attributes through which relationship is maintained. These first two steps can be thought of reaching to an ER (Entity Relationship) diagram. Once this is achieved, keep it aside for later consumption and move to the next step.

Know your application’s access patterns

This is one of the most significant part of the modelling. When I started with NoSQL databases, I struggled a lot that “how knowing application access pattern can contribute in data modelling.” However, I was able to understand this gradually. You may like to start with understanding and writing access pattern of your application as first step. There is no specific sequence of steps to be followed for data modelling of NoSQL databases. However, before you start data modelling ( i.e. what will be the final structure of your table etc.), you must succinctly know access patterns. Now, there might be a question that “What is an access pattern?” “Access pattern” can be considered as a query to your database. This query can be a simple query or complex query. For example, “A user wants to view listing of all the employees by department”. Another possible access pattern could be “A user wants to view the average salary at different levels of employees”. All such access patterns have to be noted down in a spreadsheet or a plain paper. We will cover this step by step once we go over in future articles.

Conclusion

The DynamoDB data modelling has been described above. This is the first article in this series and has covered just an overview of data modelling. In the upcoming articles in this series, I’ll cover topics like “How to design one-many relationships”, “How To design many-many relationships”, “Querying best practices”.