リレーショナルデータベースとは

一括採点では、生徒や採点結果などのデータを管理するために リレーショナルデータベースを使用しています。 この記事では、その基本概念を解説します。

なぜデータを保存する必要があるか

採点ソフトでは、生徒の情報、試験の設定、採点結果など、 多くのデータを保存しておく必要があります。 アプリを閉じても、次に開いたときに前回の続きから作業できなければ困ります。

データを保存する方法はいくつか考えられます。

一括採点ではデータベースを採用しました。 その理由は、この後の説明で明らかになります。

データは表で管理する

データベースでは、データを表で管理します。 Excelの表を想像してください。

たとえば、3年1組に山田太郎さん、鈴木花子さん、田中次郎さんがいるとします。 これを表にすると、次のようになります。

1行が1人分のデータ、各列が「生徒名」「学籍番号」「学級」といった項目になります。 Excelで成績表を作るのと同じ感覚です。

表は分割した方が良い

では、すべてのデータを1つの大きな表にまとめればよいでしょうか？ 先ほどの3年1組の例に、学級の情報（担任、教室）も追加してみましょう。

3人だけなら問題なさそうですが、実際の学級には30人以上の生徒がいます。 すると「3年1組」「佐藤先生」「301教室」を30回も書くことになります。

さらに問題があります。担任が変わったらどうなるでしょうか？30件すべてのデータを「佐藤先生」から「高橋先生」に書き換える必要があります。 1件でも書き換え忘れると、データに矛盾が生じてしまいます。

この問題を解決するのが、表の分割です。

こうすることで、学級の情報は1箇所だけに保存されます。 担任が変わっても、学級テーブルの1行を修正するだけで済みます。 30人分の生徒データを書き換える必要はありません。

このように、複数の表を「ID」で関連付けて管理するデータベースをリレーショナルデータベースと呼びます。 「リレーション（Relation）= 関係」が名前の由来です。

一対多と多対多

テーブル間の関係には、一対多と多対多の2種類があります。 先ほどの生徒と学級の例で見てみましょう。

一対多の関係

先ほどの例では、生徒テーブルに「学級ID」を持たせていました。 これは一対多の関係です。

この設計は単純でわかりやすいのですが、1つ問題があります。生徒が複数の学級に所属する場合はどうすればよいのでしょうか？

たとえば、山田太郎さんが2年生のときは2年3組、 3年生になって3年1組に転籍したとします。 生徒テーブルの「学級ID」は1つしか持てないので、 過去の所属情報を保存できません。

多対多の関係

生徒が複数の学級に所属できるようにしたい。 これは多対多の関係です。

多対多の関係は、直接2つのテーブルを繋ぐことができません。 そこで中間テーブルを使います。

中間テーブルは、生徒テーブルと学級テーブルの両方への外部キーを持っています。 1人の生徒が複数の学級に所属する場合は、中間テーブルに複数の行が作られます。

多対多の関係を中間テーブルで分解すると、 「生徒 → 所属」と「所属 → 学級」という2つの一対多の関係になります。 中間テーブルのおかげで、生徒の転籍履歴も正しく管理できるようになりました。

採点結果を保存してみよう

では、採点ソフトの本題である「採点結果」を保存する場合を考えてみましょう。 「山田太郎さんの問1の採点結果は○」という情報を保存したいとします。

先ほどと同じように、1つの表にまとめた場合と、 表を分割した場合を比較してみます。

これを図に表すと

採点結果テーブルは、生徒テーブルと設問テーブルの両方を参照しています。 「S001のQ001の結果は○」という情報から、 「山田太郎さんの問1は○」という完全な情報を組み立てられます。

用語の整理

ここまでの説明で使った概念を、データベースの用語で整理しておきましょう。

一括採点では、すべてのテーブルでUUID（Universally Unique Identifier）を 主キーとして使用しています。 たとえば、採点結果を保存するとき、新しく生成したUUIDを主キーとして保存します。

UUIDは36文字のランダムな文字列です。 約340澗（かん）通り、つまり340兆の1兆倍の1兆倍もの組み合わせがあるため、 世界中で使われているどのUUIDとも重複しないとされています。

一括採点での活用

ここまでの例では、生徒・学級・設問・採点結果の4つのテーブルを使いました。 実際の一括採点では、全部で50を超えるテーブルが複雑に関連しています。 リレーショナルデータベースの仕組みにより、 これらの関連を整理して管理できています。