Ruby on Railsでテーブルを定義してみよう

ActiveRecordにおける規約

リンクをコピーしました

テーブルを定義する前にActiveRecordにおける規約を確認しておきましょう。

カラム名

リンクをコピーしました

ActiveRecordには、利用する目的に応じてカラム名が決められているものがあります。

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

テーブルの主キーはidで、外部キーは親テーブル名の単数形_idになります。

モデルのクラス名とテーブル名

リンクをコピーしました

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

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

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

モデルの作成

リンクをコピーしました

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

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

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

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

1
2
class Department < ApplicationRecord
end

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

モデルの作成・削除コマンド

リンクをコピーしました

モデルを作成するときはrails generateコマンドを使えば、モデルのクラスだけではなく、関連するファイルも自動で生成することができます。

モデル名には、モデルのクラス名を指定します。

1
rails generate model モデル名

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

この章では、上２つのファイルだけを学習します。１つ目のファイルは、モデルクラスのファイルで、２つ目のファイルはテーブルを作成するためのファイルです。

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

1
rails destroy model モデル名

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

モデルを作成してみよう

リンクをコピーしました

それでは、rails generateコマンドを利用して２つのモデルを作成してみましょう。

作成するモデルは、DepartmentモデルとEmployeeモデルです。rails generateコマンドは、アプリケーションのディレクトリで実行させます。

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

1
cd ~/environment/employee_management

1
pwd

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

以下のコマンドをemployee_managementディレクトリで実行して、Departmentモデルクラスと関連するファイル一式を生成してみましょう。

1
rails g model department

実行すると、複数のファイルが自動生成されます。以下の緑枠で囲う２つのファイルがDepartmentモデルのクラス、departmentsテーブルを作成するためのファイルです。

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

app/modelsディレクトリに生成されたdepartment.rbは、Departmentモデルのクラスファイルです。departmentsテーブルを操作するために必要なファイルです。

db/migrateディレクトリの方は、departmentsテーブルを作成するために必要なファイルです。ファイル名はYYYYMMDDHHMMSS_create_departments.rbのような形式になります。先頭部分には、ファイルが生成された日時が追加されます。

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

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

テーブル作成に必要なYYYYMMDDHHMMSS_create_departments.rbについては、マイグレーションで学習します。

以下のコマンドをemployee_managementディレクトリで実行して、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モデルになります。

テーブル作成に必要なYYYYMMDDHHMMSS_create_employees.rbについては、次のマイグレーションで学習します。

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

phpMyAdminにログインして、employee_management_developmentにテーブルが作成されていないことを確認しましょう。

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

マイグレーション

リンクをコピーしました

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

マイグレーションを利用する主なメリットとして、以下のようなことが挙げられます。

• データベース構造の定義をRubyで記述することができる
• バージョン管理を行うことができる

SQLでテーブルの作成や変更を加える場合は、CREATE TABLE文やALTER TABLE文などのデータ定義言語を使用しましたね。Railsでは、これらの処理を行うメソッドが提供されているので、SQLのデータ操作言語を使わずにRubyで記述することができます。

バージョン管理では変更履歴を記録できるので、後から巻き戻れるようにしておけます。

マイグレーションの仕組み

リンクをコピーしました

マイグレーションの全体像をざっくりと把握してみましょう。マイグレーションを利用して、データベースにdepartmentsテーブルを作成する流れで確認してみます。

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

また「マイグレーション管理テーブル」に、マイグレーションファイル名のタイムスタンプが挿入されることで、どこまで実行されているかを管理することができます。

マイグレーションファイルの基礎

リンクをコピーしました

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

マイグレーションファイルは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というRailsのメソッドを利用してdepartmentsテーブルを作成します。上記の設定では、最低限必要なカラムしか作成されません。

テーブルに必要なカラムを指定できるように、マイグレーションファイルの基本的な書き方を学びましょう。

基本書式

リンクをコピーしました

データベースにテーブルを新規作成する場合は、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.データ型メソッドを利用して、カラムを定義します。

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という名前のカラムが「VARCHAR型」で定義されます。

※ 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
9
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も予約済みのカラム名です。

カラム名だけではなく、Railsで利用できるデータ型や制約も確認してみましょう。

データ型

リンクをコピーしました

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

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で利用できる主なデータ型は、以下の通りです。

制約・オプション

リンクをコピーしました

制約とは、データベースに格納するデータが満たさなければならない条件のことでしたね。

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では、カラムに外部キー制約を設定する場合は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

t.referencesメソッドでは、カラムに自動でインデックスが付与されます。

マイグレーションファイルを編集してみよう

リンクをコピーしました

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

以下のように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である点にも注意しましょう。

マイグレーションファイルを実行

リンクをコピーしました

マイグレーションファイルの実行は、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

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

実行の流れを確認しよう

リンクをコピーしました

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テーブルに登録されるマイグレーションファイルは、絶対に編集や手動で削除しないように注意してください。

マイグレーションを実行して、テーブルを作成してみよう

リンクをコピーしました

それでは、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カラムの値には、実行済みのマイグレーションファイルのタイムスタンプ（バージョン）が登録されています。

スキーマファイルを確認しよう

リンクをコピーしました

実は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テーブル」の最終行の値であることを確認してみましょう。

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

マイグレーションの状況を表示

リンクをコピーしました

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と表示されるので、どちらのマイグレーションファイルも実行済みだとわかります。

マイグレーションを前の状態に戻す

リンクをコピーしました

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

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している）状況や本番環境でマイグレーションファイルが実行済みであれば、ロールバックで既存のマイグレーションファイルを直接変更してはいけません。

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

マイグレーションファイルを作成

リンクをコピーしました

マイグレーションファイルは、モデルと併せて作成する以外にも、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カラムが削除されていることを確認しましょう。