diff --git a/module2/lessons/assets/images/one_to_many/1_to_many_db_image_1.png b/module2/lessons/assets/images/one_to_many/1_to_many_db_image_1.png
new file mode 100644
index 00000000..0a21c7c1
Binary files /dev/null and b/module2/lessons/assets/images/one_to_many/1_to_many_db_image_1.png differ
diff --git a/module2/lessons/assets/images/one_to_many/1_to_many_db_image_2.png b/module2/lessons/assets/images/one_to_many/1_to_many_db_image_2.png
new file mode 100644
index 00000000..ad89d811
Binary files /dev/null and b/module2/lessons/assets/images/one_to_many/1_to_many_db_image_2.png differ
diff --git a/module2/lessons/assets/images/one_to_many/1_to_many_db_image_3.png b/module2/lessons/assets/images/one_to_many/1_to_many_db_image_3.png
new file mode 100644
index 00000000..8853a1cf
Binary files /dev/null and b/module2/lessons/assets/images/one_to_many/1_to_many_db_image_3.png differ
diff --git a/module2/lessons/assets/images/one_to_many/1_to_many_db_image_4.png b/module2/lessons/assets/images/one_to_many/1_to_many_db_image_4.png
new file mode 100644
index 00000000..d8cad518
Binary files /dev/null and b/module2/lessons/assets/images/one_to_many/1_to_many_db_image_4.png differ
diff --git a/module2/lessons/assets/images/one_to_many/1_to_many_db_image_5.png b/module2/lessons/assets/images/one_to_many/1_to_many_db_image_5.png
new file mode 100644
index 00000000..943e23e6
Binary files /dev/null and b/module2/lessons/assets/images/one_to_many/1_to_many_db_image_5.png differ
diff --git a/module2/lessons/index.md b/module2/lessons/index.md
index 506d794d..76a52d32 100644
--- a/module2/lessons/index.md
+++ b/module2/lessons/index.md
@@ -5,6 +5,9 @@ title: Module 2 - Lessons
## Introduction To Rails
* [Beginner Rails Workshop](./beginner_rails_workshop)
+* [One to Many Relationships in the Database](./one_to_many_relationships_part1)
+* [One to Many Relationships in Rails](./one_to_many_relationships_part2)
+
* [Introduction to MVC](./intro_to_mvc)
## Professional Development
diff --git a/module2/lessons/one_to_many_relationships_part1.md b/module2/lessons/one_to_many_relationships_part1.md
new file mode 100644
index 00000000..3ea7f923
--- /dev/null
+++ b/module2/lessons/one_to_many_relationships_part1.md
@@ -0,0 +1,92 @@
+---
+layout: page
+length: 60 minutes
+title: One to Many Relationships
+---
+
+There are many ways that objects can relate to each other. There can be a *one to one* relationship as in a person and their social security number, or a *one to many* relationship as in an author and their books, or even a *many to many* relationship is in instructors and their students. In this lesson, we will be focusing on the **one to many** relationship and how that relationship is set up in a normalized database.
+
+## Learning Goals
+* Define Primary Key and Foreign Key
+* Visualize One to Many relationships
+* Define ORM
+
+## Vocab
+* One to Many
+* Normalization
+* Primary Key
+* Foreign Key
+* ORM
+
+## Warmup
+
+* During this week, we will start using an application called Set List in class, which will have a songs database table. The table will store songs' title, length and seconds, and its play count. If we wanted to store and relate songs to an artist (for example, the artist Prince has two songs in our app: 'Purple Rain' and 'Raspberry Beret') how might you try to incorporate that data into the Set List database? Sketch out an example.
+
+## What is a database?
+
+Before we jump into how we might relate a song to a specific artist, let's take a step back to review what a database *is*. At the highest level, a database is a location where we can store information and allow that information to persist in our application. Right now, in our app, we have a database that is storing song information. More specifically, we have a `database` that has a songs `table` and that table has columns that store each song's `attributes`; we could visualize this configuration like this:
+
+
+ 
+
+
+In our database, we have a table that looks similar to an excel sheet where each row of this table is one song entry or record in our database. So far, this is a fairly simple database, holding on to only a few attributes. Without much difficulty, we could update our database to hold additional song attributes by adding additional columns to our songs table.
+
+But, what if we want to keep track of the artist that wrote each song? We *could* add a column to our database called `artist` and store the artist directly on a song, like this:
+
+
+ 
+
+
+Seems like it works, right? Well... not exactly. What if we wanted to also store information about specific artists, like their hometown or years active. If we imagine what that might look like, we would see more columns on our `songs` table and many of those columns would be storing the exact same information - every Prince song would be storing 'Minneapolis' and '1975-2016':
+
+
+ 
+
+
+This is very repetitive!
+
+Let's explore a better way to store this information using **database normalization**.
+
+## Normalizing our Database
+
+In order to cut down on redundant data on a specific table in our database, we can rely on **normalization**. Normalization is a process by which we break down tables in our database so that each table relates only to one resource. In the example we are working with, when we look at our songs table, we are storing information about songs and about artists. Really, we are trying to store information about two resources on one table - let's fix that.
+
+In a normalized database, we can break this one table into two: songs and artists. Then we can separate the attributes of each resource to their appropriate table:
+
+
+ 
+
+
+Great! Now, our database has tables that relate to only one resource each, and we have eliminated redundant data. But, we have lost something - we no longer know which artist wrote each song.
+
+When we normalize our database, we need to include some sort of marker for ourselves to know how to relate the tables to one another. We do this with **primary keys** and **foreign keys**. As our database exists now, every record has an `id`. We can use these ids to relate information in one table, to information in the other (or give each of our songs an artist). For each song in our database, we will add an attribute `artist_id` that will hold the `id` of the artist that song belongs to.
+
+
+ 
+
+
+This `artist_id` is the **foreign key** on our songs table that relates a song back to the `id` of an artist on the artists table - also referred to as the **primary key** of the artists table.
+
+As we build out our databases, we will want them to be as normalized as possible - only storing information from a single resource per table.
+
+## Describing these Relationships
+
+There are a lot of words we could use to describe this relationship between songs and artists, but to stay consistent and follow rails conventions, we will describe this as a **One to Many Relationship**, where a **song belongs to an artist** and an **artist has many songs**. Every database relationship has two sides and it is important to describe both sides of the relationship.
+
+It may seem like a small thing, but having consistency with how we describe these relationships will help us as we build our rails apps, and as we describe our database design to other developers.
+
+Whenever we have a **one to many** relationship, Resource A will always **belong to** Resource B, with the use of a **foreign key**; and, Resource B **has many** Resource A.
+
+
+## Using Resource Records in our Applications
+
+While databases are great at storing information, they are not so great at giving our applications information that is easily manipulated or passed around - Because the database is storing raw data, not Objects as we are used to seeing in Ruby. What we would like, is to be able to work with each record in our database as if it were a smart ruby object - that way we could give each record additional behaviors through ruby methods. This is where an **ORM** comes in.
+
+**ORMs** or **Object Relational Mappers** are a tool that sits between our application and our database and turns each record in our database into an object. There are many **ORMs** for many different web frameworks. The most common **ORM** for Ruby is [ActiveRecord](https://guides.rubyonrails.org/active_record_basics.html), and that is the one that we will be using. In fact, ActiveRecord is so standard that it is included in the base configuration of Rails.
+
+## Checks for Understanding
+
+1. What is database normalization?
+1. Define primary and foreign keys.
+1. How would you describe the one to many relationship between an author and their books?
diff --git a/module2/lessons/one_to_many_relationships_part2.md b/module2/lessons/one_to_many_relationships_part2.md
new file mode 100644
index 00000000..fc39d344
--- /dev/null
+++ b/module2/lessons/one_to_many_relationships_part2.md
@@ -0,0 +1,458 @@
+---
+layout: page
+title: ActiveRecord Associations with TDD
+tags: migrations, databases, relationships, rails, activerecord
+---
+
+## Learning Goals
+
+- Write migrations in Rails.
+- Define Schema.
+- Explain what a migration is, and how it relates to our schema.
+- Create one-to-many relationships at the database level using foreign keys.
+- Use `has_many` and `belongs_to` to create one-to-many relationship at the model level.
+
+## Vocabulary
+
+- Migration
+- Schema
+- Relationships
+
+## Warm Up
+
+- In your own words, what is a migration?
+- What are some things that we can do with a migration?
+- What is the relationship between a migration and our database?
+
+## Setup
+
+This lesson plan starts at the `associations-practice` branch of [this SetList repo](https://github.com/turingschool-examples/set-list-7/). In order to set up the app for this lesson:
+
+- Clone the repo
+- Checkout the `associations-practice` branch
+- Run `bundle install`
+- Run `rails db:{drop,create,migrate,seed}`
+
+## Models, Migrations, and Databases in Rails
+
+In this lesson, we'll be adding to our new SetList Rails app to demonstrate a one-to-many relationship.
+
+We'll add a table `artists` to our database, and connect them to our existing `songs` table. What might the relationships look like?
+
+## One-to-Many Relationships
+
+### At the Database Level: Artist
+
+We want to create some artists with a name. Let's add a test for that! Since this will be a model test, we need to first make a `/models` directory nested under `/spec` then create an `artist_spec.rb` file:
+
+```bash
+$ mkdir spec/models
+$ touch spec/models/artist_spec.rb
+```
+
+We're going to use the handy dandy gem [shoulda-matchers](https://github.com/thoughtbot/shoulda-matchers) to give us some streamlined syntax to use in testing our validations and relationships.
+
+- Add `gem "shoulda-matchers"` to `group :development, :test` in your `Gemfile`
+- run `bundle install`
+- Put the following at the bottom of `rails_helper.rb`:
+
+```ruby
+Shoulda::Matchers.configure do |config|
+ config.integrate do |with|
+ with.test_framework :rspec
+ with.library :rails
+ end
+end
+```
+
+**spec/models/artist_spec.rb**
+
+```ruby
+require 'rails_helper'
+
+describe Artist, type: :model do
+ describe "validations" do
+ it { should validate_presence_of :name }
+ end
+end
+```
+
+Run `bundle exec rspec` and we should get an error similar to this:
+
+```bash
+Failure/Error:
+ describe Artist, type: :model do
+ describe "validations" do
+ it { should validate_presence_of :name }
+ end
+ end
+
+NameError:
+ uninitialized constant Artist
+```
+
+There are a few things that have to happen to get this test passing.
+
+First, let's clear this error by creating our `Artist` model:
+
+```bash
+$ touch app/models/artist.rb
+```
+
+**app/models/artist.rb**
+
+```ruby
+class Artist < ApplicationRecord
+
+end
+```
+
+Now, let's run our test again. We should see an error like this:
+
+```bash
+ActiveRecord::StatementInvalid:
+ PG::UndefinedTable: ERROR: relation "artists" does not exist
+ LINE 9: WHERE a.attrelid = '"artists"'::regclass
+ ^
+ # ./spec/models/artist_spec.rb:5:in `block (3 levels) in '
+ # ------------------
+ # --- Caused by: ---
+ # PG::UndefinedTable:
+ # ERROR: relation "artists" does not exist
+ # LINE 9: WHERE a.attrelid = '"artists"'::regclass
+ # ^
+ # ./spec/models/artist_spec.rb:5:in `block (3 levels) in
+```
+
+This error is telling us that we don't have an `artists` table set up in our database, so let's create that with a migration:
+
+```bash
+$ rails g migration CreateArtists name:string
+```
+
+The migration generator creates a migration for us. If we follow the working convention for Rails (e.g. the `name:string`), the migration will be pre-populated.
+
+Let's look at the migration inside of `db/migrate`. It should look like this:
+
+```ruby
+class CreateArtists < ActiveRecord::Migration[7.0]
+ def change
+ create_table :artists do |t|
+ t.string :name
+
+ t.timestamps
+ end
+ end
+end
+```
+
+Will this fix our tests?
+
+Take a look at our `db/schema.rb`; at this point, it should look something like this:
+
+**db/schema.rb**
+
+```ruby
+ActiveRecord::Schema[7.0].define(version: 2023_02_22_180629) do
+ # These are extensions that must be enabled in order to support this database
+ enable_extension "plpgsql"
+
+ create_table "songs", force: :cascade do |t|
+ t.string "title"
+ t.integer "length"
+ t.integer "play_count"
+ t.datetime "created_at", null: false
+ t.datetime "updated_at", null: false
+ end
+
+end
+```
+
+There are two things to focus on here. First, we only see a `create_table 'songs'` command, which means that our database only has a `songs` table. Second, take a look at the `version: 2023_02_22_180629` - this version number *should* match the version of our latest migration file, but it doesn't! That means that we have migrations that have not been run yet. Let's do that now:
+
+```bash
+$ rails db:migrate
+```
+
+Now, if we go back to our schema, we should see a command to `create_table 'artists'`, and when we run our tests again, we should be getting a new error!
+
+Let's run RSpec again.
+
+```bash
+Failures:
+
+ 1) Artist validations is expected to validate that :name cannot be empty/falsy
+ Failure/Error: it { should validate_presence_of :name }
+
+ Expected Artist to validate that :name cannot be empty/falsy, but this
+ could not be proved.
+ After setting :name to ‹""›, the matcher expected the Artist to be
+ invalid, but it was valid instead.
+ # ./spec/models/artist_spec.rb:5:in `block (3 levels) in '
+```
+
+The important part to read here is `Expected Artist to validate that :name cannot be empty/falsy`
+
+Let’s add a validation to Artist!
+
+**app/models/artist.rb**
+
+```ruby
+class Artist < ApplicationRecord
+ validates_presence_of :name
+end
+```
+
+Run RSpec again and we get passing tests.
+
+### What about Songs?
+
+What's the relationship between song and artist? Draw this out in a diagram to help visualize the relationship.
+
+Let's create a test to help us drive this out. Add the following to your `artist_spec.rb` within the greater describe Artist block, but outside of the validations block.
+
+**spec/models/artist_spec.rb**
+
+```ruby
+require 'rails_helper'
+
+describe Artist, type: :model do
+ describe "validations" do
+ it { should validate_presence_of :name }
+ end
+
+ describe 'relationships' do
+ it { should have_many :songs }
+ end
+end
+```
+
+When we run this test we get an error something like this:
+
+```bash
+1) Artist relationships is expected to have many songs
+ Failure/Error: it { should have_many :songs }
+ Expected Artist to have a has_many association called songs (no association called songs)
+ # ./spec/models/artist_spec.rb:9:in `block (3 levels) in '
+```
+
+The important part here is `Expected Artist to have a has_many association called songs (no association called songs)`. This tells us that we are missing a relationship. We need to make one.
+
+```bash
+$ rails g migration AddArtistsToSongs artist:references
+```
+
+(It helps me to remember that the thing that gets put in the migration is the thing that is the one in the one to many relationship, in this case, the `Artist` has many `Songs`.)
+
+Take a look at what this migration creates.
+
+```ruby
+class AddArtistsToSongs < ActiveRecord::Migration[7.0]
+ def change
+ add_reference :songs, :artist, null: false, foreign_key: true
+ end
+end
+```
+
+Run `rails db:migrate` to run this migration. Now open `schema.rb` and make sure that your `songs` table now has the `artist_id` foreign key.
+
+Run the tests again and you'll see that we're still getting `Expected Artist to have a has_many association called songs (no association called songs)`. We've added the foreign key at the database level, but our we still haven't set up our model to make use of that foreign key.
+
+## Associations
+
+### One-to-Many Relationships at the Model Level: Song/Artist
+
+We have set up our database level relationships, now let's implement some model-level associations using some handy ActiveRecord methods.
+
+- `has_many`
+- `belongs_to`
+
+**app/models/song.rb**
+
+```ruby
+class Song < ApplicationRecord
+ belongs_to :artist
+
+end
+```
+
+**app/models/artist.rb**
+
+```ruby
+class Artist < ApplicationRecord
+ has_many :songs
+
+ validates_presence_of :name
+end
+```
+
+Run the tests again and now they should be passing!
+
+Why do we need a foreign key at the database level and the `belongs_to` method in the model? What do each of these things allow for?
+
+Let's play around in our development database by dropping in to the rails console `rails console` or `rails c`
+
+*In the console*:
+
+- Create a artist `Artist.create!(name: 'Prince')`
+- Create a song `Song.create!(title: 'Raspberry Beret', length: 345, play_count: 34)`
+
+Did you get an error?
+
+- Why are we getting this error?
+- What do we need to do to fix this error?
+
+Now that a `song` **belongs to** an `artist`, a `song` can not exist without an `artist`
+
+- What are different ways to associate songs with artists?
+
+```ruby
+artist = Artist.create(name: 'Prince')
+song = Song.create(title: 'Raspberry Beret', length: 345, play_count: 34, artist: artist)
+
+# OR
+
+artist = Artist.create(name: 'Prince')
+song = Song.create(title: 'Raspberry Beret', length: 345, play_count: 34, artist_id: artist.id)
+# OR
+
+artist = Artist.create(name: 'Prince')
+song = artist.songs.create(title: 'Raspberry Beret', length: 345, play_count: 34)
+```
+
+Since we've added code into our Song model, it would also be a good idea to write a test for this association.
+
+### Model Testing
+We've talked about Feature Testing already, this is a form of integration test since a single feature relies on many pieces of the application. A Model test will be more of a unit test, where we're testing a specific Model by itself to ensure it works as intended.
+
+The good news: Model testing in Rails looks almost **exactly** like testing from Mod 1!
+
+In your `spec` directory, add a `models` directory. Then create a `song_spec.rb` (if you don't already have one). We typically have one spec file for each model. Add a test for the relationship from Songs to Artists:
+(here you will see the shoulda-matchers gem syntax come in to give us these one-line tests.)
+
+**spec/models/song_spec.rb**
+
+```ruby
+require 'rails_helper'
+
+RSpec.describe Song do
+
+ describe 'relationships' do
+ it {should belong_to :artist}
+ end
+end
+```
+
+Run this test and you should see it passing!
+
+## Seeds
+
+Now that our App is getting more complex, it would be good to add some seeds. Seeding your database is when you insert a set of data into the database. It is useful to have some seed data when we are experimenting and developing. You could consider what we've done in the Rails Console so far as a type of seeding, but doing things manually in the Rails Console can get very tedious, so what we will do instead is write a script to seed our database that we can reuse. Rails comes with a file for us to write this script in `db/seeds.rb`. Open up that file and add the following:
+
+**db/seeds.rb**
+
+```ruby
+Song.destroy_all
+Artist.destroy_all
+
+prince = Artist.create!(name: 'Prince')
+rtj = Artist.create!(name: 'Run The Jewels')
+caamp = Artist.create!(name: 'Caamp')
+jgb = Artist.create!(name: 'Jerry Garcia Band')
+billie = Artist.create!(name: 'Billie Eilish')
+lcd = Artist.create!(name: 'LCD Soundsystem')
+
+prince.songs.create!(title: 'Raspberry Beret', length: 345, play_count: 34)
+prince.songs.create!(title: 'Purple Rain', length: 524, play_count: 19)
+
+rtj.songs.create!(title: 'Legend Has It', length: 2301, play_count: 2300000)
+rtj.songs.create!(title: 'Talk to Me', length: 2301, play_count: 2300000)
+
+caamp.songs.create!(title: '26', length: 940, play_count: 150000)
+caamp.songs.create!(title: 'Vagabond', length: 240, play_count: 120000)
+
+jgb.songs.create!(title: 'Aint No Bread In The Breadbox', length: 540, play_count: 12000)
+jgb.songs.create!(title: 'The Harder They Come', length: 240, play_count: 120000)
+
+billie.songs.create!(title: 'bury a friend', length: 340, play_count: 1200000)
+billie.songs.create!(title: 'bad guy', length: 240, play_count: 100000)
+
+lcd.songs.create!(title: 'Someone Great', length: 500, play_count: 1000000)
+lcd.songs.create!(title: 'I Can Change', length: 640, play_count: 100000)
+```
+
+Now that we have our seeds file, we can run it with `rails db:seed`. Additionally, if we check this file into our version control system, other developers working on this app will be able to easily seed their local databases.
+
+Notice that the first two lines of this seeds file will destroy all Songs and Artists from the database. The reason we want to do this is so that we know we are starting with an empty database every time we want to reseed our database. If we did not have these two lines, this script would create duplicate records every time we reran `rails db:seed`.
+
+## Adding Behaviors to Models
+
+Now, we have two models that are related to each other with **has_many** and **belongs_to**, and these models can handle basic CRUD functionality through the methods that they inherit from ActiveRecord - but what if we need our models to be customized to perform behaviors related to our application? For example, what if we want our `Song` model to be able to tell us how many songs exist in our database, and we want an `artist` to be able to tell us the average length of all their songs.
+
+First - Test!
+
+**spec/models/song_spec.rb**
+
+```ruby
+require 'rails_helper'
+
+RSpec.describe Song do
+ describe 'relationships' do
+ it {should belong_to :artist}
+ end
+
+ describe 'class methods' do
+ it '.song_count' do
+ prince = Artist.create!(name: 'Prince')
+ talking_heads = Artist.create!(name: 'Talking Heads')
+ rasperry_beret = prince.songs.create!(title: 'Raspberry Beret', length: 234, play_count: 34)
+ wild_life = talking_heads.songs.create!(title: 'Wild Wild Life', length: 456, play_count: 45)
+
+ expect(Song.song_count).to eq(2)
+ end
+ end
+end
+```
+
+Use TDD to create a class method on our `Song` model that returns a count of the songs in our database. As you build out this method, remember to use `pry` and `self` to help debug and guide your implementations!
+
+And for our next method - a test!
+
+**spec/models/artist_spec.rb**
+
+```ruby
+require 'rails_helper'
+
+RSpec.describe Artist do
+ describe 'validations' do
+ it {should validate_presence_of :name}
+ end
+
+ describe 'relationships' do
+ it {should have_many :songs}
+ end
+
+ describe 'instance methods' do
+ it '.average_song_length' do
+ talking_heads = Artist.create!(name: 'Talking Heads')
+ she_was = talking_heads.songs.create!(title: 'And She Was', length: 234, play_count: 34)
+ wild_life = talking_heads.songs.create!(title: 'Wild Wild Life', length: 456, play_count: 45)
+
+ expect(talking_heads.average_song_length).to eq(345)
+ end
+ end
+end
+```
+
+Use TDD to create an instance method on our `Artist` model that returns the average of a single artist's songs. As you build out this method, remember to use `pry` and `self` to help debug and guide your implementations!
+
+## Wrap Up
+
+- What are two different types of table relationships that you might need to implement? In what scenario would you use each?
+- What is the syntax for the following migrations in Rails?
+ - Create a table
+ - Add a column to a table, with or without a data type
+ - Add a reference from one table to another
+
+
+Completed code from this lesson plan can be found on this branch [here](https://github.com/turingschool-examples/set-list-7/tree/associations-practice-solutions\).