• カスケード
  参照先のテーブルが変更されたり、削除された場合に参照元のテーブルのレコードを削除または更新すること

わからん、主キーと似てる？

一意制約 　一意制約は、ある列の組について一意性を求める制約です。その点で、主キーと似ていますが、主キーがテーブル一つにつき一つしか設定できないのに対し、一意制約は何個でも設定できます。

重複を許さないってだけか

id は主キー：→ 絶対に重複もNULLもダメ
email と phone は一意制約：→ 重複はダメだがNULLはOK

なんと...

実務での論理設計において本当に頭を悩ませることになるのは、一通りの正規化が「終わった後」なのだ、ということが、後続の章を読むとわかってきます。

正規化（１〜５）

第1正規化

第1正規化（1NF）において満たすべき要件は以下の通り。

• 各列の値はスカラ値（単一の値）であること
• 列（カラム）はすべて同じデータ型の値を持つこと
• すべての行と列の交差部分に、原子性（Atomicity）があること
• 各行は一意に識別できる（主キーが存在する）

つまり

1. 1つのセルに 複数の値を詰め込まない！
2. 列の中は すべて同じ種類のデータで統一！
3. 各行が一意に特定できるようにしておく！

---

確かに、バシッと端的に答えられなさそう

なぜ、一つのセルに複数の値を入れることがリレーショナルデータベースでは認められないか、その理由を端的に言うと、セルに複数の値を許せば、主キーが各列の値を一意に特定できないから。

第2正規化

• 第1正規化（1NF）を満たしていること
• 主キーの一部にのみ依存している列（部分関数従属）を排除すること

書籍の以下の例は会社名を切り出してるけど、部署名も切り出せるのでは？

会社コード	会社名	社員ID	社員名	年齢	部署コード	部署名
C0001	A商事	000A	加藤	40	D01	開発
C0001	A商事	000B	藤本	32	D02	人事
C0001	A商事	001F	三島	50	D03	営業
C0002	B化学	000A	斉藤	47	D03	営業
C0002	B化学	009F	田島	25	D01	開発
C0002	B化学	010A	渋谷	33	D04	総務

• 会社名 は 会社コード にのみ依存
• 部署名 は 部署コード にのみ依存
  つまり、複合キーの一部にだけ依存している列（部分関数従属）があるため、第二正規形を満たしていません。

テーブル3つでは？

社員ID	社員名	年齢	会社コード	部署コード
000A	加藤	40	C0001	D01
000B	藤本	32	C0001	D02
001F	三島	50	C0001	D03
000A	斉藤	47	C0002	D03
009F	田島	25	C0002	D01
010A	渋谷	33	C0002	D04

会社コード	会社名
C0001	A商事
C0002	B化学

部署コード	部署名
D01	開発
D02	人事
D03	営業
D04	総務

---

なるほどね

第2正規化というのは、言ってみれば「会社」と「社員」という、それぞれに異なるレベルの実体（エンティティ）を、きちんとテーブルとしても分離してやる作業

第3正規化

ここで、部署テーブルの切り出しが出てきたけど第2正規化でやることじゃないの？

隠れた関係従属性が残っているかららしい

このような不都合が発生する理由は、「社員」テーブルの中に、まだ隠れた関数従属性が残っているからです。
今、明らかにこの二つの列の間には、
　　{部署コード} → {部署名}
という関数従属が成立します。
一方、社員IDと部署コードの間にも、当然のことながら、
　　{会社コード, 社員ID} → {部署コード}
という関数従属が存在しています。つまり、全体としては、
　　{会社コード, 社員ID} → {部署コード} → {部署名}
という二段階の関数従属があるわけです。このように、テーブル内部に存在する段階的な従属関係のことを、推移的関数従属と呼びます。

シビレる。
常識とかを正確に言語化できる能力こそ言語を作った人間の本質なのかも

正規化は常識に過ぎないという理由で批判されてきたが
常識の意味を正確かつ形式的の述べることが偉業である
「常識は、多くの人に広めてこそ常識として価値を持つようになるのだ」と。

だから、そういった言語化された常識を見るのが好きだし感動を覚えるのかも

早くトンデモ設計見たい

とんでもない論理設計を行なう「規格外」の人たちが一定数います。
本書の後半で、そのような「トンデモ設計」の一部を見ることになります。