剖析資料庫設計三範式

文章目錄

• 第一範式（1NF）：就是能分就分，分到不能分為止（所有欄位值都是不可分解的原子值）
• 第二範式（2NF）：要求實體的屬性完全依賴於主關鍵字（函數不能部分依賴）。

概要 

     早就聽說三範式了,記得第一次做機房收費系統的時候,只是為了簡單的完成資料的增刪改查,並沒有去想資料庫如何設計,現在不同了,第二遍設計資料庫,要求提高了嘛，我們需要的是根據需求來更加合理的設計資料庫,要遵循資料庫的基本原則三範式,三範式剛開始聽起來覺得懵懂,後來通過學習漸漸的明朗起來,首先介紹一下三範式的大致內容:

三範式的目的

     為了建立合理結構的資料庫，減少資料冗餘，設計資料庫必須要遵循一定的規則，在關係型資料庫中這種規則叫做範式，想設計一個結構合理的關係型資料庫，必須要滿足一定的範式，我們把一個項目中用到的資料庫分別建立多個表並建立表中間的關係，可以消除很多錯誤或者垃圾資料並減少我們的工作量、減少資料的不完整性，是資料庫設計的更加規範。

詳細剖析

 

     範式達到五個，但是對於我們來說，三個範式已經很高了，（後期再逐漸的深入學習）

 

第一範式（1NF）：就是能分就分，分到不能分為止（所有欄位值都是不可分解的原子值）

    第一範式（1NF），（一個欄位不能包含多個列，即每個列和記錄包含一個僅包含一個值的表）在任何一個關聯式資料庫中，第一範式（1NF）是對關係模式的基本要求，不滿足第一範式（1NF）的資料庫就不是關聯式資料庫。

    所謂第一範式（1NF）是指資料庫表的每一列都是不可分割的基本資料項目，同一列中不能有多個值，即實體中的某個屬性不能有多個值或者不能有重複的屬性。如果出現重複的屬性，就可能需要定義一個新的實體，新的實體由重複的屬性構成，新實體與原實體之間為一對多關聯性。 第一範式的合理遵循需要根據系統的實際需求來定

例如：執行個體1

    不滿足第一範式，學院、年級、班都是還可以再往下分的

 

 

改進後：

 

第二範式（2NF）：要求實體的屬性完全依賴於主關鍵字（函數不能部分依賴）。

 

    第二範式在第一範式的基礎上，要保證資料庫表中的每一列都和主鍵相關，完全依賴主鍵，所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性，如果存在，那麼這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體，新實體與原實體之間是一對多的關係。為實現區分通常需要為表加上一個列，以儲存各個執行個體的唯一標識。簡而言之，第二範式就是非主屬性非部分依賴於主關鍵字（一種表只能儲存一種資料，不可以把多種資料儲存在同一張資料庫表中）

    對於自己第一遍的機房收費系統資料庫學生資訊表，當時就是為了表減少,調用方便現在現在看起來很是冗餘。例如：

 

 

根據第二範式的要求修改後為資訊基本資料表和卡資訊表

 

學生基本資料表：

卡資訊表：

 

每個表建立了資料自己表的主鍵，其他欄位完全依賴於主鍵而存在，在這兩個表之間我們建立了外鍵的約束關係。顯得很是清晰：

 

3．第三範式3NF：(確保每列都和主鍵列直接相關,而不是間接相關)

第三範式需要確保資料表中的每一列資料都和主鍵直接相關，而不能間接相關，消除欄位冗餘。

 

 

一個UserID依賴於CardID和StudentID，而一個Role依賴於CardID，這就是傳遞依賴間接相關，第三範式就是要消除這種依賴，我們可以改進為：

 

和

 

   

  凡是都有利弊,貴在把握的粒度，由於範式的設計使後期我們的查詢遇到了很大的麻煩，操作困難，例如上下機記錄：學號、卡號、學生姓名等欄位需要從多個資料表中來讀取得需要從多個表調出資料，而且範式越高靈活效能就會越差，到達三個範式就可以了，有利於資料的管理

        

 

總結:

    資料庫的設計範式是資料庫設計所需要滿足的規範，滿足這些規範的資料庫是簡潔的、結構明晰的，同時，不會發生插入（insert）、刪除（delete）和更新（update）操作異常。反之則是亂七八糟，不僅給資料庫的編程人員製造麻煩，而且面目可憎，可能儲存了大量不需要的冗餘資訊。