こんにちは、つーくんです。
59歳からデータベーススペシャリスト試験合格を目指して勉強しています。
今回は、データベースの基本である**「正規化」**に挑戦しました。
第1正規形、第2正規形、第3正規形……。
名前だけ見ると難しそうですが、実際に問題を解きながら考えてみると、少しずつ意味が分かってきました。
ただ、やっぱり難しい！
今回は、つーくんが実際に考えた内容を記録しておきます。
そもそも正規化って何？
正規化とは、簡単に言えば、
「データの重複や矛盾が起きにくいように、テーブルを整理すること」
だと理解しています。
例えば、受注データを全部一つの表に入れてしまうと、同じ顧客名や商品名が何度も登場します。
そこで、顧客は顧客表、商品は商品表というように、データの関係を考えながらテーブルを分けていきます。
でも、ただ分ければいいわけではありません。
ここで重要になるのが**「関数従属」**です。
今回考えた受注表
今回の問題では、受注に関するデータについて考えました。
登場する主な項目は、
受注番号、受注日、顧客番号、顧客名、商品番号、商品名、商品分類番号、商品分類名、数量
などです。
このデータを見ながら、
「どの項目が、どの項目によって決まるのか？」
を考えていきました。
例えば、
顧客番号 → 顧客名
商品番号 → 商品名
商品分類番号 → 商品分類名
という関係があります。
「顧客番号が決まれば顧客名が決まる」
これが関数従属ということですね。
第2正規形を考えてみる
問題を解きながら、つーくんは次のようなテーブル分割を考えました。
顧客表
顧客番号、顧客名
商品表
商品番号、商品名、商品分類番号、商品分類名
受注表
受注番号、受注日、顧客番号、商品番号、数量
ここまでは比較的イメージしやすかったです。
ところが、商品表をよく見ると気になるところがあります。
商品番号から商品分類番号が決まり、
さらに、
商品分類番号から商品分類名が決まります。
つまり、
商品番号 → 商品分類番号 → 商品分類名
という関係があります。
ここで登場したのが、
「推移的関数従属」
です。
第3正規形へ！
商品分類名は、商品番号から直接決まるというより、商品分類番号を経由して決まっています。
そこで商品表をさらに分けます。
商品表
商品番号、商品名、商品分類番号
商品分類表
商品分類番号、商品分類名
こうすることで、
商品分類番号と商品分類名の関係を、商品表から切り離すことができます。
これが第3正規形への分解です。
最初は、
「商品分類名も商品表に入れておけばいいのでは？」
と思いました。
でも、同じ商品分類にたくさんの商品があったら、商品分類名を何度も保存することになります。
さらに商品分類名を変更するときには、複数のデータを変更しなければなりません。
そこで、
商品分類番号 → 商品分類名
を独立したテーブルにする。
なるほど。
これが正規化する理由の一つなんですね。
実際に問題を解くと理解が変わる
参考書を読んで、
「第3正規形とは推移的関数従属を排除したもの」
と覚えるだけなら簡単です。
でも、
「では、この表のどこが推移的関数従属なの？」
と聞かれると急に難しくなります。
今回、自分でテーブルを分解してみたことで、
商品番号 → 商品分類番号 → 商品分類名
という具体例と結び付けて考えられるようになりました。
これは大きな収穫でした。
今日覚えておきたいこと
今回の勉強で、つーくんが特に覚えておきたいのは、
「どの項目が、何によって決まるのかを見る」
ということです。
正規化の問題を見たら、いきなりテーブルを分割するのではなく、
「Aが決まればBが決まる」
という関係を探してみる。
そして、
主キー → 項目
だけでなく、
主キー → A → B
となっていないか確認する。
この考え方を身につけたいと思います。
まだまだ正規化を練習します
第3正規形まで勉強しましたが、まだ完全に理解できたとは思っていません。
問題の形が変わったら、また迷うと思います。
だから次は、違うパターンの正規化問題にも挑戦してみます。
59歳のつーくん。
まだ第2回ですが、少しずつデータベースの考え方が面白くなってきました。
データベーススペシャリスト合格への道は、まだ始まったばかりです！
コメント