Goals

Learn about the differences between a relational data model and an aggregate data model, and how they relate to the term NoSQL. Understand the advantages and disadvantages of both approaches, as well as the steps required to migrate denormalized data. Explore different strategies for associating entities in the aggregate model. Finally, design a data model that can be used to achieve desired access patterns.

Examples:

• Structure of a webshop in a relational data model
• Structure of a webshop in an aggregate data model
• Implicit application schema of a schemaless database
• Migration steps for denormalized data
• Association strategies for webshop entities

Exercises:

• Design of a Star Wars film actors data model and queries for access patterns

Introduction

Context

NoSQL

The term NoSQL traces back to a meetup by Johan Oskarsson (Slack, Cassandra, Twitter, Last.fm) in 2009 (sadalage13):

Original NOSQL meetup description

NOSQL meetup - Braindump

As we can see, NOSQL was a word play on “open source, distributed, non relational databases” and the hashtag #nosql was used to advertise the event. Hence, the term NoSQL is not strictly defined, but often share common characteristics:

• No relational data model is used, but an aggregate data model
• Databases run well on distributed clusters of machines
• Databases are open-source

Rows and Tables

In a traditional relational data model, data is divided into rows with attributes and is spread across tables. As data normalization suggests, building complex, nested values is not encouraged. All data operations are based on tables, rows and attributes.

Database normalization

Example

When saving a single order for a webshop, all order data needs to be split to be stored into multiple tables, and a transaction is used to ensure that all writes to all tables succeed. When an order is read, multiple, potentially large tables need to be queried, and the results are then combined into an order object: