This lesson walks you through the three kinds of relationships you can create between sets of data so that you can build a fully functional, customized web app.
Home > Ontraport for no-code web apps > Custom Objects > The three relationship types
Home > Custom Objects > The three relationship types
The three relationship types
Course Instructor
- The difference between one-to-many, one-to-one and many-to-many relationship types
- Examples of each relationship type so you can figure out how to organize your data
- The basics of intermediate objects, like tickets
- Why setting up your data properly matters
Comments
[Block//Author//First Name ##cap_first] [Block//Author//Last Name ##cap_first] on [Block//Date Added %F j, Y g:i a%+0d0h0m]
[Block//Comment]
Leave your comment
14-day free trial. No commitment.
Related resources
[Block//Resource Type]
[Block//Resource Description ##ellipsis(166)]
Transcript
In the last video, I showed you how custom objects can work in different situations.
If you are a veterinarian, for example, you might store your pet owners as contacts in your Ontraport account and their pets in a separate object.
It’s good to have those two objects. But a crucial part of the puzzle here is knowing which pets belong to which owners.
To track that, you need to link the two objects together so that if you’re looking at a pet record, you can see who owns it. And if you’re looking at a pet owner record, you can see a list of their respective pets.
To set this up, you’ll need to create relationships between objects.
There are three kinds of relationships that you can create between sets of data. It’s important to understand the differences between them because the relationships you create determine what you can see and do with your data later.
I’ll go over each of the three relationship types, explain what each one looks like in your account and when to use them.
I’ll also discuss the important concept of intermediate objects, which is an object that connects to others in a way that’s especially useful and powerful.
So, let’s dive in.
The three relationship types are:
One-to-many, one-to-one and many-to-many.
The first and most common relationship between objects is a One-to-many relationship — also called a Parent/child relationship.
In a one-to-many relationship, there is one parent record associated with many child records.
Something kind of like this:
This one-to-many concept applies to our vet clinic example. A pet has one owner, but the owner might have many pets.
When you create relationships between objects in Ontraport, some new fields get created in each record for you to record the connection. The types of fields you create will depend on the type of relationship you set up.
So going back to our vet example, let’s take a look at what happens when you create a one-to-many relationship between pets and contacts, a.k.a. your pet owners.
Since you know that each pet will have one owner and you want to see who that owner is in each pet record, Ontraport will need to make a single field in the pet record that shows who the owner is.
But if you go to the owner’s record, you know that they might have 47 birds, so you’ll see a list of pets this person owns. This list is called a subcollection, and it’s added to your contact records automatically when the relationship is created.
This list has some cool functionality which I’ll cover in our “Using Custom Objects” video.
If you want to see one owner field in one record and a list of related records in the other record, then you know you’re going to need a one-to-many relationship.
Of course, it's important to nail down which record is the parent and which is the child. When you set it up, the system will ask you this. The one with the parent field is the child, and the one with the list of children is the parent.
The one-to-many relationship is going to be your most common — and most useful — relationship type. But there are others, like the One-to-one relationship.
In this relationship, each record can have only one related record. It’ll look something like this:
A good example might be someone’s account ID, if they never have more than one account.
Or, in most places on Earth, a spouse would be a good example of a one-to-one relationship. In this case, each record will have a single field that represents the connected contact. When you select a spouse in one contact record, that record will automatically be selected in the other spouse’s record. It’s a reciprocal situation.
Apart from things like spouses though, one-to-one relationships are pretty rare and generally less useful. That’s because if there’s only one of a thing that’s related, it will usually make sense to just add more fields to your original record.
So, let’s move on to the next relationship, which is very common but also a bit challenging to set up: the Many-to-many relationship.
Here’s a quick visual to show you what this relationship looks like:
As the name suggests, this relationship is used when each record may be related to many others.
A magazine subscription is a good example, because a magazine might have many subscribers, but people may be subscribed to many magazines.
Tickets are another good example of many-to-many relationships. Someone might buy tickets to several events but of course, any event will have multiple ticket buyers.
So if you’re selling event tickets and you go to a contact record, you’ll see a subcollection of tickets that person has purchased. And if you go over to the event record, you’ll see a list of ticket holders.
This is all really pretty straightforward, so let’s complicate things just a bit.
Many-to-many relationships are common… but they’re not necessarily super useful.
That’s because there’s no way to store what we call “metadata,” which is data about the relationships themselves.
Now, all this is probably confusing, so I’ll use our ticket seller example to explain what I mean.
As I said before, it’s good to know who bought tickets from you, and a many-to-many relationship will do that for you.
But what about seat numbers? What about purchase dates? What about admission types or price paid? Or maybe someone bought a ticket for someone else, and you need to record who the ticket is actually for. Or how about recording who actually showed up and used their ticket?
In a many-to-many relationship, there’s nowhere to store any of that information. You can’t put it in the contact record, because the contact record will have different seat numbers for each ticket. And you can’t put it in the event record because every buyer will have a different seat number.
So you’re stuck. This leaves you without a bunch of important info and it also really limits your opportunities for automating things later.
Fortunately, there’s a solution — building an Intermediate object between your contacts and events.
In this case, the intermediate object has a name you’ll recognize: it’s a ticket.
We call it an intermediate object because it sits between contacts and events, which in our new setup, are no longer related to each other directly. Instead we have tickets, which are the children in a one-to-many relationship with your contacts. A contact can buy many tickets, but a ticket has only one buyer.
And there’s a second relationship, which is a one-to-many relationship with your events, where again, tickets are the children. This makes sense because an event has many tickets, but a ticket is only good for one event.
And now, you’ll see that everything falls nicely into place. We can go to our tickets object and create all those fields we had no place for before: purchase date, seat number, VIP level, who the ticket is registered to, whether they showed up, etc.
And, when you go to contacts, you’ll still be able to see all the tickets they’ve bought, with all that extra info. Likewise, when you go to events, you’ll see all the tickets you sold, again with all that useful information.
And, when it’s time to send your event recordings to the folks who showed up, it’s easy as pie. You just go to the tickets object and make a group of tickets for this event that were checked in and then send off emails to the registered attendees. Of course, you could automate all that just as easily, because you set this all up in a smart way.
Because you were clever with your custom objects setup, you’re going to be able to create a web application where people can log in and see their tickets, register them, check in, upgrade, downgrade and more. You’ll learn how to do all that in the coming videos.
Okay cool, you got through all three relationship types and no one got hurt! I even got you thinking about intermediate objects, which is some higher-level stuff.
We’re on the right track here so next, I’m going to show you how to set up custom objects, step by step. Let’s get ‘er done.
If you are a veterinarian, for example, you might store your pet owners as contacts in your Ontraport account and their pets in a separate object.
It’s good to have those two objects. But a crucial part of the puzzle here is knowing which pets belong to which owners.
To track that, you need to link the two objects together so that if you’re looking at a pet record, you can see who owns it. And if you’re looking at a pet owner record, you can see a list of their respective pets.
To set this up, you’ll need to create relationships between objects.
There are three kinds of relationships that you can create between sets of data. It’s important to understand the differences between them because the relationships you create determine what you can see and do with your data later.
I’ll go over each of the three relationship types, explain what each one looks like in your account and when to use them.
I’ll also discuss the important concept of intermediate objects, which is an object that connects to others in a way that’s especially useful and powerful.
So, let’s dive in.
The three relationship types are:
One-to-many, one-to-one and many-to-many.
The first and most common relationship between objects is a One-to-many relationship — also called a Parent/child relationship.
In a one-to-many relationship, there is one parent record associated with many child records.
Something kind of like this:
This one-to-many concept applies to our vet clinic example. A pet has one owner, but the owner might have many pets.
When you create relationships between objects in Ontraport, some new fields get created in each record for you to record the connection. The types of fields you create will depend on the type of relationship you set up.
So going back to our vet example, let’s take a look at what happens when you create a one-to-many relationship between pets and contacts, a.k.a. your pet owners.
Since you know that each pet will have one owner and you want to see who that owner is in each pet record, Ontraport will need to make a single field in the pet record that shows who the owner is.
But if you go to the owner’s record, you know that they might have 47 birds, so you’ll see a list of pets this person owns. This list is called a subcollection, and it’s added to your contact records automatically when the relationship is created.
This list has some cool functionality which I’ll cover in our “Using Custom Objects” video.
If you want to see one owner field in one record and a list of related records in the other record, then you know you’re going to need a one-to-many relationship.
Of course, it's important to nail down which record is the parent and which is the child. When you set it up, the system will ask you this. The one with the parent field is the child, and the one with the list of children is the parent.
The one-to-many relationship is going to be your most common — and most useful — relationship type. But there are others, like the One-to-one relationship.
In this relationship, each record can have only one related record. It’ll look something like this:
A good example might be someone’s account ID, if they never have more than one account.
Or, in most places on Earth, a spouse would be a good example of a one-to-one relationship. In this case, each record will have a single field that represents the connected contact. When you select a spouse in one contact record, that record will automatically be selected in the other spouse’s record. It’s a reciprocal situation.
Apart from things like spouses though, one-to-one relationships are pretty rare and generally less useful. That’s because if there’s only one of a thing that’s related, it will usually make sense to just add more fields to your original record.
So, let’s move on to the next relationship, which is very common but also a bit challenging to set up: the Many-to-many relationship.
Here’s a quick visual to show you what this relationship looks like:
As the name suggests, this relationship is used when each record may be related to many others.
A magazine subscription is a good example, because a magazine might have many subscribers, but people may be subscribed to many magazines.
Tickets are another good example of many-to-many relationships. Someone might buy tickets to several events but of course, any event will have multiple ticket buyers.
So if you’re selling event tickets and you go to a contact record, you’ll see a subcollection of tickets that person has purchased. And if you go over to the event record, you’ll see a list of ticket holders.
This is all really pretty straightforward, so let’s complicate things just a bit.
Many-to-many relationships are common… but they’re not necessarily super useful.
That’s because there’s no way to store what we call “metadata,” which is data about the relationships themselves.
Now, all this is probably confusing, so I’ll use our ticket seller example to explain what I mean.
As I said before, it’s good to know who bought tickets from you, and a many-to-many relationship will do that for you.
But what about seat numbers? What about purchase dates? What about admission types or price paid? Or maybe someone bought a ticket for someone else, and you need to record who the ticket is actually for. Or how about recording who actually showed up and used their ticket?
In a many-to-many relationship, there’s nowhere to store any of that information. You can’t put it in the contact record, because the contact record will have different seat numbers for each ticket. And you can’t put it in the event record because every buyer will have a different seat number.
So you’re stuck. This leaves you without a bunch of important info and it also really limits your opportunities for automating things later.
Fortunately, there’s a solution — building an Intermediate object between your contacts and events.
In this case, the intermediate object has a name you’ll recognize: it’s a ticket.
We call it an intermediate object because it sits between contacts and events, which in our new setup, are no longer related to each other directly. Instead we have tickets, which are the children in a one-to-many relationship with your contacts. A contact can buy many tickets, but a ticket has only one buyer.
And there’s a second relationship, which is a one-to-many relationship with your events, where again, tickets are the children. This makes sense because an event has many tickets, but a ticket is only good for one event.
And now, you’ll see that everything falls nicely into place. We can go to our tickets object and create all those fields we had no place for before: purchase date, seat number, VIP level, who the ticket is registered to, whether they showed up, etc.
And, when you go to contacts, you’ll still be able to see all the tickets they’ve bought, with all that extra info. Likewise, when you go to events, you’ll see all the tickets you sold, again with all that useful information.
And, when it’s time to send your event recordings to the folks who showed up, it’s easy as pie. You just go to the tickets object and make a group of tickets for this event that were checked in and then send off emails to the registered attendees. Of course, you could automate all that just as easily, because you set this all up in a smart way.
Because you were clever with your custom objects setup, you’re going to be able to create a web application where people can log in and see their tickets, register them, check in, upgrade, downgrade and more. You’ll learn how to do all that in the coming videos.
Okay cool, you got through all three relationship types and no one got hurt! I even got you thinking about intermediate objects, which is some higher-level stuff.
We’re on the right track here so next, I’m going to show you how to set up custom objects, step by step. Let’s get ‘er done.
Features
© Ontraport 2024
playlist_add_check
PCI DSS, Level 1
security
Privacy Shield Certified