How To Draw NoSql Data Model Diagram?

NoSql, unlike SQL which has ER and class diagrams, has neither names nor constraints for data modeling diagram(s). The obvious reason is NoSql’s lack of hard and fast relationship rules, which aims to get a developer started with minimum requirements.

Since data modeling diagram is the blueprint of any application we should always draw one. For tool I prefer draw.io, where you simply need to drag and drop symbols into the canvas and align them. Its “Entity Relation” section on the left menu is most suitable for our modeling.

Example Problem Statement

Let us take a problem statement and draw our data model diagram around it in steps:

There’s a gift shop full of gift items. Mutiple cashiers perform duty at different times of day and sell these items to customers. Customers are unregistered in system but their name is inquired and put on receipt.

We need to buid a basic gift inventory and checkout system in light of above information. So, we start by identifying obvious and implied entities.

  • Item
  • Product - not mentioned but required to distinguish between say Hugo Boss perfume (product) and 10 bottles of it (items)
  • Cashier
  • Transaction - a more informative word than “sell” or “purchase”

And that’s all we need. Customer is not required because we just need its name and has no other information. Recepit is unnecessary as all data to print on receipt is avaialbe in transaction.

Following is the breakdown of all entities with diagrams, their relation with others, and example documents. Due to its familiarity I’m using MongoDB’s collections as entities and documents as examples.

Product

{
    id: 1,
    name: "Dark Blue Cologne",
    brand: "Hugo Boss",
    price: 22.46
}

Cashier

{
    id: 1,
    name: "John Smith",
    cellNum: "4565456789",
    address: "Broadway Street house no. 12, Brooklyn, New York, US",
    ssn: "011-72-XXXX"
    .
    .
    .
}

Product Has Many Items

//products
{
    id: 1,
    name: "Dark Blue Cologne",
    brand: "Hugo Boss",
    price: 22.46
}

//items
{
    id: 1,
    productId: 1,
    barcode: "0705632441947"
}

{
    id: 2,
    productId: 1,
    barcode: "0705632441948"
}

{
    id: 3,
    productId: 1,
    barcode: "0705632441949"
}

Transaction

Transaction is a required associative collection to solve following many to many problem:

  • A cashier can sell unlimited number of product items (Cashier John sells 15 sets of Hugo’s Dark Blue Cologne)
  • A product item can be sold by many cashiers (Hugo’s Dark Blue Cologne is sold by cahiers John, Tony, Malinda, George and 2 others)

salePrice is necessary to know at what price the product item was sold (in case of discount it’ll be less)

It might be tempting to model transaction on real world scenario where a customer buys multiple items in one go, which are shown in receipt as such. However, transaction should represent only one sale. For buying of multiple items, say 10 at a time, 10 transaction documents should be created. You can create another collection to group multiple transactions or simply place some unique identifier field (ex: transactionId) in all of transactions made collectively at one time.

Transaction Belongs To Product, Cashier And Item

This relationship can also be described as: Product has many Transactions, Cashier has many Transactions, Item has many Transactions.

Product has many Transactions” is completely optional and depends on requirements. For instance, when you need to generate yearly reports of sale and therefore need to know products in aggregated data, it’s easier to have product reference in transaction document than getting it through item (which will either require join if available in db or multiple queries).

//products
{
    id: 1,
    name: "Dark Blue Cologne",
    brand: "Hugo Boss",
    price: 22.46
}

//items
{
    id: 1,
    productId: 1,
    barcode: "0705632441947"
}

{
    id: 2,
    productId: 1,
    barcode: "0705632441948"
}

{
    id: 3,
    productId: 1,
    barcode: "0705632441949"
}

// cashiers
{
    id: 1,
    name: "John Smith",
    cellNum: "4565456789",
    address: "Broadway Street house no. 12, Brooklyn, New York, US",
    ssn: "011-72-XXXX"
    .
    .
    .
}

{
    id: 2,
    name: "Malinda Johnson",
    cellNum: "4565456689",
    address: "Harold Street house no. 133, Brooklyn, New York, US",
    ssn: "011-73-XXXX"
    .
    .
    .
}

//transactions
{
    id: 1,
    productId: 1,
    itemId: 1,
    customerName: "Daniel Witz",
    cashierId: 1,
    salePrice: 22 //salePrice to provide discount option
}

{
    id: 1,
    productId: 1,
    itemId: 2,
    customerName: "Glenn McDowell",
    cashierId: 1,
    salePrice: 22 
}

{
    id: 1,
    productId: 1,
    itemId: 3,
    customerName: "Robert Williams",
    cashierId: 2,
    salePrice: 22 
}

Rounding Out

We’ve finished our first design iteration! This basic diagram can be improved as the application development proceeds.

As noted earlier, NoSql data modeling lacks conventional names and design principles similar to that of SQL. For this, it’s always better to include the symbols used in the diagram itself for ease of reading for everyone. Let’s add entity and one-to-many symbols, the only two used.

A More Complex Design Example

Here’s a bit more real world (and rough!) problem depicted in the following data model diagram. I’ll leave it without explaining.