テーブルとは？
- 共通点を持つレコードの集合体
正規化とは？
データの冗長性を排除し、一貫性と効率性を保持するためのデータ形式
第一正規形
1つのセルには1つの値の原則を満たせば第一正規形
1つのセルに複数の値を入れることがRDBで認められない理由は、
複数セルを許すことで主キーが各列の値を一意に決定できないためです
（↓第一正規形）
問題点1
- 主キーを決めることが出来ない
- 一意のレコードが特定出来ない
- レコードを特定するには、
ユーザーid、名前、子全ての情報が必要 - 主キーはその列の一部のため、吉田さんの子は
NULLなので一意にはならないので×
問題点2
- ユーザーと、扶養者の2つのエンティティを含んでいる
- テーブルの意味やレコードの単位が理解できない
修正後
ユーザーと、子どもで分けました
関数従属性を満たすことが出来ました。
関数従属性とは、どんな関数でもXが決まれば、Yが決まる性質
社員ID → 社員
社員ID → 子1
社員ID → 子2
社員ID → 子3
第二正規形
第二正規形とは、
部分関数従属を解消して、完全関数従属のみのテーブルを作ること
部分関数従属とは、主キーの一部の列に対して従属関係があること
完全関数従属とは、主キーを構成する全ての列に対して従属関係があること
こちらのテーブルは第二正規形ではありません。
理由は、完全関数従属では無いからです。
こちらのテーブルでは主キーは、食べ物種別コードと食べ物idの二つがあります
食べ物種別コードは、食べ物種別に従属しています
主キーの一部の列に対して従属関係があるので、部分関数従属になります
第二正規化すると
第二正規化にする意味
第二正規化する前のテーブルに対して、食べ物は無いですが食べ物種別として、中華を追加しようとしたとします。
しない場合のデメリットとしては、
- 主キーである食べ物idをNULLにできないので、何かしらのダミー値を登録する必要があります
- また、想定外のデータを登録してしまう可能性があります
-
{4, 中華}と登録するつもりが、ある特定のレコードだけ{4, China}と登録してしまうかもしれません - アプリケーション側でチェックはできるものの、DBに直接挿入されれば対処出来ません
-
第三正規形
生産地コードと、生産地にフォーカスを当てます。
仮に、生産地に愛知が増えたとして登録しようとしたとき。
新しく生産地ができただけで実際に生産された食べ物が存在しない場合、主キーである食べ物コードと食べ物idは空になるため登録できません
また、テーブル内には関数従属性が存在します（生産地コード → 生産地)
仮に、生産地が食べ物に対して1:1の場合、
食べ物種別コード、食べ物id → 生産地コードとなり、
全体としては、
食べ物種別コード、食べ物id → 生産地コード → 生産地
の2段階の関数従属が存在します
このような従属性を推移的関数従属性と言い、正規化されていないことになります
第三正規化を行う
