Notion is an application that has become very popular among productive people in a short time. There are many different apps available in the productivity space that can support your productive process, for example for maintaining your to-do lists, monitoring your progress via Kanban functionality, setting up and managing your projects, and so on. There are numerous apps available for every purpose. However. the strength of Notion is that it integrates all these different functionalities into one environment. What is even more powerful, however, is that Notion makes it possible to build all these functionalities yourself using standard building blocks, so that it exactly matches your own wishes. In this article, I look at the database functionality within Notion. I see in many of the Notion database tutorials in blogs and on Youtube that databases are often not structured properly. So in this article, I want to explain the importance of Normalization for your Notion databases.
Note: This article contains affiliate links. At no additional cost to you, I will earn a small commission if you choose to click through and make a purchase via the linked website. For more information see the Affiliate Disclaimer.
Content of the article
- What is a database?
- What is Normalization?
- Why is normalization important in Notion databases?
- How to normalize your Notion databases
What is a database?
Before I jump directly into talking about normalization of a database, I want to start a bit simpler because maybe not everyone knows what a database actually is. Say you are a baker, a bicycle repairman, a writer, or a wedding planner, you all want to record important data about your purchases, your sales, your stock, your products, your outstanding activities, and so on. You can structure all this data for example in a spreadsheet, but also in a database in an application such as Notion, and of course, other database applications. In this article, I will only focus on relational databases. A relational database consists of one or more tables that have some relationship with each other. The data we want to store in these tables are organized in rows and columns. In Notion called Properties, the columns represent the different attributes of the data you want to store. Each row in the database represents a unique record for an item you want to store something about, such as in the case of a baker a sales record for the sale of bread, for which you specify the type of bread, the cost price, the selling price, and the number of items sold. Or when you organize courses, you want to store different records for students, the course they have requested, the course details, and when the course is planned.
There’s a lot more to say about databases and how to set them up, organize them, and how to query information from a database, but I’ll save that for future articles. In this article I want to focus on the topic of Normalization, what it means, why it matters for you as a Notion user, and how to deal with it properly.
What is Normalization?
It is extremely important to structure a database correctly. One of the pitfalls that inexperienced database users and designers tend to fall into is the tendency to want to store too much in one and the same table. As a result, redundant storage of the same data can quickly arise. And in the event of multiple captures of the same data, you’ll be faced with problems inserting, updating, and deleting this redundant data in the future. This may sound a bit theoretical right now, so let’s clarify this with an example.
In the Pizza Order Table below a pizza baker wants to store information about the orders placed, the customers who order the pizzas, and the product information.
Pizza Order Table
| Order date | Customer Name | Customer Address | Customer city | Customer phone number | Product name | Product type | Product price | Quantity |
|---|---|---|---|---|---|---|---|---|
| 2023 Feb 22 | Jan Pietersen | Hoofdstraat 35 | Nootjespolder | 08 45657821 | Hawaiian Pizza | Pizza | 12.00 | 1 |
| 2023 Feb 22 | Jan Pietersen | Hoofdstraat 35 | Nootjespolder | 08 45657821 | Pepperoni Pizza | Pizza | 14.00 | 3 |
| 2023 Feb 24 | John Been | Kerkstraat 23 | Lutjebalk | 08 12788547 | Veggie Pizza | Pizza | 13.00 | 2 |
| 2023 Feb 25 | Tonja van Diepen | Blaag 123 | Blakingen | 08 87658554 | Pepperoni Pizza | Pizza | 14.00 | 1 |
| 2023 Feb 25 | Tonja van Diepen | Blaag 123 | Blakingen | 08 87658554 | Cinnamon roll | Side dish | 4.50 | 2 |
At first glance this looks like a great table. All the information the pizza baker needs is stored to know who ordered the pizzas and where the customer lives, which pizzas were ordered and in what quantity, and the price information. But now let’s look at the aforementioned problems for inserting, updating, and deleting data.
Insert
Suppose customer Jan Pietersen was so satisfied with the previous order that he wants to order another 16 pizzas divided over 5 different types of pizzas for his party on February 26, 2023. In the current database setup, 5 new records must be created, namely a record for each type of pizza. For each record for each type of pizza, the Customer name, Customer address, Customer city, customer phone number, Pizza price, and quantity must then be recorded. It immediately becomes clear that much of the same information must be recorded over and over again, with the potential for errors, and just too much unnecessary redundant work.
Update
Suppose that thousands of records have been added to this table over the years and that there are also 50 orders still to be delivered in the coming days. Then suppose an employee of the pizza bakery thinks that Side dish as Product type is not the right name and it would be better to call it Dessert, think about all the work that needs to be done to keep all historical and outstanding order records updated to rename Side dish to Desert. It immediately becomes clear that much of the same information must be updated over and over again, with the potential for errors, and just too much unnecessary redundant work.
Delete
Suppose the pizza baker wants to clean up the table by removing order records older than 1 month. Suppose customer John Been last ordered pizzas 2 months ago. With the database cleanup, there will not be a single record of John Been’s customer data. With a new order, this customer information is therefore no longer available and must be entered again. It immediately becomes clear that when the pizza baker wants to delete his older order records, he also deletes related customer details.
Based on the above example I think it should be clear that the pizza baker should do things a bit differently. The solution is Normalization. Normalizing your database structure will help you avoid the above problems by removing redundant data structures. Several levels of normalization can be distinguished, but I will pay more attention to that in a future article. I want to focus on the basics for now. What is important for now to know, is that the concept and the process of normalization will help us to make and keep our data consistent, accurate, and reliable, by cleverly splitting your data into multiple related tables, instead of capturing everything in a single table. We do this by distinguishing specific subjects, also called entities, that each stand on their own. So let’s look at the above example gain and try to help out the pizza baker.
What we want to solve is the problem of redundancy. In principle, we don’t want to have too much repetition of the same data. When we look closely at all the columns in the Pizza Order Table, we can distinguish 3 different entities, namely Order, Customer, and Product. So what we can do is create separate tables for these entities. So let’s create an Order Table, a Customer Table, and a Product Table. Oh wait, let’s not forget that these tables have a certain relationship with each other. Without these relations, we can’t use them together. Below I will show what this looks like.
Product Table
In the Product Table we need to store information on the Product name, the Product type, and the Product price.
| Product name | Product type | Product price |
|---|---|---|
| Hawaiian Pizza | Pizza | 12.00 |
| Pepperoni Pizza | Pizza | 14.00 |
| Veggie Pizza | Pizza | 13.00 |
| Cinnamon roll | Side dish | 4.50 |
Customer Table
In the Customer Table we need to store information on the Customer name, Customer address, Customer city, and the Customer phone number.
| Customer Name | Customer Address | Customer city | Customer phone number |
|---|---|---|---|
| Jan Pietersen | Hoofdstraat 35 | Nootjespolder | 08 45657821 |
| John Been | Kerkstraat 23 | Lutjebalk | 08 12788547 |
| Tonja van Diepen | Blaag 123 | Blakingen | 08 87658554 |
Order Table
In the Order Table we now only need to store information on the Order date, the Customer name, the Product type, and the Quantity.
| Order date | Customer Name | Product name | Quantity |
|---|---|---|---|
| 2023 Feb 22 | Jan Pietersen | Hawaiian Pizza | 1 |
| 2023 Feb 22 | Jan Pietersen | Pepperoni Pizza | 3 |
| 2023 Feb 24 | John Been | Veggie Pizza | 2 |
| 2023 Feb 25 | Tonja van Diepen | Pepperoni Pizza | 1 |
| 2023 Feb 25 | Tonja van Diepen | Cinnamon roll | 2 |
The complete database design looks like this:
When we have organized our database properly, the tables are connected with each other in such a way that for an order, you only need to store the name of the customer and the product type in the Order Table. Based on the name of the customer, you can find all the details of this customer. So you only have to store the name of the customer redundant, but the rest of the customer details only need to be stored once. The same for the products. In the Products table you only store all the details for each product once, so each time you store the product name in an order record, you have a relation to that single product record with all the details. So let’s now look again at the previous problems with inserting, updating, and deleting, and see if things have improved for the same use cases.
Insert
Suppose customer Jan Pietersen was so satisfied with the previous order that he wants to order another 16 pizzas divided over 5 different types of pizzas for his party on February 26, 2023. In the current database setup, 5 new records must be created, namely a record for each type of pizza. For each record for each type of pizza, only the Customer name and the Product name must be recorded. As this customer was already registered once in the Customer Table the first time he ordered, this customer data can now be referenced again. And because all products are already registered in the Product table, the product data can be referenced as well.
Order Table
| Order date | Customer Name | Product name | Quantity |
|---|---|---|---|
| 2023 Feb 26 | Jan Pietersen | Pepperoni Pizza | 4 |
| 2023 Feb 26 | Jan Pietersen | Veggie Pizza | 3 |
| 2023 Feb 26 | Jan Pietersen | Hawaiian Pizza | 4 |
| 2023 Feb 26 | Jan Pietersen | BBQ Chicken Pizza | 4 |
| 2023 Feb 26 | Jan Pietersen | Buffalo Pizza | 1 |
Customer Table
| Customer Name | Customer Address | Customer city | Customer phone number |
|---|---|---|---|
| Jan Pietersen | Hoofdstraat 35 | Nootjespolder | 08 45657821 |
Product Table
| Product name | Product type | Product price |
|---|---|---|
| Hawaiian Pizza | Pizza | 12.00 |
| Pepperoni Pizza | Pizza | 14.00 |
| Veggie Pizza | Pizza | 13.00 |
| BBQ Chicken Pizza | Pizza | 14.00 |
| Buffalo Pizza | Pizza | 13.00 |
| Cinnamon roll | Side dish | 4.50 |
Update
Suppose that thousands of records have been added to the Order Table over the years and that there are also 50 orders still to be delivered in the coming days. Then suppose an employee of the pizza bakery thinks that Side dish as Product type is not the right name and it would be better to call it Dessert. Now it is very easy to just update one record in the Product Table for Cinnamon roll.
Product Table
| Product name | Product type | Product price |
|---|---|---|
| Hawaiian Pizza | Pizza | 12.00 |
| Pepperoni Pizza | Pizza | 14.00 |
| Veggie Pizza | Pizza | 13.00 |
| BBQ Chicken Pizza | Pizza | 14.00 |
| Buffalo Pizza | Pizza | 13.00 |
| Cinnamon roll | Dessert | 4.50 |
Delete
Suppose the pizza baker wants to clean up the Order Table by removing order records older than 1 month. Suppose customer John Been last ordered pizzas 2 months ago. Now it is not a problem at all to clean up the Order Table, because both the Customer Table and the Product Table remain unchanged.
I hope the examples above make it clear how the situation has been greatly improved by splitting the original Order Table into a simplified Order Table, a Customer Table, and a Product Table and establishing the necessary relationships between them. Mutations such as updates, deletes, and inserts can be performed much more easily and without consequences.
If you got interested in database concepts like normalization and you would like to go deeper, you should have a look at Edgar Frank Cod’s book “The Relational Model for Database Management“, or “Database Design and Relational Theory: Normal Forms and All That Jazz” written by C.J. Date (Affiliate links).
(Affiliate link)
(Affiliate link)
Why is normalization important in Notion databases?
Notion is a very comprehensive application and very flexible in organizing your data in the way that best suits your needs. When you become more and more experienced in the possibilities of Notion, you will soon start using the possibilities of databases, tables, and views. Like for every database application, I think it is very important to organize your Notion databases as optimally as possible right from the start so that you will not have to do a lot of repairs later when you notice that you have ended up in the aforementioned problems.
How to normalize your Notion databases
In this article I will not go into depth and describe how to actually create databases in Notion. That will be a separate article in this Notion Basics series since databases, tables, and views are together such a large subject that it deserves a more in-depth explanation and is better reflected in a separate dedicated article. But in this article, I want to give you some basic tips that can help you to design your Notion databases in a normalized way.
- Purpose – Determine the purpose of your database. Do you want to manage your sales? Do you want to set up a project administration? Do you want to keep an administration of all the books you have already read and still want to read?
- Entities – Now that the purpose of your database is clear, you want to determine what your main subjects are, or your entities. Determine which entities you can identify that can exist on their own, such as a Course entity, a Student entity, a Teacher entity, and a Course Location entity.
- Attributes – Now that your entities are clear, you want to determine per entity which attributes, or properties, you want to record, such as the customer name, customer address, and customer mobile phone in the customer entity. Take into account minimizing your data redundancy. Try to record as much as possible once.
- Relationships – Determine the relationships between the entities, such as a course can be taken by multiple students, a teacher can teach multiple courses, and a course can be scheduled at multiple locations.
- Tables – Now that you know which entities and attributes you need, you can translate them into the necessary tables.
- Relations – You now have all the information available and you have also set up the necessary tables to create relationships between the tables. For example, you can create a Property of the type Relation in the Order Table and then establish a connection with the Product Table. When this connection has been made in the Order Table, you can easily refer to a record in the Product Table for each record in this new column.
Final words
In dit artikel in mijn Notion Basics series heb ik een eerste licht willen schijnen op het belang van een goede database structuur voordat je je databases en tabellen op gaat zetten in notion. Deze informatie is daarnaast natuurlijk niet alleen binnen Notion van belang, maar is fundamenteel bij ieder database design. Ik heb inzicht gegeven wat het belang is van normalisatie aan de hand van een aantal voorbeelden waarin we inserted, updated, and deleted data. Het werd daarmee duidelijk dat via normalisatie overbodige redundantie aangepakt kan worden. Er is nog veel meer te vertellen over database normalisatie, zoals de verschillende normal vormen en hun toepassingen, dat ik bewaar voor een toekomstig artikel.
If you are interested in my book on Linux, my course on Zorin OS, or my unique desktop wallpapers, have a look at my store.
