資料庫系統的設計方法有哪些方法有哪些方法

A. 資料庫設計的設計技巧

（需求分析階段）
1) 理解客戶需求，詢問用戶如何看待未來需求變化。讓客戶解釋其需求，而且隨著開發的繼續，還要經常詢問客戶保證其需求仍然在開發的目的之中。
2) 了解企業業務可以在以後的開發階段節約大量的時間。
3) 重視輸入輸出。
在定義資料庫表和欄位需求（輸入）時，首先應檢查現有的或者已經設計出的報表、查詢和視圖（輸出）以決定為了支持這些輸出哪些是必要的表和欄位。
舉例：假如客戶需要一個報表按照郵政編碼排序、分段和求和，你要保證其中包括了單獨的郵政編碼欄位而不要把郵政編碼糅進地址欄位里。
4) 創建數據字典和ER 圖表
ER 圖表和數據字典可以讓任何了解資料庫的人都明確如何從資料庫中獲得數據。ER圖對表明表之間關系很有用，而數據字典則說明了每個欄位的用途以及任何可能存在的別名。對SQL表達式的文檔化來說這是完全必要的。
5) 定義標準的對象命名規范
資料庫各種對象的命名必須規范。 （資料庫邏輯設計）
表設計原則
1) 標准化和規范化
數據的標准化有助於消除資料庫中的數據冗餘。標准化有好幾種形式，但Third Normal Form（3NF）通常被認為在性能、擴展性和數據完整性方面達到了最好平衡。簡單來說，遵守3NF 標準的資料庫的表設計原則是：「One Fact in One Place」即某個表只包括其本身基本的屬性，當不是它們本身所具有的屬性時需進行分解。表之間的關系通過外鍵相連接。它具有以下特點：有一組表專門存放通過鍵連接起來的關聯數據。
舉例：某個存放客戶及其有關定單的3NF資料庫就可能有兩個表：Customer 和Order。Order 表不包含定單關聯客戶的任何信息，但表內會存放一個鍵值，該鍵指向Customer 表裡包含該客戶信息的那一行。
事實上，為了效率的緣故，對表不進行標准化有時也是必要的。
2) 數據驅動
採用數據驅動而非硬編碼的方式，許多策略變更和維護都會方便得多，大大增強系統的靈活性和擴展性。
舉例，假如用戶界面要訪問外部數據源（文件、XML 文檔、其他資料庫等），不妨把相應的連接和路徑信息存儲在用戶界面支持表裡。還有，如果用戶界面執行工作流之類的任務（發送郵件、列印信箋、修改記錄狀態等），那麼產生工作流的數據也可以存放在資料庫里。角色許可權管理也可以通過數據驅動來完成。事實上，如果過程是數據驅動的，你就可以把相當大的責任推給用戶，由用戶來維護自己的工作流過程。
3) 考慮各種變化
在設計資料庫的時候考慮到哪些數據欄位將來可能會發生變更。
舉例，姓氏就是如此（注意是西方人的姓氏，比如女性結婚後從夫姓等）。所以，在建立系統存儲客戶信息時，在單獨的一個數據表裡存儲姓氏欄位，而且還附加起始日和終止日等欄位，這樣就可以跟蹤這一數據條目的變化。
4) 每個表中都應該添加的3 個有用的欄位
dRecordCreationDate，在VB 下默認是Now()，而在SQL Server · 下默認為GETDATE()
sRecordCreator，在SQL Server 下默認為NOT NULL DEFAULT · USER
nRecordVersion，記錄的版本標記；有助於准確說明記錄中出現null 數據或者丟失數據的原因 ·
5) 對地址和電話採用多個欄位
描述街道地址就短短一行記錄是不夠的。 Address_Line1、Address_Line2 和Address_Line3 可以提供更大的靈活性。還有，電話號碼和郵件地址最好擁有自己的數據表，其間具有自身的類型和標記類別。
6) 使用角色實體定義屬於某類別的列
在需要對屬於特定類別或者具有特定角色的事物做定義時，可以用角色實體來創建特定的時間關聯關系，從而可以實現自我文檔化。
舉例：用PERSON 實體和PERSON_TYPE 實體來描述人員。比方說，當John Smith, Engineer 提升為John Smith, Director 乃至最後爬到John Smith, CIO 的高位，而所有你要做的不過是改變兩個表PERSON 和PERSON_TYPE 之間關系的鍵值，同時增加一個日期/時間欄位來知道變化是何時發生的。這樣，你的PERSON_TYPE 表就包含了所有PERSON 的可能類型，比如Associate、Engineer、Director、CIO 或者CEO 等。還有個替代辦法就是改變PERSON 記錄來反映新頭銜的變化，不過這樣一來在時間上無法跟蹤個人所處位置的具體時間。
7) 選擇數字類型和文本類型盡量充足
在SQL 中使用smallint 和tinyint 類型要特別小心。比如，假如想看看月銷售總額，總額欄位類型是smallint，那麼，如果總額超過了$32,767 就不能進行計算操作了。
而ID 類型的文本欄位，比如客戶ID 或定單號等等都應該設置得比一般想像更大。假設客戶ID 為10 位數長。那你應該把資料庫表欄位的長度設為12 或者13 個字元長。但這額外占據的空間卻無需將來重構整個資料庫就可以實現資料庫規模的增長了。
8) 增加刪除標記欄位
在表中包含一個「刪除標記」欄位，這樣就可以把行標記為刪除。在關系資料庫里不要單獨刪除某一行；最好採用清除數據程序而且要仔細維護索引整體性。 （資料庫邏輯設計）
鍵選擇原則：
1) 鍵設計4 原則為
關聯欄位創建外鍵。
所有的鍵都必須唯一。
避免使用復合鍵。
外鍵總是關聯唯一的鍵欄位。
2) 使用系統生成的主鍵
設計資料庫的時候採用系統生成的鍵作為主鍵，那麼實際控制了資料庫的索引完整性。這樣，資料庫和非人工機制就有效地控制了對存儲數據中每一行的訪問。採用系統生成鍵作為主鍵還有一個優點：當擁有一致的鍵結構時，(不讓主鍵具有可更新性)
在確定採用什麼欄位作為表的鍵的時候，可一定要小心用戶將要編輯的欄位。通常的情況下不要選擇用戶可編輯的欄位作為鍵。
4) 可選鍵有時可做主鍵
把可選鍵進一步用做主鍵，可以擁有建立強大索引的能力。
索引使用原則：
索引是從資料庫中獲取數據的最高效方式之一。95%的資料庫性能問題都可以採用索引技術得到解決。
1) 邏輯主鍵使用唯一的成組索引，對系統鍵（作為存儲過程）採用唯一的非成組索引，對任何外鍵列採用非成組索引。考慮資料庫的空間有多大，表如何進行訪問，還有這些訪問是否主要用作讀寫。
2) 大多數資料庫都索引自動創建的主鍵欄位，但是可別忘了索引外鍵，它們也是經常使用的鍵，比如運行查詢顯示主表和所有關聯表的某條記錄就用得上。
3) 不要索引memo/note 欄位，不要索引大型欄位（有很多字元），這樣作會讓索引佔用太多的存儲空間。
4) 不要索引常用的小型表
不要為小型數據表設置任何鍵，假如它們經常有插入和刪除操作就更別這樣作了。對這些插入和刪除操作的索引維護可能比掃描表空間消耗更多的時間。 （資料庫邏輯設計）
1) 完整性實現機制：
實體完整性：主鍵
參照完整性：
父表中刪除數據：級聯刪除；受限刪除；置空值
父表中插入數據：受限插入；遞歸插入
父表中更新數據：級聯更新；受限更新；置空值
DBMS對參照完整性可以有兩種方法實現：外鍵實現機制（約束規則）和觸發器實現機制
用戶定義完整性：
NOT NULL；CHECK；觸發器
2) 用約束而非商務規則強制數據完整性
採用資料庫系統實現數據的完整性。這不但包括通過標准化實現的完整性而且還包括數據的功能性。在寫數據的時候還可以增加觸發器來保證數據的正確性。不要依賴於商務層保證數據完整性；它不能保證表之間（外鍵）的完整性所以不能強加於其他完整性規則之上。
3) 強制指示完整性
在有害數據進入資料庫之前將其剔除。激活資料庫系統的指示完整性特性。這樣可以保持數據的清潔而能迫使開發人員投入更多的時間處理錯誤條件。
4) 使用查找控制數據完整性
控制數據完整性的最佳方式就是限制用戶的選擇。只要有可能都應該提供給用戶一個清晰的價值列表供其選擇。這樣將減少鍵入代碼的錯誤和誤解同時提供數據的一致性。某些公共數據特別適合查找：國家代碼、狀態代碼等。
5) 採用視圖
為了在資料庫和應用程序代碼之間提供另一層抽象，可以為應用程序建立專門的視圖而不必非要應用程序直接訪問數據表。這樣做還等於在處理資料庫變更時給你提供了更多的自由。 1) 避免使用觸發器
觸發器的功能通常可以用其他方式實現。在調試程序時觸發器可能成為干擾。假如你確實需要採用觸發器，你最好集中對它文檔化。
2) 使用常用英語（或者其他任何語言）而不要使用編碼
在創建下拉菜單、列表、報表時最好按照英語名排序。假如需要編碼，可以在編碼旁附上用戶知道的英語。
3) 保存常用信息
讓一個表專門存放一般資料庫信息非常有用。在這個表裡存放資料庫當前版本、檢查/修復（對 Access）、關聯設計文檔的名稱、客戶等信息。這樣可以實現一種簡單機制跟蹤資料庫，當客戶抱怨他們的資料庫沒有達到希望的要求而與你聯系時，這樣做對非客戶機/伺服器環境特別有用。
4) 包含版本機制
在資料庫中引入版本控制機制來確定使用中的資料庫的版本。時間一長，用戶的需求總是會改變的。最終可能會要求修改資料庫結構。把版本信息直接存放到資料庫中更為方便。
5) 編制文檔
採用給表、列、觸發器等加註釋的資料庫工具。對開發、支持和跟蹤修改非常有用。
對資料庫文檔化，或者在資料庫自身的內部或者單獨建立文檔。這樣，當過了一年多時間後再回過頭來做第2 個版本，犯錯的機會將大大減少。
6) 測試、測試、反復測試
建立或者修訂資料庫之後，必須用用戶新輸入的數據測試數據欄位。最重要的是，讓用戶進行測試並且同用戶一道保證選擇的數據類型滿足商業要求。測試需要在把新資料庫投入實際服務之前完成。
7) 檢查設計
在開發期間檢查資料庫設計的常用技術是通過其所支持的應用程序原型檢查資料庫。換句話說，針對每一種最終表達數據的原型應用，保證你檢查了數據模型並且查看如何取出數據。

B. ERP管理軟體資料庫系統的幾種設計方法

1. 自增長primary key採用自增長primary key主要是性能。早期的資料庫系統，經常採用某種編號，比如身份證號碼，公司編號等等作為資料庫表的primary key。然而，很快，大家就發現其中的不利之處。 比如早期的醫院管理系統，用身份證號碼作為病人表的primary key。然而，第一，不是每個人都有身份證；第二，對於國外來的病人，不同國家的病人的證件號碼並不見得沒有重復。因此，用身份證號碼作為病人表的primary key是一個非常糟糕的設計。考慮到沒有醫生或者護士會刻意去記這些號碼，使用自增長primary key是更好的設計。 公司編號採用某種特定的編碼方法，這也是早期的資料庫系統常見的做法。它的缺點也顯而易見：很容易出現像千年蟲的軟體問題，因為當初設計資料庫表的時候設計的位數太短，導致系統使用幾年後不能滿足要求，只有修改程序才能繼續使用。問題在於，任何人設計系統的時候，在預計某某編號多少位可以夠用的時候，都存在預計不準的風險。而採用自增長primary key 則不存在這種問題。同樣的道理，沒有人可以去記這些號碼。 使用自增長primary key另外一個原因是性能問題。略有編程常識的人都知道，數字大小比較比字元串大小比較要快得多。使用自增長primary key可以大大地提高數據查找速度。 2. 避免用復合主鍵 (compound primary key)這主要還是因為性能問題。數據檢索是要用到大量的 primary key 值比較，只比較一個欄位比比較多個欄位快很多。使用單個primary key 從編程的角度也很有好處， sql 語句中 where 條件可以寫更少的代碼，這意味著出錯的機會大大減少。 3. 雙主鍵雙主鍵是指資料庫表有兩個欄位，這兩個欄位獨立成為主鍵，但又同時存在。 資料庫系統的雙主鍵最早用在用戶管理模塊。最早的來源可能是參照操作系統的用戶管理模塊。 操作系統的用戶管理有兩個獨立的主鍵：操作系統自己自動生成的隨機 ID (Linux, windows 的 SID), login id。這兩個 ID 都必須是唯一的，不同的是，刪除用戶 test 然後增加一個用戶 test, SID 不同，login id 相同。採用雙主鍵主要目的是為了防止刪除後增加同樣的 login id 造成的混亂。比如銷售經理 hellen 本機共享文件給總經理 peter, 一年後總經理離開公司，進來一個普通員工 peter ，兩個peter 用同樣的 login id, 如果只用 login id 作操作系統的用戶管理主鍵，則存在漏洞：普通員工 peter 可以訪問原來只有總經理才能看的文件。操作系統自己自動生成的隨機 ID 一般情況下面用戶是看不到的。 雙主鍵現在已經廣泛用在各種資料庫系統中，不限於用戶管理系統。 4. 以固定的資料庫、表應付變化的客戶需求這主要基於以下幾個因素的考慮： ◆4.1 大型EPR系統的正常使用、維護需要軟體廠商及其眾多的合作夥伴共同給客戶提供技術服務，包括大量的二次開發。 如果用戶在軟體正常使用過程中需要增加新的表或者資料庫，將給軟體廠商及其眾多的合作夥伴帶來難題。 ◆4.2 軟體升級的需要。 沒有一個軟體能夠讓客戶使用幾十上百年不用升級的。軟體升級往往涉及資料庫表結構的改變。軟體廠商會做額外的程序將早期版本軟體的資料庫數據升級到新的版本，但是對於用戶使用過程中生成的表進行處理就比較為難。 ◆4.3 軟體開發的需要。 使用固定的資料庫庫表從開發、二次開發來說，更加容易。對於用戶使用過程中生成的表，每次查找數據時都要先查表名，再找數據，比較麻煩。 舉例來說，早期的用友財務軟體用Access作資料庫，每年建立一個新的資料庫。很快，用戶和用友公司都發現，跨年度數據分析很難做。因此這是一個不好的設計。在 ERP 中，很少有不同的年度數據單獨分開。一般來說，所有年份的數據都在同一個表中。對於跨國公司甚至整個集團公司都用同一個 ERP 系統的時候，所有公司的數據都在一起。這樣的好處是數據分析比較容易做。 現在大多數資料庫系統都能做到在常數時間內返回一定量的數據。比如，Oracle 資料庫中，根據 primary key 在 100萬條數據中取 10 條數據，與在1 億條數據中取 10 條數據，時間相差並不多。 5. 避免一次取資料庫大量數據，取大量數據一定要用分頁這基本上是現在很多資料庫系統設計的基本守則。ERP 系統中超過 100萬條數據的表很多，對於很多表中的任何一個，一次取所有的會導致資料庫伺服器長時間處於停滯狀態，並且影響其它在線用戶的系統響應速度。 一般來說，日常操作，在分頁顯示的情況下面，每次取得數據在 1-100 之間，系統響應速度足夠快，客戶端基本沒有特別長的停頓。這是比較理想的設計。這也是大型資料庫系統往往用 ODBC, ADO 等等通用的資料庫聯接組件而不用特定的速度較快的專用資料庫聯接組件的原因。因為系統瓶頸在於資料庫( Database) 方面(數據量大)，而不在於客戶端(客戶端每次只取少量數據)。 在B/S 資料庫系統中，分頁非常普遍。早期的資料庫系統經常有客戶端程序中一次性取大量數據做緩沖。現在已經不是特別需要了，主要原因有： ◆5.1 資料庫本身的緩沖技術大大提高 大部分資料庫都會自動將常用的數據自動放在內存中緩沖，以提高性能。 ◆5.2 資料庫聯接組件的緩沖技術也在提高。 包括ADO 在內的一些資料庫聯接組件都會自動對數據結果集(result set)進行緩沖，並且效果不錯。比較新穎的資料庫聯接組件，比如 Hibernate 也加入了一些數據結果集緩沖功能。 當然，也有一些資料庫聯接組件沒有對數據結果集進行緩沖，比如 JDBC Driver，不過幾年之內情況應該有所改觀。也有些不太成功的數據緩沖，比如 EJB 中的實體Bean，性能就不盡如人意，實體Bean數據也是放在內存中，可能是因為佔用內存過多的緣故。 相對來說，今天的程序員寫客戶端數據緩沖，能夠超過以上兩個緩沖效果的，已經比較難了。

C. 資料庫概念設計的方法是什麼

資料庫概念構設計的任務是在需求分析階段產生的需求說明書的基礎上，按照特定的方法把它們抽象為一個不依賴於任何具體機器的數據模型，即概念模型。

概念模型使設計者的注意力能夠從復雜的實現細節中解脫出來，而只集中在最重要的信息的組織結構和處理模式上。

D. 資料庫設計的步驟有哪些

資料庫的設計過程大致可分為以下六個階段：

1. 需求分析階段

需求收集和分析，結果得到數據字典描述的數據需求（和數據流圖描述的處理需求）。

2. 概念結構設計階段

通過對用戶需求進行綜合、歸納與抽象，形成一個獨立於具體DBMS的概念模型，可以用E-R圖表示。

3. 邏輯結構設計階段

將概念結構轉換為某個DBMS所支持的數據模型（例如關系模型），並對其進行優化。

4. 資料庫物理設計階段

為邏輯數據模型選取一個最適合應用環境的物理結構（包括存儲結構和存取方法）。

5. 資料庫實施階段

運用DBMS提供的數據語言（例如SQL）及其宿主語言（例如C），根據邏輯設計和物理設計的結果建立資料庫，編制與調試應用程序，組織數據入庫，並進行試運行。

6. 資料庫運行和維護階段

資料庫應用系統經過試運行後即可投入正式運行。在資料庫系統運行過程中必須不斷地對其進行評價、調整與修改。