Railsでのデータベース設計と操作を学ぼう

はじめに

リンクをコピーしました

概要

リンクをコピーしました

この章では、Railsを使用したデータベース操作の基本について学びます。初めに、MVCアーキテクチャを振り返り、その中でモデルの基本概念を理解します。続いて、ActiveRecordの概要とそれがモデルとどのように連携するかを学びます。

その後、データベース接続の設定、データベースの作成と削除方法、モデルとテーブルの命名規約について詳しく学びます。また、モデルの作成方法やマイグレーションの基本についても解説します。この章を通じて、Railsでのモデルとデータベース操作に関する基本的な概念とテクニックを習得しましょう。

目標

リンクをコピーしました

• データベースの基本的な概念を理解し、作成と削除を実行できる
• ActiveRecordの規約に従って、正確なモデルとテーブルを設計できる
• マイグレーションの基本的な仕組みを理解し、ファイルを作成・実行できる
• データベースのスキーマを確認し、マイグレーションの状況を管理できる

必要な前提条件・事前準備

リンクをコピーしました

この章を始める前に、リレーショナルデータベースに関する基本用語と概念、SQLでの基本的なデータベース操作についての理解が必要です。また、SQLを学習した前章で作成したテーブルの削除が完了していることを確認してください。

• リレーショナルデータベースの基本用語と概念に関する理解
• SQLでの基本的なデータベース操作
• ⚠️ SQLの章で作成したテーブルの削除が完了していること！！
• 適切なタイムゾーンが設定されていること（次で説明します。）

以下の手順に従って、適切なタイムゾーンの設定を行いましょう。

タイムゾーンの設定

リンクをコピーしました

タイムゾーン（Time Zone）とは、世界中の異なる場所で時間を調整するための仕組みです。地球が24時間で回るため、各地域で時間を統一的に扱うために、地球をいくつかの区分に分けています。

多くの場合、サーバーには世界の時刻の標準であるUTC（協定世界時）が設定されます。グローバルなアプリケーションを開発・運用する場合であれば、タイムゾーンはUTCで統一させますが、日本国内では、UTCに9時間を足したJST（日本標準時）が用いられます。

今回は、RailsのタイムゾーンとOSのタイムゾーンを「UTC」から「JST」に変更します。

Railsのタイムゾーンを設定しよう

リンクをコピーしました

Railsのタイムゾーンの設定は、config/application.rbで行います。

config.time_zoneでは、アプリケーションやActive Recordで使用するデフォルトのタイムゾーンを設定することができます。以下のようにapplication.rbの19行目のコメントを外し、タイムゾーンを東京に設定しましょう。

1
config.time_zone = "Tokyo"

application.rbの20行目に以下の1行を追加して、タイムゾーンを設定しましょう。

1
config.active_record.default_timezone = :local

OSのタイムゾーンを設定しよう

リンクをコピーしました

以下のコマンドを実行して、Cloud9の環境に設定されるタイムゾーンがUTCであることを確認しましょう。

1
date

以下のコマンドを上から順番に実行して、タイムゾーンをJSTに変更しましょう。

※ コマンドは、タイプミスを減らすためにコピー&ペーストしてください。現時点でsedやlnコマンドを理解する必要はありません。

1
sudo sed -i -e "/^ZONE=/c\ZONE=Asia/Tokyo" /etc/sysconfig/clock

1
sudo ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime

1
sudo reboot

最後のsudo rebootを実行すると、以下のようにCloud9が再起動されます。

再起動後、以下のようにdateを実行して、Cloud9の環境に設定されるタイムゾーンがUTCではなく、JSTに変更されていることを確認しましょう。

1.Railsでのデータベース操作の理解

リンクをコピーしました

1-1.MVCアーキテクチャでの処理の流れ

リンクをコピーしました

Pikawakaカリキュラムでは、Webアプリケーションのデータ保存先としてリレーショナルデータベースを利用します。前回は、SQLを使ってリレーショナルデータベースを操作する方法を学びました。

今回は、Ruby on Railsを使用してリレーショナルデータベースを操作する方法を学びます。

Railsでは、以前に学んだ通り、MVCアーキテクチャが採用されています。このアーキテクチャでは、アプリケーションが「Model（モデル）」「View（ビュー）」「Controller（コントローラー）」という3つの主要な要素に分けられ、それぞれが特定の役割を担うように設計されています。特に、モデルはデータベースとのやり取りを担当します。

これまでの学習では、モデルを除くルーティング、コントローラ、ビューを使ってページを表示する方法について学んできました。

モデルを組み合わせた処理の全体的な流れは、以下の通りです。

それでは、次にモデルの役割と機能について詳しく学びましょう。モデルはアプリケーションのデータとそのロジックを管理し、データベースとの間の橋渡しをします。これを理解することは、Railsで効率的にアプリケーションを開発するために不可欠です。

1-2.モデルの基本概念

リンクをコピーしました

Ruby on Railsのモデルは、アプリケーションのデータベースとのやり取りを担当し、ユーザーからの情報（例えば、ウェブサイト上で入力されたデータ）をデータベースに保存したり、必要に応じてデータベースから情報を取り出したりします。

このプロセスは、コントローラからの指示に従って行われます。モデルが処理したデータはコントローラに提供され、その後コントローラはこの情報をビューに渡して、ユーザーに表示される出力を生成します。

Railsのモデルはapp/models/ディレクトリに配置されます。初期状態では、このディレクトリにはモデルのファイルが存在しません。新しいモデルを作成する際には、必要に応じてこのディレクトリに新しいファイルを追加してモデルを定義します。

モデルのファイル内では、特定のクラスを定義します。
このクラスには、ApplicationRecordというクラスを継承する必要があります。

1
2
class クラス名 < ApplicationRecord
end

ApplicationRecordクラスを継承することで、モデルはデータベースとのやり取りに必要な一連の機能にアクセスできるようになります。これは、ApplicationRecordがデータベース操作を簡素化するActiveRecord::Baseクラスを継承しているためです。

この継承により、モデルのクラスは「Active Record」というライブラリの機能を利用でき、データベース操作をより効率的かつ直感的に行えるようになります。

1-3.ActiveRecordの概要

リンクをコピーしました

Ruby on Railsのモデルは通常、ApplicationRecordクラスを継承し、ActiveRecordという強力なRubyのgemを利用して、データベースとのやり取りを行います。

ActiveRecordは、オブジェクトリレーショナルマッピング（Object-Relational Mapping、略称ORM）の機能を提供します。これにより、RailsのモデルはリレーショナルデータベースのレコードをRubyのオブジェクトとして扱うことができます。

例えば、新しいユーザーをデータベースに追加する際、従来のSQL操作ではINSERT構文を使用してテーブルにレコードを挿入します。

1
INSERT INTO users(name, age) VALUES('山田花子', 34);

しかし、ActiveRecordを使えば、Railsのモデルを介して同じ操作をRubyのコードで簡単に実行できます。オブジェクトを操作する感覚でデータを扱うことが可能になります。

1
2
user = User.new(name: "山田花子", age: 34)
user.save

ActiveRecordを使用すると、Railsのモデルを通じてデータベースのレコードをより簡単に管理でき、Railsアプリケーションの開発がより迅速かつ効率的になります。これにより、開発者は複雑なSQLクエリを直接書くことなく、Railsのモデルを使ってデータベースのレコードを作成、読み取り、更新、削除することができます。

オブジェクトリレーショナルマッピング（ORM）の役割

リンクをコピーしました

オブジェクトリレーショナルマッピング（ORM）は、オブジェクト指向プログラミング言語とリレーショナルデータベース間のギャップを埋める重要な役割を果たします。

オブジェクト指向プログラミングとリレーショナルデータベースは、データの構造が根本的に異なります。オブジェクト指向では、データと関連する振る舞い（メソッド）がクラスやオブジェクト（インスタンス）にカプセル化されています。対照的に、リレーショナルデータベースはテーブル、レコード、カラムを用いてデータを管理します。

この構造的な違いを効率的に解決するため、オブジェクトリレーショナルマッピング（ORM）が広く使用されています。ORMは、リレーショナルデータベースのテーブルやレコードをオブジェクト指向プログラミング内のクラスやインスタンスにマッピング（対応付け）します。

これにより、プログラム内でのオブジェクト操作はデータベースの操作と直接結びつき、より直感的かつ効率的なデータベース管理が可能になります。

ORMの使用により、データベースのCRUD（作成、読み出し、更新、削除）操作をプログラミング言語のコードを通じて簡単に実行できるようになり、SQLクエリを直接書く手間が省けます。また、ORMはデータベースの整合性を維持する機能を提供し、アプリケーション全体の品質が向上します。

2.データベース接続と管理の基本

リンクをコピーしました

2-1.データベース接続の設定

リンクをコピーしました

Ruby on RailsでActiveRecordを使用してリレーショナルデータベースに接続する際には、configディレクトリ内のdatabase.ymlファイルでデータベースの接続情報を設定する必要があります。

database.ymlファイルでは、開発、テスト、本番環境ごとに異なるデータベース設定を定義することができます。ActiveRecordは、このファイルに記述された設定に基づいてデータベースへの接続を管理します。

rails newコマンドを使用してRailsアプリケーションを作成する際、database.ymlファイルは自動的に生成されます。

database.ymlファイルの詳細については、既に「データベースの準備」のセクションで学習しています。より深い理解を求める場合は、そのセクションを参照してください。

2-2.データベースの作成と削除

リンクをコピーしました

これまで、phpMyAdminの画面で操作したり、SQLを実行してデータベースを作成や削除してきました。しかし、Railsではrailsコマンドを使ってこれらの操作が可能です。

1
rails db:create

1
rails db:drop

これらのコマンドは、database.ymlの設定に基づいてデータベースを作成または削除します。

データベースを削除しよう

リンクをコピーしました

アプリケーション作成準備の章では、rails db:createコマンドを実行して、以下のように「開発環境」と「テスト環境」のデータベースを作成しましたね。

phpMyAdminでも、以下のように２つのデータベースを確認することができます。

以下のコマンドを順番に実行して、作成済みの「開発環境」と「テスト環境」のデータベースを削除しましょう。

1
cd ~/environment/employee_management

1
pwd

1
rails db:drop

rails db:dropを実行すると、以下のように２つのデータベースが削除されます。

まず、以下のコマンドを順番に実行してサーバを起動しましょう。

1
cd ~/environment/employee_management/public/phpMyAdmin-5.1.1-all-languages

1
php -S 127.0.0.1:8081

次にphpMyAdminにログインしてみましょう。
そこで、以下のように２つのデータベースが削除されていることを確認できます。

データベースを作成しよう

リンクをコピーしました

rails db:createを実行すると、database.ymlの設定に従って「開発環境」と「テスト環境」のデータベースが作成されます。

以下のコマンドを順番に実行して、開発環境とテスト環境のデータベースを作成しましょう。

1
cd ~/environment/employee_management

1
pwd

1
rails db:create

rails db:createを実行すると、以下のように２つのデータベースが作成されます。

railsコマンドで作成された２つのデータベースは、database.ymlに設定されている開発環境とテスト環境のデータベースです。database.ymlで設定されたデータベース名とrailsコマンドで作成されるデータベース名は、以下のように一致しています。

phpMyAdminにアクセスし、下の画像に示されているように、２つのデータベースが作成されていることを確認できます。

このようにrailsコマンドを使用すると、ターミナル上で簡単にデータベースの作成や削除の操作を行うことができます。

3. モデルとテーブルの命名規約

リンクをコピーしました

Railsでは、モデルを通じてデータベースとのやり取りが行われます。これらのモデルは、特定のクラスを継承することでActiveRecordの機能を活用し、データベースとの効率的なコミュニケーションを可能にすることを学びましたね。

ActiveRecordは「規約による設定」（Convention Over Configuration）の原則に基づいており、特定の命名規則に従うことで、モデルとデータベースのテーブル間の自動的な関連付けが行われます。

この命名規則を適切に理解し適用することにより、Railsアプリケーションのデータベース構造を効率的かつ直感的に設計・管理することができます。次に、カラム名の規約やモデルのクラス名とテーブル名の関係について詳しく学んでいきましょう。

3-1.カラム名の規約

リンクをコピーしました

ActiveRecordでは、特定の目的のために予め定められたカラム名が使用されます。これらのカラムはRailsの内部で重要な役割を果たし、データベース操作を効率的かつ自動的に行うことが可能になります。

以下の表に、予約済みのカラム名とその利用目的を示します。

例えば、idは各レコードを一意に識別する主キーとして、テーブル名の単数形_idは外部キーとして機能します。

以前、phpMyAdminとSQLの章で作成したemployeesとdepartmentsテーブルの「主キー」と「外部キー」も、このActiveRecordの規約に従っています。

created_atとupdated_atカラムは、それぞれレコードの作成日時と更新日時を自動的に記録するために使用されます。これらのカラムにより、レコードの追加や最終更新時刻を簡単に追跡でき、データの整合性を維持するのに役立ちます。

3-2.モデルのクラス名とテーブル名

リンクをコピーしました

ActiveRecordでは、いくつかの規約に従うことで「モデルのクラス」と「データベースのテーブル」を自動的に関連付けられます。

テーブル名は、モデルのクラス名を複数形・語頭を小文字にした名前になります。

例えばUserという名前のモデルのクラスがある場合、自動的に紐付けられるテーブルは複数形のusersになります。

4.モデル操作の基本

リンクをコピーしました

4-1.モデルの作成方法

リンクをコピーしました

モデルのクラスとは、ApplicationRecordを継承したクラスのことです。

モデルのクラス名は、先ほどの命名ルールで学習したように「先頭大文字の単数形」に指定することで、クラス名を複数形にしたテーブル名に対応付けられます。

1
2
class モデルのクラス名 < ApplicationRecord
end

例えば、次のようにモデルのクラス名をDepartmentに指定すると、departmentsという名前のテーブルに対応付けることができます。

1
2
class Department < ApplicationRecord
end

モデルのクラスは「ApplicationRecordクラスを継承したクラス」のことで、テーブルを操作するモデル本体になります。そのためRailsでは、モデルのクラスのことを「モデル」と指す場合が多いです。

4-2.モデル作成・削除のコマンド

リンクをコピーしました

モデルを作成するときはrails generateコマンドを使えば、適切な命名規則や継承のルールを持つモデルファイルや関連するファイルが自動的に生成されます。

モデルを作成する際には、Railsアプリケーションのルートディレクトリで以下のようにコマンドを実行します。モデル名には、モデルのクラス名を指定します。

1
2
rails generate model モデル名
# または「rails g model モデル名」としても同様に作成できます

上記のコマンドを実行すると、複数のファイルが自動で生成されます。
※ 以下の例でのファイル名は、コマンドのモデル名をDepartmentに指定した場合です。

この章では、マーキングされた２つのファイルに焦点を当てて学習します。１つ目はモデルクラスのファイルで、２つ目はテーブル作成のためのファイルです。

モデル名を間違えた場合は、rails destroyコマンドで取り消すことができます。

1
2
rails destroy model モデル名
# または「rails d model モデル名」としても同様に削除できます

上記のコマンドを実行すると、rails generateコマンドで自動生成されたファイルが全て取り消されます。

4-3.実際にモデルを作成する手順

リンクをコピーしました

それでは、rails generateコマンドを使用してDepartmentモデルとEmployeeモデルを作成しましょう。このコマンドは、アプリケーションのディレクトリで実行する必要があります。

まず、カレントディレクトリをアプリケーションのディレクトリに変更しましょう。以下のコマンドを実行して、カレントディレクトリをemployee_managementディレクトリに変更します。

1
cd ~/environment/employee_management

1
pwd

実行すると、以下のように~/environment/employee_managementと表示されます。

次に、rails generateコマンドを使用して、Departmentモデルを生成します。以下のコマンドをemployee_managementディレクトリで実行してください。

1
rails g model department

実行すると、Departmentモデルのクラスファイルおよびdepartmentsテーブルを作成するためのファイルが自動生成されます。生成されるファイルは以下の通りです。

※ db/migrateディレクトリに生成されるファイル名の先頭にある数字は、一致する必要はありません。

• app/models/department.rb：Departmentモデルのクラスファイル
• db/migrate/YYYYMMDDHHMMSS_create_departments.rb：departmentsテーブルを作成するマイグレーションファイル

ファイルの位置関係は以下の画像に示されています。

department.rbを開くと、ApplicationRecordクラスを継承するDepartmentクラスが以下のように定義されています。

モデルのクラスは「ApplicationRecordクラスを継承したクラス」として定義され、これらを「モデル」と呼びます。したがって、Departmentモデルはdepartment.rbに定義されるDepartmentクラスを指します。

次に、同様の手順でEmployeeモデルを生成します。

1
rails g model employee

実行すると、Employeeモデルのクラスファイルおよびemployeesテーブルを作成するためのファイルが自動生成されます。これらのファイルは以下の通りです。

※ db/migrateディレクトリに生成されるファイル名の先頭の数字は、一致している必要はありません。

• app/models/employee.rb：Employeeモデルのクラスファイル
• db/migrate/YYYYMMDDHHMMSS_create_employees.rb：employeesテーブルを作成するマイグレーションファイル

ファイルの位置関係は以下の画像に示されています。

employee.rbを開くと、ApplicationRecordクラスを継承するEmployeeクラスが以下のように定義されています。こちらのクラスがEmployeeモデルを指します。

rails generateコマンドは、モデルに関連するファイルが自動的に生成するだけで、テーブルは作成されません。

phpMyAdminにログインし、employee_management_developmentデータベースにテーブルがまだ作成されていないかを確認してみましょう。

以下の画像に示されているように、テーブルはまだ作成されていません。

Railsでデータベースにテーブルを作成するには、次に学習する「マイグレーション」を利用します。

5.マイグレーションの基礎

リンクをコピーしました

ActiveRecordには、マイグレーション（migration）という機能があります。マイグレーションとは、データベースの構造を作成、変更、または削除できる仕組みです。

マイグレーションの主なメリットは、以下の通りです。

• データベース構造（テーブルの作成や変更など）をRubyで記述できる。
• バージョン管理ができる。（変更履歴を記録し、必要に応じて以前の状態に戻せる）

SQLでテーブルの作成や変更をする場合、CREATE TABLEやALTER TABLEといったデータ定義言語を使用します。しかし、RailsではActiveRecordを介して、これらの処理をRubyで行うためのメソッドが提供されているため、SQLの命令を使わずにRubyコードで記述することが可能となります。

5-1. マイグレーションの仕組み

リンクをコピーしました

マイグレーションの全体像についてざっくりと理解しましょう。例として、マイグレーションを使ってデータベースにdepartmentsテーブルを作成する流れを見てみます。

最初に、どのようなテーブルを作成するかを「マイグレーションファイル」に記述します。ここでは必要なカラム、データ型、オプションなどを定義します。その後、「railsコマンド」を実行することで、これらの定義をデータベースに反映させることができます。

さらに、「マイグレーション管理テーブル」にはマイグレーションファイルのタイムスタンプが記録され、どのマイグレーションが実行されたかが管理されます。

5-2.マイグレーションファイルの基本

リンクをコピーしました

マイグレーションファイルは、データベースの構造を定義するためのファイルです。簡単に説明すると、「どのようなテーブルを作成するか」を定義するファイルです。

マイグレーションファイルは、ActiveRecord::Migrationクラスを継承するクラスでなければなりません。このクラスがマイグレーションの実際の処理を担います。

1
2
3
4
5
6
7
8
class クラス名 < ActiveRecord::Migration[6.1]
  def change
    create_table :テーブル名 do |t|

      t.timestamps
    end
  end
end

マイグレーションファイルはdb/migrateディレクトリ内に格納され、ファイル名の先頭には生成された日時の「タイムスタンプ」が付けられます。このタイムスタンプは、マイグレーションを識別するために使用されます。

rails generateコマンドでモデルを作成する際には、対応するテーブルを作成するマイグレーションファイルも自動的に生成されます。Departmentモデルを作成した際に、以下のようにマイグレーションファイルも生成されましたね。

このマイグレーションファイルは、Departmentモデルに対応するdepartmentsテーブルを作成する設定で生成されます。

ファイルを開くと、クラスにはchangeというメソッドが定義されています。

1
2
3
4
5
6
7
8
class CreateDepartments < ActiveRecord::Migration[6.1]
  def change
    create_table :departments do |t|

      t.timestamps
    end
  end
end

changeメソッド内では、create_tableメソッドを使用してdepartmentsテーブルを作成します。上記では、基本的なカラムのみが作成されます。

テーブルに必要なカラムを指定する方法を理解するために、次にマイグレーションファイルの基本的な書式について学びましょう。

5-3.基本的な書式

リンクをコピーしました

データベースにテーブルを新規作成する際には、changeメソッド内でcreate_tableメソッドを使用します。create_tableメソッドは、テーブル名とカラムの定義が行えます。

テーブル名の指定は、以下のようにcreate_tableの後に:テーブル名とします。

1
2
3
4
5
6
7
class クラス名 < ActiveRecord::Migration[6.1]
  def change
    create_table :テーブル名 do |t|
      #ここにカラム定義
    end
  end
end

create_tableメソッドではブロックが利用可能です。ブロック内で|t|として指定されたブロック変数tを使ってカラムを定義します。このt変数には、カラムのデータ型を指定するためのメソッド（例：t.string, t.integerなど）が提供されます。

カラムの定義は、以下のようにt.データ型 :カラム名, 制約名: 値の形式で行います。

1
2
3
4
5
6
7
class クラス名 < ActiveRecord::Migration[6.1]
  def change
    create_table :テーブル名 do |t|
      t.データ型 :カラム名, 制約名: 値
    end
  end
end

例えば、以下のusersテーブルでは「非NULL制約」を設定したnameカラムがstring型で定義されます。Railsでstring型を指定すると、MySQL（MariaDB）ではVARCHAR型に置き換えられます。

1
2
3
4
5
6
7
8
class CreateUsers < ActiveRecord::Migration[6.1]
  def change
    create_table : users do |t|
      t.string :name, null: false
      #t.データ型 :カラム名, 制約名: 値
    end
  end
end

このマイグレーションファイルが実行されると、usersテーブルにはnameカラムのほか、idという主キーが自動的に生成されます。またt.timestampsが指定されると、created_atとupdated_atの２つのカラムも生成されます。

1
2
3
4
5
6
7
8
class クラス名 < ActiveRecord::Migration[6.1]
  def change
    create_table :テーブル名 do |t|
      t.データ型 :カラム名, 制約名: 値
      t.timestamps #created_atとupdated_atを生成
    end
  end
end

ActiveRecordの規約により、特定の目的に応じたカラム名が予約されていましたね。idの主キーのほか、t.timestampsで生成されるcreated_atとupdated_atも予約済みのカラム名に含まれます。

5-4.データ型

リンクをコピーしました

データ型は、テーブルに格納するデータの種類を限定すると学習しましたね。

Railsでは、create_tableメソッドのブロック内で「t.データ型」メソッドを用いてカラムのデータ型を定義できます。

1
2
3
4
5
6
7
class クラス名 < ActiveRecord::Migration[6.1]
  def change
    create_table :テーブル名 do |t|
      t.データ型 :カラム名
    end
  end
end

Railsで使用可能な主要なデータ型は、以下の通りです。

これらのデータ型は、create_tableメソッド内でカラムを定義する際に使用され、テーブル内の各カラムが保持するデータの種類を指定します。

5-5.制約とオプション

リンクをコピーしました

制約とは、データベースに格納されるデータが満たすべき条件を指します。

Railsではt.データ型メソッドを用いてカラムに制約を設定することができます。制約はカラム名の後にカンマで区切り、制約名: 値の形式で記述します。

1
2
3
4
5
6
7
class クラス名 < ActiveRecord::Migration[6.1]
  def change
    create_table :テーブル名 do |t|
      t.データ型 :カラム名, 制約名: 値
    end
  end
end

Railsで使用可能な主な制約とオプションは、データベース内のデータ整合性を保つために重要です。以下の表は、Railsで利用できる一般的な制約とオプションを示しており、これらはマイグレーションファイル内でカラム定義時に指定されます。

5-6.外部キー制約の設定

リンクをコピーしました

Railsでは、カラムに外部キー制約を設定する際には、create_tableメソッドのブロック内でt.referencesメソッドを利用します。

t.referencesメソッドには、カラム名の後にforeign_key: trueを指定します。

1
2
3
4
5
6
7
class クラス名 < ActiveRecord::Migration[6.1]
  def change
    create_table :テーブル名 do |t|
      t.references :カラム名, foreign_key: true
    end
  end
end

t.referencesを用いると、カラム名に_idを付ける必要がなくなります。

ActiveRecordでは、用途に応じて予め決められたカラム名があり、外部キーは通常親テーブル名の単数形_idと学びましたね。

t.referencesメソッドを使用すると、指定した親テーブル名の単数形に基づき、自動的に親テーブル名の単数形_idというカラムが生成されます。

たとえば、departmentを指定すると、カラム名はdepartment_idで生成されます。

1
2
3
4
5
6
7
class クラス名 < ActiveRecord::Migration[6.1]
  def change
    create_table :テーブル名 do |t|
      t.references :department, foreign_key: true
    end
  end
end

6.マイグレーションの実践

リンクをコピーしました

マイグレーションは、Railsアプリケーションのデータベース構造を定義し、変更するための強力なツールです。ここでは、マイグレーションファイルの編集、そして実行に至るまでのプロセスを段階的に学びます。

6-1.マイグレーションファイルの編集

リンクをコピーしました

マイグレーションファイルを編集して、テーブルに必要なカラムを定義していきましょう。

以下のようにdb/migrateディレクトリ内に格納される２つのマイグレーションファイルを編集していきます。ファイル名の先頭部分は一致している必要はありません。

上記のファイルは、それぞれdepartmentsテーブル、employeesテーブルを作成するためのファイルです。

まずは、Departmentモデルを作成した際に自動で生成されたマイグレーションファイルを開きましょう。

ファイルを開いて、以下のような記述になっているかを確認しましょう。

1
2
3
4
5
6
7
8
class CreateDepartments < ActiveRecord::Migration[6.1]
  def change
    create_table :departments do |t|

      t.timestamps
    end
  end
end

上記のマイグレーションファイルを編集して、departmentsテーブルに必要なカラムを定義していきます。

departmentsテーブルに必要なカラムは、以下のようにidとnameです。

データ型と制約は、以下の通りです。

上記の内容でdepartmentsテーブルを作成するSQL文は、以下の通りでしたね。

1
2
3
4
5
CREATE TABLE departments (
  id int(11) NOT NULL AUTO_INCREMENT,
  name varchar(30) NOT NULL,
  PRIMARY KEY(id) -- idに主キー制約を設定する
);

SQLでは主キーを設定しましたが、Railsではテーブルを作成するマイグレーションが実行されると、idという名前の主キーが暗黙的に生成されます。そのため、マイグレーションファイルではnameカラムの定義だけを行います。

以下のようにマイグレーションファイルを編集して、nameカラムを定義しましょう。

1
2
3
4
5
6
7
8
9
class CreateDepartments < ActiveRecord::Migration[6.1]
  def change
    create_table :departments do |t|
      t.string :name, null: false, limit: 30

      t.timestamps #削除しないでおきましょう
    end
  end
end

次にEmployeeモデルを作成した際に自動で生成されたマイグレーションファイルを開きましょう。

ファイルを開いて、以下のような記述になっているかを確認しましょう。

1
2
3
4
5
6
7
8
class CreateEmployees < ActiveRecord::Migration[6.1]
  def change
    create_table :employees do |t|

      t.timestamps
    end
  end
end

上記のマイグレーションファイルを編集して、employeesテーブルに必要なカラムを定義していきます。

employeesテーブルに必要なカラムは、以下のように４つのカラムです。外部キー制約は、子テーブルであるemployeesテーブルのdepartment_idに設定します。

ほとんどのカラムには、非NULL制約を設定しますが、birthdayのカラムだけは、デフォルト値をNULLにできるよう制約を設定しません。

その他のデータ型と制約は、以下の通りです。

上記の内容でemployeesテーブルを作成するSQL文は、以下の通りでしたね。

1
2
3
4
5
6
7
8
9
10
11
CREATE TABLE employees (
  id int(11) NOT NULL AUTO_INCREMENT,
  name varchar(30) NOT NULL,
  birthday date DEFAULT NULL,
  department_id int(11) NOT NULL,
  PRIMARY KEY(id),  -- idに主キー制約を設定する
  FOREIGN KEY(department_id) -- department_idに外部キー制約を設定する
    REFERENCES departments(id) --親テーブルと親テーブルの主キーを指定する
    ON DELETE RESTRICT -- 親テーブルに対する削除操作を拒否する
    ON UPDATE RESTRICT -- 親テーブルに対する更新操作を拒否する
);

SQLではON DELETEとON UPDATEでRESTRICTを指定することで、親テーブルに対する削除・更新操作を拒否していましたね。Railsでもt.referencesメソッドのforeign_keyを利用して、同じように設定してみます。

以下のようにマイグレーションファイルを編集して、employeesテーブルのカラムを定義しましょう。

1
2
3
4
5
6
7
8
9
10
11
class CreateEmployees < ActiveRecord::Migration[6.1]
  def change
    create_table :employees do |t|
      t.string :name, null: false, limit: 30
      t.date :birthday, default: nil
      t.references :department, foreign_key: { on_delete: :restrict, on_update: :restrict }

      t.timestamps #削除しないでおきましょう
    end
  end
end

birthdayカラムに設定するデフォルト値は、nullではなくnilである点にも注意しましょう。

6-2.マイグレーションファイルの実行

リンクをコピーしました

マイグレーションファイルの実行は、rails db:migrateコマンドを利用します。

1
rails db:migrate #ここでは実行しません！

rails db:migrateコマンドは、まだ実行されていないマイグレーションファイルのchangeメソッドを実行します。

1
2
3
4
5
6
7
8
9
class CreateDepartments < ActiveRecord::Migration[6.1]
  def change
    create_table :departments do |t|
      t.string :name, null: false, limit: 30

      t.timestamps
    end
  end
end

マイグレーションファイルの実行順序は、ファイル名の先頭にあるタイムスタンプ（ファイルが生成された日時）が基準になります。

6-3.実行プロセスの確認

リンクをコピーしました

rails db:migrateが実行されると、以下の図のようにschema_migrationsテーブルが調べられます。テーブルが存在しなければ作成されます。

schema_migrationsテーブルは、マイグレーションの実行履歴を管理するテーブルです。versionカラムの値は、マイグレーションファイルのタイムスタンプが入ります。

次にdb/migrateディレクトリ内に格納される全てのマイグレーションファイルが調べられます。そしてschema_migrationsテーブルと比較されます。

schema_migrationsテーブルに「タイムスタンプ値」が登録されてないマイグレーションファイルがあれば、データベースに適用されます。

最後にschema_migrationsテーブルが更新されます。

schema_migrationsテーブルに「20230214061519」という値があるということは、20230214061519_create_departments.rbが実行されていることを意味します。

実行の流れをまとめると、以下の通りです。

1. rails db:migrateを実行する
2. schema_migrationsテーブルを調べる、テーブルが存在しなければ作成される
3. db/migrateディレクトリ内に格納される全てのマイグレーションファイルを調べる
4. schema_migrationsテーブルのバージョンと異なるバージョンがあれば、データベースに適用させる
5. schema_migrationsテーブルを更新する

あとで詳しく説明しますが、schema_migrationsテーブルと齟齬が生じてエラーが起きる可能性があるので、実行完了後のマイグレーションファイル、つまりschema_migrationsテーブルに登録されるマイグレーションファイルは、絶対に編集や手動で削除しないように注意してください。

6-4.マイグレーションによるテーブルの作成

リンクをコピーしました

それでは、rails db:migrateコマンドを利用して２つのテーブルを作成してみましょう。

データベースに作成するテーブルは、departmentsテーブルとemployeesテーブルです。rails db:migrateコマンドは、アプリケーションのディレクトリで実行させます。

以下のコマンドを実行して、カレントディレクトリをemployee_managementディレクトリに変更しましょう。

1
cd ~/environment/employee_management

1
pwd

実行すると、以下のように~/environment/employee_managementと表示されます。

以下のコマンドをemployee_managementディレクトリで実行して、マイグレーションファイルで定義したテーブルをデータベースに適用させましょう。

1
rails db:migrate

実行すると、以下のように表示されます。数字部分は、一致する必要ありません。

phpMyAdminのページを再読み込みし、employee_management_developmentにテーブルが作成されていることを確認しましょう。

departmentsテーブルを作成するためのマイグレーションファイルでは、以下のようにカラムを定義しましたね。

1
2
3
4
5
6
7
8
9
class CreateDepartments < ActiveRecord::Migration[6.1]
  def change
    create_table :departments do |t|
      t.string :name, null: false, limit: 30

      t.timestamps
    end
  end
end

phpMyAdminでdepartmentsテーブルを確認してみましょう。

以下のようにnameカラムだけではなく、主キーであるidが暗黙的に生成されています。またt.timestampsによって、created_atとupdated_atという２つのカラムも生成されていますね。

employeesテーブルを作成するためのマイグレーションファイルでは、以下のようにカラムを定義しましたね。

1
2
3
4
5
6
7
8
9
10
11
class CreateEmployees < ActiveRecord::Migration[6.1]
  def change
    create_table :employees do |t|
      t.string :name, null: false, limit: 30
      t.date :birthday, default: nil
      t.references :department, foreign_key: { on_delete: :restrict, on_update: :restrict }

      t.timestamps
    end
  end
end

phpMyAdminでemployeesテーブルを確認してみましょう。

以下のようにマイグレーションファイルで定義したカラムが生成されています。そしてt.referencesで指定したdepartmentは、department_idというカラム名で生成されます。

実行の流れでは、schema_migrationsテーブルのversionカラムの値は、実行済みのマイグレーションファイルのタイムスタンプが入ると学びました。

データベースには、departments テーブルとemployeesテーブルが作成されているので、以下のマイグレーションファイルは実行されているはずです。

phpMyAdminでschema_migrationsテーブルを確認してみましょう。

以下のようにschema_migrationsテーブルのversionカラムの値には、実行済みのマイグレーションファイルのタイムスタンプ（バージョン）が登録されています。

6-5.スキーマファイルの検証

リンクをコピーしました

実はrails db:migrateコマンドを実行すると、db:schema:dumpというコマンドも同時に呼び出されます。このコマンドは、スキーマファイルの作成や更新を行います。

スキーマファイルとは、現在のデータベースの状態を表すファイルのことです。スキーマファイルは、schema.rbという名前でdbディレクトリ内に作成されます。

個別のマイグレーションファイルは、データベースの新しい「バージョン」とみなすことができるのに対して、スキーマファイルはマイグレーションファイルの集合です。

schema.rbファイルを開くと、現在のデータベースの状態を確認することができます。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
ActiveRecord::Schema.define(version: 2023_02_14_065344) do

  create_table "departments", charset: "utf8mb4", force: :cascade do |t|
    t.string "name", limit: 30, null: false
    t.datetime "created_at", precision: 6, null: false
    t.datetime "updated_at", precision: 6, null: false
  end

  create_table "employees", charset: "utf8mb4", force: :cascade do |t|
    t.string "name", limit: 30, null: false
    t.date "birthday"
    t.bigint "department_id"
    t.datetime "created_at", precision: 6, null: false
    t.datetime "updated_at", precision: 6, null: false
    t.index ["department_id"], name: "index_employees_on_department_id"
  end

  add_foreign_key "employees", "departments"
end

1行目にあるversionの値は、マイグレーションファイル名のタイムスタンプで、バージョンです。どのバージョンまでデータベースに適用されているかを表しています。

先ほどのマイグレーションの実行によって、データベースには「20230214065344」まで適用されているので、versionの値は2023_02_14_065344になります。

それでは、スキーマファイル（schema.rb）のversionの値が「schema_migrationsテーブル」の最終行の値であることを確認してみましょう。

※ 下の画像と値が一致している必要はありません。

6-6.マイグレーション状況の表示

リンクをコピーしました

schema_migrationsテーブルのversionカラムには、実行済みのマイグレーションファイルのタイムスタンプ値が入るので、「マイグレーションファイルがどこまで実行されているか」を確かめることができます。

しかし、マイグレーションの状況はschema_migrationsテーブルを確認しなくてもrails db:migrate:statusコマンドを利用することで、すぐに調べることができます。

rails db:migrate:statusコマンド

リンクをコピーしました

1
rails db:migrate:status # ここでは実行しません

上記のコマンドを実行すると、以下のようにマイグレーションの状況が表示されます。

Migration IDは、マイグレーションファイル名のタイムスタンプです。Statusがupであれば、そのマイグレーションファイルは実行済みで、データベースにも適用されている状況です。

1
2
3
4
5
6
database: データベース名

 Status   Migration ID    Migration Name
--------------------------------------------------
   up     20xxxxxxxxxxxx  Create departments
   up     20xxxxxxxxxxxx  Create employees

上記のようにStatusがupのマイグレーションファイルは、Railsは既に実行済みであると認識しているので、rails db:migrateを実行しても何も変更されません。

以下のようにStatusがdownであれば、そのマイグレーションファイルは実行されておらず、データベースにも適用されていない状況です。

1
2
3
4
5
6
database: データベース名

 Status   Migration ID    Migration Name
--------------------------------------------------
   down     20xxxxxxxxxxxx  Create departments
   down     20xxxxxxxxxxxx  Create employees

カレントディレクトリをemployee_managementディレクトリに変更して、rails db:migrate:statusコマンドを実行してみましょう。

1
cd ~/environment/employee_management

1
pwd

1
rails db:migrate:status

rails db:migrate:statusコマンドを実行すると、以下のようにStatusがupと表示されるので、どちらのマイグレーションファイルも実行済みだとわかります。

7.データベースの変更と修正の基本

リンクをコピーしました

開発過程ではデータベースの構造変更が頻繁に生じます。このセクションでは、データベースの変更や修正を行う基本的な手法を詳しく学んでいきます。

まず、「マイグレーションのロールバック」について学びます。これは、誤って行ったデータベースの変更を元に戻すための重要な機能です。ロールバックは、誤った変更を修正する際や、以前の状態に戻す際に不可欠です。

続いて、データベースに新しい項目を追加したり、不要な項目を削除する方法を学びます。これには新しいマイグレーションファイルを作成する必要があります。それでは、具体的な学習に進みましょう。

7-1.マイグレーションのロールバック

リンクをコピーしました

マイグレーションを利用するメリットとして、バージョン管理を行うことができる点が挙げられます。バージョン管理とは、いわばセーブデータの履歴のようなもので、作業の進捗をセーブデータのように保存し、後から巻き戻れるようにしておけます。

Railsのマイグレーションの場合は、実行したマイグレーションファイルのタイムスタンプをschema_migrationsテーブルに挿入することで、実行履歴を管理することができます。

このように変更履歴が記録されることで、データベースの構造を過去のある時点の状態に戻すことができます。この機能を「ロールバック」と呼びます。

ロールバックすると、schema_migrationsテーブルからもバージョンが削除されます。

マイグレーションファイルは、rails db:migrateで一度実行すると再度実行できない仕組みになっています。一般に修正する場合は、履歴として残すために修正用のマイグレーションファイルを新たに作成する必要があります。

しかし、カラム名の間違えなど履歴に残す必要がない程度の修正(※1)であれば、ロールバックでマイグレーションの状態を戻し、修正を行い、マイグレーションを実行しなおします。

rails db:rollbackコマンド

リンクをコピーしました

マイグレーションのロールバックは、rails db:rollbackコマンドを利用します。

1
rails db:rollback

上記のコマンドを実行すると、以下のようにマイグレーションが１つ前の状態に戻ります。

先ほどのrails db:migrate:statusコマンドでマイグレーションの状況を調べたときは、データベースにemployeesテーブル作成まで適用されている状態でしたね。

この状況でrails db:rollbackを実行すると、マイグレーションが１つ前の状態に戻るので、データベースからemployeesテーブルが削除されます。

それでは、カレントディレクトリをemployee_managementディレクトリに変更して、rails db:rollbackコマンドを実行してみましょう。

1
cd ~/environment/employee_management

1
pwd

1
rails db:rollback

rails db:rollbackを実行すると、ロールバックしたマイグレーションの情報がターミナルに出力されます。このロールバックで、データベースからemployeesテーブルが削除されたので、以下のようにdrop_table(:employees)とも表示されています。

ロールバック後、マイグレーションの状況が更新されているかを確かめてみましょう。

1
rails db:migrate:status

rails db:migrate:statusを実行すると、以下のようにロールバックしたマイグレーションのStatusがdownと表示されます。

Statusがdownであれば、そのマイグレーションファイルは実行されておらず、データベースにも適用されていない状況です。

schema_migrationsテーブルでは、実行済みのマイグレーションファイルのタイムスタンプを登録して、マイグレーションの実行履歴を管理しています。ロールバックしたマイグレーションは、Statusがdownになり、まだ実行していない状態になります。

phpMyAdminにアクセスし、以下のようにschema_migrationsテーブルからロールバックしたバージョンが削除されていることを確かめてみましょう。

schema_migrationsテーブルの最終行の値は、現在データベースに適用されているマイグレーションのバージョンになります。

スキーマファイルとは、現在のデータベースの状態を表すファイルのことでしたね。
schema.rbの1行目にあるversionの値は、マイグレーションファイル名のタイムスタンプで、どのバージョンまでデータベースに適用されているかを表しています。

以下のようにversionの値がschema_migrationsテーブルの最終行の値で、１つ前のマイグレーションファイル名のタイムスタンプであることを確かめてみましょう。

ロールバックにより１つ前のマイグレーションに戻るので、以下のようにversionの値と共にdepartmentsテーブル作成の定義だけが存在しています。

データベースにはdepartmentsテーブル作成だけ適用されていることがわかりますね。

それでは、データベースでemployeesテーブルが削除されて、departmentsテーブルだけが作成されているかを確かめてみましょう。

rails db:migrateコマンドを実行して、データベースにemployeesテーブルを作成するマイグレーションを適用させましょう。

1
rails db:migrate

上記のコマンドを実行すると、以下のようにschema.rbも更新されます。

続いて、以下のrails db:migrate:statusを実行して、マイグレーションの状況を確かめてみましょう。

1
rails db:migrate:status

上記のコマンドを実行すると、以下のようにemployeesテーブルを作成するマイグレーションのStatusがupと表示されるので、データベースに適用されている状況です。

最後にデータベースを確認してみましょう。

以下のようにschema_migrationsテーブルには、実行済みのマイグレーションのバージョンが挿入されます。データベースにはemployeesテーブルも作成されていますね。

ロールバックの注意点

リンクをコピーしました

すでに学習した内容ですが、マイグレーションファイルはrails db:migrateで一度実行すると、再度実行できない仕組みになっています。

この仕組みは、個別のマイグレーションファイルを変更履歴として残し、「どのような変更が行われてきたか」を確認したり、過去のある状態に戻れるようにするためです。

ロールバックでは、マイグレーションを過去のバージョンに戻すことができます。ロールバックで修正を行う際、ケアレスミスなどの軽度な修正でも状況を見極める必要があります。

もし、チーム開発で共同作業者に影響が出る（masterにmergeしている）状況や本番環境でマイグレーションファイルが実行済みであれば、ロールバックで既存のマイグレーションファイルを直接変更してはいけません。

この状況では、ロールバックで既存のマイグレーションを直接修正するのではなく、影響を小さく抑えるために修正用のマイグレーションファイルを新たに作成する必要があります。

7-2.新しいマイグレーションファイルの作成方法

リンクをコピーしました

マイグレーションファイルは、モデルと併せて作成する以外にも、rails generate migrationコマンドでマイグレーションファイル単体を作成する方法があります。

• rails generate model - モデルと併せてファイルを作成する
• rails generate migration - マイグレーションファイル単体を作成する

モデルと併せて自動生成されるマイグレーションファイルは、モデルに対応するテーブルを作成するためのものです。作成済みのテーブルに変更を加える場合は、新たにマイグレーションファイル単体を作成して変更を加えていきます。

rails generate migrationコマンド

リンクをコピーしました

マイグレーションでは、「クラス名」とタイムスタンプ後の「ファイル名」を一致させる必要があります。rails generate migrationコマンドを利用することで、適切な名前で単体のマイグレーションファイルを作成することができます。

1
rails generate migration クラス名

クラス名は、キャメルケース（CamelCase）で指定します。ファイル名の後半は、クラス名のスネークケース（snake_case）で作成されます。

例えば、以下のようにクラス名を「AddAgeToUsers」と指定した場合、作成されるマイグレーションファイルの名前は、「20xxxxxxxxxxxx_add_age_to_users.rb」になります。

1
rails generate migration AddAgeToUsers

1
2
3
4
class AddAgeToUsers < ActiveRecord::Migration[6.1]
  def change
  end
end

クラス名は自由に付けることができますが、マイグレーションのクラス名やファイル名を確認するだけで処理内容を識別しやすいように具体的な名前を付けるようにしましょう。

一般にマイグレーションのクラス名は「処理内容 + テーブル名」にします。

オプション：追加/削除コードの自動生成

リンクをコピーしました

本章では学習のため使用しませんが、rails generate migrationコマンドでは、クラス名などをある形式に則ることで、追加や削除に必要なコードも自動生成することができます。

カラム追加では「Addカラム名Toテーブル名」、カラム削除では「Removeカラム名Fromテーブル名」のクラス名を指定し、カラム名や型が続く形式にします。

1
rails generate migration クラス名 カラム名:データ型

1
rails generate migration AddAgeToUsers age:integer

上記のコマンドを実行すると、以下のようなマイグレーションファイルが自動で生成されます。

1
2
3
4
5
class AddAgeToUsers < ActiveRecord::Migration[6.1]
  def change
    add_column :users, :age, : integer
  end
end

テーブルへのカラム追加方法

リンクをコピーしました

テーブルにカラムを追加する場合は、rails generate migrationで指定する「クラス名」を「Addカラム名Toテーブル名」にします。

1
rails generate migration クラス名

1
rails generate migration Addカラム名Toテーブル名

例えばusersテーブルにageカラムを追加する場合、以下のようにクラス名を「AddAgeToUsers」と指定します。

1
rails generate migration AddAgeToUsers

上記のコマンドを実行すると、以下のようにファイル名の後半と一致するクラス名のマイグレーションファイルが作成されます。クラス内には、changeメソッドが定義されます。

1
2
3
4
class AddAgeToUsers < ActiveRecord::Migration[6.1]
  def change
  end
end

テーブルにカラムを追加する場合、changeメソッド内でadd_columnメソッドを利用します。以下のように追加するカラムを定義することができます。例ではusersテーブルに追加するageカラムに対して、INT型、非NULL制約を設定しています。

1
2
3
4
5
class AddAgeToUsers < ActiveRecord::Migration[6.1]
  def change
    add_column :テーブル名, :カラム名, :データ型, オプション
  end
end

1
2
3
4
5
class AddAgeToUsers < ActiveRecord::Migration[6.1]
  def change
    add_column :users, :age, :integer, null: false
  end
end

それでは、マイグレーションファイルを作成して、employeesテーブルにINT型のageカラムを追加してみましょう。以下のコマンドを順番に実行してください。

1
cd ~/environment/employee_management

1
rails g migration AddAgeToEmployees

上記のコマンドを実行すると、以下のようにdb/migrateディレクトリにマイグレーションファイルが作成されます。※ タイムスタンプ値は一致する必要はありません。

まずは、db/migrateディレクトリ内にあるマイグレーションファイルを開きましょう。

以下のようにadd_columnメソッドを利用して、追加するageカラムを定義しましょう。

1
2
3
4
5
class AddAgeToEmployees < ActiveRecord::Migration[6.1]
  def change
     add_column :employees, :age, :integer
  end
end

現時点では、マイグレーションファイルに追加するカラムを定義しただけなので、データベースに適用していない状況です。rails db:migrate:statusコマンドを実行して、 作成したマイグレーションファイルのStatusがdownであることを確認しましょう。

1
rails db:migrate:status

それでは、rails db:migrateコマンドを利用して、未実行のマイグレーションファイルを実行させて、データベースに適用させましょう。

1
rails db:migrate

上記のコマンドを実行すると、以下のようにマイグレーションファイルが実行されます。

続いて、以下のようにrails db:migrate:statusコマンドを実行して、 作成したマイグレーションファイルのStatusがupであることを確認しましょう。

1
rails db:migrate:status

最後にphpMyAdminにログインして、employeesテーブルにageカラムが追加されていることを確認しましょう。

テーブルからのカラム削除方法

リンクをコピーしました

テーブルからカラムを削除する場合は、rails generate migrationで指定する「クラス名」を「Removeカラム名Fromテーブル名」にします。

1
rails generate migration クラス名

1
rails generate migration Removeカラム名Fromテーブル名

例えばusersテーブルからageカラムを削除する場合、以下のようにクラス名を「RemoveAgeFromUsers」と指定します。

1
rails generate migration RemoveAgeFromUsers

上記のコマンドを実行すると、以下のようにファイル名の後半と一致するクラス名のマイグレーションファイルが作成されます。クラス内には、changeメソッドが定義されます。

1
2
3
4
class RemoveAgeFromUsers < ActiveRecord::Migration[6.1]
  def change
  end
end

テーブルからカラムを削除する場合、changeメソッド内でremove_columnメソッドを利用します。以下のように削除するカラムを定義することができます。例ではusersテーブルから削除するカラムとして、INT型、非NULL制約が設定されるageカラムを定義しています。

1
2
3
4
5
class RemoveAgeFromUsers < ActiveRecord::Migration[6.1]
  def change
    remove_column :テーブル名, :カラム名, :データ型, オプション
  end
end

1
2
3
4
5
class RemoveAgeFromUsers < ActiveRecord::Migration[6.1]
  def change
    remove_column :users, :age, :integer, null: false
  end
end

それでは、マイグレーションファイルを作成して、employeesテーブルからINT型のageカラムを削除してみましょう。以下のコマンドを順番に実行してください。

1
cd ~/environment/employee_management

1
rails g migration RemoveAgeFromEmployees

上記のコマンドを実行すると、以下のようにdb/migrateディレクトリにマイグレーションファイルが作成されます。※ タイムスタンプ値は一致する必要はありません。

まずは、db/migrateディレクトリ内にあるマイグレーションファイルを開きましょう。

以下のようにremove_columnメソッドを利用して、削除するageカラムを定義しましょう。

1
2
3
4
5
class RemoveAgeFromEmployees < ActiveRecord::Migration[6.1]
  def change
    remove_column :employees, :age, :integer
  end
end

現時点では、マイグレーションファイルに削除するカラムを定義しただけなので、データベースに適用していない状況です。rails db:migrate:statusコマンドを実行して、 作成したマイグレーションファイルのStatusがdownであることを確認しましょう。

1
rails db:migrate:status

それでは、rails db:migrateコマンドを利用して、未実行のマイグレーションファイルを実行させて、データベースに適用させましょう。

1
rails db:migrate

上記のコマンドを実行すると、以下のようにマイグレーションファイルが実行されます。

続いて、以下のようにrails db:migrate:statusコマンドを実行して、 作成したマイグレーションファイルのStatusがupであることを確認しましょう。

1
rails db:migrate:status

最後にphpMyAdminにログインして、employeesテーブルからageカラムが削除されていることを確認しましょう。

この章のまとめ

リンクをコピーしました

この章では、Railsにおけるデータベース操作の基本的な概念と手法について学びました。
MVCアーキテクチャにおけるデータベースとのやり取りの流れを学び、モデルの基本概念とActiveRecordの重要性について理解を深めました。また、マイグレーションの基礎から実践を通して、実際にRailsでデータベースを管理する方法を学びました。

この章を通じて、Railsにおけるデータベースの操作方法と管理の基本を習得し、実際にRailsアプリケーションでデータベースを効率的に扱うための基盤を築くことができました。

この章をもう一度学習したい方のみ、以下のコマンドを実行して環境をリセットし、改めて「1.Railsでのデータベース操作の理解」から取り組んでみてください。

1
cd ~/employee_management

アプリケーションのルートディレクトリで以下のコマンドを実行して、EmployeeモデルとDepartmentモデル、データベースを削除して、再度データベースを作成しなおしましょう。

1
rails d model employee && rails d model department && rails db:drop && rails db:create

1
rm -rf db/migrate