這是一個客人後由阿努姆洛德 ，誰具有很大的興趣 ， 軟件設計

正如您需要的藍圖，蓋房子，你需要一個數據庫藍圖，以實現一個數據庫成功。過程建造後者稱為'設計階段'，其中包括一個數字重型步驟結束產品採取靈活態度。 這一階段的信息來界定（+結構），將進入數據庫，所作的假設有關的類型或值項的數據和數據之間的關係在數據庫項目。 所有專業公司使用此過程設計的數據庫及其最有效的方法。

它包括四個步驟：

1。 需求分析

該數據庫的要求決定的。 在確實需要的用戶從系統是captured.All相關信息相關的系統收集。 六個最常用的技術是：

• 採樣的現有文件，表格，數據庫
• 研究和實地考察
• 觀察工作環境
• 問卷
• 原型設計建造了一個小模型，用戶的要求核實前手
• 聯合需求計劃（需求規劃） - 組會議進行分析存在的問題

2。 實體關係圖（ERD的）

ERD的是一個高層的符號表達的數據庫設計。 它生動地定義了結構的數據庫的一個很簡單的和可理解的方式通過使用符號。

收集到的資料中的需求分析：第一步是轉化為一個 ERD的（實體關係圖），它的數據組織成實體和它們之間的關係。 因此，與其經歷一個漫長的一塊材料，我們有代表性的圖案同一塊的資料更易於閱讀。

樣本 ER圖是這樣的：

（圖片來自維基百科 ）

各種數據建模語言可以用來創建 ERD像烏鴉的腳符號，陳符號，Idefix號（定義為信息集成建模），底紋符號，巴赫曼符號，UML（統一建模語言）標準等具有良好的維基網頁約急診室圖在這裡

3。 關係模型

這是非常容易理解的情況，從 ERD的，但後者非常薄弱，從執行的角度來看。 概念的子協議（IS -甲結構）和關係，例如，無法實施直接在數據庫中。此時關係模型開始發揮作用。

阿關係模型採用一個單一的概念表（也稱關係）。實體集和的關係描繪的ERD轉換成表，關係模型。

有五個步驟進行轉換：

• 打開每個非弱實體集到其對應的表具有相同的屬性集
• 替換關係的一種關係，其屬性是關鍵的連接實體集
• 有些關係能做好，如果合併或排除在外。 例如，支持關係（弱實體集）不必將轉換為關係的。
• 弱實體替換一個關係設置其屬性是它自己的屬性（如果有的話），加上借來的屬性，有助於提高其行動的主鍵。
• 子類結構轉換使用對象導向的方法，電子 / R風格轉換或空值。

說明 ER圖轉換到關係模式具有廣闊的概念，將不包括在這個職位。 有很多很好的書籍和網上資源，使得它很容易理解。 對於概覽考慮這個例子，我已經從維基百科：

一個理想化，很簡單的例子說明一些relvars和它們的屬性：

• 客戶（ 客戶ID，稅號，名稱，地址，城市，州，郵編，電話）
• 訂單（ 訂單不 ， 客戶ID，發票編號 ，日期置於日期承諾，條款，狀態）
• 訂購行（ 號令 ， 命令行不 ， 產品代碼 ，數量）
• 發票（ 發票編號 ， 客戶編號 ， 訂單編號 ，日期，狀態）
• 發票線（ 無發票 ， 無發票線 ， 產品代碼 ，數量發貨）
• 產品（ 產品編號 ，產品描述）

在這個設計 ，我們有六個relvars：客戶，訂單，訂單行，發票，發票線和產品。 大膽的，強調屬性候選鍵 。 非粗體，下劃線屬性外鍵 。

4。 規範化

規範化是一個過程，增加正常形式的評級。它消除了以下主要依賴，以避免重複和數據異常：

• 部分依賴：根據部分主鍵
• 傳遞依賴：基於屬性是不屬於主鍵

第一三種形式的正常化是：

1. 1nF的
   • 最低可執行範式
   • 主鍵實體完整性要求得到滿足
   • 每個單元包含一個值
   • 非主鍵的值依賴於主鍵
2. 2NF
   • 所有1nF的條件得到滿足
   • 部分
     依賴被刪除
3. 3NF的
   • 所有條件都滿足 2Nf
   • 傳遞依賴刪除

高級的形式到5NF和範式（ 博伊斯，科德範式）也存在。

正常化可以應用在兩個方面：

• 申請表格後正常關係模型的創建
• 第三步是跳過並建立表務求在審議直接關係正常化

daleeman博客有一個非常好的職位有關數據庫正常化。 閱讀： 實際應用的數據庫正常化 ，將幫助您了解數據庫標準化的細節。