🔗 Lesson 3.5: Relations & Rollups: Connecting Databases Together

Why Connect Databases at All?

You've built databases that each do one job well: a Tasks list, a Reading tracker, maybe a Contacts page. But the real world isn't made of separate lists — things belong to other things. A task belongs to a project. A book belongs to an author. A note belongs to a meeting. When your tools can't express "belongs to," you end up copying the same information into two places and keeping them in sync by hand. That always breaks.

Here's the mental model for this lesson. Think of two databases as two lists of index cards. A relation is a piece of string you tie between a card in one pile and a card in the other: "this Task is tied to that Project." A rollup is you following all the strings out of one Project card, reading what's written on the Task cards at the other end, and writing a summary back on the Project — "4 tasks, 2 done." You tie the strings once; Notion reads them for you forever.

Relations: Links Between Databases

A relation is a property type — just like text, date, or select — but instead of holding a value you type, it holds a link to one or more pages in another database. On a Task, a "Project" relation property lets you pick which Project this task belongs to. That's it. The magic comes later; the relation itself is just a connection.

Creating a relation, step by step

1. Open the database that will point to the other (e.g. Tasks).
2. Add a new property; choose type Relation.
3. Notion asks which database to relate to — pick the target (e.g. Projects). You can even relate to a brand-new database it creates for you.
4. Decide whether to show on the other side too (that's the two-way switch — more in the next section), then create the property.
5. Now each Task row has a "Project" cell. Click it and a picker appears listing Project rows; choose one (or several).

Here's the Tasks database with a new Project relation column. Notice the relation cells hold the name of a Project page, not typed text:

One-Way, Two-Way & Self-Relations

When you create a relation you choose whether it's visible on one side or both.

Two-way (synced) relations

A two-way relation shows the link on both databases. Add a Project to a Task, and that Task automatically appears in a "Tasks" property on the Project — Notion keeps both ends in sync. This is what you almost always want, because it's what lets a Project "see" all its tasks (and roll them up).

You never typed these Tasks into the Project — they appeared because the relation is two-way. Set a Task's Project and it shows up here instantly; clear it and it disappears from here.

One-way relations

A one-way relation shows the link on only the side you created it on. The Task knows its Project, but the Project has no "Tasks" property cluttering it. Use one-way when you only ever need to travel the link in one direction and don't want a return column — for example, tagging notes with a "Related area" you don't need the area to list back.

Self-relations

A relation can point a database at itself. This is a self-relation, and it's how you express hierarchy or dependency within one database:

• A Tasks database with a "Blocked by" self-relation — a task links to the tasks it depends on.
• A Projects database with a "Parent project" / "Sub-projects" self-relation for nesting.
• A Notes/wiki database with a "Related notes" self-relation to build a web of linked ideas.

Rollups: Pulling Info Across the Link

A relation gives you the string between two databases. A rollup is what walks that string and brings information back. A rollup is a property you add to the database that has the relation, and it answers a question about the related rows on the other end.

Every rollup needs three answers

When you add a rollup property, Notion asks you three things. Get these three right and rollups are easy:

1. Relation — which link do I follow? (e.g. the "Tasks" relation on a Project)
2. Property — what do I read on the far end? (e.g. the Task's "Status" or "Done" checkbox)
3. Calculate — how do I summarize it? (e.g. Count, Percent checked, Sum)

Rollup: "Open tasks"
   Relation:  Tasks
   Property:  Status
   Calculate: Count where Status is not Done   (Count → then filter)

Read it as a sentence: "Follow my Tasks relation, look at each task's Status, and count the ones that aren't Done." That single property now shows a live number on every Project, updating the instant a task's status changes.

Rollup Calculations

The Calculate option is where a rollup earns its keep. The choices you'll actually use most often:

Worked Example: Projects & Tasks

Let's assemble the whole picture. We have two databases, related two-way, with two rollups on the Projects side. First, the Tasks database (each task belongs to one project, and has a Done checkbox):

Now the Projects database. It has the synced Tasks relation plus two rollups — Task count (Count) and % complete (Percent checked on Done):

Nobody typed "3" or "33%". Check off "Write copy" and Website Redesign's % complete jumps to 67% by itself. Add a new task and point it at a project, and that project's count ticks up. This is the connected system — data entered once, summaries everywhere, always current.

🎯 Project: Build the Connected System

You'll create a Projects database, relate your existing Tasks database to it, and add rollups so each project shows its task count and percent complete. Everything here works on the Free plan — relations and rollups are core features, not paid add-ons.

Projects ▸ new property ▸ Rollup ▸ "Task count"
   Relation:  Tasks
   Property:  Name
   Calculate: Count all

Projects ▸ new property ▸ Rollup ▸ "% complete"
   Relation:  Tasks
   Property:  Done   (a checkbox)
   Calculate: Percent checked

Best Practices for Relations & Rollups

✅ Do's

• Default to two-way relations. The return side is what makes rollups possible.
• Name rollups for the answer, not the mechanism. "Open tasks" beats "Rollup 1".
• Limit a relation to one page when a row truly belongs to only one thing — it keeps rollups predictable.
• Add a Done checkbox if you want easy "percent checked" progress numbers.

❌ Don'ts

• Don't retype related data. If you're copying a project name into a task by hand, you want a relation.
• Don't over-relate. Not every database needs to touch every other. Connect what you'll actually roll up.
• Don't expect to edit a rollup. Rollups are read-only summaries; change the source rows instead.

📓 Learning Journal

📝 Lesson Summary

🎉 What You've Accomplished

You connected two databases and made one of them report on the other — automatically and forever. A Project now knows how many tasks it has and how far along it is, without you tallying anything. This is the single biggest leap in the whole course, and you just made it.

❓ Common Questions at This Stage

🔭 Looking Ahead

You've seen rollups hint at something bigger — turning data into new information. Next module opens with Formulas 2.0: Thinking in Formulas, a gentle introduction to Notion's formula property. You'll learn to compute your own values (like an "Overdue?" flag) one small, approachable step at a time.

✅ Before the Next Lesson

• Keep your related Projects + Tasks databases — formulas will build on them
• Make sure at least one task has a Due date (we'll compute against it next lesson)
• Write your Learning Journal entry for this lesson

📚 Additional Resources

• Notion Help — Relations & rollups
• Notion Help — Intro to databases
• Notion Help Center