設(shè)計(jì)數(shù)據(jù)庫的步驟
1.需求分析階段:分析客戶的業(yè)務(wù)和數(shù)據(jù)處理需求.
2.概要設(shè)計(jì)階段:主要就是繪制數(shù)據(jù)庫的E-R圖.
3.詳細(xì)設(shè)計(jì)階段:應(yīng)用數(shù)據(jù)庫的三大范式進(jìn)行審核數(shù)據(jù)庫的結(jié)構(gòu).
總結(jié):在進(jìn)行數(shù)據(jù)庫的系統(tǒng)分析時(shí),都以下列4點(diǎn)為參考的基本步驟.
01.收集信息.
02.標(biāo)識(shí)實(shí)體.
03.標(biāo)識(shí)每個(gè)實(shí)體需要儲(chǔ)存的詳細(xì)信息.
04.標(biāo)識(shí)實(shí)體之間的關(guān)系.
示例：
某酒店管理系統(tǒng)E-R圖：
數(shù)據(jù)模型圖：
掌握關(guān)系型數(shù)據(jù)庫的三大范式
1.第一范式:
目標(biāo)是確保每列的原子性.如果每列都是不可再分的最小數(shù)據(jù)單元,則滿足第一范式.
第一范式（1NF）：要求數(shù)據(jù)庫表的每一列都是不可分割的原子數(shù)據(jù)項(xiàng)。
舉例說明：
在上面的表中，“家庭信息”和“學(xué)校信息”列均不滿足原子性的要求，故不滿足第一范式，調(diào)整如下：
可見，調(diào)整后的每一列都是不可再分的，因此滿足第一范式（1NF）；
2.第二范式:
第二范式在第一范式的基礎(chǔ)上更進(jìn)一層,其目標(biāo)是確保表中的每列都和主鍵相關(guān),也就是說在一個(gè)數(shù)據(jù)庫表中，一個(gè)表中只能保存一種數(shù)據(jù)，不可以把多種數(shù)據(jù)保存在同一張數(shù)據(jù)庫表中.如果一個(gè)關(guān)系滿足第一范式,并且除了主鍵以外的其他列都依賴于該主鍵.則滿足第二范式.
第二范式需要確保數(shù)據(jù)庫表中的每一列都和主鍵相關(guān)，而不能只與主鍵的某一部分相關(guān)（主要針對(duì)聯(lián)合主鍵而言）。
舉例說明：
在上圖所示的情況中，同一個(gè)訂單中可能包含不同的產(chǎn)品，因此主鍵必須是“訂單號(hào)”和“產(chǎn)品號(hào)”聯(lián)合組成，
但可以發(fā)現(xiàn)，產(chǎn)品數(shù)量、產(chǎn)品折扣、產(chǎn)品價(jià)格與“訂單號(hào)”和“產(chǎn)品號(hào)”都相關(guān)，但是訂單金額和訂單時(shí)間僅與“訂單號(hào)”相關(guān)，與“產(chǎn)品號(hào)”無關(guān)，
這樣就不滿足第二范式的要求，調(diào)整如下，需分成兩個(gè)表：
3.第三范式:
第三范式在第二范式的基礎(chǔ)上更進(jìn)一層,第三范式的目標(biāo)是確保每列都和主鍵列直接相關(guān),而不是間接相關(guān).如果一個(gè)關(guān)系滿足第二范式,并且除了主鍵以外的其他列都這能依賴于主鍵列,列和列之間不存在相互依賴關(guān)系,則滿足第三范式。
第三范式需要確保數(shù)據(jù)表中的每一列數(shù)據(jù)都和主鍵直接相關(guān)，而不能間接相關(guān)。
舉例說明：
上表中，所有屬性都完全依賴于學(xué)號(hào)，所以滿足第二范式，但是“班主任性別”和“班主任年齡”直接依賴的是“班主任姓名”，
而不是主鍵“學(xué)號(hào)”，所以需做如下調(diào)整：
這樣以來，就滿足了第三范式的要求。
注: 把上表中的班主任姓名改成班主任教工號(hào)可能更確切，更符合實(shí)際情況，不過只要能理解就行。
注意事項(xiàng)：
1.必須先滿足第一范式才能滿足第二范式，必須同時(shí)滿足第一第二范式才能滿足第三范式。
三大范式只是一般設(shè)計(jì)數(shù)據(jù)庫的基本理念，可以建立冗余較小、結(jié)構(gòu)合理的數(shù)據(jù)庫。如果有特殊情況，當(dāng)然要特殊對(duì)待，數(shù)據(jù)庫設(shè)計(jì)最重要的是看需求跟性能，需求>性能>表結(jié)構(gòu)。所以不能一味的去追求范式建立數(shù)據(jù)庫。
總結(jié)：
第1范式：每個(gè)表中都有1列，并且該列是不可拆分的最小單元（強(qiáng)調(diào)的是列的原子性，即列不能夠再分成其他幾列）
第2范式：1張表只描述一件事情（非主鍵列是否完全依賴于主鍵，還是依賴于主鍵的一部分）
第3范式：用外鍵做表的關(guān)聯(lián)（非主鍵列是直接依賴于主鍵，還是直接依賴于非主鍵列）
4. BCNF范式：在第三范式的基礎(chǔ)上消除主屬性對(duì)于主鍵的部分與傳遞函數(shù)依賴。
要了解 BCNF 范式，那么先看這樣一個(gè)例子：
假如：
某公司有若干個(gè)倉庫；
每個(gè)倉庫只能有一名管理員，一名管理員只能在一個(gè)倉庫中工作；
一個(gè)倉庫中可以存放多種物品，一種物品也可以存放在不同的倉庫中。每種物品在每個(gè)倉庫中都有對(duì)應(yīng)的數(shù)量。
那么關(guān)系模式 倉庫（倉庫名，管理員，物品名，數(shù)量） 屬于哪一級(jí)范式？
答：已知函數(shù)依賴集：倉庫名 → 管理員，管理員 → 倉庫名，（倉庫名，物品名）→ 數(shù)量
鍵值：（管理員，物品名），（倉庫名，物品名）
主屬性：倉庫名、管理員、物品名
非主屬性：數(shù)量
因?yàn)椴淮嬖诜侵鲗傩詫?duì)碼的部分函數(shù)依賴和傳遞函數(shù)依賴，所以， 此關(guān)系模式屬于3NF。
基于此關(guān)系模式的關(guān)系（具體的數(shù)據(jù)）可能如圖所示：
既然此關(guān)系模式已經(jīng)屬于了 3NF，那么這個(gè)關(guān)系模式是否存在問題呢？我們來看以下幾種操作：
先新增加一個(gè)倉庫，但尚未存放任何物品，是否可以為該倉庫指派管理員？——不可以，因?yàn)槲锲访彩侵鲗傩?，根?jù)實(shí)體完整性的要求，主屬性不能為空。
某倉庫被清空后，需要?jiǎng)h除所有與這個(gè)倉庫相關(guān)的物品存放記錄，會(huì)帶來什么問題？——倉庫本身與管理員的信息也被隨之刪除了。
如果某倉庫更換了管理員，會(huì)帶來什么問題？——這個(gè)倉庫有幾條物品存放記錄，就要修改多少次管理員信息。
從這里我們可以得出結(jié)論，在某些特殊情況下，即使關(guān)系模式符合 3NF 的要求，仍然存在著插入異常，修改異常與刪除異常的問題，仍然不是 ”好“ 的設(shè)計(jì)。
造成此問題的原因：存在著主屬性對(duì)于碼的部分函數(shù)依賴與傳遞函數(shù)依賴。（在此例中就是存在主屬性【倉庫名】對(duì)于碼【（管理員，物品名）】的部分函數(shù)依賴。
解決辦法就是要在 3NF 的基礎(chǔ)上消除主屬性對(duì)于碼的部分與傳遞函數(shù)依賴。
倉庫（倉庫名，管理員）
庫存（倉庫名，物品名，數(shù)量）
這樣，之前的插入異常，修改異常與刪除異常的問題就被解決了。
數(shù)據(jù)庫規(guī)范性和性能的關(guān)系
為了滿足三大范式,我們的數(shù)據(jù)操作性能會(huì)受到相應(yīng)的影響,所以,在實(shí)際的數(shù)據(jù)庫設(shè)計(jì)中,既要考慮三大范式,避免數(shù)據(jù)的冗余和各種數(shù)據(jù)操作異常;又要考慮到數(shù)據(jù)訪問性能,有時(shí),為了減少表間連接,提高數(shù)據(jù)庫的訪問性能,允許適當(dāng)?shù)臄?shù)據(jù)冗余列,這才是最合適的數(shù)據(jù)庫設(shè)計(jì)方案。規(guī)范化的優(yōu)點(diǎn)是明顯的，它避免了大量的數(shù)據(jù)冗余，節(jié)省了存儲(chǔ)空間，保持了數(shù)據(jù)的一致性。當(dāng)一個(gè)庫里的數(shù)據(jù)經(jīng)常發(fā)生變化時(shí)，達(dá)到3NF的庫可以使用戶不必在超過兩個(gè)以上的地方更改同一個(gè)值。那么是不是只要把所有的表都規(guī)范為3NF后，數(shù)據(jù)庫的設(shè)計(jì)就是最優(yōu)的呢?這可不一定。范式越高意味著表的劃分更細(xì)，一個(gè)數(shù)據(jù)庫中需要的表也就越多，用戶不得不將原本相關(guān)聯(lián)的數(shù)據(jù)分?jǐn)偟蕉鄠€(gè)表中。當(dāng)用戶同時(shí)需要這些數(shù)據(jù)時(shí)只能采用連接表的形式將數(shù)據(jù)重新合并在一起。同時(shí)把多個(gè)表連接在一起的花費(fèi)是巨大的，尤其是當(dāng)需要連接的兩張或者多張表數(shù)據(jù)非常龐大的時(shí)候，表連接操作幾乎是一個(gè)噩夢，這將會(huì)嚴(yán)重地降低系統(tǒng)運(yùn)行性能。
參考材料：
鏈接：https://www.zhihu.com/question/24696366/answer/29189700
來源：知乎
