1. 程式人生 > >數據庫設計---入門

數據庫設計---入門

cells width 導致 標識 屬於 原因 image 表結構 數據庫設計

1. 數據庫設計的概述

1.1. 數據庫設計是什麽

  所謂的數據庫設計就是根據需求文檔的描述將需求轉成數據庫的存儲結構的過程.

  在數據庫設計的流程上,我們通常根據需求,畫出數據的ER圖.然後在通過ER圖生成數據庫的建庫腳本.(Entity Relational)

ER圖,所謂的ER圖就是數據庫關系圖

為什麽我們使用ER圖來實現數據庫設計的設計呢?

1.可見即可得.使用ER圖可以通過圖形的方式展示表與表直接的關系

2.可以根據設置的數據庫,方便生成不同的數據庫的SQL建庫腳本

3.可以快速的生成數據庫文檔

1.2. 為什麽需要數據庫設計

軟件開發都是分別從頁面設計和數據庫設計開始的.

創建項目的數據庫是項目開發必須的階段.

2. 數據庫設計基礎理論(重點)

2.1. 數據庫設計的步驟

數據庫設計的步驟是根據需求的描述:

第一步:標識表

第二步:標識表的字段

第三步:標識表與表之間的關系

2.2. 標識表註意事項

我們在標識表的時候,可以將表分為實體表和業務表.

所謂的實體表:就是記錄需求中描述為一個對象(名詞)的表.如:用戶,商品,訂單,管理員,角色等

所謂的業務表:就是記錄在需求中描述為一個業務行為的表:收藏,關註,等 (大部分是中間表)

雖然沒有強制的規定先標識實體表還是業務表,但我們通常在標識表時會先標識實體表,再標識業務表.

因為業務表一般是用於標識實體表與另一個實體的多對多的關系的.

2.3. 標識字段註意事項

標識字段,在數據庫設計中,盡量符合數據庫設計的三大範式原則.

--三大範式,就是用於數據庫設計,標識字段的時候使用的!!!。

2.3.1. 三大範式

1.第一範式:確保標識的字段的原子性,字段的概念分得不能再分。如:姓名可以分為姓和名。

--所謂的概述分的不能再分,就是說這個概念會在出現兩種以上的情況的了。因為,姓名,中國人的姓名是 :姓+名,外國有些國家:名 + 姓。意味著姓名這個概念有兩種情況,所以可以在分成姓和名。所以違反三大範式!!

2.第二範式:確保標識的字段與表有依賴的關系,在用戶表定義一個商品價格

--所謂的字段與表有依賴關系,必須字段是表概述的屬性。 表概念的XXX

3.第三方範式:確保標識的字段與表有直接依賴的關系,用戶表,用戶類型的名稱

數學上:A依賴B,B依賴於C,我們認為A依賴於C。但在數據庫設計裏面,如果出現這種情況就違反了第三範式了!

三大範式解決了什麽問題呢?

使用三大範式的原則標識的數據庫字段,保證了字段在數據庫表中的唯一性.從而避免了數據庫的數據的冗余.

--user表

技術分享圖片

--usertype表

技術分享圖片

--需求查詢用戶以及類型,程序員不知道以哪個類型字段為準!!

技術分享圖片

數據冗余會導致,數據增刪改查都有可能出現數據異常

是否數據庫字段的標識就一定要完成符合三大範式呢?

其實數據庫設計,只是為了不要出現過多的數據庫冗余的數據,建議盡量在數據庫設計的時候符合三大範式..

但在系統實現中:根據性能的要求和業務邏輯的要求,是可以出現少量的數據冗余的。但記得在數據庫設計文檔說明原因!!!

2.3.2. 示例-性能的要求出現的冗余數據

我們很多系統都要記錄日誌.而日誌裏面,必須要包括用戶的信息.如果嚴格按照三大方式.日誌的用戶信息必須是從用戶表中獲得,日誌每天都會出現巨量的數據。如果關聯用戶表查詢,整理日誌,會導致用戶表的訪問大大被拖慢。

所以,我們會將用戶的信息直接寫在日誌表裏面。在日誌表中寫用戶的的信息,明顯違反了第二範式,基於查詢的性能的需要,一般日誌表的用戶信息是冗余。

2.3.3. 示例-業務邏輯的要求出現的冗余數據

我們在訂單中有一個商品的價格.而這個商品的價格直接就是訂單的字段.並不是商品表裏面商品的價格.明顯違反了第三範式.

但業務上,由於訂單的商品的價格不能隨著著商家修改了商品價格而修改.所以像這種需求下,必須要給訂單表一個冗余的商品價格字段。

2.4. 標識表與表之間的關系

2.4.1. 表與表之間的關系

表與表之間的關系包括有:

1.一對一

2.一對多

3.多對一

4.多對多

數據庫表與表的關系,就是也需求描述的從屬關系。

問題:表與表之間的關系,是誰決定的?

答:需求決定的!!!

如: 板塊與版主的關系是什麽?

答:表與表之間的關系是由需求的決定的。板塊與版主的關系,在沒有確定需求之前是無法確定的。

技術分享圖片

2.4.2. 一對一

  一對一的關系,一般出現在,主表和從表之間記錄是一一對應的情況。

  如再設計中,有一個學生表和學生身份表,需求上一個學生只有一個身份。意味著一個學生對應一個身份,所以是一對一關系。

技術分享圖片

  當兩個表的關系是一對一的時候,外鍵可以在兩個表的任何一方都可以實現連接表找到對應的數據.但是實際設計中一般遵守現實邏輯中的從屬關系來定表的從屬關系..

  如: 用戶表和用戶詳細信息表的關系是一對一的關系. 現實邏輯中,我們認為用戶的信息是屬於用戶的. 所以用戶表為主表, 用戶信息是外鍵表.

  一對一的表設計特征:外鍵表的主鍵就是關聯表的外鍵!外鍵表的主鍵和外鍵是重疊的!!

2.4.3. 一對多/多對一

  兩個表的一對多的關系:

  主鍵表為一的一方,外鍵表為多的一方.

  表的主從關系是通過由需求本身決定的.

技術分享圖片

2.4.4. 多對多

  表的多對多的關系,在關系型數據庫中,表是不支持一個字段存儲一個集合的值的。

  所以關系型數據庫本身表之間是沒有多對多的關系的,多對多的關系是業務邏輯的要求。

  數據庫設計遇到表之間多對多的關系會使用是一個中間表來記錄兩個表多對多的關系.

  註意:如果遇到多對多,必須拆分一個中間表!!!!

3. 小結(重點)

  1. 數據庫設計就是建立項目的表結構
  2. 基於數據的復雜性,一般數據庫數據庫是先畫ER圖的。
  3. 數據庫設計的步驟是:標識表,標識字段,標識表與表之間關系

  標識表,先標識實體表,在標識業務表

  實體表(名詞,沒有行為)

  業務表(包括業務動作,一般就是一個中間表)

  標識字段,必須要求理解三大範式

  為什麽需要三大範式,避免數據的冗余,導致數據的異常。

  數據庫設計總體上要符合三大範式,但是基於業務需求和性能要求,有時候可以有少許的冗余

  數據設計冗余,設計者必須要說明原因

  標識表與表之間的關系

  1. 有哪些表與表之間關系,一對多,多對一,一對一,多對多
  2. 表與表之間的關系是由需求決定,討論表之間的關系前,必須要先確定需求
  3. 關系數據庫是不能直接支持多對多的業務關系的,如果出現多對多必須要拆分一個中間表,原因是數據庫裏面的字段不能存儲一個集合數據。

數據庫設計---入門