What is a relational database?

Relationships are just as important as individual features

A practical example

Relational Databases are a way of connecting data and establishing a relationship between them. Or, simply put, defining how one block of information relates to another.

To show the meaning of this in a more practical manner, let's go through a simple example:

If we look at the Clients table below, we can see that it's a simple table that's totally self contained. That is: I have no information besides what I'm seeing on the table.

A simple table with no related information.A simple table with no related information.

A simple table with no related information.

However, there's certainly more important information to know about a client than their contact info. If we're a SaaS startup, for example, we might have different plans that the clients can subscribe to. If that's the case, we might want to add a "list" type field called "Plan" to indicate this. It would look something like this:

A table of clients and their chosen plan.A table of clients and their chosen plan.

A table of clients and their chosen plan.

At first it might seem we solved our problem, but there's one thing we still have to take into account: the characteristics of the plans themselves. Of course, we could just add more fields (like pricing, maximum number of users, features), but that would not be ideal for two reasons:

  1. I'd have to unnecessarily write down the same information many, many times: every client with the Smart plan, for example, would have the exact same features, and I'd have to copy it every time I added a new client to our database;

  2. It's very easy to mess up and very hard to correct: because I have to input every information manually every time, the chance of human error increases exponentially. Also, if I change some characteristic of a plan (say, pricing), I'll have to edit each client manually, furthering the chance of something going wrong.

However, a relational database allows me to do something else: connect tables. I could, for example, create a separate table for Plans:

A separate table for Plans.A separate table for Plans.

A separate table for Plans.

And then *connect the Clients table to the Plans table to indicate this relationship using a "Connect tables" field, which would look something like this:

Connecting a client to a chosen plan.Connecting a client to a chosen plan.

Connecting a client to a chosen plan.

Not only can I choose from the plans in my database, I can click on the plan directly from the client record and see the plan's information. Because I've established the relationship between client and plan, I now have access to the information directly should I want to use it (whether for a quick glance through the interface or for automations).

Now, the way we built the relationship above is that every client can point/connect to a plan. So what happens if more several more clients choose the same plan?

This information is also available through the plans's table. If I open the "Smart" plan, for example, I can easily see which clients are subscribers to that specific plan:

Using the Connected part of the UI to check relationship between tables.Using the Connected part of the UI to check relationship between tables.

Using the Connected part of the UI to check relationship between tables.

How does it help me?

What Relational Databases do is allow you to create those connections in a way you can better organize and use data. Traditionally it would be necessary to hard code these relationships when designing a process, but jestor allows you to create them through the UI with just a few clicks.

📘

Understanding connected data

If you'd like to know more about how to effectively use Relational Databases to build processes, we strongly recommend that you read the Three Laws of Process Building: https://jestor.com/blog/jestor-process/pareidolia-to-process/