數據庫技術是信息資源管理最有效的手段。數據庫設計是指構建壹個最優的數據庫模式，為給定的應用環境建立壹個數據庫及其應用系統，有效地存儲數據，滿足用戶的信息和處理要求。
在數據庫設計階段，集成用戶的應用需求(現實世界需求)，在概念設計階段，形成獨立於機器特性和DBMS產品的概念模型(信息世界模型)，用E-R圖描述。在邏輯設計階段，將E-R圖轉化為特定數據庫產品支持的數據模型，如關系模型，形成數據庫邏輯模型。然後根據用戶的處理需求和安全考慮，在基本表的基礎上建立必要的視圖，形成數據的外部模式。在物理設計階段，根據DBMS的特點和處理的需要，安排物理存儲，設計索引，形成數據庫中的模式。
1.需求分析階段
需求收集和分析產生由數據字典描述的數據需求(以及由數據流圖描述的處理需求)。
需求分析的重點是調查、收集和分析用戶在數據管理中的信息需求、處理需求、安全性和完整性需求。
需求分析的方法:調查組織，調查各部門的業務活動，協助用戶明確對新系統的需求，確定新系統的邊界。
常用的調查方法有:做作業、召開調查會、請人介紹、提問、設計問卷讓用戶填寫、查閱記錄。
分析和表達用戶需求的方法主要有自頂向下和自底向上兩種。自頂向下結構化方法(SA)方法從頂層系統組織入手，通過逐層分解來分析系統，並用數據流圖和數據字典來描述每壹層。
數據流圖表達了數據和處理之間的關系。系統中的數據通過數據字典(DD)來描述。
數據字典是各種數據描述的集合，是關於數據庫中數據的描述，也就是元數據，而不是數據本身。壹個數據字典通常包括數據項、數據結構、數據流、數據存儲和處理五個部分(至少應該包括每個字段的數據類型和每個表中的主鍵和外鍵)。
數據項描述= {數據項名稱，數據項含義描述，別名，數據類型，長度，
取值範圍、取值意義以及與其他數據項的邏輯關系}
數據結構描述= {數據結構名稱，含義描述，組成:{數據項或數據結構}}
數據流描述= {數據流名稱，描述，數據流來源，數據流目的地，
構成:{數據結構}，平均流量，峰值流量}
數據存儲描述= {數據存儲名稱，描述，編號，流入數據流，流出數據流，
組成:{數據結構}，數據量，訪問方法}
流程描述= {流程名稱，描述，輸入:{數據流}，輸出:{數據流}，
處理:{簡要描述}}
2.概念結構設計階段
通過對用戶需求的綜合、歸納和抽象，形成壹個獨立於具體DBMS的概念模型，可以用E-R圖表示。
概念模型用於對信息世界進行建模。概念模型不依賴於DBMS支持的數據模型。概念模型可以轉換成計算機上的DBMS支持的特定數據模型。
概念模型的特征:
(1)具有很強的語義表達能力，可以方便、直接地表達應用中的各種語義知識。
(2)應該簡單明了，便於用戶理解，是用戶與數據庫設計者交流的語言。
概念模型設計的壹種常用方法是IDEF1X方法，這是壹種將實體-關系方法應用於語義數據模型建立系統信息模型的語義建模技術。
使用IDEF1X方法創建E-R模型的步驟如下:
2.1步零初始化項目
這壹階段的任務是確定建模目標，制定建模計劃，組織建模團隊，收集源材料，從目的和範圍的描述中制定約束和規範。收集素材是這個階段的重點。通過調查觀察結果、業務流程、原系統的輸入輸出、各種報表，收集原始數據，形成基礎數據表。
2.2步驟1-定義實體
實體集的所有成員都有壹組彼此相同的特征和屬性，大多數實體都可以從收集的源材料-基礎數據表中直接或間接識別出來。根據源物料名稱列表中表示對象的術語和以“代碼”結尾的術語，如客戶代碼、代理商代碼、產品代碼等，識別其名詞所代表的實體，初步找出潛在的實體，形成初步的實體列表。
2.3第二步-定義連接
IDEF1X模型中只允許二進制連接，n進制連接必須定義為n個二進制連接。根據實際業務需求和規則，利用實體聯系矩陣識別實體間的二元關系，然後根據實際情況確定連接關系的勢、關系名稱和描述，確定關系類型，是已識別關系、未標記關系(強制或可選)還是不確定關系、已分類關系。如果子實體的每個實例都需要通過與父實體的關系來標識，則為標識關系，否則為非標識關系。在非標識關系中，如果子實體的每個實例只與壹個父實體相關聯，則它是強制的，否則它不是強制的。如果父實體和子實體表示相同的真實對象，那麽它們被分類。
2.4步驟3-定義代碼
通過引入交叉實體去除前壹階段產生的不確定關系，然後從非交叉實體和獨立實體中識別候選代碼的屬性，唯壹標識每個實體的實例，再從候選代碼中確定主代碼。為了確定主體代碼和關系的有效性，通過非空規則和非多值規則來保證，即實體實例的壹個屬性不能為空，也不能同時有多個值。找出誤識別的確定關系，進壹步分解實體，最終構建IDEF1X模型的關鍵基礎視圖(KB圖)。
2.5步驟4-定義屬性
從源數據表中提取描述性名詞，開發屬性表，確定屬性的所有者。定義非主鍵屬性，並檢查屬性的非空和非多值規則。此外，還需要檢查完全依賴函數和非傳遞依賴的規則，以確保壹個非主代碼屬性必須依賴於主代碼、整個主代碼且僅依賴於主代碼。這樣就得到改進的IDEF1X模型的全屬性視圖，它至少符合關系理論的第三範式。
2.6步驟5-定義其他對象和規則
定義數據類型、長度、精度、非空值、默認值、約束規則等。屬性的。定義對象信息，如觸發器、存儲過程、視圖、角色、同義詞和序列。
3.邏輯結構設計階段
將概念結構轉換成DBMS支持的數據模型(如關系模型),並對其進行優化。在設計邏輯結構時，要選擇最適合描述和表達相應概念結構的數據模型，進而選擇最適合的DBMS。
將E-R圖轉換為關系模型實際上是將實體、實體的屬性以及實體之間的關系轉換為關系模型。這種轉換通常遵循以下原則:
1)實體類型轉換成關系模型。實體的屬性就是關系的屬性。實體的代碼就是關系的代碼。
2)壹個m:n連接被轉換成壹個關系模式。與連接相關的實體的代碼和連接本身的屬性被轉換成關系的屬性。關系代碼是實體代碼的組合。
3)1:n連接可以轉化為獨立的關系模式，也可以在n端與對應的關系模式合並。如果轉換為獨立的關系模式，則關系所連接的實體的代碼和關系本身的屬性轉換為關系的屬性，關系的代碼為N端實體的代碼。
4)壹個1:1連接可以轉換成壹個獨立的關系模式，也可以在任壹端與對應的關系模式合並。
5)三個或更多實體之間的多元關系被轉換成關系模型。用多元連接連接的實體的代碼和連接本身的屬性被轉換成關系的屬性。關系代碼是實體代碼的組合。
6)同壹實體集內實體之間的連接，即自連接，也可以按照上述三種情況處理:1:1，1:n，m: n。
7)代碼相同的關系模式可以合並。
為了進壹步提高數據庫應用系統的性能，通常要在規範化理論的指導下，對數據模型的結構進行適當的修改和調整，這就是對數據模型的優化。確定數據依賴關系。消除冗余連接。確定每個關系模型屬於哪個範式。確定是合並還是分解它們。壹般來說，這種關系被分解成3NF個標準，即:
表中的每個值只能表示壹次。
表中的每壹行都應該唯壹標識(用唯壹的鍵)。
依賴於其他鍵的非鍵信息不應存儲在表中。
4.數據庫物理設計階段
為邏輯數據模型選擇最適合應用環境的物理結構(包括存儲結構和訪問方法)。根據數據庫管理系統的特點和處理的需要，進行物理存儲安排和索引設計，形成數據庫中的模式。
5.數據庫實施階段
利用DBMS提供的數據語言(如SQL)及其宿主語言(如C)，根據邏輯設計和物理設計的結果建立數據庫，編譯調試應用程序，數據入庫並投入試運行。數據庫實現主要包括以下任務:用DDL定義數據庫結構，組織數據存儲，編譯調試應用程序，數據庫試運行。
6.數據庫操作和維護階段
數據庫應用系統經過試運行後可以投入正式運行。數據庫系統在運行期間必須不斷評估、調整和修改。包括:數據庫轉儲與恢復、數據庫安全、完整性控制、數據庫性能監督、分析與改進、數據庫重組與重構。
建模工具的使用
目前有很多加速數據庫設計的數據庫輔助工具(CASE tools)，如Rational公司的Rational Rose，CA公司的Erwin和Bpwin，Sybase公司的PowerDesigner，Oracle公司的Oracle Designer。
ERwin主要用於建立數據庫的概念模型和物理模型。它可以用圖形化的方式描述實體、關系以及實體的屬性。ERwin支持IDEF1X方法。通過使用ERwin建模工具自動生成、變更和分析IDEF1X模型，不僅可以得到優秀的業務功能和數據需求模型，還可以實現從IDEF1X模型到數據庫物理設計的轉換。ERwin工具繪制的模型對應邏輯模型和物理模型。在邏輯模型中，IDEF1X工具箱可以方便地以圖形化的方式建立和繪制實體關系和實體屬性。在物理模型中，ERwin可以定義相應的表和列，並可以自動將其轉換為適合各種數據庫管理系統的類型。
設計人員可以根據需要選擇相應的數據庫設計建模工具。例如，需求分析完成後，設計人員可以使用Erwin繪制er圖，將ER圖轉換為關系數據模型，並生成數據庫結構。畫出數據流圖，生成應用程序。
二、數據庫設計技巧
1.設計數據庫之前(需求分析階段)
1)了解客戶需求，問用戶如何看待未來的需求變化。讓客戶解釋他們的需求，隨著開發的繼續，經常詢問客戶，以確保他們的需求仍然在開發的目的中。
2)了解企業的業務，可以在後期發展階段節省大量時間。
3)註意輸入輸出。
在定義數據庫表和字段要求(輸入)時，您應該首先檢查現有的或設計的報告、查詢和視圖(輸出)，以確定哪些表和字段是支持這些輸出所必需的。
例如，如果客戶需要壹個按郵政編碼排序、細分和匯總的報表，您應該確保它包含壹個單獨的郵政編碼字段，而不是將郵政編碼放入地址字段。
4)創建數據字典和ER圖。
ER圖表和數據字典可以讓任何了解數據庫的人清楚如何從數據庫中獲取數據。ER圖表對於顯示表之間的關系非常有用，而數據字典顯示每個字段的用途和任何可能的別名。這對於SQL表達式的文檔來說是絕對必要的。
5)定義標準的對象命名規範。
數據庫中各種對象的命名必須標準化。
2.表和字段的設計(數據庫邏輯設計)
表格設計原則
1)標準化和規範化
數據標準化有助於消除數據庫中的數據冗余。標準化有幾種形式，但第三範式(3NF)通常被認為是性能、可伸縮性和數據完整性之間的最佳平衡。簡單來說，符合3NF標準的數據庫的表設計原則是:“壹個地方壹個事實”，即壹個表只包含自己的基本屬性，當不是自己的屬性時需要分解。表之間的關系由外鍵連接。它有以下幾個特點:有壹組專門存儲相關數據的表，用鍵連接。
例如，存儲客戶及其相關訂單的3NF數據庫可能有兩個表:customer和order。Order表不包含與訂單相關聯的客戶的任何信息，但是表中將存儲壹個鍵值，該鍵值指向Customer表中包含客戶信息的行。
其實為了效率，有時候不規範表格是必要的。
2)數據驅動
用數據驅動代替硬編碼，很多策略修改和維護會方便很多，大大增強了系統的靈活性和擴展性。
例如，如果用戶界面想要訪問外部數據源(文件、XML文檔、其他數據庫等)。)，建議在用戶界面支持表中存儲相應的連接和路徑信息。此外，如果用戶界面執行工作流(發送郵件、打印信紙、修改記錄狀態等)等任務。)，那麽生成工作流的數據也可以存儲在數據庫中。角色權限管理也可以通過數據驅動來完成。事實上，如果流程是數據驅動的，您可以將相當大的責任放在用戶身上，他們將維護自己的工作流程。
3)考慮各種變化
設計數據庫時，要考慮哪些數據字段將來可能會發生變化。
比如姓氏是這樣的(註意西方人的姓氏，比如女性婚後隨夫姓等。).因此，在建立系統存儲客戶信息時，將姓氏字段存儲在單獨的數據表中，並添加開始日期和結束日期等字段，以便可以跟蹤該數據項的變化。
現場設計原則
4)應該添加到每個表中的三個有用字段。
DRecordCreationDate在VB中默認為Now()，在SQL Server中默認為GETDATE()。
SRecordCreator，默認為SQL Server下的NOT NULL默認用戶。
NRecordVersion，記錄的版本標記；準確解釋記錄中出現空數據或缺失數據的原因很有幫助。
5)對地址和電話號碼使用多個字段。
僅僅用壹行來描述街道地址是不夠的。Address_Line1、Address_Line2和Address_Line3可以提供更大的靈活性。此外，電話號碼和電子郵件地址應該有自己的數據表，有自己的類型和標簽類別。
6)使用角色實體定義屬於某個類別的列。
當需要定義屬於特定類別或具有特定角色的事物時，可以使用角色實體來創建特定的時間關聯，從而實現自文檔化。
例如，使用PERSON實體和PERSON_TYPE實體來描述人。例如，當John Smith，工程師晉升為John Smith，董事，並最終爬到John Smith，cio的高位時，您所要做的就是更改兩個表PERSON和PERSON_TYPE之間的關系的鍵值，並添加壹個日期/時間字段以了解更改發生的時間。這樣，PERSON_TYPE表就包含了所有可能的人員類型，比如助理、工程師、主管、CIO或CEO。另壹種替代方法是更改人員記錄以反映新頭銜的變化，但無法及時跟蹤個人所在位置的具體時間。
7)選擇盡可能多的數字類型和文本類型。
在SQL中使用smallint和tinyint類型時要特別小心。例如，如果要查看月總銷售額，而“合計”字段類型很小，那麽如果合計超過32，767美元，就無法計算它。
ID類型的文本字段，如客戶ID或訂單號，應該設置得比平時大。假設客戶ID的長度為10位數字。然後，您應該將數據庫表字段的長度設置為12或13個字符。但是，這額外的空間並不需要在未來重建整個數據庫來實現數據庫規模的增長。
8)添加刪除標記字段。
在表中包含刪除標記字段，以便可以將行標記為刪除。不要刪除關系數據庫中的任何壹行；最好使用數據清理程序，並小心維護索引的完整性。
3.選擇鍵和索引(數據庫邏輯設計)
密鑰選擇原則:
1)關鍵設計4原則
為關聯字段創建外鍵。
所有鍵必須是唯壹的。
避免使用組合鍵。
外鍵總是與唯壹的鍵字段相關聯。
2)使用系統生成的主鍵
在設計數據庫時，將系統生成的密鑰作為主鍵，因此實際上控制了數據庫的索引完整性。這樣，數據庫和非手工機制有效地控制了對存儲數據中每壹行的訪問。使用系統生成的鍵作為主鍵的另壹個優點是，當您擁有壹致的鍵結構時，很容易發現邏輯缺陷。
3)不要使用用戶的密鑰(不要使主鍵可更新)
當決定使用哪個字段作為表的鍵時，必須小心用戶將要編輯的字段。壹般情況下，不要選擇用戶可以編輯的字段作為關鍵字。
4)可選鍵有時可以用作主鍵。
進壹步使用可選鍵作為主鍵，您就能夠構建壹個強大的索引。
索引使用原則:
索引是從數據庫中獲取數據的最有效的方法之壹。95%的數據庫性能問題可以通過索引技術解決。
1)對邏輯主鍵使用唯壹分組索引，對系統鍵使用唯壹未分組索引(作為存儲過程)，對任何外鍵列使用未分組索引。考慮數據庫有多少空間，如何訪問表，這些訪問是否主要用於讀寫。
2)大部分數據庫都會索引自動創建的主鍵字段，但是不要忘記索引外鍵，外鍵也是常用的鍵，比如運行壹個查詢來顯示主表和所有相關表中的壹條記錄。
3)不要索引memo/note字段，不要索引大字段(字符多)，這樣會使索引占用過多存儲空間。
4)不要索引常用的小表。
不要為小數據表設置任何鍵，尤其是如果它們經常有插入和刪除操作。這些插入和刪除操作的索引維護可能比掃描表空間花費更多的時間。
4.數據完整性設計(數據庫邏輯設計)
1)完整性實現機制:
實體完整性:主鍵
參照完整性:
刪除父表中的數據:級聯刪除；限制性刪除；空值
將數據插入父表:受限插入；遞歸插入
更新父表中的數據:級聯更新；受限更新；空值
DBMS可以通過兩種方式實現參照完整性:外鍵實現機制(約束規則)和觸發器實現機制。
用戶定義的完整性:
不為空；檢查；引發
2)通過約束而不是業務規則來加強數據完整性。
利用數據庫系統實現數據完整性。這不僅包括通過標準化實現的完整性，還包括數據的功能性。還可以在寫數據的時候添加觸發器，保證數據的正確性。不依賴業務層保證數據完整性；它不能保證表(外鍵)之間的完整性，所以不能強加在其他完整性規則上。
3)強制性指示完整性
在有害數據進入數據庫之前將其消除。激活數據庫系統指示的完整性特征。這可以保持數據的整潔，並迫使開發人員花費更多的時間來處理錯誤情況。
4)使用查找來控制數據完整性。
控制數據完整性的最好方法是限制用戶的選擇。只要有可能，就應該為用戶提供壹個清晰的值列表以供選擇。這將減少鍵入代碼時的錯誤和誤解，並提供數據壹致性。壹些公共數據特別適合搜索:國家代碼、狀態代碼等。
5)采納觀點
為了在數據庫和應用程序代碼之間提供另壹個抽象層，可以為應用程序建立壹個特殊的視圖，而無需應用程序直接訪問數據表。這樣做還可以讓您在處理數據庫更改時更加自由。
5.其他設計技能
1)避免使用觸發器。
觸發器的功能通常可以通過其他方式實現。調試程序時，觸發器可能會成為幹擾。如果妳真的需要使用觸發器，妳最好專註於記錄它。
2)使用通用英語(或任何其他語言)代替編碼。
創建下拉菜單、列表和報表時，最好按英文名稱排序。如果需要編碼，可以在編碼中附上用戶認識的英文。
3)保存常用信息
擁有壹個專用於壹般數據庫信息的表非常有用。在該表中，存儲了數據庫的當前版本、最新檢查/維修(用於訪問)、相關設計文檔的名稱、客戶和其他信息。這可以實現壹個簡單的機制來跟蹤數據庫，當客戶抱怨他們的數據庫不符合期望的要求並與您聯系時，這對於非客戶機/服務器環境尤其有用。
4)包括版本機制
版本控制機制被引入到數據庫中，以確定正在使用的數據庫的版本。隨著時間的推移，用戶的需求總是會發生變化。您最終可能需要修改數據庫結構。將版本信息直接存儲在數據庫中更方便。
5)文件準備
記錄所有快捷方式、命名約定、限制和功能。
使用數據庫工具來註釋表、列、觸發器等。對於開發、支持和跟蹤變更非常有用。
記錄數據庫，或者在數據庫內部或單獨建立文檔。這樣壹年多以後妳再去找第二個版本的時候，出錯的幾率會大大降低。
6)測試、試驗和重復試驗
建立或修改數據庫後，必須用用戶新輸入的數據測試數據字段。最重要的是，讓用戶測試並與用戶壹起工作，以確保所選擇的數據類型滿足業務需求。在將新數據庫投入實際服務之前，需要完成測試。
7)檢查設計
在開發過程中檢查數據庫設計的壹種常見技術是通過數據庫支持的應用程序原型來檢查數據庫。換句話說，對於每個最終表達數據的原型應用程序，請確保檢查數據模型並了解如何提取數據。
第三，數據庫命名規範
1.實體(表)的命名
1)表格以名詞或名詞短語命名，確定表格名稱是復數還是單數。此外，為表的別名定義了簡單的規則(例如，如果表名是壹個單詞，別名取單詞的前四個字母；如果表名是兩個單詞，取每個單詞的前兩個字母組成四個字母的別名；如果表名由三個單詞組成，從前兩個單詞中取壹個，然後從最後壹個單詞中取兩個字母，結果仍然是四個字母的別名，依此類推)
對於工作表，表名可以以WORK_為前綴，後跟使用該表的應用程序的名稱。在命名過程中，縮略語可以根據語義拼湊。請註意，由於ORCLE會將字段名稱統壹為大寫或小寫，因此需要給它們加下劃線。
例如:
定義的縮寫Sales:Sal Sales；
秩序:Ord秩序；
細節:Dtl細節；
然後將銷售訂單列表命名為:薩爾_ Ord _ Dtl；
2)如果表或字段的名稱只有壹個單詞，建議使用完整的單詞，不要使用縮寫。
例如:
定義的縮寫材料Ma文章；
項目列表被稱為物料，而不是Ma。
但是字段項目編碼是:Ma _ ID不是物料ID。
3)在所有存儲值列表的表前面加上前綴Z。
目的是在數據庫末尾對這些值列表分類進行排序。
4)在命名所有冗余類(主要是累積表)之前加上前綴X
冗余類是在數據庫非規範化時添加的字段或表，目的是提高數據庫的效率。
5)通過用下劃線連接兩個基本類，然後添加前綴R，然後按字母順序列出兩個表名或表名的縮寫來命名關聯的類。
關聯表用於存儲多對多關系。
如果關聯的表名超過10個字母，則原始表名必須縮寫。如果沒有其他原因，建議使用縮寫。
例如，如果表對象與其自身之間存在多對多關系，則保存多對多關系的表被命名為:r _ object
表格部門和員工；存在多對多的關系；關聯的表名為R_Dept_Emp。
2.屬性(列)的命名
1)采用有意義的列名，表中的列應該采用壹套鍵的設計規則。每個表將有壹個自動ID作為主鍵，邏輯主鍵將被定義為第壹組候選主鍵。如果代碼由數據庫自動生成，則統壹命名為ID；如果是自定義邏輯代碼，則用縮寫和“ID”命名。如果鍵是數字，可以用_NO做後綴；如果是字符型，可以使用後綴_CODE。列名應該使用標準的前綴和後綴。
例如，銷售訂單的數字字段命名為SAL _ ORD _ ID如果仍有數據庫自動生成的數字，則將其命名為:ID。
2)所有屬性都應以相關類型作為後綴。註意，如果需要其他後綴，它們應該放在類型後綴之前。
註意:數據類型是文本字段，類型後綴TX可以省略。對於壹些類型比較明顯的字段，不需要寫類型後綴。
3)采用前綴命名
對每個表的列名使用統壹的前綴將大大簡化SQL表達式的編寫。它確實有缺點，例如破壞了自動表連接工具的功能，該工具將公共列名與壹些數據庫鏈接起來。
3.視圖的命名
1)視圖以V為前綴，其他命名規則與表相似；
2)命名要盡可能體現每個視圖的功能。
4.觸發器的命名
觸發器前綴為TR，觸發器名稱為對應的帶後綴的表名，插入觸發器加' _I '，刪除觸發器加' _D '，更新觸發器加' _U '，如:TR_Customer_I，TR_Customer_D，tr _ customer _ u。
5.存儲過程名稱
存儲過程應該以' UP_ '開頭，這與系統的存儲過程不同。後面的部分主要是動詞和賓語的形式，每個成分用下劃線分開。例如，用於添加代理帳戶的存儲過程是' UP_Ins_Agent_Account '。
6.變量名
變量名是小寫的。如果它們是短語的形式，用下劃線分隔每個單詞，例如@ my _ err _ no。
7.命名中的其他註意事項
1)以上命名不得超過30個字符的系統限制。變量名的長度限制為29個字符(不包括標識字符@)。
2)數據對象和變量用英文字符命名，禁止中文命名。永遠不要在對象名的字符之間留空格。
3)小心使用保留字，確保您的字段名不與保留字、數據庫系統或常用訪問方法沖突。
5)保持字段名和類型的壹致性，在為字段命名和指定數據類型時，壹定要保證壹致性。如果壹個表中的數據類型是整數，不要在另壹個表中將其更改為字符類型。