イチから全部作ってみよう（35）テーブル結合はリレーショナルデータベースの肝：山浦恒央の“くみこみ”な話（204）（1/3 ページ）

ソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」。第35回は、リレーショナルデータベースの肝となるテーブル結合について解説する。

[山浦恒央 人間環境大学 環境情報学科 教授（工学博士），MONOist]

1．はじめに

　山浦恒央の“くみこみ”な話の連載第170回から、入門者をターゲットとして、「イチから全部作ってみよう」というシリーズを始めました。このシリーズでは、多岐にわたるソフトウェア開発の最初から最後まで、すなわち、要求仕様の定義、設計書の作成、コーディング、デバッグ、テスト、保守までの「開発フェーズ」の全プロセスを具体的に理解、経験することを目的にしています。

　興味がある方は、連載第170回からのバックナンバーをご覧ください。

⇒連載「山浦恒央の“くみこみ”な話」バックナンバー

2．前回までの振り返り

　コンピュータサイエンスの古典的名著に「Algorithms + Data Structures = Programs（邦題：アルゴリズム＋データ構造＝プログラム）」があります。コンピュータ界のノーベル賞であるチューリング賞（これまで日本人の受賞なし）を受賞したニクラウス・ヴィルトが1976年に著した書籍で、「プログラムは、適切なデータ構造の選択と、データを処理するアルゴリズムの2つを組み合わせて初めて成立する」というプログラミングの普遍的な本質を提示しています。

　本シリーズでも、プログラムは処理とデータから成り立っていると考え、現在データに着目しています。特に、ここ数回にわたってデータベースの話を取り上げており、前回は複数の処理をひとまとめにして実行し、途中で失敗したら後戻りし、それまでに実施した全ての処理を取り消す「トランザクション」の概念を説明しました。

　ここまでで、データを安全に読み書きする方法は学びましたが、実際にどんな形でデータを保存するかは、まだ決めていません。今回は、テーブル結合について取り上げ、設計書から一通りのテーブル構造を作ります。

3．テーブル結合とは

　まず、テーブル結合について簡単に説明します。

　リレーショナルデータベースでは、データを役割ごとに複数のテーブルに分けて管理し、必要なときにテーブルをガッチャンコ（結合）して利用します。そのため、テーブルを設計するときには、どのデータをどのテーブルに分け、どの項目を使ってテーブル同士を関連付けるのかを考える必要があるのです。

　例えば、学生情報（表1）と履修表（表2）を別々のテーブルで管理していたとします。

項目名	カラム名	データ型	制約	備考
学籍番号	student_id	TEXT	主キー
名前	name	TEXT
表1　学生情報テーブル

項目名	カラム名	データ型	制約	備考
学籍番号	student_id	TEXT	外部キー
科目名	subject	TEXT
表2　履修表テーブル

　また、2つのテーブルには次のデータが入っているとします（表3、4）。

学籍番号	名前
1	山田
2	鈴木
表3　学生情報テーブルのデータ

学籍番号	科目
1	離散数学
1	データ構造とアルゴリズム
1	プログラミング入門
2	コンパイラ
表4　履修表テーブルのデータ

　これら2つのテーブルのどちらにも学籍番号があります。そのため、2つのテーブルを関連付けてくっつけることで、「誰がどの科目を履修しているか」を1つの表にできますね（表5）。

学籍番号	名前	科目
1	山田	離散数学
1	山田	データ構造とアルゴリズム
1	山田	プログラミング入門
2	鈴木	コンパイラ
表5　学生情報テーブルと履修表テーブルを結合したテーブル

※画像はイメージです

　このように、学生情報テーブルの学籍番号のようにレコードを一意に識別するための情報を「主キー（Primary Key）」と呼びます。また、履修テーブルの学籍番号のように、別のテーブルの主キーを参照するキーを「外部キー（Foreign Key）」と呼びます。

　ここで、「初めから結合したテーブルを持ってしまえばよいのではないか」と考える人もいるでしょう。もちろん、そのように定義してもいいですが、データが多くなると、同じ名前などの情報を保存することになり、名前を変更するときに修正漏れが発生する可能性があります。よって、データを役割ごとに別々のテーブルに分けて保存することで、不要な重複を減らすことができます。

　主キーと外部キーを使ってテーブル同士を関連付け、必要なときに結合して利用する仕組みが、リレーショナルデータベースの大きな特徴です。