データベースの正規化。らしきものはできる。
でも、「データベースの正規化とは」となると・・・
・データ等を一定のルールに基づき利用しやすいように整理すること
・第一正規形：データの冗長性や不整合を排除する。繰り返しの項目を持たない
・第二正規形：すべての非キー属性が候補キーに完全関数従属する
・第三正規形：すべての非キー属性が候補キーに推移的関数従属しない。
・・・と書いてあるのを見かけるが、意味が分からない。
なので、この機会に正規化についてぴよぴよ頭で理解するように努めてみました。
参考になる記事を読んで、ざっくり以下のように飲み込みました。
・第一正規形：とりあえず最低限データベースに突っ込めそうな形にする
・第二正規形：主キーをみつけて「主キーが決まればこの項目は決まるよね」という項目を表から切り離す
・第三正規形：主キー以外の項目でも「この項目が決まればこの項目は決まるよね」という項目を表から切り離す
やってみます。
- ◆例１：請求書をデータベース化する。
- 1.第一正規形
- 2.第二正規形
- ①主キーの特定
- ②「主キーが決まればこの項目は決まるよね」という項目を表から切り離す
- 3.第三正規形
- ◆例２：料理レシピをデータベース化する
- １．第一正規形
- ２．第二正規規形
- ①主キーをさがせ！
- ②「主キーが決まればこの項目は決まるよね」という項目を表から切り離す
◆例１：請求書をデータベース化する。
1.第一正規形
何枚か紙の請求書があります。これを正規化しながらデータベースに入れてみようと思います。
こうしました。
でも、これではデータベースにつっこめません。
エクセルの表としては見やすいですが、データベースに突っ込んだ場合、明細の2行目がNULLになってしまいます。
なので、こうしました。色付きの部分（「請求ナンバー」と「請求先」「請求先住所」）を2行目にもコピーしました。
これで第一正規形ができました。
2.第二正規形
次に第二正規形です。
①主キーの特定
まず、各項目（候補キーというらしい）から主キーになるものを探します。
主キーの制約は
１）重複がないこと
２）NULLがないこと
だそうです。
それと、
・主キーとは。テーブルの行を一つに特定するためのキー
つまり、行が変われば必ず違う項目のこと。テーブルの中でその行だけに唯一無二の値！そして、複数のキーの組み合わせでも可、です。
さて、主キーを探します。
請求№ → 重複があるからだめ
請求先 → 重複があるからだめ
請求先住所 → 重複があるからだめ
明細№ → 重複があるからだめ
商品名 → 重複があるからだめ
数量 → どう考えてもちがうだろう
単価 → どう考えてもちがうだろう
ない！
まてよ。「請求№」と「明細№」の組み合わせではどうだろう。
これで行ける！
よって、この表で主キーは「請求№」と「明細№」としました。
②「主キーが決まればこの項目は決まるよね」という項目を表から切り離す
この値が決まればこの値は決まるよね、ということを「関数従属」というそうです。
たとえば、社員番号が特定されれば社員名も特定される＝社員名は社員番号に関数従属しているといえる、といったような感じ。
「主キーが決まればこの項目は決まるよね」ですが、主キーに関係していれば「主キーの一部が決まればこの項目は決まるよね」も同様とします。
表を眺める… 「請求№」がきまれば「請求先」「請求先住所」が決まるっぽい。
なので、切り離します。
表か2つになりました。
「請求一覧」と「請求明細一覧」とテーブル名を付けました。
黄色の項目が各テーブルの主キーです。
これで第二正規形ができました。
評価分離する際に気を付けること！元の表に戻るようにしなければなりません。
下のようにしちゃうと元に戻らない・・・。
3.第三正規形
主キー以外の項目で関数従属を探します。
主キー以外の項目で「この項目が決まればこの項目は決まるよね」です。
請求一覧を眺める…「請求先」がきまれば「請求先住所」が決まります！→取引先マスターとして分離
請求明細を眺める…「商品ｺｰﾄﾞ」がきまれば「商品名」「単価」が決まります！→商品マスターとして分離
表か４つに分かれました。なんだかリレーショナルデータベースって感じになりましたね！
これで第三正規形ができました。完成！
理解を深めるため、もう一つやってみます。
◆例２：料理レシピをデータベース化する
何枚かの料理メモがあります。これをデータベース化します。
１．第一正規形
表にしました！
１メモ1行に整理しましたが、なんかだめっぽい表ですね。
どこがだめかというと「材料」と「分量」が横に繰り返しになってます。いわゆる「冗長な表」という感じです。
「材料7」「分量7」まで表を作ってますが7個を超える材料のレシピがでてきたら表を「材料8」「分量8」・・・と項目を追加する必要が出てきてしまいます。
また、カレーの「材料7」「分量7」はNULLです。NULLがあるのはあんまり好ましくなさそうですよね。
一つの料理に材料は何個必要かしら・・・？とか集計するのも大変そうですね。
なので、こうしました。
これでさっきよりはましになりました。
一応データベースに突っ込める形にはなったので、第1正規形完了とします。
２．第二正規規形
①主キーをさがせ！
さて、主キーをさがせ！です
№ → 重複がある
料理名 → 重複がある
材料 → 重複がある。っていうかいろいろある。キーっぽくない
分量 → 違うだろ～
作り方 → 重複がある。っていうか違うだろ～
組み合わせると唯一無二のもの（行ごとに違うもの）を探します。
「料理№」と「材料」
「料理名」と「材料」
どちらも行ごとに違うものですが、「料理№」と「材料」のほうがキーっぽいかな。ということで「料理№」と「材料」の組み合わせで主キーとします。
②「主キーが決まればこの項目は決まるよね」という項目を表から切り離す
および「主キーの一部が決まればこの項目は決まるよね」という項目を表から切り離す。
主キーの一部「№」→「料理名」「作り方」がきまる
主キーの「№」「材料」→「分量」がきまる
分離します。
レシピテーブルと材料テーブルに分離しました。
これで第二正規形となりました。
主キーと関係ない項目で、もう分離できる項目はないので、これは第二正規形でおしまいです。
やれやれ。疲れますね。
要は、
・管理がしやすい形（データの追加はよくても項目の追加・削除はない方がよい）
・集計がしやすい形
・重複するものはまとめる（例えば上の例でレシピテーブルに料理名、作り方をまとめたので、カレーの作り方が変わった場合一つの表の一つのデータだけ直せばよい。正規化前だと何行も直さなければならず、大変～ということになる）
・各表は主キーにつながっているデータで構成されるのがよい
といったものを目指す、というところでしょうか。
データベースの正規形について、理解が違っていたらすみません。
accessにさわりはじめて十何年・・・正規化をちゃんと理解せずになんとなくもやもや正規化をやってきたが、ここでだいたいこんなものかな～と理解できたと思い、自分的には満足。
参考にさせていただいたホームページ（わかりやすかったです！）
データベースの正規化の手順をわかりやすく解説 (katalog.tokyo)
【データベース】正規形をなんとなくでいいから理解したいのに理解が難しい人のためになるべくわかりやすく書いた記事 │ コジマノテック (kojimanotech.com)
データベースの正規化(正規形)とはなんぞや – gomokulog (gomocool.net)
【初級編⑧】テーブル正規化の概要とその手順 | SQL Server 虎の巻 (kaya-soft.com)
ありがとうございました！
コメント