Data Models Overview

Before we can build powerful databases, we need to understand the blueprints that guide their construction. Imagine trying to build a house without a plan. We might end up with a very strange and unstable structure! A data model is like a blueprint for our data. 

Data model

A data model is a set of concepts and rules used to describe the structure of a database. There are different types of data models, each designed for specific use cases.

Think of it as the architect’s master plan. It provides a framework for organizing data and determining the relationships between different pieces of information. For example, in our OnlineStore database, a data model defines how a Customer is linked to their Orders, and how each Order is linked to specific Products.

Choosing the right data model is crucial because it affects how efficiently we can store, access, and manage data.

Just as a skyscraper needs a different blueprint than a single-family home, different types of applications require different data models. We’ll explore some of the most important models that have shaped the history of databases.

These data model types have evolved over time to address different data organization needs.

The early models

Before the databases we commonly use today, there were two pioneering models: the hierarchical and the network model. Understanding them helps us appreciate why modern databases work the way they do.

The hierarchical data model

The hierarchical data model was one of the first database models.

As the name suggests, it organizes data in a tree-like structure. Each record has a single parent, and each parent can have one or more children. This creates a clear, top-down hierarchy. A classic example of a hierarchical structure can be seen in a computer’s file system.

At the top level, we have a root drive (the parent), which contains folders (the children). Each folder can, in turn, contain additional subfolders or files, forming a tree-like structure.

Similarly, in our OnlineStore database, we can visualize the Electronics category as a parent entity, with individual products such as Laptop and Smartphone acting as its children. This relationship illustrates how data can be organized hierarchically to represent logical groupings and dependencies.

This model is very efficient for one-to-many relationships (one parent, many children). However, it struggles with more complex scenarios. What if a product belonged to multiple categories? For instance, a Smartwatch could be in Electronics and Sports & Outdoors. The hierarchical model’s rigid one parent per child rule makes this impossible to represent cleanly.

The network model

The network model was developed to overcome the limitations of the hierarchical model. It also organizes data in a graph-like structure of records and links, but with a key difference: it allows each record to have multiple parent and child records.

This flexibility makes it easy to model many-to-many relationships. A Product can be supplied by multiple Suppliers, and a Supplier can provide multiple Products. This creates a network of interconnected data.

While the network model was more powerful, it was also more complex. Navigating these interconnected webs of data required programmers to manage a lot of pointers, making the system difficult to work with and maintain. This complexity paved the way for a much simpler and more intuitive model.

The modern standard (the relational model)

The relational model has its strengths in simplicity and mathematical foundation. In this model, data is organized into tables (relations). Each table consists of rows (called tuples) and columns (called attributes). For example, our Customers table is a relation, where each row represents a unique customer and each column represents an attribute like CustomerName or Email.

Relationships between tables are not managed with physical pointers but with data itself, specifically through keys. A PRIMARY KEY is a unique identifier for a row in a table (like ProductID in the Products table). A FOREIGN KEY is a column in one table that references the PRIMARY KEY of another table, creating a logical link.

For instance, the CategoryID column in our Products table is a foreign key that points to the CategoryID primary key in the Categories table. This simple mechanism allows us to link a product to its category without complex pointers. We can easily query this relationship to find all products in the Electronics category.

The relational model’s table-based structure is intuitive, flexible, and powerful, making it the foundation for SQL and the vast majority of databases used in businesses worldwide.

Beyond relational

While the relational model is dominant, certain applications benefit from different approaches. These are often grouped under the NoSQL umbrella.

The document model

In a document model, data is stored in flexible, self-describing documents, typically in formats like JSON or BSON. Unlike the rigid rows and columns of a relational table, each document can have its own unique structure. A document contains all the information related to a single item in one place.

For example, instead of storing an order across Orders, Order_Details, and Customers tables, we could store it as a single JSON document:

This model is great for applications where the data structure varies or when we need to retrieve all information about a single item quickly without performing joins.

The graph model

The graph model is specifically designed to handle data in which relationships are just as important as the data itself. It is built on two core concepts: nodes and edges.

• Nodes represent entities, such as customers, products, or locations.

• Edges represent the relationships between those entities, such as referrals, friendships, or transactions.

This model is especially powerful in domains where connections drive insights—for example, social networks, recommendation systems, and fraud detection. In our OnlineStore database, we could represent customer referrals using a graph structure. Each Customer is a node, and when one customer refers another, an edge labeled “REFERRED” connects them. This structure enables remarkably fast queries, such as:

• Find all customers referred by 'Jane Smith'.

• Identify the most influential customer in the network.

Queries that would be complex and time-consuming in a relational database become simple, intuitive, and highly efficient within a graph model.

We’ve just covered the essential blueprints for organizing data.

By understanding the strengths and use cases of different data model types, such as hierarchical, network, relational, document, and graph models, we are now better equipped to select the appropriate model for various applications. Great job getting through this foundational lesson!

Understanding these models is a huge step. Keep up the great work!