數據庫邏輯設計

數據庫設計

數據庫設計包含需求設計、邏輯設計、物理設計和維護優化。數據庫

  • 需求分析:全面瞭解產品設計的存儲需求(存儲需求,數據處理需求,數據的安全性和完整性)
  • 邏輯設計:設計數據的邏輯存儲結構(數據實體之間的邏輯關係,解決數據冗餘和數據維護異常 )
  • 物理設計:根據所使用的數據庫特色進行表結構設計
  • 維護優化:根據實際狀況對索引、存儲結構等進行優化

數據庫結構優化的目的

  • 減小數據冗餘
  • 儘可能你變數據維護中出現更新,插入和刪除異常
  • 簡約數據庫的存儲空間
  • 提升查詢效率

爲了設計出沒有數據冗餘和數據維護異常的數據結構,咱們須要遵循如下規範:安全

  • 第一範式
  1. 數據庫表中的全部字段都只有單一屬性
  2. 單一屬性的列都是由基本的數據類型所構成
  3. 設計出來的表都是簡單的二維表
  • 第二範式 要求一個表中只具備一個業務主鍵,也就是說符合第二範式的表中不能存在非主鍵列對只對部分主鍵的依賴關係。以學生選課爲例,它的主鍵是複合主鍵(學生編號,課程),而學分只依賴於課程,即非主鍵列只對部分主鍵存在依賴關係,不符合第二範式。
    image.png

針對這個問題,咱們怎麼破呢?咱們對上面這個表拆分爲3個表:學生表、課程表、學生課程關係表。其中,學生表和課程表只有一個主鍵,而學生課程關係表有一個複合主鍵(學生編號,課程),分數徹底依賴於這個複合主鍵,所以符合第二範式。 bash

image.png

image.png

image.png

第三範式

每個非主屬性既不部分依賴於也不傳遞依賴於業務主鍵,也就是在第二範式的基礎上消除了非主屬性對主鍵的傳遞依賴。 對於學生表,學院依賴於學生編號,而學院地址卻依賴於學院,這就是傳遞依賴,此時,這張表不知足第三範式。若是想讓這張表知足第三範式就須要繼續對這張表進行拆分。 微信

image.png
image.png

反範式化

遵循範式化的數據庫設計,實現了消除數據冗餘的目的,可是此時數據庫的性能和讀取效率並非最優的。爲了性能和讀取效率的考慮而適當的對數據庫設計範式的要求進行違反,而容許存在少許的數據冗餘,換句話來講反範式化就是使用空間來換取時間。 舉個栗子,以咱們常常進行下單爲例。根據範式準則,定單表和訂單商品關聯表以下:數據結構

訂單表:{訂單編號,下單用戶名,下單日期,支付金額,物流單號}
訂單商品關聯表:{訂單編號,訂單商品分類,訂單商品名,商品數量}
複製代碼

咱們知道查詢訂單時,每每須要知道用戶名稱和用戶手機號,那麼,此時咱們就須要將訂單表和用戶表進行關聯查詢。這種設計存在一個問題,當用戶修改手機號,那麼用舊手機號買的訂單號的手機信息是新的手機號,而不是舊手機號,這是不符合業務需求的。解決這個問題的辦法就是將用戶名和用戶手機號加入到訂單表中。一樣狀況,商品的價格也存在修改的狀況,所以,也須要將支付金額加入到訂單表中,此時,訂單表和訂單商品關聯表以下:數據庫設計

訂單表:{訂單編號,下單用戶名,下單日期,支付金額,物流單號,訂單金額}
訂單商品關聯表:{訂單編號,訂單商品分類,訂單商品名,商品數量,商品單價}

複製代碼

總結

  • 範式化設計能夠儘可能的減小數據冗餘,更新操做比反範式化更快,可是對於查詢須要對多個表進行關聯,更難進行索引優化。
  • 反範式化設計能夠減小表的關聯(順序IO),能夠更好的進行索引優化,可是存在數據冗餘及數據維護異常,對數據的修改須要更多的成本(須要修改多個地方)。 所以,咱們須要結合反範式化和範式化,設計出高性能數據庫結構。

image

歡迎關注微信公衆號:木可大大,全部文章都將同步在公衆號上。性能

相關文章
相關標籤/搜索