文章目錄

設計的步驟

② 概念結構設計：E-R圖
③ 邏輯結構設計：將E-R圖轉換為某一種資料模型，並優化。
④ 物理結構設計：選哪種資料庫
⑤ 資料庫實施
⑥ 資料庫維護和優化：建表、索引優化、大表拆分驟

需求分析

1、資料是什麼、有什麼屬性、特點（時效性？核心資料？增長情況？）、哪些屬性或屬性組合可以唯一標識一個實體

使用者模組：資料需要永久儲存、隨時間逐漸增加、是否需要分庫分表？
商品模組：永久儲存，下線商品歸檔儲存
訂單模組：永久儲存、分庫分表
購物車模組：不用永久儲存（設定歸檔、清理規則）
供應商模組：永久儲存

2、實體與實體之間的關係（1對1？1對多？多對多？）

概念結構設計

關係（一個關係對應一張表）、元組（一行）、屬性（一列）、候選碼（唯一確定一個元組的屬性組）、主碼（其中一個候選碼）、主屬性（可以組成候選碼的屬性）、域（屬性取值範圍）、分量（元組中的一個屬性值）

E-R圖：矩形（實體集，上面的資料模組）、菱形（聯絡集（關係名稱），上面實體與實體之間的關係）、橢圓（實體屬性、下劃線標識主碼）

區域性E-R圖設計

1．確定區域性範圍
各個部門或各個主要功能作為區域性
2．確定實體與屬性
① 屬性是不能再分的資料項；
② 聯絡只發生在兩實體之間；
③ 原則上，能夠作為屬性，就不要作為實體。

合併成總體E-R圖

1．消除各區域性E-R圖的衝突問題。
2．按公共實體名合併，生成初步E-R圖。

邏輯結構設計

通過ER圖將需求轉化為資料庫的邏輯模型，與具體的DBMS系統無關

邏輯設計的一些條件

① 冗餘應儘可能少；

多個地方存在或者可以通過某列計算得到

② 應儘可能避免插入、更新、刪除異常；

插入異常（有這個就會有下面兩個）：某實體隨另一個實體的存在而存在，如新開課程沒有學生選修時，新開課程的課程號、課程名插不進去。

更新異常：更改某實體的某一屬性，需要更新多行

刪除異常：刪除某一行資料後，另一個不同實體資訊丟失。

③ 消去關係中不合適的屬性依賴關係。(如選修某門課的學生畢業了，在刪除學生資訊的同時，把課程資訊也刪除掉。)

函式依賴

完全函式依賴：x’是x的真子集，存在x→y，但對每一個x’都有x’!→y，則稱y完全函式依賴於x。如（學號，班級，姓名）假設不同的班級學號有相同的，班級內學號不能相同，在R關係中，（學號，班級）->（姓名），但是（學號）->(姓名)不成立，（班級）->(姓名)不成立，所以姓名完全函式依賴與（學號，班級）；

部分函式依賴：存在x→y，若x’是x的真子集，存在x’→y，則稱y部分函式依賴於x。如（學號，身份證號）->（姓名），（學號）->（姓名），（身份證號）->（姓名）；所以姓名部分函式依賴與（學號，身份證號）

傳遞函式依賴：x→y,y→z,但y!→x, 則x傳遞函式依賴z，如(學號)->(宿舍),宿舍！=學號，(宿舍)->(費用),費用!=宿舍

正規化

一個關係的非主屬性函式依賴於主碼的程度。一個關係從低階正規化向高階正規化的轉換過程稱為關係規範化。

第一正規化（1NF）條件：若關係R的所有屬性不能再分，即沒有HBase中的列族。

第二正規化（2NF）:若關係R∈1NF，消除非主屬性對主碼的部分依賴，則稱R∈2NF。通常實現有增加一列unique標識，或者拆分。例如：如果一個表有商品名稱、供應商名稱和其他非主屬性的商品相關列，而相同商品名稱的行僅僅是供應商名稱不同（所以商品名稱、供應商名稱這兩列都可作為唯一標識），從而存在部分依賴。解決方法是商品和供應商各自單獨一張表，並加上一張對映兩表關係的表。

第三正規化（3NF）：消去非主屬性對主碼的傳遞依賴。例子：一個表有商品名稱、分類和分類描述，這裡存在“商品名稱 - 分類 - 分類描述”的依賴關係，分類描述對主碼是傳遞依賴。那麼就應該把 “商品名稱” 和 “分類和分類描述” 拆分為兩張表，並加上一張對映兩表關係的表。

BCNF正規化：複合關鍵字之間不存在依賴關係，即去除主屬性對於候選碼的部分函式依賴與傳遞函式依賴。例子：一個表有商品id、供應商、供應商聯絡人，其中供應商和聯絡人一一對應。此時“商品id + 供應商” 或 “商品id + 供應商聯絡人”可以確定一行資訊，而供應商和“供應商聯絡人+商品id”存在部分依賴關係。解決方法是把這個表拆分為“供應商 + 商品id” 和 “供應商 + 供應商聯絡人”兩個表。

物理結構設計

• 選擇資料庫管理系統、儲存引擎（如無意外都是Innodb）

• 定義資料庫、表及欄位命名規範

• 欄位型別：處理速度，數字 > 日期 > 字元；IO速度，列越短，即每個欄位定義的大小。

• 反正規化化設計

命名

1. 表達是與否概念的欄位，必須使用is_xxx的方式命名，資料型別是unsigned tinyint（ 1表示是，0表示否）。

2. 表名、欄位名必須使用小寫字母或數字，禁止出現數字開頭，禁止兩個下劃線中間只出現數字。資料庫欄位名的修改代價很大，因為無法進行預釋出，所以欄位名稱需要慎重考慮。

3. 表名不使用複數名詞。

4. 臨時表以tmp字首，以日期為字尾。備份庫以bak字首，以日期字尾。

5. 禁用保留字，如desc、range、match、delayed等，請參考MySQL官方保留字。

6. 主鍵索引名為pk_欄位名；唯一索引名為uk_欄位名；普通索引名則為idx_欄位名。

7. 表的命名最好是加上“業務名稱_表的作用”。

8. 庫名與應用名稱儘量一致。

欄位型別

1. 合適的字元儲存長度，如127 or 200百以上smallint、3 or 6萬以上mediumint、8 or 16百int、20 or 40億以上bingint
2. 小數型別為decimal，禁止使用float和double（除非不用精確）。如果儲存的資料範圍超過decimal的範圍，建議將資料拆成整數和小數分開儲存。
3. 如果儲存的字串長度幾乎相等，使用char定長字串型別。如果列中最大資料長度小於50Byte，也用char，大於這個值就用VARCHAR。
4. varchar是可變長字串，不預先分配儲存空間，長度不要超過5000，如果儲存長度大於此值，定義欄位型別為text，獨立出來一張表，用主鍵來對應，避免影響其它欄位索引效率。
5. 所有儲存相同資料的列名和列型別必須一致
6. 使用inet_aton 和 int_ntoa實現字串和數字型別的轉換

反正規化化

欄位允許適當冗餘，以提高查詢效能，但必須考慮資料一致。冗餘欄位應遵循：

• 不是頻繁修改的欄位。

• 不是varchar超長欄位，更不能是text欄位。

商品類目名稱使用頻率高，欄位長度短，名稱基本一成不變，可在相關聯的表中冗餘儲存類目名稱，避免關聯查詢。

補充

1. 表必備三欄位：id, gmt_create, gmt_modified。 其中id必為主鍵，型別為unsigned bigint、單表時自增、步長為1。gmt_create,gmt_modified的型別均為datetime型別，前者現在時表示主動建立，後者過去分詞表示被動更新。

2. 如果修改欄位含義或對欄位表示的狀態追加時，需要及時更新欄位註釋。

3. 單錶行數超過500萬行或者單表容量超過2GB，才推薦進行分庫分表。

4. 庫和表字符集合統一UTF8

5. 表和欄位都需要添加註釋

6. 禁止預留欄位、儲存圖片等二進位制資料、在線上做壓力測試、從開發/測試環境連線資料庫

7. 避免觸發器

8. 冷熱分表

9. 對大表使用pt-online-schema-change修改表結構

資料庫維護和優化

索引

強制

1. 業務上具有唯一特性的欄位，即使是多個欄位的組合，也必須建成唯一索引。

2. 超過三個表禁止join。需要join的欄位，資料型別必須絕對一致；多表關聯查詢時，保證被關聯的欄位需要有索引。

3. 在varchar欄位上建立索引時，必須指定索引長度，沒必要對全欄位建立索引，根據實際文字區分度決定索引長度即可。（一般對字串型別資料，長度為20的索引，區分度會高達90%以上，可以使用count(distinct left(列名, 索引長度))/count(*)的區分度來確定。）

4. 頁面搜尋嚴禁左模糊或者全模糊，如果需要請走搜尋引擎來解決。 （索引檔案具有B-Tree的最左字首匹配特性，如果左邊的值未確定，那麼無法使用此索引。）