The Classic Northwind Database Converted to the NoSQL World

This blog post uses the classical Northwind example from Microsoft to show how you can migrate from a traditional relational database to a NoSQL cloud database.

Northwind Traders Access database is a sample database that shipped with Microsoft Office suite. The Northwind database contains the sales data for a fictitious company called Northwind Traders, which imports and exports specialty foods from around the world. Developers (back in the 90s) used it to learn the MS Access product.

In the following example we will show how to:

• Import the original SQL data files.
• Map relations between tables (collections).
• Use the REST API to the new Northwind NoSQL database.

Original Data Model

The Northwind relational data schema is shown in the picture below. 13 tables and 13 relations, we will try to re-create this in a modern NoSQL document schema.

Behold the UI from the Access database.

Uploading the Raw Data

Thanks a GitHub project we found, we save time and get a nice set of CSV files from a data dump from the Northwind database.

Importing the data is easy. Just click the Import button on the restdb.io database dashboard.

The screen shot below shows the import of orders and the mapping of the data fields.

After we've imported all data files, we can see the newly created collections and the count of their data records. All in all, it counts 6,635 records (or Documents, as we say in NoSQL speak).

When we navigate to the Orders collection, we can see that the data has been imported correctly. We can also see the CustomerID column that refers to a column in the Customer collection.

The next step is to start the mapping of the relations.

Mapping of Relations Between Collections

In order to create relations, we must change the schema of our database. First, we switch to Developer mode (button in the upper right corner) and then navigate to Orders > Settings.

The screen shot below shows all the fields on the Orders collection. We then select the CustomerID field, and change it from a textdata type to a Lookup to Customers. Note that we also need to select the Advanced option and then pick the foreign key field from the Customers collection (CustomerID).

The mapping process described here is repeated for all the relations we wish to map.

For example, to create a relation between Orders and Order-details, we navigate to the Order-detail collection and change the OrderIDfield to a Lookupthat refers to Orders with the foreign key OrderID.

The screenshot below shows the Order-detail view with the finished mappings against both Orders and Customers.

As we now have a data schema that "knows" about the relations between our collections, restdb.io provides us with some really useful productivity features.

Navigate to any Product shows all Order-details for that particular product.

And if you click on the Order-Details tab, you will see all associated records. The same "automagic" navigation tools are provided for all the relations in our data model.

The REST API

What does the Northwind data look like in our NoSQL database?

Let's run a cURL command line query to get a particular Order.

curl -k -i -H "Content-Type: application/json"\
-H "x-apikey: <some key>"\
-X GET 'https://northwindnosql-39ba.restdb.io/rest/orders/594a3c65f8b84a36000016be'

We get back the following JSON document.

{
  "_id": "594a3c65f8b84a36000016be",
  "OrderID": 10249,
  "CustomerID": [
    {
      "_id": "594a3d22f8b84a36000022ca",
      "CustomerID": "TOMSP",
      "CompanyName": "Toms Spezialitäten",
      "ContactName": "Karin Josephs",
      "ContactTitle": "Marketing Manager",
      "Address": "Luisenstr. 48",
      "City": "Münster",
      "Region": "NULL",
      "PostalCode": 44087,
      "Country": "Germany",
      "Phone": "0251-031259",
      "Fax": "0251-035695",
      "_created": "2017-06-21T09:32:18.575Z"
    }
  ],
  "EmployeeID": [
    {
      "_id": "594a3d88f8b84a36000022f2",
      "EmployeeID": "6",
      "LastName": "Suyama",
      "FirstName": "Michael",
      "Title": "Sales Representative",
      "TitleOfCourtesy": "Mr.",
      "BirthDate": "1963-07-02T00:00:00.000Z",
      "HireDate": "1993-10-17T00:00:00.000Z",
      "Address": "Coventry House",
      "_created": "2017-06-21T09:34:00.201Z"
    }
  ],
  "OrderDate": "1996-07-05T00:00:00.000Z",
  "RequiredDate": "1996-08-16T00:00:00.000Z",
  "ShippedDate": "1996-07-10T00:00:00.000Z",
  "ShipVia": 1,
  "Freight": 11.61,
  "ShipName": "Toms Spezialitäten",
  "ShipAddress": "Luisenstr. 48",
  "ShipCity": "Münster",
  "ShipRegion": "NULL",
  "ShipPostalCode": "44087",
  "ShipCountry": "Germany"
}

We see that the fields CustomerID and EmployeeID which used to be just text, has been replaced with the actual documents (records) they refer.

This differs from SQL databases, where we would have to join the three collections to produce a similar result.

In the NoSQL world, we embed and duplicate — and that's okay.

Conclusion

SQL and NoSQL databases will probably continue to live side by side in a long time ahead. Due to the increasing popularity of document databases like MongoDB, it's important to understand how you can migrate from one model to another. This blog post shows that this is actually quite easy.