資料庫設計原則

Ⅰ 請大夥給我解釋一下資料庫設計的基本原則！

資料庫設計的三範式所謂範式，是關系型資料庫關系模式規范化的標准，從規范化的寬松到嚴格，分別為不同的範式，通常使用的有第一範式、第二範式、第三範式及BC範式等。範式是建立在函數依賴基礎上的。

函數依賴

定義：設有關系模式R(U)，X和Y是屬性集U的子集，函數依賴是形為X→Y的一個命題，對任意R中兩個元組t和s，都有t[X]=s[X]蘊涵t[Y]=s[Y]，那麼FD X→Y在關系模式R(U)中成立。X→Y讀作『X函數決定Y』，或『Y函數依賴於X』。通俗的講，如果一個表中某一個欄位Y的值是由另外一個欄位或一組欄位X的值來確定的，就稱為Y函數依賴於X。函數依賴應該是通過理解數據項和企業的規則來決定的，根據表的內容得出的函數依賴可能是不正確的。

第一範式（1NF）

定義：如果關系模式R的每個關系r的屬性都是不可分的數據項，那麼就稱R是第一範式的模式。
簡單的說，每一個屬性都是原子項，不可分割。1NF是關系模式應具備的最起碼的條件，如果資料庫設計不能滿足第一範式，就不稱為關系型資料庫。關系資料庫設計研究的關系規范化是在1NF之上進行的。

第二範式（2NF）

定義：如果關系模式R是1NF，且每個非主屬性完全函數依賴於候選鍵，那麼就稱R是第二範式。
簡單的說，第二範式要滿足以下的條件：首先要滿足第一範式，其次每個非主屬性要完全函數依賴與候選鍵，或者是主鍵。也就是說，每個非主屬性是由整個主鍵函數決定的，而不能由主鍵的一部分來決定。舉個例子：
有股票日行情表的主鍵是股 票代碼和交易日期組成。非主屬性中有收盤價和成交量等，都是由主鍵，即股票代碼和交易日期函數決定的，單獨的股票代碼或者交易日期都不能函數決定這些非主 屬性。如果這個表中有非主屬性股票簡稱，則股票簡稱是可以由股票代碼來函數決定的，這樣股票簡稱這個非主屬性就不是完全函數依賴於候選鍵，這樣的設計就不 滿足第二範式。

第三範式（3NF）
定義：如果關系模式R是2NF，且關系模式R（U，F）中的所有非主屬性對任何候選關鍵字都不存在傳遞依賴，則稱關系R是屬於第三範式。
簡單的說，第三範式要滿足以下的條件：首先要滿足第二範式，其次非主屬性之間不存在函數依賴。由於滿足了第二範式，表示每個非主屬性都函數依賴於主鍵。如果非主屬性之間存在了函數依賴，就會存在傳遞依賴，這樣就不滿足第三範式。
舉 個例子：在股票基本情況表中，主鍵是股票代碼，有非主屬性所屬一級行業和所屬二級行業。根據業務規則，所屬二級行業能夠函數決定所屬一級行業，這就表示存 在這樣一種關系：股票代碼函數決定所屬二級行業，所屬二級行業函數決定所屬一級行業，這就形成了傳遞依賴，這樣的設計就不符合第三範式。不過在實際運用 中，為查詢和使用的方便，有時也會違反第三範式。如上例，如果沒有所屬一級行業的屬性，需要查詢所屬一級行業的相關股票，需要查詢時使用函數來從二級行業 中函數生成所屬一級行業，使用性能上會受影響。所以通常會加上所屬一級行業的屬性。

BC範式（BCNF）

BC範式是第三範式的增強版，不過也有人說是直接從1NF發展過來的，即每個屬性，包括主屬性或非主屬性，都完全依賴於候選鍵，並且不存在傳遞依賴情況。

Ⅱ 資料庫完整性的設計原則

在實施資料庫完整性設計的時候，有一些基本的原則需要把握：
1．根據資料庫完整性約束的類型確定其實現的系統層次和方式，並提前考慮對系統性能的影響。一般情況下，靜態約束應盡量包含在資料庫模式中，而動態約束由應用程序實現。
2．實體完整性約束、參照完整性約束是關系資料庫最重要的完整性約束，在不影響系統關鍵性能的前提下需盡量應用。用一定的時間和空間來換取系統的易用性是值得的。
3．另一方面，觸發器的多級觸發不好控制，容易發生錯誤，非用不可時，最好使用Before型語句級觸發器。
4．在需求分析階段就必須制定完整性約束的命名規范，盡量使用有意義的英文單詞、縮寫詞、表名、列名及下劃線等組合，使其易於識別和記憶，如：CKC_EMP_REAL_INCOME_EMPLOYEE、PK_EMPLOYEE、CKT_EMPLOYEE。如果使用CASE工具，一般有預設的規則，可在此基礎上修改使用。
5．要根據業務規則對資料庫完整性進行細致的測試，以盡早排除隱含的完整性約束間的沖突和對性能的影響。
6．要有專職的資料庫設計小組，自始至終負責資料庫的分析、設計、測試、實施及早期維護。資料庫設計人員不僅負責基於DBMS的資料庫完整性約束的設計實現，還要負責對應用軟體實現的資料庫完整性約束進行審核。
7．應採用合適的CASE工具來降低資料庫設計各階段的工作量。好的CASE工具能夠支持整個資料庫的生命周期，這將使資料庫設計人員的工作效率得到很大提高，同時也容易與用戶溝通。

Ⅲ 簡述資料庫系統構成的及資料庫的設計原則。

資料庫系統（database systems），是由資料庫及其管理軟體組成的系統。它是為適應數據處理的需要而發展起來的一種較為理想的數據處理的核心機構。它是一個實際可運行的存儲、維護和向應用系統提供數據的軟體系統，是存儲介質、處理對象和管理系統的集合體。 資料庫系統DBS（Data Base System，簡稱DBS）通常由軟體、資料庫和數據管理員組成。其軟體主要包括操作系統、各種宿主語言、實用程序以及資料庫管理系統。資料庫由資料庫管理系統統一管理，數據的插入、修改和檢索均要通過資料庫管理系統進行。數據管理員負責創建、監控和維護整個資料庫，使數據能被任何有權使用的人有效使用。資料庫管理員一般是由業務水平較高、資歷較深的人員擔任。 資料庫系統的個體含義是指一個具體的資料庫管理系統軟體和用它建立起來的資料庫；它的學科含義是指研究、開發、建立、維護和應用資料庫系統所涉及的理論、方法、技術所構成的學科。在這一含義下，資料庫系統是軟體研究領域的一個重要分支，常稱為資料庫領域。

Ⅳ 大型資料庫設計原則

一個好的資料庫產品不等於就有一個好的應用系統 如果不能設計一個合理的資料庫模型 不僅會增加客戶端和伺服器段程序的編程和維護的難度 而且將會影響系統實際運行的性能 一般來講 在一個MIS系統分析 設計 測試和試運行階段 因為數據量較小 設計人員和測試人員往往只注意到功能的實現 而很難注意到性能的薄弱之處 等到系統投入實際運行一段時間後 才發現系統的性能在降低 這時再來考慮提高系統性能則要花費更多的人力物力 而整個系統也不可避免的形成了一個打補丁工程 筆者依據多年來設計和使用資料庫的經驗 提出以下一些設計准則 供同仁們參考

命名的規范

不同的資料庫產品對對象的命名有不同的要求 因此 資料庫中的各種對象的命名 後台程序的代碼編寫應採用大小寫敏感的形式 各種對象命名長度不要超過 個字元 這樣便於應用系統適應不同的資料庫

游標（Cursor）的慎用

游標提供了對特定集合中逐行掃描的手段 一般使用游標逐行遍歷數據 根據取出的數據不同條件進行不同的操作 尤其對多表和大表定義的游標（大的數據集合）循環很容易使程序進入一個漫長的等特甚至死機 筆者在某市《住房公積金管理系統》進行日終帳戶滾積數計息處理時 對一個 萬個帳戶的游標處理導致程序進入了一個無限期的等特（後經測算需 個小時才能完成）(硬體環境 Alpha/ Mram Sco Unix Sybase ) 後根據不同的條件改成用不同的UPDATE語句得以在二十分鍾之內完成 示例如下

Declare Mycursor cursor for select count_no from COUNT

Open Mycursor

Fetch Mycursor into @vcount_no

While (@@sqlstatus= )

Begin

If @vcount_no= 條件

操作

If @vcount_no= 條件

操作

Fetch Mycursor into @vcount_no

End

改為

Update COUNT set 操作 for 條件

Update COUNT set 操作 for 條件

在有些場合 有時也非得使用游標 此時也可考慮將符合條件的數據行轉入臨時表中 再對臨時表定義游標進行操作 可時性能得到明顯提高 筆者在某地市〈電信收費系統〉資料庫後台程序設計中 對一個表（ 萬行中符合條件的 多行數據）進行游標操作(硬體環境 PC伺服器 PII Mram NT Ms Sqlserver ) 示例如下

Create #tmp /* 定義臨時表 */

(欄位

欄位

)

Insert into #tmp select * from TOTAL where

條件 /* TOTAL中 萬行 符合條件只有幾十行 */

Declare Mycursor cursor for select * from #tmp

/*對臨時表定義游標*/

索引(Index)的使用原則

創建索引一般有以下兩個目的 維護被索引列的唯一性和提供快速訪問表中數據的策略 大型資料庫有兩種索引即簇索引和非簇索引 一個沒有簇索引的表是按堆結構存儲數據 所有的數據均添加在表的尾部 而建立了簇索引的表 其數據在物理上會按照簇索引鍵的順序存儲 一個表只允許有一個簇索引 因此 根據B樹結構 可以理解添加任何一種索引均能提高按索引列查詢的速度 但會降低插入 更新 刪除操作的性能 尤其是當填充因子（Fill Factor）較大時 所以對索引較多的表進行頻繁的插入 更新 刪除操作 建表和索引時因設置較小的填充因子 以便在各數據頁中留下較多的自由空間 減少頁分割及重新組織的工作

數據的一致性和完整性

為了保證資料庫的一致性和完整性 設計人員往往會設計過多的表間關聯（Relation） 盡可能的降低數據的冗餘 表間關聯是一種強制性措施 建立後 對父表（Parent Table）和子表(Child Table)的插入 更新 刪除操作均要佔用系統的開銷 另外 最好不要用Identify 屬性欄位作為主鍵與子表關聯 如果數據冗餘低 數據的完整性容易得到保證 但增加了表間連接查詢的操作 為了提高系統的響應時間 合理的數據冗餘也是必要的 使用規則（Rule）和約束（Check）來防止系統操作人員誤輸入造成數據的錯誤是設計人員的另一種常用手段 但是 不必要的規則和約束也會佔用系統的不必要開銷 需要注意的是 約束對數據的有效性驗證要比規則快 所有這些 設計人員在設計階段應根據系統操作的類型 頻度加以均衡考慮

事務的陷阱

事務是在一次性完成的一組操作 雖然這些操作是單個的操作 SQL Server能夠保證這組操作要麼全部都完成 要麼一點都不做 正是大型資料庫的這一特性 使得數據的完整性得到了極大的保證

眾所周知 SQL Server為每個獨立的SQL語句都提供了隱含的事務控制 使得每個DML的數據操作得以完整提交或回滾 但是SQL Server還提供了顯式事務控制語句

BEGIN TRANSACTION 開始一個事務

MIT TRANSACTION 提交一個事務

ROLLBACK TRANSACTION 回滾一個事務

事務可以嵌套 可以通過全局變數@@trancount檢索到連接的事務處理嵌套層次 需要加以特別注意並且極容易使編程人員犯錯誤的是 每個顯示或隱含的事物開始都使得該變數加 每個事務的提交使該變數減 每個事務的回滾都會使得該變數置 而只有當該變數為 時的事務提交（最後一個提交語句時） 這時才把物理數據寫入磁碟

資料庫性能調整

在計算機硬體配置和網路設計確定的情況下 影響到應用系統性能的因素不外乎為資料庫性能和客戶端程序設計 而大多數資料庫設計員採用兩步法進行資料庫設計 首先進行邏輯設計 而後進行物理設計 資料庫邏輯設計去除了所有冗餘數據 提高了數據吞吐速度 保證了數據的完整性 清楚地表達數據元素之間的關系 而對於多表之間的關聯查詢（尤其是大數據表）時 其性能將會降低 同時也提高了客 戶端程序的編程難度 因此 物理設計需折衷考慮 根據業務規則 確定對關聯表的數據量大小 數據項的訪問頻度 對此類數據表頻繁的關聯查詢應適當提高數據冗餘設計

數據類型的選擇

數據類型的合理選擇對於資料庫的性能和操作具有很大的影響 有關這方面的書籍也有不少的闡述 這里主要介紹幾點經驗

Identify欄位不要作為表的主鍵與其它表關聯 這將會影響到該表的數據遷移

Text 和Image欄位屬指針型數據 主要用來存放二進制大型對象（BLOB） 這類數據的操作相比其它數據類型較慢 因此要避開使用

日期型欄位的優點是有眾多的日期函數支持 因此 在日期的大小比較 加減操作上非常簡單 但是 在按照日期作為條件的查詢操作也要用函數 相比其它數據類型速度上就慢許多 因為用函數作為查詢的條件時 伺服器無法用先進的性能策略來優化查詢而只能進行表掃描遍歷每行

例如 要從DATA_TAB 中（其中有一個名為DATE的日期欄位）查詢 年的所有記錄

lishixin/Article/program/Oracle/201311/17929

Ⅳ 在系統設計中，對資料庫的設計應考慮哪些設計原則

資料庫是整個軟體應用的根基，是軟體設計的起點，它起著決定性的質變作用，因此我們必須對資料庫設計高度重視起來，培養設計良好資料庫的習慣，是一個優秀的軟體設計禪仿巧師所必須具備的基本素質條件！
那麼我們要做到什麼程度才是對的呢？下面就說說資料庫設計的原則：
1、資料庫設計最起碼要佔用整個項目開發的40%以上的時間
資料庫是需求的直觀反應和表現，因此設計時必須要切實符合用戶的需求，要多次與用戶溝通交流來細化需求，將需求中的要求和每一次的變化都要一一體現在資料庫的設計當中。如果需求不明確，就要分析不確定的因素，設計表時就要事先預留出可變通的欄位，正所謂「有備無患」。
2、資料庫設計不僅僅停留於頁面demo的表面
頁面內容所需要的欄位，在資料庫設計中只是一部分，還有系統運轉、模塊交互、中轉數據、表之間的聯系等等所需要的欄位，因此資料庫設計絕對不是簡單的基本數據存儲，還有邏輯數據存儲。
3、資料庫設計完成後，項目80%的設計開發在你腦海中就已經完成了
每個欄位的設計都是大友有他必要賀鍵的意義的，你在設計每一個欄位的同時，就應該已經想清楚程序中如何去運用這些欄位，多張表的聯系在程序中是如何體現的。換句話說，你完成資料庫設計後，程序中所有的實現思路和實現方式在你的腦海中就已經考慮過了。如果達不到這種程度，那當進入編碼階段後，才發現要運用的技術或實現的方式資料庫無法支持，這時再改動資料庫就會很麻煩，會造成一系列不可預測的問題。
4、資料庫設計時就要考慮到效率和優化問題
一開始就要分析哪些表會存儲較多的數據量，對於數據量較大的表的設計往往是粗粒度的，也會冗餘一些必要的欄位，已達到盡量用最少的表、最弱的表關系去存儲海量的數據。並且在設計表時，一般都會對主鍵建立聚集索引，含有大數據量的表更是要建立索引以提供查詢性能。對於含有計算、數據交互、統計這類需求時，還要考慮是否有必要採用存儲過程。
5、添加必要的（冗餘）欄位
像「創建時間」、「修改時間」、「備注」、「操作用戶IP」和一些用於其他需求（如統計）的欄位等，在每張表中必須都要有，不是說只有系統中用到的數據才會存到資料庫中，一些冗餘欄位是為了便於日後維護、分析、拓展而添加的，這點是非常重要的，比如黑客攻擊，篡改了數據，我們便就可以根據修改時間和操作用戶IP來查找定位。
6、設計合理的表關聯
若多張表之間的關系復雜，建議採用第三張映射表來關聯維護兩張表之間的關系，以降低表之間的直接耦合度。若多張表涉及到大數據量的問題，表結構盡量簡單，關聯也要盡可能避免。
7、設計表時不加主外鍵等約束性關聯，系統編碼階段完成後再添加約束性關聯
這樣做的目的是有利於團隊並行開發，減少編碼時所遇到的問題，表之間的關系靠程序來控制。編碼完成後再加關聯並進行測試。不過也有一些公司的做法是乾脆就不加表關聯。
8、選擇合適的主鍵生成策略

Ⅵ 在系統實施中，資料庫設計的原則

1. 原始單據與實體之間的關系
可以是一對一、一對多、多對多的關系。在一般情況下，它們是一對一的關系：即一張原始單據對應且只對應一個實體。
在特殊情況下，它們可能是一對多或多對一的關系，即一張原始單證對應多個實體，或多張原始單證對應一個實體。
這里的實體可以理解為基本表。

〖例1〗：一份員工履歷資料，在人力資源信息系統中，就對應三個基本表：員工基本情況表、社會關系表、工作簡歷表。 這就是「一張原始單證對應多個實體」的典型例子。

2. 主鍵與外鍵
一般而言，一個實體不能既無主鍵又無外鍵。在E—R 圖中, 處於葉子部位的實體, 可以定義主鍵，也可以不定義主鍵 (因為它無子孫), 但必須要有外鍵(因為它有父親)。

主鍵與外鍵的設計，在全局資料庫的設計中，佔有重要地位。主鍵是實體的高度抽象，主鍵與外鍵的配對，表示實體之間的連接。

3. 基本表的性質
基本表與中間表、臨時表不同，因為它具有如下四個特性：
(1) 原子性。基本表中的欄位是不可再分解的。
(2) 原始性。基本表中的記錄是原始數據（基礎數據）的記錄。
(3) 演繹性。由基本表與代碼表中的數據，可以派生出所有的輸出數據。
(4) 穩定性。基本表的結構是相對穩定的，表中的記錄是要長期保存的。
理解基本表的性質後，在設計資料庫時，就能將基本表與中間表、臨時表區分開來。

4. 範式標准
基本表及其欄位之間的關系, 應盡量滿足第三範式。但是，滿足第三範式的資料庫設計，往往不是最好的設計。
為了提高資料庫的運行效率，常常需要降低範式標准：適當增加冗餘，達到以空間換時間的目的。

〖例2〗：有一張存放商品的基本表，如表1所示。「金額」這個欄位的存在，表明該表的設計不滿足第三範式， 因為「金額」可以由「單價」乘以「數量」得到，說明「金額」是冗餘欄位。但是，增加「金額」這個冗餘欄位， 可以提高查詢統計的速度，這就是以空間換時間的作法。 在Rose 2002中，規定列有兩種類型：數據列和計算列。「金額」這樣的列被稱為「計算列」，而「單價」和 「數量」這樣的列被稱為「數據列」。
5. 通俗地理解三個範式
通俗地理解三個範式，對於資料庫設計大有好處。在資料庫設計中，為了更好地應用三個範式，就必須通俗地理解
三個範式(通俗地理解是夠用的理解，並不是最科學最准確的理解)：
第一範式：1NF是對屬性的原子性約束，要求屬性具有原子性，不可再分解；
第二範式：2NF是對記錄的惟一性約束，要求記錄有惟一標識，即實體的惟一性；
第三範式：3NF是對欄位冗餘性的約束，即任何欄位不能由其他欄位派生出來，它要求欄位沒有冗餘。

沒有冗餘的資料庫設計可以做到。但是，沒有冗餘的資料庫未必是最好的資料庫，有時為了提高運行效率，就必須降
低範式標准，適當保留冗餘數據。具體做法是：在概念數據模型設計時遵守第三範式，降低範式標準的工作放到物理
數據模型設計時考慮。降低範式就是增加欄位，允許冗餘。

6. 要善於識別與正確處理多對多的關系
若兩個實體之間存在多對多的關系，則應消除這種關系。消除的辦法是，在兩者之間增加第三個實體。這樣，原來一
個多對多的關系，現在變為兩個一對多的關系。要將原來兩個實體的屬性合理地分配到三個實體中去。這里的第三個
實體，實質上是一個較復雜的關系，它對應一張基本表。一般來講，資料庫設計工具不能識別多對多的關系，但能處
理多對多的關系。

〖例3〗：在「圖書館信息系統」中，「圖書」是一個實體，「讀者」也是一個實體。這兩個實體之間的關系，是一 個典型的多對多關系：一本圖書在不同時間可以被多個讀者借閱，一個讀者又可以借多本圖書。為此，要在二者之 間增加第三個實體，該實體取名為「借還書」，它的屬性為：借還時間、借還標志(0表示借書，1表示還書)，另外， 它還應該有兩個外鍵(「圖書」的主鍵，「讀者」的主鍵)，使它能與「圖書」和「讀者」連接。

7. 主鍵PK的取值方法
PK是供程序員使用的表間連接工具，可以是一無物理意義的數字串, 由程序自動加1來實現。也可以是有物理意義
的欄位名或欄位名的組合。不過前者比後者好。當PK是欄位名的組合時，建議欄位的個數不要太多，多了不但索引 佔用空間大，而且速度也慢。

8. 正確認識數據冗餘
主鍵與外鍵在多表中的重復出現, 不屬於數據冗餘，這個概念必須清楚，事實上有許多人還不清楚。非鍵欄位的重復出現, 才是數據冗餘！而且是一種低級冗餘，即重復性的冗餘。高級冗餘不是欄位的重復出現，而是欄位的派生出現。

〖例4〗：商品中的「單價、數量、金額」三個欄位，「金額」就是由「單價」乘以「數量」派生出來的，它就是冗餘，而且是一種高級冗餘。冗餘的目的是為了提高處理速度。只有低級冗餘才會增加數據的不一致性，因為同一數據，可 能從不同時間、地點、角色上多次錄入。因此，我們提倡高級冗餘(派生性冗餘)，反對低級冗餘(重復性冗餘)。

9. E--R圖沒有標准答案
信息系統的E--R圖沒有標准答案，因為它的設計與畫法不是惟一的，只要它覆蓋了系統需求的業務范圍和功能內容，就是可行的。反之要修改E--R圖。盡管它沒有惟一的標准答案，並不意味著可以隨意設計。好的E—R圖的標準是： 結構清晰、關聯簡潔、實體個數適中、屬性分配合理、沒有低級冗餘。

10 . 視圖技術在資料庫設計中很有用
與基本表、代碼表、中間表不同，視圖是一種虛表，它依賴數據源的實表而存在。視圖是供程序員使用資料庫的 一個窗口，是基表數據綜合的一種形式, 是數據處理的一種方法，是用戶數據保密的一種手段。為了進行復雜處理、 提高運算速度和節省存儲空間, 視圖的定義深度一般不得超過三層。 若三層視圖仍不夠用, 則應在視圖上定義臨時表, 在臨時表上再定義視圖。這樣反復交迭定義, 視圖的深度就不受限制了。

對於某些與國家政治、經濟、技術、軍事和安全利益有關的信息系統，視圖的作用更加重要。這些系統的基本表完 成物理設計之後，立即在基本表上建立第一層視圖，這層視圖的個數和結構，與基本表的個數和結構是完全相同。 並且規定，所有的程序員，一律只准在視圖上操作。只有資料庫管理員，帶著多個人員共同掌握的「安全鑰匙」， 才能直接在基本表上操作。

11. 中間表、報表和臨時表
中間表是存放統計數據的表，它是為數據倉庫、輸出報表或查詢結果而設計的，有時它沒有主鍵與外鍵(數據倉 庫除外)。臨時表是程序員個人設計的，存放臨時記錄，為個人所用。基表和中間表由DBA維護，臨時表由程序員 自己用程序自動維護。

12. 完整性約束表現在三個方面
域的完整性：用Check來實現約束，在資料庫設計工具中，對欄位的取值范圍進行定義時，有一個Check按鈕，通 過它定義欄位的值城。
參照完整性：用PK、FK、表級觸發器來實現。
用戶定義完整性：它是一些業務規則，用存儲過程和觸發器來實現。

13. 防止資料庫設計打補丁的方法是「三少原則」
(1) 一個資料庫中表的個數越少越好。只有表的個數少了，才能說明系統的E--R圖少而精，去掉了重復的多餘的 實體，形成了對客觀世界的高度抽象，進行了系統的數據集成，防止了打補丁式的設計；

(2) 一個表中組合主鍵的欄位個數越少越好。因為主鍵的作用，一是建主鍵索引，二是做為子表的外鍵，所以組 合主鍵的欄位個數少了，不僅節省了運行時間，而且節省了索引存儲空間；

(3) 一個表中的欄位個數越少越好。只有欄位的個數少了，才能說明在系統中不存在數據重復，且很少有數據冗 余，更重要的是督促讀者學會「列變行」，這樣就防止了將子表中的欄位拉入到主表中去，在主表中留下許 多空餘的欄位。所謂「列變行」，就是將主表中的一部分內容拉出去，另外單獨建一個子表。這個方法很簡 單，有的人就是不習慣、不採納、不執行。 資料庫設計的實用原則是：在數據冗餘和處理速度之間找到合適的平衡點。「三少」是一個整體概念，綜合觀點， 不能孤立某一個原則。該原則是相對的，不是絕對的。「三多」原則肯定是錯誤的。試想：若覆蓋系統同樣的功 能，一百個實體(共一千個屬性) 的E--R圖，肯定比二百個實體(共二千個屬性) 的E--R圖，要好得多。 提倡「三少」原則，是叫讀者學會利用資料庫設計技術進行系統的數據集成。數據集成的步驟是將文件系統集成 為應用資料庫，將應用資料庫集成為主題資料庫，將主題資料庫集成為全局綜合資料庫。集成的程度越高，數據 共享性就越強，信息孤島現象就越少，整個企業信息系統的全局E—R圖中實體的個數、主鍵的個數、屬性的個數就會越少。

提倡「三少」原則的目的，是防止讀者利用打補丁技術，不斷地對資料庫進行增刪改，使企業資料庫變成了隨意設計資料庫表的「垃圾堆」，或資料庫表的「大雜院」，最後造成資料庫中的基本表、代碼表、中間表、臨時表雜亂無章，不計其數，導致企事業單位的信息系統無法維護而癱瘓。 「三多」原則任何人都可以做到，該原則是「打補丁方法」設計資料庫的歪理學說。「三少」原則是少而精的 原則，它要求有較高的資料庫設計技巧與藝術，不是任何人都能做到的，因為該原則是杜絕用「打補丁方法」
設計資料庫的理論依據。

14. 提高資料庫運行效率的辦法
在給定的系統硬體和系統軟體條件下，提高資料庫系統的運行效率的辦法是：
(1) 在資料庫物理設計時，降低範式，增加冗餘, 少用觸發器, 多用存儲過程。
(2) 當計算非常復雜、而且記錄條數非常巨大時(例如一千萬條)，復雜計算要先在資料庫外面，以文件系統方 式用C++語言計算處理完成之後，最後才入庫追加到表中去。這是電信計費系統設計的經驗。
(3) 發現某個表的記錄太多，例如超過一千萬條，則要對該表進行水平分割。水平分割的做法是，以該表主鍵 PK的某個值為界線，將該表的記錄水平分割為兩個表。若發現某個表的欄位太多，例如超過八十個，則垂直分割該表，將原來的一個表分解為兩個表。
(4) 對資料庫管理系統DBMS進行系統優化，即優化各種系統參數，如緩沖區個數。
(5) 在使用面向數據的SQL語言進行程序設計時，盡量採取優化演算法。
總之，要提高資料庫的運行效率，必須從資料庫系統級優化、資料庫設計級優化、程序實現級優化，這三個層次上同時下功夫。

上述十四個技巧，是許多人在大量的資料庫分析與設計實踐中，逐步總結出來的。對於這些經驗的運用，讀者不能生幫硬套，死記硬背，而要消化理解，實事求是，靈活掌握。並逐步做到：在應用中發展，在發展中應用。

Ⅶ 大型資料庫的設計原則與開發技巧

隨著計算機技術越來越廣泛地應用於國民經濟的各個領域 在計算機硬體不斷微型化的同時 應用系統向著復雜化 大型化的方向發展 資料庫是整個系統的核心 它的設計直接關系系統執行的效率和系統的穩定性 因此在軟體系統開發中 資料庫設計應遵循必要的資料庫範式理論 以減少冗餘 保證數據的完整性與正確性 只有在合適的資料庫產品上設計出合理的資料庫模型 才能降低整個系統的編程和維護難度 提高系統的實際運行效率 雖然對於小項目或中等規模的項目開發人員可以很容易地利用範式理論設計出一套符合要求的資料庫 但對於一個包含大型資料庫的軟體項目 就必須有一套完整的設計原則與技巧

一 成立數據小組

大型資料庫數據元素多 在設計上有必要成立專門的數據小組 由於資料庫設計者不一定是使用者 對系統設計中的數據元素不可能考慮周全 資料庫設計出來後 往往難以找到所需的庫表 因此數據小組最好由熟悉業務的項目骨幹組成

數據小組的職能並非是設計資料庫 而是通過需求分析 在參考其他相似系統的基礎上 提取系統的基本數據元素 擔負對資料庫的審核 審核內容包括審核新的資料庫元素是否完全 能否實現全部業務需求 對舊資料庫（如果存在舊系統）的分析及數據轉換 資料庫設計的審核 控制及必要調整

二 設計原則

規范命名 所有的庫名 表名 域名必須遵循統一的命名規則 並進行必要說明 以方便設計 維護 查詢

控制欄位的引用 在設計時 可以選擇適當的資料庫設計管理工具 以方便開發人員的分布式設計和數據小組的集中審核管理 採用統一的命名規則 如果設計的欄位已經存在 可直接引用 否則 應重新設計

庫表重復控制 在設計過程中 如果發現大部分欄位都已存在 開發人員應懷疑所設計的庫表是否已存在 通過對欄位所在庫表及相應設計人員的查詢 可以確認庫表是否確實重復

並發控制 設計中應進行並發控制 即對於同一個庫表 在同一時間只有一個人有控制權 其他人只能進行查詢

必要的討論 資料庫設計完成後 數據小組應與相關人員進行討論 通過討論來熟悉資料庫 從而對設計中存在的問題進行控制或從中獲取資料庫設計的必要信息

數據小組的審核 庫表的定版 修改最終都要通過數據小組的審核 以保證符合必要的要求

頭文件處理 每次數據修改後 數據小組要對相應的頭文件進行修改（可由管理軟體自動完成） 並通知相關的開發人員 以便進行相應的程序修改

三 設計技巧

分類拆分數據量大的表 對於經常使用的表（如某些參數表或代碼對照表） 由於其使用頻率很高 要盡量減少表中的記錄數量 例如 銀行的戶主賬表原來設計成一張表 雖然可以方便程序的設計與維護 但經過分析發現 由於數據量太大 會影響數據的迅速定位 如果將戶主賬表分別設計為活期戶主賬 定期戶主賬及對公戶主賬等 則可以大大提高查詢效率

索引設計 對於大的資料庫表 合理的索引能夠提高整個資料庫的操作效率 在索引設計中 索引欄位應挑選重復值較少的欄位 在對建有復合索引的欄位進行檢索時 應注意按照復合索引欄位建立的順序進行 例如 如果對一個 萬多條記錄的流水表以日期和流水號為序建立復合索引 由於在該表中日期的重復值接近整個表的記錄數 用流水號進行查詢所用的時間接近 秒 而如果以流水號為索引欄位建立索引進行相同的查詢 所用時間不到 秒 因此在大型資料庫設計中 只有進行合理的索引欄位選擇 才能有效提高整個資料庫的操作效率

數據操作的優化 在大型資料庫中 如何提高數據操作效率值得關注 例如 每在資料庫流水表中增加一筆業務 就必須從流水控製表中取出流水號 並將其流水號的數值加一 正常情況下 單筆操作的反應速度尚屬正常 但當用它進行批量業務處理時 速度會明顯減慢 經過分析發現 每次對流水控製表中的流水號數值加一時都要鎖定該表 而該表卻是整個系統操作的核心 有可能在操作時被其他進程鎖定 因而使整個事務操作速度變慢 對這一問題的解決的辦法是 根據批量業務的總筆數批量申請流水號 並對流水控製表進行一次更新 即可提高批量業務處理的速度 另一個例子是對插表的優化 對於大批量的業務處理 如果在插入資料庫表時用普通的Insert語句 速度會很慢 其原因在於 每次插表都要進行一次I/O操作 花費較長的時間 改進後 可以用Put語句等緩沖區形式等滿頁後再進行I/O操作 從而提高效率 對大的資料庫表進行刪除時 一般會直接用Delete語句 這個語句雖然可以進行小表操作 但對大表卻會因帶來大事務而導致刪除速度很慢甚至失敗 解決的方法是去掉事務 但更有效的辦法是先進行Drop操作再進行重建

資料庫參數的調整 資料庫參數的調整是一個經驗不斷積累的過程 應由有經驗的系統管理員完成 以Informix資料庫為例 記錄鎖的數目太少會造成鎖表的失敗 邏輯日誌的文件數目太少會造成插入大表失敗等 這些問題都應根據實際情況進行必要的調整

必要的工具 在整個資料庫的開發與設計過程中 可以先開發一些小的應用工具 如自動生成庫表的頭文件 插入數據的初始化 數據插入的函數封裝 錯誤跟蹤或自動顯示等 以此提高資料庫的設計與開發效率

避免長事務 對單個大表的刪除或插入操作會帶來大事務 解決的辦法是對參數進行調整 也可以在插入時對文件進行分割 對於一個由一系列小事務順序操作共同構成的長事務（如銀行交易系統的日終交易） 可以由一系列操作完成整個事務 但其缺點是有可能因整個事務太大而使不能完成 或者 由於偶然的意外而使事務重做所需的時間太長 較好的解決方法是 把整個事務分解成幾個較小的事務 再由應用程序控制整個系統的流程 這樣 如果其中某個事務不成功 則只需重做該事務 因而既可節約時間 又可避免長事務

適當超前 計算機技術發展日新月異 資料庫的設計必須具有一定前瞻性 不但要滿足當前的應用要求 還要考慮未來的業務發展 同時必須有利於擴展或增加應用系統的處理功能

lishixin/Article/program/SQL/201311/16498

Ⅷ 資料庫設計的基本步驟

資料庫設計的基本步驟

1、需求分析階段

進行資料庫設計首先必須准確了解與分析用戶需求（包括數據與處理）。需求分析是整個設計過程的基礎，是最困難和最耗費時間的一步。作為「地基」的需求分析是否做得充分與准確，決定了在其上構建資料庫「大廈」的速度與質量。需求分析做的不好，可能會導致整個資料庫設計返工重做。

2、概念結構設計階段

概念結構設計階段是整個資料庫設計的關鍵，它通過對用戶需求進行綜合、歸納與抽象，形成一個獨立於具體資料庫管理系統的概念模型。

3、邏輯結構設計階段

邏輯結構設計是將概念結構轉換為某個資料庫管理系統所支持的數據模型，並對其進行優化。

4、物理設計階段

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

5、資料庫實施階段

在資料庫實施階段，設計人員運用資料庫管理系統提供資料庫語言及其宿主語言，根據邏輯設計和物理設計的結果建立資料庫，編寫與調試應用程序，組織數據入庫，並進行測試運行。

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

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

資料庫設計的基本原則

1、一致性原則：對數據來源進行統一、系統的分析與設計，協調好各種數據源，保證數據的一致性和有效性。

2、完整性原則：資料庫的完整性是指數據的正確性和相容性。要防止合法用戶使用資料庫時向資料庫加入不合語義的數據。對輸入到資料庫中的數據要有審核和約束機制。

3、安全性原則：資料庫的安全性是指保護數據，防止非法用戶使用資料庫或合法用戶非法使用資料庫造成數據泄露、更改或破壞。要有認證和授權機制。

4、可伸縮性與可擴展性原則：資料庫結構的設計應充分考慮發展的需要、移植的需要，具有良好的擴展性、伸縮性和適度冗餘。

5、規范化原則：資料庫的設計應遵循規范化理論。規范化的資料庫設計，可以減少資料庫插入、刪除、修改等操作時的異常和錯誤，降低數據冗餘度等。