データベース設計入門 第3回：テーブル・カラム設計の基本

はじめに

前回「データベース設計入門 第2回：要件から「必要なデータ」を洗い出す」の記事では、業務要件から「データベースにどのようなデータが必要なのか」を洗い出す方法について解説しました。

データベース設計では、必要なデータを洗い出しただけでは、まだ実際のデータベースとして利用することはできません。

洗い出した「ユーザー」「商品」「注文」といった情報を、データベース上でどのような形で保存するのかを考える必要があります。

そこで登場するのが、テーブルとカラムです。

今回は、データベース設計の中でも特に基本となる、

• テーブル
• カラム
• レコード
• 主キー
• NULL
• データ型
• ID
• created_at / updated_at

といった要素について解説していきます。

これらはデータベースを設計するうえで必ずと言っていいほど登場するものです。

最初は用語が多く感じるかもしれませんが、ひとつずつ見ていけばそれほど難しいものではありません。

本記事は、MySQLを前提に記述されています。自動的な番号の割り当てや日付と時刻に関するデータ型などで、別の関係データベースシステム（RDBMS）との差異が存在します。あらかじめご了承ください。

---

この記事の対象者

この記事は、以下のような方を対象としています。

• エンジニアとして仕事をしているが、データベースについてあまり詳しくない
• SQLは多少書けるが、テーブルを自分で設計した経験が少ない
• テーブルやカラムという言葉は知っているが、どう設計すればよいのか分からない
• データベース設計を基礎から学びたい
• なんとなくテーブルを作っているが、設計時に何を考えればよいのか整理したい

今回は、複雑な正規化やテーブル同士のリレーションについてはまだ深く扱いません。

まずは1つのテーブルをどのように作るのかという基本部分に注目します。

---

まずは簡単なテーブルを見てみる

最初に、ユーザー情報を保存するための簡単なテーブルを考えてみます。

テーブル名を users とします。

users
-------------------
id
name
email
created_at

これだけを見ると、Excelの表のように見えるかもしれません。

もう少し具体的にデータを入れてみると、次のようなイメージになります。

id	name	email	created_at
1	山田太郎	[e-mail]	2026-09-01 10:00:00
2	佐藤花子	[e-mail]	2026-09-02 14:30:00
3	鈴木一郎	[e-mail]	2026-09-03 09:15:00

この表を使って、

「テーブル」「カラム」「レコード」とは何なのかを確認していきましょう。

---

テーブルとは

**テーブル（Table）**とは、関連するデータをまとめて保存するための入れ物です。

先ほどの例では、

users

というテーブルを作っています。

このテーブルには「ユーザーに関する情報」を保存します。

例えば、

• ユーザー
• 商品
• 注文
• 支払い

などが存在するシステムであれば、

users
products
orders
payments

といった形で、それぞれの役割ごとにテーブルを作っていきます。

重要なのは、何でも1つのテーブルに詰め込まないことです。

例えばユーザー情報と注文情報をすべて同じテーブルに入れてしまうと、

「このカラムはユーザーの情報なのか、注文の情報なのか」

という区別が難しくなります。

基本的には、

何についてのデータを保存するテーブルなのか

を明確にして設計します。

---

カラムとは

**カラム（Column）**とは、テーブルに保存するデータの項目です。

先ほどの users テーブルでは、

id
name
email
created_at

がカラムです。

例えば、

name

にはユーザーの名前を保存します。

email

にはメールアドレスを保存します。

つまり、

テーブルが「何のデータを保存するか」を表し、
カラムが「そのデータのどの情報を保存するか」を表す

と考えると分かりやすいでしょう。

例えば商品を保存する products テーブルであれば、

products
-------------------
id
name
price
stock
created_at

のような設計が考えられます。

---

レコードとは

**レコード（Record）**とは、テーブルに保存されている1件分のデータです。

先ほどの例であれば、

1 | 山田太郎 | [e-mail] | 2026-09-01 10:00:00

この1行が1つのレコードです。

次のようなテーブルがあった場合、

id	name	email
1	山田太郎	[e-mail]
2	佐藤花子	[e-mail]

ユーザーが2人登録されているため、2件のレコードが存在することになります。

Excelに置き換えて考えるなら、

• テーブル → シート
• カラム → 列
• レコード → 行

というイメージが近いです。

ただし、データベースにはExcelとは異なるルールや制約があるため、完全に同じものではありません。

---

主キー（Primary Key）とは

テーブルを作る際に非常に重要になるものが、**主キー（Primary Key）**です。

主キーとは、

テーブルの中で、1つのレコードを一意に特定するための値

です。

例えば次のテーブルを見てみましょう。

id	name
1	山田太郎
2	山田太郎

名前だけを見ると、どちらも「山田太郎」です。

現実のシステムでは、同姓同名の人が登録されることは当然あります。

そのため、

name = 山田太郎

だけでは「どちらの山田太郎なのか」を特定できません。

そこで利用するのが id です。

id = 1

であれば1人目の山田太郎、

id = 2

であれば2人目の山田太郎、

というように確実に区別できます。

この id を主キーとして設定します。

主キーには基本的に、

• 値が重複しない
• NULLにならない
• 原則として後から変更しない

といった性質が求められます。

---

NULLとは

データベースでは、値が存在しないことを表すためにNULLという特別な値があります。

例えばユーザー情報に電話番号を追加してみます。

users
-------------------
id
name
email
phone_number

すべてのユーザーが電話番号を登録するとは限りません。

その場合、

id	name	phone_number
1	山田太郎	090-1234-5678
2	佐藤花子	NULL

のようになります。

この NULL は、

空文字 ""

や、

0

とは意味が異なります。

NULLは基本的に、

値が存在しない、または値が分からない

という状態を表します。

何でもNULLにしてよいわけではない

NULLを許可すると柔軟にデータを保存できますが、必要以上にNULLを許可すると扱いが複雑になります。

例えば、

name
email

が必須項目なのであれば、

name = NULL
email = NULL

を許可する必要はありません。

その場合は、データベース側で NOT NULL を設定します。

例えば、

name VARCHAR(100) NOT NULL

のようにします。

設計時には、

この項目は必ず値が存在するのか？

を考えることが重要です。

---

データ型とは

カラムを作成するときには、

このカラムには、どの種類のデータを保存するのか

を指定します。

これをデータ型と呼びます。

代表的なデータ型には次のようなものがあります。

種類	用途の例
INTEGER	ID、個数、年齢などの整数
VARCHAR	名前、メールアドレスなどの文字列
TEXT	長い文章
DATE	日付
DATETIME / TIMESTAMP	日付と時刻
BOOLEAN	true / false
DECIMAL	金額など正確な小数を扱いたい値

例えば、

users
-------------------
id           INTEGER
name         VARCHAR
email        VARCHAR
created_at   DATETIME

のようになります。

データ型は保存する値に合わせる

例えば年齢を保存するのであれば、

age VARCHAR

ではなく、

age INTEGER

のほうが自然です。

文字列として保存してしまうと、

"10"
"2"
"30"

などが文字として扱われ、数値として比較・計算するときに問題になる可能性があります。

逆に電話番号は、数字だけで構成されているからといって整数型にするべきではありません。

09012345678

のような電話番号は計算するための数値ではなく、文字列として意味を持つ値だからです。

郵便番号なども同様です。

重要なのは、

見た目が数字だから数値型

ではなく、

そのデータをどのように扱うのか

で判断することです。

---

IDをどう設計するか

テーブル設計では、多くの場合 id というカラムを作ります。

例えば、

users
-------------------
id
name
email

です。

そして通常、この id を主キーとして利用します。

連番のID

最も分かりやすいのが、次のような連番です。

1
2
3
4
5

MySQLであれば AUTO_INCREMENT、PostgreSQLであればIDENTITYなどを利用して、自動的に番号を割り当てる方法があります。

小規模なシステムや一般的なWebアプリケーションでは、扱いやすい方法です。

UUID

一方で、

550e8400-e29b-41d4-a716-446655440000

のようなUUIDをIDとして利用することもあります。

UUIDには、

• 複数のサーバーでIDを生成しやすい
• IDが単純な連番にならない
• システムをまたいでも重複しにくい

といった特徴があります。

ただし、

• 人間が見て扱いにくい
• サイズが大きくなりやすい
• DBや利用方法によってはインデックスの効率を考慮する必要がある

などの注意点もあります。

そのため、

IDは全部UUIDにすればよい

というわけではありません。

システムの規模や構成に合わせて選択します。

メールアドレスを主キーにしてはいけないのか

例えばユーザーのメールアドレスは基本的に重複しないため、

email

を主キーにしたくなるかもしれません。

しかし、メールアドレスは将来変更される可能性があります。

主キーは他のテーブルから参照されることも多いため、変更される可能性のある値を利用すると扱いが難しくなります。

そのため、

id

というシステム内部用の値を主キーとして持たせ、

email

には必要に応じてUNIQUE制約を設定する、

という設計がよく利用されます。

---

created_at / updated_at

多くのWebシステムでは、次のようなカラムを持たせることがあります。

created_at
updated_at

created_at は、

このデータが作成された日時

を保存します。

updated_at は、

このデータが最後に更新された日時

を保存します。

例えば、

id	name	created_at	updated_at
1	山田太郎	2026-09-01 10:00:00	2026-09-10 15:30:00

というデータがあれば、

2026年9月1日にユーザーが作成され、2026年9月10日に何らかの情報が更新されたことが分かります。

なぜ作成日時を持つのか

作成日時があると、

最近登録されたユーザー

を取得したり、

今月作成された注文

を集計したりできます。

障害調査などでも、

「このデータはいつ作られたのか」

を確認できるため非常に便利です。

updated_atも役に立つ

updated_at があれば、

「最後にいつ変更されたのか」

を確認できます。

そのため、特別な理由がなければ、

created_at
updated_at

をセットで持つ設計がよく利用されます。

---

usersテーブルを少し具体的に設計する

ここまでの内容を使って、最初に紹介した users テーブルをもう少し具体的にしてみましょう。

users
-----------------------------------------
id          BIGINT       PRIMARY KEY
name        VARCHAR(100) NOT NULL
email       VARCHAR(255) NOT NULL
created_at  DATETIME     NOT NULL
updated_at  DATETIME     NOT NULL

それぞれの役割は次のようになります。

カラム	役割
id	ユーザーを一意に識別するID
name	ユーザー名
email	メールアドレス
created_at	作成日時
updated_at	更新日時

さらに、

email

について、

「同じメールアドレスで複数のユーザーを登録できない」

という要件があるのであれば、UNIQUE制約を設定します。

イメージとしては、

users
-----------------------------------------
id          BIGINT       PRIMARY KEY
name        VARCHAR(100) NOT NULL
email       VARCHAR(255) NOT NULL UNIQUE
created_at  DATETIME     NOT NULL
updated_at  DATETIME     NOT NULL

となります。

このようにテーブル設計では、

単純に、

どのカラムを作るか

だけではなく、

どのデータ型にするのか
NULLを許可するのか
重複を許可するのか
主キーは何にするのか

といったことも合わせて決めていきます。

---

カラムを増やしすぎない

テーブルを設計していると、

「あとで必要になるかもしれない」

と考えて、たくさんのカラムを追加したくなることがあります。

例えば、

users
-------------------
id
name
email
phone_number
fax_number
company_name
department_name
position_name
facebook_url
twitter_url
instagram_url
...

と増やしていくようなケースです。

もちろん業務上必要なのであれば問題ありません。

しかし、

将来使うかもしれない

という理由だけで追加すると、使われないカラムが大量に残る可能性があります。

前回の記事でも触れたように、

「将来必要かもしれない情報」と「現時点で必要な情報」

を分けて考えることが重要です。

テーブル設計でも、

なぜこのカラムが必要なのか

を説明できる状態にしておくと、不要なカラムを減らしやすくなります。

---

カラム名は意味が分かる名前にする

カラム名も重要です。

例えば、

n
mail
dt

のような名前では、そのカラムが何を意味しているのか分かりにくくなります。

できるだけ、

name
email
created_at

のように、意味が分かる名前を付けましょう。

特に複数人で開発する場合、

「作った本人には分かる」

という名前では不十分です。

数か月後に別のエンジニアが見ても意味が理解できる名前を意識することが重要です。

---

テーブル名・カラム名のルールを統一する

命名規則についても、プロジェクト内で統一しておくことをおすすめします。

例えばテーブル名を、

user

と単数形にするのか、

users

と複数形にするのか。

日時を、

createdDate

とするのか、

created_at

とするのか。

どちらが絶対に正しいというものではありません。

重要なのは、

プロジェクト内で統一されていること

です。

例えば、

users
orders
products

と複数形を使うルールに決めたのであれば、他のテーブルもそのルールに合わせます。

命名規則が統一されていると、データベース全体が読みやすくなります。

---

まとめ

今回は、テーブル・カラム設計の基本について解説しました。

まず覚えておきたいのは、

• テーブルは、関連するデータをまとめて保存する入れ物
• カラムは、保存するデータの項目
• レコードは、実際に保存される1件分のデータ
• 主キーは、レコードを一意に識別するための値
• NULLは「値が存在しない」ことを表す
• カラムには保存する値に合ったデータ型を設定する
• IDには連番やUUIDなどの方法がある
• created_at / updated_atを持たせるとデータの管理や調査がしやすくなる
• NULLを許可するか、重複を許可するかといったルールもテーブル設計の一部

という点です。

テーブル設計というと、

users
products
orders

のように「テーブルを何個作るのか」だけを考えがちですが、実際には1つ1つのカラムについても、

何を保存するのか
どのデータ型を使うのか
NULLを許可するのか
一意である必要があるのか

といったことを考える必要があります。

そして、実際のシステムでは1つのテーブルだけで完結することはほとんどありません。

ユーザーが注文を行ったり、注文の中に複数の商品が含まれたりと、複数のテーブルが互いに関連します。

次回以降は、こうしたテーブル同士の関係についても見ていきます。

---

関連記事

データベース設計シリーズの関連記事については、「データベース設計入門 第1回：そもそもデータベース設計とは何か」もあわせてご覧ください。