正規化(設計規範)

2022-08-15 03:27:19 字數 3265 閱讀 4576

正規化:normal format,是一種離散數學中的知識,是為了解決資料的儲存與優化的問題:儲存資料的儲存之後,凡是能夠通過關係尋找出來的資料,堅決不再重複儲存,終極目標是為了減少資料的冗餘。

正規化:是一種分層結構的規範,分為六層,每一層都比上一層更加嚴格,若要滿足下一層正規化,前提是滿足上一層正規化。

六層正規化:1nf,2nf,….6nf。 6nf最高層,最嚴格

mysql屬於關係型資料庫:有空間浪費,與正規化所解決的問題不謀而合:在設計資料庫的時候,會利用到正規化來指導設計。

但是資料庫不單是要解決空間問題,還要保證效率問題。正規化只為解決空間問題,所以資料庫的設計又不可能完全按照正規化的要求實現,一般情況下,只有前三種正規化需要滿足。

正規化在資料庫的設計當中是有指導意義,但是不是強制規範。

第一正規化:在設計表儲存資料的時候,如果表中設計的字段儲存的資料,在取出來使用之前,還需要額外的處理(拆分),那麼說表的設計不滿足第一正規化,第一正規化要求欄位的資料就有原子性:不可再分。

第二正規化:在資料表設計的過程中,如果有復合主鍵(多欄位主鍵),且表中有字段並不是由整個主鍵來確定,而是依賴主鍵中的某個字段(主鍵的部分):存在字段依賴主鍵的部分的問題,稱之為部分依賴,第二正規化就是解決表不允許出現部分依賴。

以上表中:因為講師沒有辦法作為獨立主鍵,需要結合班級才能作為主鍵(復合主鍵:乙個老師在乙個班永遠只能帶一階級的課),代課時間,開始和結束欄位都是與當前代課主鍵(講師和班級),但是性別並不依賴班級,教師並不依賴講師,性別只依賴講師,教師只依賴班級,出現了性別和教師依賴主鍵中的一部分:部份依賴,不符合第二正規化。

解決方案1:可以將性別 與講師單獨成表,班級與教室單獨成表

解決方案2:取消復合主鍵,使用邏輯主鍵。

要滿足第三正規化,必須滿足第二正規化。

第三正規化:理論上講,應該一張表中的所有欄位都應該直接依賴主鍵,如果表設計中存在乙個字段,並不直接依賴主鍵,而是通過某個非主鍵字段依賴,最終實現依賴主鍵,把這種不是直接依賴主鍵,而是依賴非主鍵欄位的依賴關係稱之為傳遞依賴。第三正規化就是要解決傳遞依賴的問題

講師帶課表

以上設計方案中,性別依賴講師存在,講師依賴主鍵,教室依賴班級,班級依賴主鍵,性別和教室都存在傳遞依賴。

解決方案:將存在傳遞依賴的字段以及依賴的字段本身單獨取出,形成乙個單獨的表,然後在需要對應資訊的時候,使用對應的實體表的主鍵加進來。

講師帶課表

講師表   id=講師   主鍵是講師  而不是邏輯主鍵(具有傳遞依賴)

班級表   id=班級   主鍵是班級  而不是邏輯主鍵(具有傳遞依賴)

有時候,在設計表的時候,如果一張表中有幾個字段需要從另外的表中去獲取資訊,理論上講,的確可以獲得想要的資料,但是效率低一點,會刻意的在某些表中,不去儲存另外表的主鍵,而是直接儲存想要的資料資訊,這樣一來,在查詢資料的時候,一張表可以直接提供資料,而不需要多表查詢((效率低),但是冗餘會增加

逆規範化:磁碟利用率與效率的對抗。

正規化:normal format,是一種離散數學中的知識,是為了解決資料的儲存與優化的問題:儲存資料的儲存之後,凡是能夠通過關係尋找出來的資料,堅決不再重複儲存,終極目標是為了減少資料的冗餘。

正規化:是一種分層結構的規範,分為六層,每一層都比上一層更加嚴格,若要滿足下一層正規化,前提是滿足上一層正規化。

六層正規化:1nf,2nf,….6nf。 6nf最高層,最嚴格

mysql屬於關係型資料庫:有空間浪費,與正規化所解決的問題不謀而合:在設計資料庫的時候,會利用到正規化來指導設計。

但是資料庫不單是要解決空間問題,還要保證效率問題。正規化只為解決空間問題,所以資料庫的設計又不可能完全按照正規化的要求實現,一般情況下,只有前三種正規化需要滿足。

正規化在資料庫的設計當中是有指導意義,但是不是強制規範。

第一正規化:在設計表儲存資料的時候,如果表中設計的字段儲存的資料,在取出來使用之前,還需要額外的處理(拆分),那麼說表的設計不滿足第一正規化,第一正規化要求欄位的資料就有原子性:不可再分。

第二正規化:在資料表設計的過程中,如果有復合主鍵(多欄位主鍵),且表中有字段並不是由整個主鍵來確定,而是依賴主鍵中的某個字段(主鍵的部分):存在字段依賴主鍵的部分的問題,稱之為部分依賴,第二正規化就是解決表不允許出現部分依賴。

以上表中:因為講師沒有辦法作為獨立主鍵,需要結合班級才能作為主鍵(復合主鍵:乙個老師在乙個班永遠只能帶一階級的課),代課時間,開始和結束欄位都是與當前代課主鍵(講師和班級),但是性別並不依賴班級,教師並不依賴講師,性別只依賴講師,教師只依賴班級,出現了性別和教師依賴主鍵中的一部分:部份依賴,不符合第二正規化。

解決方案1:可以將性別 與講師單獨成表,班級與教室單獨成表

解決方案2:取消復合主鍵,使用邏輯主鍵。

要滿足第三正規化,必須滿足第二正規化。

第三正規化:理論上講,應該一張表中的所有欄位都應該直接依賴主鍵,如果表設計中存在乙個字段,並不直接依賴主鍵,而是通過某個非主鍵字段依賴,最終實現依賴主鍵,把這種不是直接依賴主鍵,而是依賴非主鍵欄位的依賴關係稱之為傳遞依賴。第三正規化就是要解決傳遞依賴的問題

講師帶課表

以上設計方案中,性別依賴講師存在,講師依賴主鍵,教室依賴班級,班級依賴主鍵,性別和教室都存在傳遞依賴。

解決方案:將存在傳遞依賴的字段以及依賴的字段本身單獨取出,形成乙個單獨的表,然後在需要對應資訊的時候,使用對應的實體表的主鍵加進來。

講師帶課表

講師表   id=講師   主鍵是講師  而不是邏輯主鍵(具有傳遞依賴)

班級表   id=班級   主鍵是班級  而不是邏輯主鍵(具有傳遞依賴)

有時候,在設計表的時候,如果一張表中有幾個字段需要從另外的表中去獲取資訊,理論上講,的確可以獲得想要的資料,但是效率低一點,會刻意的在某些表中,不去儲存另外表的主鍵,而是直接儲存想要的資料資訊,這樣一來,在查詢資料的時候,一張表可以直接提供資料,而不需要多表查詢((效率低),但是冗餘會增加

逆規範化:磁碟利用率與效率的對抗。

UI設計規範

以使用者為中心。設計由使用者控制的介面,而不是介面控制使用者。清楚一致的設計。所有介面的風格保持一致,所有具有相同含義的術語保持一致,且易於理解 較快的響應速度。簡單且美觀。使用者介面設計的乙個重要原則是使用者應該總是感覺在控制軟體而不是感覺被軟體所控制。操作上假設是使用者 而不是計算機或軟體 開始...

硬體設計規範

1 硬體需求說明書 2 硬體總體設計報告 3 單板硬體總體設計方案 4 單板硬體詳細設計 5 單板硬體過程除錯文件 6 單板硬體系統除錯報告 7 單板硬體測試文件 8 硬體總體方案歸檔詳細文件 9 硬體單板總體方案歸檔詳細文件 10 硬體資訊庫 2.2.2 硬體開發文件編制規範詳解 1 硬體需求說明...

Mysql設計規範

資料庫命名規範 1 所有資料庫物件名稱必須使用小寫字母並用下劃線分割。2 所有資料庫物件名稱禁止使用mysql保留關鍵字 3 資料庫物件的命名要能做到見名識義,並且最好不要超過32個字元。4 臨時表必須以tmp為字首並以日期為字尾。5 備份庫,備份表必須以bak為字首並以日期為字尾。6 所有儲存相同...