IT用語はアブリビエーション（abbreviation; アルファベット3文字など）が多くて、いつも混乱します。職場では可能な限りアブリビエーションを使わないよう、お達しが出ていました。親切に日本語に訳してくれている用語もありますが、あまりに直訳ゆえに意味を取りにくい。カタカナ表記が多いのは、日本語直訳を否定して、英語での理解を助ける合理的な選択なのだと思います。
関係データベース正規化というトピックが経営情報システムの学習範囲に出てきます。耳慣れない言葉だったので、説明資料をいくつかあさりました。正規形、更新異常、部分的関数従属性、推移的関数従属性などなど難しい言葉が並んでいて、一読しただけでは理解が及びませんでした。しかし、理解が及ぶにつれて、間違いないデータ処理を行う上で理想のデータベース構築のための、ごく一般的な手続きであることがわかりました。
データベース正規化の目的
ある関係を列挙したデータベースがあって、そこから目的とするデータを抽出するコード（プログラム）を書くとします。その後、データを更新したり、追加たり、削除したりする場合でも、コードが引き続き正しい結果を返すよう、データの完全性（Data Integrity）を維持できることが理想です。そのために、どういうデータを準備すべきか一目でわかるよう、データベースをいくつかに分けて、「このデータ変更するときには、このデータベースのここだけを変更すれば良い」というような形にしておくと間違いがなくなります。データ正規化の手続ききは、データ完全性を維持することを目的とします。
データベース正規化の手順
手順はどうあれ、結果としてデータ完全性が維持されていれば良いのですが、手順を一般化した方が間違いが少なくなるということで、エドガー・コッドという科学者が1970年代に記した正規化手続きが広く知られています。正規化手続きとして何段階ものステップが発表されていますが、実務では第3正規化まで行うことが一般的です。
まず、そもそも関係データベースというものの定義があります。縦横2次元のデータベースで、横（RowとかTupleとかいいます）に関係を示すデータの組が並び、縦（Column）にデータの属性（Attribute）が並びます。横に並んだデータの組には、その組を一意に示すID（主キー）があり、主キーが複数あったり、欠けたりしている組はありません。さらに主キーのほかに、候補キーというものがあり、これらはある限定範囲において、データの組を一意に示します。
第1正規化では、ひとつのセルにひとつのデータしかない状態を作ります。複数のデータが入ったセルがあれば、組を分けたり、属性を追加したりしてデータベースを整備します。
第2正規化では、主キーとは関係ない候補キーと関係あるデータの組を、別の表に取り出します。候補キーは取り出したデータの組を一意に示すもので、複数あったり、欠けていたりする組はありません。主キーと候補キーの間に関係がないので、別表にあるデータを変更しても、主キーの含まれる表に影響は及びません。そうすることで、データ変更時の間違いを少なくできます。この第2正規化手続きは「部分的関数従属性を解消する」などといいます。即ち、候補キーとその関係するデータの組を別表に分けるということです。言葉はピンときませんが、内容は難しくありません。
第3正規化では、主キーとは関係あるけれども間接的な関係、即ち、主キーと関係ある候補キーに関係あるデータの組を、更に別の表に取り出します。ここでも候補キーは取り出したデータの組を一意に示すもので、複数あったり、欠けていたりする組はありません。この第3正規化手続きは「推移的関数従属性を解消する」などといいます。即ち、主キーと関係のある候補キーとその関係するデータの組を別表に分けるということです。
正規化されたデータベース
第3正規化まで行って正規化されたデータベースは、複数の表に分かれ、そのそれぞれにデータの組を一意に示すキーが付されています。それぞれの表は独立していることから、こちらの表にあるデータを変更したら、こちらの表も変更するといったようなことは生じません。データ変更の際には、変更するデータのある表を見に行って、その組に含まれる属性データすべてを過不足なく変更することで、全体データの完全性が維持されます。
前述のエドガー・コッドは、データベースプログラムの設計者でした。データの完全性が維持されなければ、いくら優秀なプログラムでも機能しません。コンピュータが進化する過程で、プログラムが進化し、プログラムが処理しやすいようなデータベース構築を求めることは、自然の流れだったのでしょう。
