会社の研修で正規化理論に関する話が出てきたので、これを機に記事化します。
情報処理技術者試験対策の上でも重要な話ですし、テーブルの設計に携わる技術者であれば実務を行う上でも理解しておきたい理論です。
【正規化理論について】
基本情報処理・応用情報処理では、非正規形～第３正規形まで理解していれば十分です。
データベーススペシャリストでも、非正規形～第３正規形に関する問いが中心で、ボイスコッド正規形～第５正規形が問われることは稀です。第１正規形～第３正規形に関してその意図まで理解すると共に正規化手順に慣れることが重要で、ボイスコッド正規形～第５正規形は試験直前に暗記しておく程度で十分です。
非正規形～第３正規形は下記ページにて触れられています。
DELPHI5 DATABASE APPLICATION DEVELOPER'S GUID - 正規化
http://ext-web.edu.sgu.ac.jp/HIKO/Prog03/SenpaiKyozai/shiohara/formalize.html
ボイスコッド正規形は下記ページにて触れられています。
ボイスコッド正規化 - Qiita
https://qiita.com/gooddoog/items/f40a7f0602bbe6afa1cf
第４正規形～第５正規形は下記ページにて触れられています。
第四正規化・第五正規化・ボイスコッド正規化がややこしいので、備忘録として自分なりにまとめてみた(データベーススペシャリストの勉強) メサイア・ワークス
https://www.messiahworks.com/archives/3399
【正規化のメリット・デメリットについて】
下記のページで簡単に触れられています。
リレーショナルデータベース正規形の種類と正規化手順 サービス プロエンジニア
http://proengineer.internous.co.jp/content/columnfeature/6480#section102
ただし、上記のページでは更新時異状について触れられておらず、データベーススペシャリスト対策の面でも実務での設計の判断の上でも不十分なので補足します。
第２正規化・第３正規化が行われていない場合には、以下のような更新時異状が発生します。
・第１正規形まで満たしているテーブルの例
+--------+--------+--------+--------+
| 商品ID | 取引ID | 商品名 | 取引額 |
+--------+--------+--------+--------+
| 1 | 1 | 商品１ | 100000 |
| 1 | 2 | 商品１ | 150000 |
| 2 | 1 | 商品２ | 200000 |
+--------+--------+--------+--------+
※主キーは「商品ID・取引ID」の組み合わせである
※「商品名」は「商品ID」により一意に求められる
（部分関数従属している）
・挿入時の更新時異状
新たな商品を開発したため、商品ID=3、商品名=商品３のデータを登録したい。
しかし、取引がまだなく、取引IDを割り振ることができない。
取引ID=NULLだと主キー制約に抵触するため、
取引が発生するまで登録することができない。
・更新時の更新時異状
商品名の改名に伴い、商品ID=1の商品名を商品１Ｂに変更したい。
しかし、その場合は商品ID=1の行を全て更新しないと、
商品ID=1で商品名が商品１の行と、
商品ID=1で商品名が商品１Ｂの行が混在してしまい、
データの整合性が失われてしまう。
例えば、商品名を取得する目的で商品ID=1という条件でクエリを投げると、
「商品１」と「商品１Ｂ」の２つがヒットしてしまう。
・削除時の更新時異状
取引のキャンセルに共にレコードの削除を行う際、
ある商品の全ての取引について削除を行ってしまうと、
その商品の情報も一緒に失われてしまう。
例えば、商品ID=2の取引ID=1のレコードを削除すると、
商品ID=2は商品名=商品２であるという情報も失われてしまう。
---------------------
目次
