前回の記事では、データベースの概要についてご紹介しました。この記事では、その中のリレーショナルデータベース（関係データベース）について詳しくご紹介します。
リレーションの意義
前回の記事では、リレーショナルデータベースについて以下のように解説しています。
この「リレーション」について、リレーションとは何なのか、なぜリレーションが必要なのかを具体例と共に解説したいと思います。
リレーションが無いとどうなるか
以下のような大学の教務システムをベースにしたデータベースを例に考えてみます。
一見すると、何ら問題の無いデータベースのように見えますが、実は重大な問題があります。
このデータベースが作成された段階で、「Webアプリ開発概論」の講義を担当する教員が決まっておらず、新しく「20001」という教員IDを割り当てたまでは良かったのですが、肝心な担当教員名が分からないため、「不明」になっています。
数日後、「教授 花子」先生が新たに着任され、無事に「Webアプリ開発概論」の講義を担当していただけることになりました。ここで、担当教員の欄を「不明」から「教授 花子」に更新する必要があるのですが、ID 1～5の5行分を更新しなければなりません。
今回は、簡単のために5行分しかデータを作成していませんが、実際の大学では数百人程度の受講生がいることも想定されます。この場合は、数百行分のデータ更新作業が発生し、更新漏れや入力ミスのリスクが高まることは容易に想像できます。
膨大な時間を割いて更新作業を行った上に、「誤字脱字をした」、「更新した箇所と更新し忘れた」ともなれば、せっかくシステムで効率化している意味がありません。上記のデータベースの例は、実用に耐えない悪い例なのです。
では、どうすれば良かったのでしょうか？
端的に言えば、適切にテーブル（表）を分割せず、1つのテーブルにカラム（列）を作りすぎたことが今回のトラブルの原因です。
テーブルを分割する
実際のデータベース設計・運用においては、規則に基づいて適切にテーブルを分割することが重要です。今回の例では、次のようにテーブルを４分割します。
このような構造にしておけば、教員ID「20001」に紐づく教員名を「未定」から「教授 花子」に1ヶ所更新するだけで、関係する全てのレコードが実質的に更新されたことになります。
科目IDから担当教員IDを参照し、さらに担当教員IDに紐づく教員名が参照される仕組みになっています。
疑似的な検証
上記の説明だけでは、何となく釈然としない部分もあるかと思いますので、表計算ソフトを使ってこのリレーションを疑似的に検証してみたいと思います。
補足説明の項目にはなりますが、結果的に表計算ソフトのちょっとした裏技紹介になりましたので、ぜひ最後までご覧ください。
検証用に、担当教員というカラムを一時的に復活させ、VLOOKUP関数を使ってリレーションを検証します。
D21セルには、以下のように関数を入力し、D30セルまでコピーします。
=VLOOKUP(VLOOKUP(C21;C$17:F$18;4);C$13:D$14;2)リレーションを二重に（科目IDに紐づく教員IDを参照し、さらに教員IDに紐づく教員名を参照）しているため、VLOOKUP関数をネスト（入れ子）にします。
ネストの内側「VLOOKUP(C21;C17:F18;4)」は、C21セルの科目IDを参照し、それに紐づく教員IDを返しています。
ここで、D13セルを「未定」から「教授 花子」に書き換えると、それに伴ってD21～D25セルが自動的に「未定」から「教授 花子」に更新されました！
いかがでしたか？
リレーショナルデータベースにおけるリレーションの意義と必要性について、理解の助けになったら幸いです。
