The classic Northwind database converted to the NoSQL world

by Jon Erik Solheim

northwind

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 90's 🙌) 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 Nortwind 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.

model

Behold the UI from the Access database.

access

Uploading the raw data

Thanks to 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.

import

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 6635 records (or Documents, as we say in NoSQL speak).

dash

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.

orders

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).

mapping

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

E.g. 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 foreign key OrderID.

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

orders-finished-mapping

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.

product-detail

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.

product-order-details

The REST API

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

Lets 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 ok.

Conclusion

SQL and NoSQL databases will probably continue to live side by side and each of them has its uses and advantages. The popularity of NoSQL databases like MongoDB is steadily growing due to it's simplistic and Javascript/web-friendly characteristics. This blog post showed you how to migrate data from SQL into a cloud database service like https://restdb.io.

Further reading

Blog