こんにちは！　株式会社アルシエで教育に関するサポートをしている岸本です。

今回はDB設計の正規表現についてお伝えしていきます。

正規表現

正規化の目的はデータの不整合の発生を防ぎ、重複なく、不足なくがないことです。

設計手法：商品コード商品表と売上表に持たせて、商品名を持つのは商品表だけで管理して「１事実1箇所」が正規化の絶対的なテーマです。

関数従属性

完全関数従属とは「〇〇と決まれば✖︎✖️と1つに決まる」状態の事です。

例えば、社員番号が決まれば氏名がきまり、「氏名」が社員番号に関数従属すると表現します。

完全関数従属

部分関数従属しない状態のことを完全関数従属してると表現します。

部分関数従属

「社員番号」と「売上番号」が決まれば、「氏名」が決まります。

ただ、「社員番号」だけでも「氏名」は決まる事を部分関数従属していると表現します。

非正規形

上記の表では、「商品番号」「商品名」「数量」が繰り返しになっています。

「購入番号」「顧客番号」「顧客名」「購入日」の2行目が空白となっていて、表としてなりたっていません。

実際に表をデータベーステーブルにする場合は購入番号が主キーとなる為、主キーをNullにできません。

今のままだとデータベーステーブルとして、実装できません。

第1正規化

1️⃣ 繰り返し項目を購入明細として別の表に分ける。

2️⃣ 購入者が分かるように、購入番号を購入明細に入れる。

3️⃣ 購入番号と商品番号を候補キーとする。

候補キーとは行を一意に特定できる属性の候補です。

例：社員表の中で、「社員No.」、「氏名」、「住所」と「メールアドレス」があり、社員Noとメールアドレスが社員を一意に識別できため、候補キーとなる。

ただメールアドレスは後ほど変更される恐れがあり主キーに適してないので、社員Noが主キーに最適です。

第２正規化

第２正規化は「関数従属」に着目します。

1️⃣ 候補キーに着目する

2️⃣ 候補キーが単一の表は無視をする(この時点で第2正規形決定)

3️⃣ 候補キーが複数ある場合、その一部で決定する項目があるかチェック

4️⃣ 手順3で発見した項目を別の表に分けて紐づける。

第3正規化

主キー以外の項目で、〇〇が決まればxxが決まるものがあれば、第3正規形の必要があります。

今のままだと、顧客名は購入番号が決まれば値が決まるが、顧客番号が決まっても値が決まります。

購入番号が決まれば顧客番号が決まる、顧客番号が決まれば購入番号が決まり、これを推移的関数従属といいます。

第3正規化は、推移的関数従属を取り除くことをいいます。

第3正規化の為に顧客表を追加し、購入表の顧客番号と紐づくようにします。

以上となります。

ご覧いただきありがとうございます。