正規化

正規化，設計的越詳細，對於某些實際操作可能更好，但是不一定都是好處，在實際應用中，應當具體情況具體分析

資料依賴

資料依賴有三種類型

函式依賴

設R(U)是一個屬性集U上的關係模式，X和Y是U的子集，若對於R(U)的任意一個可能的關係r，r中不可能存在兩個元組在X上的屬性值相等，而在Y上的屬性值不等
則稱“X函式確定Y”或“Y函式依賴於X”，記作X→Y，X成為這個函式依賴的決定屬性集

例：每個學校對應一個校長，當學校確定時，校長也確定了，則稱“學校確定校長”，或者“校長依賴於學校”，記作學校→校長

平凡函式依賴

如果X→Y，但是X不屬於Y，則稱X→Y是非平凡的函式依賴
如果X→Y，但是X屬於Y，則稱X→Y是平凡的函式依賴

例：（學號，課程號）→ 成績 是非平凡函式依賴
（學號，課程號）→ 學號 是平凡函式依賴
（學號，課程號）→ 課程號 是平凡函式依賴

完全函式依賴

如果單獨一個函式能決定一個依賴，則稱該依賴為完全函式依賴，如果一個函式的部分可以決定一個依賴，則稱該依賴為部分函式依賴

例：學號→姓名 完全函式依賴
（學號，課程號）→ 姓名 部分函式依賴（學號自己就能決定姓名）
（學號，課程號）→ 成績 完全函式依賴（由學號和課程號共同決定成績）

傳遞函式依賴

如果X→Y，Y→Z，且Y不屬於X，Y不決定X，則稱Z傳遞函式依賴於X
如果Y→X，即X←→Y，則Z直接依賴於X

第一正規化(1NF)

資料表中的欄位都是不可分割的原子值

例如：中國四川省成都市武侯區武侯大道100號
這個地址可以拆分為國家、省、市等資訊，不滿足第一正規化的不可分割的要求，因此這個地址不滿足第一正規化

第二正規化(2NF)

必須在滿足第一正規化的前提下，第二正規化要求，除主鍵外的每一列都必須完全依賴於主鍵
如果要出現不完全依賴，只可能發生在聯合主鍵的情況下
通俗來說，主鍵必須能決定其他列（例：學校決定校長）

當出現除主鍵外的其他列，只依賴於主鍵的部分欄位時，將不滿足第二正規化
此時可以拆表

例：新建一個訂單表

這個表使用了聯合主鍵（product_id,customer_id），但是product_name於customer都部分依賴於主鍵，因此不滿足第二正規化，此時應該將這個表拆開

create table myorder(
order_id int primary key,
product_id int,
customer_id int
);

create table product(
id int primary key,
name varchar(20)
);

create table customer(
id int primary key,
name varchar(20)
);

第三正規化(3NF)

必須先滿足第二正規化，除開主鍵列的其他列之間不能有傳遞依賴關係

例：
create table myorder(
order_id int primary key,
product_id int,
customer_id int,
customer_phone varchar(15)
);

在這個例子中，customer_phone這個屬性就和customer_id、order_id之間存在傳遞依賴，因此不滿足第三正規化

應該將上述例子拆分

create table myorder(
order_id int primary key,
product_id int,
customer_id int
);
create teble customer(
id int primary key,
name varchar(20),
phone varchar(15)
);

這樣才滿足第三正規化