2.1. 概念設計
數據庫設計分三個階段進行：
- 概念設計;
- 邏輯設計；
- 物理設計。
概念設計階段的目的是根據用戶對主題領域的想法創建概念數據模型。為了實現它，執行了一系列順序程序。實體（概念）模式的示例：
1. 實體及其文檔的定義。為了識別實體，定義了獨立於其他對象存在的對象。這些對像是實體。每個實體都被賦予了一個用戶可以理解的有意義的名稱。實體的名稱和描述被輸入到數據字典中。如果可能，設置每個實體的預期實例數。
2. 確定實體及其文檔之間的關係。只定義滿足數據庫設計要求所必需的實體之間的關係。每個的類型都已設置。顯示實體的成員類別。鏈接被賦予有意義的名稱，由動詞表達。每個連接的詳細描述，表明它的類型和參與連接的實體的所屬類別，被輸入到數據字典中。
3. 創建主題領域的 ER 模型。ER圖用於表示實體和它們之間的關係。基於它們，創建了建模主題區域的單個視覺圖像 - 主題區域的 ER 模型。
4. 屬性的定義及其文檔。顯示描述所創建 ER 模型實體的所有屬性。每個屬性都被賦予了一個用戶可以理解的有意義的名稱。以下信息存儲在每個屬性的數據字典中：
- 屬性名稱和描述；
- 值的類型和維度；
- 屬性的默認值（如果有）；
- 屬性是否可以有 NULL 值；
- 該屬性是否是複合屬性，如果是，它由哪些簡單屬性組成。例如，屬性“客戶的全名”可以由簡單屬性“姓氏”、“名字”、“父名”組成，也可以很簡單，包含單個值，例如“Sidorsky Evgeniy Mikhailovich”。如果用戶不需要訪問“名稱”的各個元素，則該屬性顯示為簡單；
- 屬性是否被計算，如果是，它的值是如何計算的。
5.屬性值的定義及其文檔。對於參與 ER 模型的實體的每個屬性，確定一組有效值並為其分配一個名稱。例如“賬戶類型”屬性只能有“存款”、“活期”、“按需”、“卡賬戶”等值。與屬性相關的數據字典條目用屬性值集的名稱更新。
6.實體及其文檔的主鍵定義。此步驟以主鍵的定義為指導 - 作為允許唯一標識其實例的實體的屬性或屬性集。主鍵信息放在數據字典中。
7. 與最終用戶討論概念數據模型。概念數據模型由 ER 模型表示，附帶的文檔包含對開發的數據模型的描述。如果發現領域不一致，則對模型進行更改，直到用戶確認他們提出的模型充分反映了他們的個人觀點。
2.2 邏輯設計
邏輯設計階段的目的是將基於所選數據模型的概念模型轉化為獨立於稍後用於數據庫物理實現的DBMS特性的邏輯模型。為了實現它，執行以下過程。
邏輯數據庫模式的示例。
1. 選擇數據模型。大多數情況下，由於數據表格表示的清晰度和使用它們的便利性，選擇關係數據模型。
2. 定義一組基於 ER 模型的表並記錄它們。為 ER 模型的每個實體創建一個表。實體名稱是表的名稱。表之間的關係是通過主鍵和外鍵機制建立的。表的結構和它們之間建立的關係被記錄下來。
3. 表的規範化。要正確執行規範化，設計人員必須深入了解數據的語義和使用模式。在這一步，他通過對它們應用規範化過程來檢查在上一步中創建的表的結構的正確性。它包括將每個表至少帶到 3rd NF。作為規範化的結果，獲得了非常靈活的數據庫設計，這使得對其進行必要的擴展變得容易。
4. 檢查邏輯數據模型是否有可能執行用戶提供的所有交易。事務是由單個用戶或應用程序執行的一組操作，用於更改數據庫的內容。因此，BANK 項目中的交易示例可以是將某個客戶的賬戶管理權轉讓給另一個客戶。在這種情況下，需要同時對數據庫進行多項更改。如果計算機在交易過程中崩潰，數據庫將處於不一致狀態，因為一些更改已經進行，而另一些則沒有。因此，必須撤消所有部分更改以使數據庫返回到其先前的一致狀態。
交易列表由用戶在主題區域中的操作決定。使用 ER 模型、數據字典以及已建立的主鍵和外鍵之間的關係，嘗試手動執行所有必要的數據訪問操作。如果任何手動操作失敗，則編譯後的邏輯數據模型不合適並且包含必須消除的錯誤。也許它們與實體、關係或屬性模型中的差距有關。
5. 確定數據完整性支持要求及其文檔。這些要求是為防止將衝突數據輸入數據庫而實施的限制。在此步驟中，涵蓋了數據完整性問題，而不考慮其實施的具體方面。應考慮以下類型的限制：
- 所需的數據。找出是否有不能有 NULL 值的屬性；
- 對屬性值的限制。定義了屬性的有效值；
- 實體完整性。如果實體的主鍵不包含 NULL 值，則實現；
- 參照完整性。據了解，外鍵值必須出現在父實體的表行之一的主鍵中；
- 業務規則施加的限制。例如，在 BANK 項目的情況下，可能會採用禁止客戶管理比方說三個以上帳戶的規則。
有關所有已建立的數據完整性約束的信息都放在數據字典中。
6. 創建邏輯數據模型的最終版本並與用戶討論。此步驟準備 ER 模型的最終版本，它表示邏輯數據模型。模型本身和更新的文檔，包括數據字典和關係錶鍊接模式，供用戶查看和分析，用戶必須確保它準確地代表主題領域。
2.3. 物理設計
物理設計階段的目的是描述位於計算機外部存儲器中的數據庫的具體實現。這是對數據存儲結構和訪問數據庫數據的有效方法的描述。在邏輯設計中，他們回答了這個問題——需要做什麼，而在物理設計中——選擇了一種方法來做這件事。物理設計過程如下。
1. 使用選定的 DBMS 設計數據庫表。選擇關係 DBMS 以用於創建在機器介質上託管的數據庫。它用於設計表格的功能已得到深入研究。然後進行了表的設計以及它們在DBMS環境中的連接方案。隨附的文檔中描述了準備好的數據庫項目。
2. 在選定的 DBMS 環境中實施業務規則。更新表中的信息可能會受到業務規則的限制。它們的實現方式取決於所選的 DBMS。一些用於實現主題領域要求的系統提供更多的功能，其他的則更少。在某些系統中，根本不支持實施業務規則。在這種情況下，開發應用程序以實現其限制。
與域業務規則的實施相關的所有決策都在隨附的文檔中進行了詳細描述。
3.設計數據庫的物理組織。此步驟為表選擇最佳文件組織。將在所設計的數據庫中執行的事務已確定，其中最重要的事務已突出顯示。分析交易吞吐量——在給定時間間隔內可以處理的交易數量，以及響應時間——完成一個交易所需的時間段。他們努力提高交易吞吐量並減少響應時間。
基於這些指標，可以通過在表中定義索引來加速從數據庫中選擇數據，或者通過降低對錶規範化級別的要求來優化數據庫的性能。估計容納創建的數據庫所需的磁盤空間。努力將其最小化。
對上述問題做出的決定已記錄在案。
4. 制定數據庫保護策略。數據庫是寶貴的企業資源，受到高度重視。為此，設計人員必須全面清楚地了解所選 DBMS 提供的所有保護。
5. 組織數據庫功能監控及調整。創建數據庫的物理項目後，組織對其功能的持續監控。有關數據庫性能級別的結果信息用於對其進行調整。為此，還涉及所選DBMS的手段。
對正在運行的數據庫進行任何更改的決定都應該經過全面考慮和權衡。