資料庫設計規范

⑴ 急需MySql資料庫設計規范

1. 數據表命名規范
模塊名縮寫_存儲信息[_存儲信息子類](多個單詞用下劃線分回隔)，全部小寫，例如：答b2c_goods_type
2. 欄位命名規范
存儲信息屬性(多個單詞用下劃線分隔)，全部小寫，命名規則只來自於業務，盡量表達出列的含義。
例如：goods_id
3. 欄位類型規范。
規則:用盡量少的存儲空間來存 數一個欄位的數據.
比如能用int的就不用char或者varchar
能用tinyint的就不用int
能用 varchar(20)的就不用varchar(255)
時間戳欄位盡量用int型，如 created:表示從 '1970-01-01?08:00:00'開始的int秒數，採用英文單詞的過去式；gmtCreated:表示datetime類型的時間，即形如 '1980-01-01?00:00:00'的時間串，Java中對應的類型為Timestamp
日期：用date
時間：用time
數字格式的用：int、tinyint、mediumint、smallint、bigint根據實際情況選擇
字元串：用char、varcahr；
文本：用text
金額：用float

⑵ SQL資料庫設計規范及如何設置外鍵

20個資料庫設計最佳實踐： 使用明確、統一的標明和列名，例如 School, SchoolCourse, CourceID。 數據表名使用單數而不是復數，例如 StudentCourse，而不是StudentCourses。 數據表名不要使用空格。 數據表名不要使用不必要的前綴或者後綴，例如使用School，而不是TblSchool，或者SchoolTable等等。 資料庫中的密碼要加密，到應用中再解密。 使用整數作為ID欄位，也許現在沒有這個必要，但是將來需要，例如關聯表，索引等等。 使用整數欄位做索引，否則會帶來很大的性能問題 。 使用bit 作為布爾欄位，使用整數或者varcha是浪費。同時，這類欄位應該以「Is」開頭。 要經過認證才能訪問資料庫，不要給每一個用戶管理員許可權。 盡量避免使用「select *」，而使用「select [required_column_list]」以獲得更好的性能。 假如程序代碼比較復雜，使用ORM框架，例如hibernate，iBatis。ORM框架的性能問題可以通過詳細的配置去解決。 分割不常使用的數據表到不同的物理存儲以獲得更好的性能。 對於關鍵資料庫，使用安全備份系統，例如集群，同步等等。 使用外鍵，非空等限制來保證數據的完整性，不要把所有的東西都扔給程序。 缺乏資料庫文檔是致命的。你應該為你的資料庫設計寫文檔，包括觸發器、存儲過程和其他腳本。 對於經常使用的查詢和大型數據表，要使用索引。數據分析工具可以幫助你決定如何建立索引。 資料庫伺服器和網頁伺服器應該放在不同的機器上。這回提高安全性，並減輕CPU壓力。 Image和blob欄位不應該定義在常用的數據表中，否則會影響性能。 範式（Normalization）要按照要求使用以提高性能。Normalization做的不夠會導致數據冗餘，而過度Normalization 會導致太多的join和數據表，這兩種情況都會影響性能。 多花點時間在資料庫設計上，否則你將來會付出加倍的時間來償還。設置外鍵：方法一：SQL語句alter table 表名 add constraint 外鍵名 foreign key(欄位名) references 主表名(欄位名) on delete cascade方法二：不想寫sql 語句也可以直接用圖形化操作 選擇你要創建外鍵的表，反鍵選擇修改表，點擊

⑶ 資料庫規范設計

這個書上應該都有的啊1.需求分析階段
准確了解與分析用戶需求（包括數據與版處理）
是整個設計權過程的基礎，是最困難、最耗費時間的一步
2.概念結構設計階段
是整個資料庫設計的關鍵
通過對用戶需求進行綜合、歸納與抽象，形成一個獨立於具體DBMS的概念模型
3.邏輯結構設計階段
將概念結構轉換為某個DBMS所支持的數據模型
對其進行優化
4.資料庫物理設計階段
為邏輯數據模型選取一個最適合應用環境的物理結構（包括存儲結構和存取方法）
5.資料庫實施階段
運用DBMS提供的數據語言、工具及宿主語言，根據邏輯設計和物理設計的結果
建立資料庫，編制與調試應用程序，組織數據入庫，並進行試運行
6.資料庫運行和維護階段
資料庫應用系統經過試運行後即可投入正式運行。

⑷ 資料庫設計原則

本系統中資料庫的設計，要考慮和遵循下列資料庫設計的基本原則，以建立穩定、安全內、可靠的容資料庫。

1)一致性原則:對數據來源進行統一、系統的分析與設計，協調好各種數據源，保證數據的一致性和有效性。

2)完整性原則:資料庫的完整性是指數據的正確性和相容性。要防止合法用戶使用資料庫時向資料庫加入不合語義的數據。對輸入到資料庫中的數據要有審核和約束機制。

3)安全性原則:資料庫的安全性是指保護數據，防止非法用戶使用資料庫或合法用戶非法使用資料庫造成數據泄露、更改或破壞。要有認證和授權機制。

4)可伸縮性與可擴展性原則:資料庫結構的設計應充分考慮發展的需要、移植的需要，具有良好的擴展性、伸縮性和適度冗餘。

5)規范化:資料庫的設計應遵循規范化理論。規范化的資料庫設計，可以減少資料庫插入、刪除、修改等操作時的異常和錯誤，降低數據冗餘度等。

⑸ 資料庫的規范化設計方法～

第一範式（1NF）：資料庫表中的欄位都是單一屬性的，不可再分。這個單一屬性由基本類型構成，包括整型、實數、字元型、邏輯型、日期型等。

例如，如下的資料庫表是符合第一範式的：

欄位1 欄位2 欄位3 欄位4

而這樣的資料庫表是不符合第一範式的：

欄位1 欄位2 欄位3 欄位4
欄位3.1 欄位3.2

很顯然，在當前的任何關系資料庫管理系統（DBMS）中，傻瓜也不可能做出不符合第一範式的資料庫，因為這些DBMS不允許你把資料庫表的一列再分成二列或多列。因此，你想在現有的DBMS中設計出不符合第一範式的資料庫都是不可能的。

第二範式（2NF）：資料庫表中不存在非關鍵欄位對任一候選關鍵欄位的部分函數依賴（部分函數依賴指的是存在組合關鍵字中的某些欄位決定非關鍵欄位的情況），也即所有非關鍵欄位都完全依賴於任意一組候選關鍵字。

假定選課關系表為SelectCourse(學號, 姓名, 年齡, 課程名稱, 成績, 學分)，關鍵字為組合關鍵字(學號, 課程名稱)，因為存在如下決定關系：

(學號, 課程名稱) → (姓名, 年齡, 成績, 學分)

這個資料庫表不滿足第二範式，因為存在如下決定關系：

(課程名稱) → (學分)

(學號) → (姓名, 年齡)

即存在組合關鍵字中的欄位決定非關鍵字的情況。

由於不符合2NF，這個選課關系表會存在如下問題：

(1) 數據冗餘：

同一門課程由n個學生選修，"學分"就重復n-1次；同一個學生選修了m門課程，姓名和年齡就重復了m-1次。

(2) 更新異常：

若調整了某門課程的學分，數據表中所有行的"學分"值都要更新，否則會出現同一門課程學分不同的情況。

(3) 插入異常：

假設要開設一門新的課程，暫時還沒有人選修。這樣，由於還沒有"學號"關鍵字，課程名稱和學分也無法記錄入資料庫。

(4) 刪除異常：

假設一批學生已經完成課程的選修，這些選修記錄就應該從資料庫表中刪除。但是，與此同時，課程名稱和學分信息也被刪除了。很顯然，這也會導致插入異常。

把選課關系表SelectCourse改為如下三個表：

學生：Student(學號, 姓名, 年齡)；

課程：Course(課程名稱, 學分)；

選課關系：SelectCourse(學號, 課程名稱, 成績)。

這樣的資料庫表是符合第二範式的， 消除了數據冗餘、更新異常、插入異常和刪除異常。

另外，所有單關鍵字的資料庫表都符合第二範式，因為不可能存在組合關鍵字。

第三範式（3NF）：在第二範式的基礎上，數據表中如果不存在非關鍵欄位對任一候選關鍵欄位的傳遞函數依賴則符合第三範式。所謂傳遞函數依賴，指的是如果存在"A → B → C"的決定關系，則C傳遞函數依賴於A。因此，滿足第三範式的資料庫表應該不存在如下依賴關系：

關鍵欄位 → 非關鍵欄位x → 非關鍵欄位y

假定學生關系表為Student(學號, 姓名, 年齡, 所在學院, 學院地點, 學院電話)，關鍵字為單一關鍵字"學號"，因為存在如下決定關系：

(學號) → (姓名, 年齡, 所在學院, 學院地點, 學院電話)

這個資料庫是符合2NF的，但是不符合3NF，因為存在如下決定關系：

(學號) → (所在學院) → (學院地點, 學院電話)

即存在非關鍵欄位"學院地點"、"學院電話"對關鍵欄位"學號"的傳遞函數依賴。

它也會存在數據冗餘、更新異常、插入異常和刪除異常的情況，讀者可自行分析得知。

把學生關系表分為如下兩個表：

學生：(學號, 姓名, 年齡, 所在學院)；

學院：(學院, 地點, 電話)。

這樣的資料庫表是符合第三範式的，消除了數據冗餘、更新異常、插入異常和刪除異常。

鮑依斯-科得範式（BCNF）：在第三範式的基礎上，資料庫表中如果不存在任何欄位對任一候選關鍵欄位的傳遞函數依賴則符合第三範式。

假設倉庫管理關系表為StorehouseManage(倉庫ID, 存儲物品ID, 管理員ID, 數量)，且有一個管理員只在一個倉庫工作；一個倉庫可以存儲多種物品。這個資料庫表中存在如下決定關系：

(倉庫ID, 存儲物品ID) →(管理員ID, 數量)

(管理員ID, 存儲物品ID) → (倉庫ID, 數量)

所以，(倉庫ID, 存儲物品ID)和(管理員ID, 存儲物品ID)都是StorehouseManage的候選關鍵字，表中的唯一非關鍵欄位為數量，它是符合第三範式的。但是，由於存在如下決定關系：

(倉庫ID) → (管理員ID)

(管理員ID) → (倉庫ID)

即存在關鍵欄位決定關鍵欄位的情況，所以其不符合BCNF範式。它會出現如下異常情況：

(1) 刪除異常：

當倉庫被清空後，所有"存儲物品ID"和"數量"信息被刪除的同時，"倉庫ID"和"管理員ID"信息也被刪除了。

(2) 插入異常：

當倉庫沒有存儲任何物品時，無法給倉庫分配管理員。

(3) 更新異常：

如果倉庫換了管理員，則表中所有行的管理員ID都要修改。

把倉庫管理關系表分解為二個關系表：

倉庫管理：StorehouseManage(倉庫ID, 管理員ID)；

倉庫：Storehouse(倉庫ID, 存儲物品ID, 數量)。

這樣的資料庫表是符合BCNF範式的，消除了刪除異常、插入異常和更新異常。

範式應用

我們來逐步搞定一個論壇的資料庫，有如下信息：

（1） 用戶：用戶名，email，主頁，電話，聯系地址

（2） 帖子：發帖標題，發帖內容，回復標題，回復內容

第一次我們將資料庫設計為僅僅存在表：

用戶名 email 主頁 電話 聯系地址 發帖標題 發帖內容 回復標題 回復內容

這個資料庫表符合第一範式，但是沒有任何一組候選關鍵字能決定資料庫表的整行，唯一的關鍵欄位用戶名也不能完全決定整個元組。我們需要增加"發帖ID"、"回復ID"欄位，即將表修改為：

用戶名 email 主頁 電話 聯系地址 發帖ID 發帖標題 發帖內容 回復ID 回復標題 回復內容

這樣數據表中的關鍵字(用戶名，發帖ID，回復ID)能決定整行：

(用戶名,發帖ID,回復ID) → (email,主頁,電話,聯系地址,發帖標題,發帖內容,回復標題,回復內容)