Active Record Associations
By: Jakob Persons
Tags: Ruby on Rails, Activerecord, Programming

1. Belongs to

The belongs_to association is exactly what is says. ‘A Book belongs to an Author.’ Just because the statement is made though doesn’t mean that it’s actually true. Just because you have a Harry Potter book in your hand doesn’t mean that it belongs to J.K. Rowling does it? No, of course not. The world would be in complete anarchy if that’s how we thought of associations. J.K. Rowling has her name printed on each of the books that she wrote. That’s how everyone around the world knows that she is the author, and the book belongs to her. You deciding to pay money to read and keep a copy of it is your business — but it still belongs to her.

In our case, we are going to demonstrate our author-book association using a Foreign-key. What I mean by that is using the unique identifier for an author (it’s ID) within your database, and matching that identifier to an attribute that you have given each book. Here is an example:

Holiday season associations illustration

Inside of our app and database, we have an Author instance for Frosty Snowman. His name is Frosty Snowman, he has 1 book, and his publishing company is ‘Penguin Random House’. When we saved Frosty to our database, sqlite3 was nice enough to assign Frosty an ID of 1 and keep records of all his information.

Now when we enter Frosty’s book into our database and save it, it will also get its own Book ID so that we can identify it. However much like Frosty has attributes for the number of books he has, and his publishing company — his book has an attribute of ‘author_id’. When we give Frosty’s book his ID as it’s author_id, we are establishing the association between them. The foreign key placement is how we establish and determine our associations!!!

2. Has_many

The has_many relationship is again, self explanatory. You might be thinking, where does the foreign key go here? Well, it goes to the model that belongs_to the model that has_many. What if Frosty Snowman wrote another book about being happy? He wouldn’t need the ID of his new book. His happy book would need his ID to be its foreign key, again establishing the relationship between himself and his new book. This pattern will go on within your app and models for each book, and the author that it belongs to.

The same can be said with Genres. Each book is also going to have a genre_id attribute, that will be assigned the ID of the specific genre it belongs to.

This establishes the has_many association by giving multiple books the same author_id or genre_id as foreign keys. As programmers, this opens a world of possibilities to us. Through these associations we are able to access the information of each book that belongs to Frosty, which books belong to a specific genre and the full spectrum of information about each book.

Again, proper documentation goes into this concept much further and will be of help to use a programmer throughout your career. Give it a read to make sure you fully understand the belongs_to and has_many associations properly.

3. has_many :through

This association is a bit special. It is used by programmers to maintain a many to many relationship through a third model. This third model is often referred to as a ‘joiner model’. Let’s visualize for a moment:

has_many :through Association — Ruby on Rails, section 2.4

Here, we can see that appointments belong to both the doctor and the patient. In addition to a doctor and patient having many appointment, they also have many of each other through their appointments.

To the left, we can see the syntax for writing out the has_many :through relationships in our models.

Think about it in terms of actual real life. You are a patient, and you have a doctor. What is your relationship with that doctor? Odds are, you’re not going out to meet with your doctor frequently, you’re not meeting for lunch and I’m certain they aren’t calling you to talk about their day. No offense to you, that would just be illegal.

What relates you to that specific Doctor is your appointment! You have an appointment with your Doctor a 1pm today. He also has an appointment with you at 1pm today.

You and your doctor have a relationship through the appointment that has been set at 1pm today. BUT, you are not his only patient with an appointment today — he has many patients with many appointments. Unfortunately, you also have other appointments with other doctors today.

You have many doctors through your appointments with them and doctors have many patients with their respective appointments. The foreign keys that are given to each individual appointment, each of which correspond to a doctor or a patient, allow you to establish relationships throughout your models and therefore your app.

Other types of associations

has_one has_one :through has_and_belongs_to_many

Each of these associations is similar to the ones reviewed previously, however there are a few special instances where these associations are appropriate to use. Once again, proper documentation will give the true explanation as to how they work and the best time to deploy these associations.