今回は僕がデータベーススペシャリストの勉強をして、
特に重要だと感じた更新時異状についてまとめました。
正規化が不十分な時に発生する更新時異状のパターンを具体例でまとめています。
データベーススペシャリストを目指している方にはもちろん、
普通のシステムエンジニアやプログラマーにも抑えておいて欲しい内容です。
この記事を書いている僕はシステムエンジニア６年目
普段はJavaでWebアプリを作ったりSQL書いたり・・・(DBAのような仕事は普段していないです)
応用情報技術者試験に合格(2回落ちましたが。。)し、データベースの分野が得意だったので、
独学でデータベーススペシャリストの勉強をして、昨年合格(これは1発合格)しました。
今回は、データベーススペシャリストの勉強を通じて、
データベーススペシャリストを目指す人はもちろん、
普通のシステムエンジニアやプログラマーの方にも抑えておいて欲しい
正規化不足の時に発生する更新時異常についてまとめてみました。
この記事を読む前に
以下の記事を参考に正規化について抑えておいて下さい。
更新時異状
正規化が不十分(第１正規形、第２正規形のまま)だと、
テーブルに新しい行を挿入、更新、削除する時にいろんな異状が発生します。
更新時異状が発生する理由としてはテーブルに冗長性があることが挙げられます。
正規化の目的はこの冗長性を排除して「１事実１箇所」(1 fact in 1 place)にすることです。
それでは、第２正規化、第３正規化されていないケースのそれぞれで、
具体的に更新時異状の例を見ていきます。
第２正規化されていない場合に発生する更新時異状
まず、以下を見て下さい。
上は第２正規化されていないテーブルの例で、下はその関数従属性を図にしたものです。
テーブルの例を見ると、
{店舗ID：01、店舗名：東京店}という情報が２箇所、
{商品ID：001、商品名：釣り竿A}という情報が２箇所、
それぞれ存在していて冗長です。(「１事実１箇所」(1 fact in 1 place)ではない)
こういうデータの持ち方をしてしまうと、
店舗名を修正したい場合、同じ修正を何箇所も行わなければなりません。
また１箇所でも修正が漏れると整合性が失われてしまいます。(修正時の更新時異状)
また、新しい商品{商品ID：004、商品名：リールD}を登録したい場合、
主キーが{店舗ID、商品ID}なので、
店舗IDをNULLのままで登録しようとすると主キー制約違反になります。(挿入時の更新時異状)
逆に{店舗ID：01、店舗名：東京店}を削除したい場合、
店舗IDをNULLで更新しようとすると主キー制約違反になります。(削除時の更新時異状)
第３正規化されていない場合に発生する更新時異状
次に第３正規化されていない場合を確認します。
以下を見て下さい。
上は第３正規化されていないテーブルの例で、下はその関数従属性を図にしたものです。
テーブルの例を見ると、
{役職ID：102、役職名：部長}という情報が２箇所、
存在していて冗長です。(「１事実１箇所」(1 fact in 1 place)ではない)
先ほどと同じくこういうデータの持ち方をしてしまうと、
役職名を修正したい場合、同じ修正を何箇所も行わなければなりません。
また１箇所でも修正が漏れると整合性が失われてしまいます。(修正時の更新時異状)
また、新しい役職{役職ID：104、役職名：係長}追加を計画しており、
まだ所属社員が決まっていないような場合、
社員IDをNULLのまま登録しようとすると主キー制約違反になります。(挿入時の更新時異状)
さらに、{社員ID：004、社員名：斎藤}が退職する場合、
社員IDをNULLにして情報を残そうとすると主キー制約違反になります。(削除時の更新時異状)
まとめ
今回は正規化不足による更新時異状のパターンについて、
第１正規形、第２正規形のそれぞれで確認しました。
データベーススペシャリストの試験では正規化が不十分なテーブルに対して
どのような更新時異状が発生するかを問う問題はよく出題されます。
実際に現場でテーブル設計をする場合にもこの知識は役に立つので、
ぜひ今回の内容は抑えておきましょう！！
参考にした資料
コメントを残す