對于現在主要的系統來說，一般而言都是管理數據型系統，因此一個系統數據庫設計的好壞直接關系到了系統，因此特在此對數據庫的設計做一個簡單的回顧，希望各位新手，老手們多多指教。好了，廢話就不多說了，直接切入主題吧：）
我們知道，數據庫的數據模式包含2種模式
1：概念模式（ER圖表示）
2：邏輯模式（關系表）
因此，在做好了系統的需求以后，就應該開始著手數據庫的設計了。
首先，根據根據需求文檔尋找名詞，評定系統中的邏輯實體，提取出數據庫設計中的實體。
其次，根據所提取的邏輯實體畫出數據庫設計中的ER圖。
再次，把ER圖轉換成你的DataBaseS????.
第一點我就不說了，偶目前的水平還未達到收集需求的層次。：）
概念模型（領域建模）E-R圖
1：實體：實體是現實世界中可區別于其他對象的“事件”或者“物體”。例如：企業中的每個人都是一個實體。每個實體還具有一組性質，其中一部分的性質可以唯一標識實體。
實體可是實實在在存在的，或者是抽象的概念。
2，屬性：實體的性質。其中特殊的屬性有：復合屬性和多值屬性。
復合屬性：可劃分的屬性。比如：人的地址這一屬性，還可劃分成街道，門牌號等屬性。
多值屬性：多個值的屬性。比如: 人的親戚，可以有好幾個。
派生屬性：通過別的屬性推倒出來的。比如：根據當前的日期和人的出生日期，可以推算他的年齡
3：聯系：指的是多個實體之間的相互關聯。其中，聯系也可以具有屬性。
實體Or屬性的選擇：
1: 屬性不能再具有需要描述的性質。
1: 屬性不能具有與其他實體的聯系。
比如：在部門表中，人是作為屬性還是字段。如果將人作為屬性字段，則如果還需要人的地址和電話屬性的話，將其作為屬性就是不好的，應該另作為一個實體來存儲。
實體Or聯系的選擇：
1：是否反映了真實的業務邏輯。
2：是否會增加系統的空間開銷（）
3：是否容易會導致系統數據的不一致性。
比如，顧客----（貸款）----銀行 如果此時一個顧客貸多筆款，多個顧客貸一筆款，則作為聯系的貸款會出現重復或者容易導致數據的不一致性。
顧客----（借）---貸款---（屬于）銀行 其中，（）里面的表示聯系。
將ER圖轉換成表：
1：用表表示強實體集，每個屬性分別作為一個字段。
2：用表表示弱實體集，注意，弱實體集的屬性還要多一個字段：與它關聯的那個強實體集的主碼。
3：用表表示聯系集，把參與聯系的每個實體集的主碼作為聯系集表的主碼。注意實體之間如果是多對1的關系的話，且A，B2個實體之間存在依賴，A依賴于B ，則可將A與AB之間的聯系集合成一張表。
因為這樣不會導致空值出現的狀況。
4：復合屬性，有幾個屬性，表追加幾列。
5：多值屬性：創建新表，并把多值屬性的那個實體的主碼表作為此新表的追加列。
6：一般化： 為高層實體創建表，并為每個低層實體創建一個表。或者直接免去高層實體表。但是，如果一個實體不屬于低層的任何一個，則第二種表示無法表達。