今回は僕がデータベーススペシャリストの勉強をして、
特に重要だと感じた更新時異状についてまとめました。
正規化が不十分な時に発生する更新時異状のパターンを具体例でまとめています。
データベーススペシャリストを目指している方にはもちろん、
普通のシステムエンジニアやプログラマーにも抑えておいて欲しい内容です。
この記事を書いている僕はシステムエンジニア6年目
普段はJavaでWebアプリを作ったりSQL書いたり・・・(DBAのような仕事は普段していないです)
応用情報技術者試験に合格(2回落ちましたが。。)し、データベースの分野が得意だったので、
独学でデータベーススペシャリストの勉強をして、昨年合格(これは1発合格)しました。
今回は、データベーススペシャリストの勉強を通じて、
データベーススペシャリストを目指す人はもちろん、
普通のシステムエンジニアやプログラマーの方にも抑えておいて欲しい
正規化不足の時に発生する更新時異常についてまとめてみました。
この記事を読む前に
以下の記事を参考に正規化について抑えておいて下さい。

更新時異状
正規化が不十分(第1正規形、第2正規形のまま)だと、
テーブルに新しい行を挿入、更新、削除する時にいろんな異状が発生します。
更新時異状が発生する理由としてはテーブルに冗長性があることが挙げられます。
正規化の目的はこの冗長性を排除して「1事実1箇所」(1 fact in 1 place)にすることです。
それでは、第2正規化、第3正規化されていないケースのそれぞれで、
具体的に更新時異状の例を見ていきます。
第2正規化されていない場合に発生する更新時異状
まず、以下を見て下さい。
上は第2正規化されていないテーブルの例で、下はその関数従属性を図にしたものです。
テーブルの例を見ると、
{店舗ID:01、店舗名:東京店}という情報が2箇所、
{商品ID:001、商品名:釣り竿A}という情報が2箇所、
それぞれ存在していて冗長です。(「1事実1箇所」(1 fact in 1 place)ではない)
こういうデータの持ち方をしてしまうと、
店舗名を修正したい場合、同じ修正を何箇所も行わなければなりません。
また1箇所でも修正が漏れると整合性が失われてしまいます。(修正時の更新時異状)
また、新しい商品{商品ID:004、商品名:リールD}を登録したい場合、
主キーが{店舗ID、商品ID}なので、
店舗IDをNULLのままで登録しようとすると主キー制約違反になります。(挿入時の更新時異状)
逆に{店舗ID:01、店舗名:東京店}を削除したい場合、
店舗IDをNULLで更新しようとすると主キー制約違反になります。(削除時の更新時異状)
第3正規化されていない場合に発生する更新時異状
次に第3正規化されていない場合を確認します。
以下を見て下さい。
上は第3正規化されていないテーブルの例で、下はその関数従属性を図にしたものです。
テーブルの例を見ると、
{役職ID:102、役職名:部長}という情報が2箇所、
存在していて冗長です。(「1事実1箇所」(1 fact in 1 place)ではない)
先ほどと同じくこういうデータの持ち方をしてしまうと、
役職名を修正したい場合、同じ修正を何箇所も行わなければなりません。
また1箇所でも修正が漏れると整合性が失われてしまいます。(修正時の更新時異状)
また、新しい役職{役職ID:104、役職名:係長}追加を計画しており、
まだ所属社員が決まっていないような場合、
社員IDをNULLのまま登録しようとすると主キー制約違反になります。(挿入時の更新時異状)
さらに、{社員ID:004、社員名:斎藤}が退職する場合、
社員IDをNULLにして情報を残そうとすると主キー制約違反になります。(削除時の更新時異状)
まとめ
今回は正規化不足による更新時異状のパターンについて、
第1正規形、第2正規形のそれぞれで確認しました。
データベーススペシャリストの試験では正規化が不十分なテーブルに対して
どのような更新時異状が発生するかを問う問題はよく出題されます。
実際に現場でテーブル設計をする場合にもこの知識は役に立つので、
ぜひ今回の内容は抑えておきましょう!!