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.
Solutions keyboard_arrow_down keyboard_arrow_up
Our Solutions
Ontraport's solutions work together to give you everything you need to run your business in one centralized, easy-to-use platform.
Sales +
CRMarrow_forward
Segment + Organizearrow_forward
Smart Pipelinesarrow_forward
Unified Contact Historyarrow_forward
Task Automationarrow_forward
Lead Scoring + Routingarrow_forward
Mobile Apparrow_forward
Trends arrow_forward
Ontraport Calendar arrow_forward
No-code Web Appsarrow_forward
Custom Objectsarrow_forward
Dynamic CMSarrow_forward
Conditional Contentarrow_forward
Membership Sitesarrow_forward
Paymentsarrow_forward
Order Formsarrow_forward
Offline Transactionsarrow_forward
Complex Offersarrow_forward
Upsells + Order bumpsarrow_forward
Decline Recoveryarrow_forward
Customer Centerarrow_forward
Referral Trackingarrow_forward
Pages + Formsarrow_forward
Drag and Drop Editorarrow_forward
Form Buildersarrow_forward
WordPress Integrationsarrow_forward
Marketing
Automationarrow_forward
Campaign Automationarrow_forward
Email + SMS Messagingarrow_forward
Email Deliverabilityarrow_forward
Tracking + Attributionarrow_forward
Facebook Custom Audiencesarrow_forward
Platformarrow_forward
API arrow_forward
Integrations arrow_forward
Security and Scalabilityarrow_forward
Industries we serve
Select your industry to see how our CRM and marketing software can support your growth
Learn more Resources keyboard_arrow_down keyboard_arrow_up
Pricing Chat Resources
Find free content on the latest marketing strategies, using Ontraport in your business, and finding the right software.
Visit the blog Research and Education
Bootcamp
Coursearrow_forward
Attend a hands-on training course designed to give users a solid foundation of software skills and marketing strategy.
Expert Certification
Coursearrow_forward
A course for business owners and marketing professionals wanting to support our mutual clients. Learn advanced marketing strategies and get exclusive perks.
Ontraport
Blogarrow_forward
Browse a collection of articles on marketing automation, email marketing, CRM, membership sites and more.
Step-by-Step
Templatesarrow_forward
Implement proven marketing processes with our easy-to-follow worksheets and checklists.
In-Depth
Guidesarrow_forward
Download our best-practice guides, complete with data-driven insights and tactics to help you optimize your marketing.
Podcastarrow_forward
Listen in as Ontraport CEO Landon Ray talks with with a star-studded cast of entrepreneurs, marketers and thought leaders.
Marketing
Blueprintsarrow_forward
Learn everything you need to know to develop fundamental marketing strategies with our digital handbooks.
Using Ontraport in Your Business
Software
Comparisonsarrow_forward
See if Ontraport is the right fit for you — compare the top marketing automation and CRM software on the market.
Setup Wizards
Libraryarrow_forward
Our Setup Wizards walk you through the steps to customize and launch a marketing campaign for your business in minutes.
Get the
Factsarrow_forward
View the most frequently asked questions about Ontraport so you can get clarity and feel confident in your buying decision.
Feature Use
Casesarrow_forward
See exactly what you can do with Ontraport, and learn how you can personalize it to perform your specific needs.
Calculate Your
ROIarrow_forward
Get an honest estimate of the return you can expect from an investment in Ontraport's software.
Exploring
Ontraportarrow_forward
Take a guided tour through the five phases of the customer lifecycle in a simulated business powered by Ontraport.
Try our free interactive customer portal demo!
Want to offer the convenient, self-service experiences your customers are looking for? Check out this free demo to see what you can create in Ontraport without code or developers.
Want to offer the convenient, self-service experiences your customers want?
Check out this free customer portal demo to see what you can build in Ontraport without code or developers.
Home > Ontraport for no-code web apps > Custom Objects > The three relationship types
Home > Custom Objects > The three relationship types
The three relationship types
You'll learn:
- 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
Jason Howell
The three relationship types
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.
- 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
Course Instructor
Jason Howell
Related resources
[Block//Author//First Name] [Block//Author//Last Name] on [Block//Date Added %F j, Y g:i a%+0d0h0m]
[Block//Comment]
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.
settings
Turn your business on with Ontraport.