DB2數據庫對象設計

表
-

數據庫中的表按定義和使用方式分爲兩類

物理表：以create table方式建立，長期保存數據
臨時表：以declare方式建立，臨時保存數據

範式原則

物理表

• 優先考慮下降數據冗餘度、消除二義性，在合理代價的前提下，以第三範式爲目標進行表設計

• 兼顧訪問性能、可擴展性等因素，能夠在適當範圍內進行必要的降範式處理，但必須有配置機制保證數據一致性

臨時表

• 優先考慮程序訪問性能和便捷性，一般不受範式化制約

表空間使用和分配原則

用戶數據與系統數據分離

永久數據與臨時數據分離

表數據與索引數據分離

大對象數據獨立

物理表

必須顯式指定表數據、索引數據、大對象數據（若是存在）的表空間
以上三類表空間應分別管理，每類表空間可根據實際狀況進一步劃分

臨時表

必須顯式指定表數據的表空間，且必須爲用戶臨時表空間
索引數據能夠和表數據合併存放，不強制要求獨立表空間

字段

表寬度限制

字段數

 同一張表中字段總數不宜超過200個

單個字段長度

 表中任意單個字段的長度不宜超過4000字節

字段總長度

 同一張表中全部字段長度合計不宜超過8000字節

字段非空約束

物理表

 儘可能對全部字段使用非空約束，並設置字段默認值
 特殊狀況下，容許部分字段不使用非空約束，但必須保證這些字段不做爲過濾條件、分組條件，且不參與表達式運算

臨時表

 全部字段必須使用非空約束，非邏輯主鍵字段儘可能設置字段默認值

字段數據類型

儘可能精確選擇數據類型大類，避免隱含數據類型轉換

 用字符型字段存儲數組、日期、時間、時間戳
 用數值型字段存儲日期、時間、時間戳

同一數據類型大類中，儘可能選擇長度較短的數據類型

 在知足需求的前提下，能使用較小長度的數據類型則不使用較大長度
 能使用SMALLINT時不使用INTEGER
 能使用DECIMAL(9,4)時不使用DECIMAL(18,4)
 能使用TIME時不使用TIMESTAMP

CHAR與VARCHAR數據類型選擇

 當字符型字段實際取值均爲長度相同的字段時，使用CHAR
 當字符型字段最大長度很是小時，使用CHAR
 當字符型字段取值表明位圖含義時，使用CHAR
 其他狀況下均使用VARCHAR，且在保存數據時，需注意去除字符串尾部的空格
 主鍵字段和非描述類字段不建議使用Unicode字符集
 將對字符串長度獲取和按位截取形成不便

VARCHAR與DECIMAL長度合理分檔

 以系統爲單位，同一系統中的VARCHAR和DECIMAL字段引用同一套分檔機制
 合理分檔可使用同一系統內的VARCHAR和DECIMAL字段設置規範性更強，且保留必定的可擴展性

大對象字段

 將大對象保存在數據庫中可能對後續應用和管理形成不便
 正常狀況下，應儘可能避免在表中設計大對象字段
 可用文件系統存儲大對象，而在表中僅使用VARCHAR字段保存相對路徑
 必須在表中設計大對象字段時，建議將其單獨保存至附加表
 附加表中只保存原主表的邏輯主鍵和須要的大對象字段
 主表與附加表之間造成1:0~1關係或1:0~n關係
 臨時表中禁止設計大對象字段

字段排序

通用原則

 表中字段排序依次爲：A類技術字段、業務主鍵字段、B類技術字段、業務非主鍵字段、C類技術字段

業務主鍵字段排序原則

 業務主鍵字段爲多個時，按訪問頻度和字段取值區分度由高到低排列

業務非主鍵字段排序原則

 根據業務含義分組，業務含義相近的字段排在一塊兒；組間和組內再按訪問頻度由高到低排列，或按業務要素生成次序排列

技術字段

 按技術特徵肯定排列順序
 A類技術字段：決定整張表數據分佈的關鍵字段
 狀態快照表的快照日期、流水錶的數據日期
 B類技術字段：決定單行記錄數據狀態的關鍵字段
 狀態拉鍊表的拉鍊起始日期
 C類技術字段：存放單行記錄描述信息的字段
 記錄生成日期、維護日期、維護用戶

主鍵

物理主鍵

推薦對全部表均創建物理主鍵

物理主鍵一般與邏輯主鍵保持一致
存在多組邏輯主鍵時，建議將字段訪問頻度最高的一組做爲物理主鍵，其它組創建惟一索引或惟一約束

特殊狀況下，容許表中不建物理主鍵

對經常使用於大批量批處理的表，爲兼顧處理性能，能夠不建物理主鍵
必須有相應的機制保證表中的數據對該表的邏輯主鍵而言具備惟一性

外鍵及其它約束

外鍵

在設計階段能夠識別的外鍵關係必須在設計文檔中體現

 外鍵關係可做爲數據完整性、一致性判斷的依據

外鍵關係一般不須要物理化

 將外鍵關係物理化會給後續的批量數據處理和數據管理帶來必定程度的不便
 可經過應用程序或數據質量校驗程序保證外鍵關係
 在某些對數據完整性要求極高的聯機應用系統中，關鍵的外鍵關係能夠物理化

其餘約束

業務性約束必須在設計文檔中體現，但一般無需物理化

 業務性約束可做爲數據完整性、一致性判斷的依據
 業務性約束一般由應用程序保證，可能隨業務需求發生變化

技術性約束一般必須物理化

 如，爲UNION ALL視圖對物理表準肯定位，須要在條件字段上顯式增長約束

分區鍵

分區鍵設置原則:

• 多分區數據庫中的全部表均必須顯式指定分區鍵

• 單分區數據庫中的表推薦在設計階段指定備選分區鍵
  單分區數據庫中的表指定分區鍵並不起實際做用，但能夠做爲數據遷移至多分區數據庫時的參考依據

• 物理表優先選擇邏輯主鍵中區分度最高的單一字段
  當邏輯主鍵中全部字段區分度均較低時，選擇能知足區分度要求的字段組合，字段組合中的字段數儘量少，最多爲邏輯主鍵中的所有字段

• 臨時表優先選擇後續關聯條件或分組條件中包含的區分度最高的單一字段

視圖

視圖建立原則

視圖主要適用場景

 同構表的記錄合併
 主表與附表的預關聯
 簡單的條件過濾和分組統計

視圖一般不包含複雜或易變的業務邏輯

儘可能避免視圖嵌套定義

當視圖訪問效率較低時，應將其物理化爲表

 視圖設計時，應儘可能保證其物理化爲表後，應用可實現平滑切換

索引

索引建立原則

• 索引應按需建立，同一張表的索引數量不宜過多

  1. 除物理主鍵所含惟一索引外，同一張表上的索引數量不宜超過三個

• 索引字段選擇及排序原則

  1. 當索引由多個字段組成時，除徹底匹配外，使用其第一個字段開始的子集對訪問效率也有提高做用

  2. 最優先考慮使用頻度：使用頻度較高的字段優先選擇且排序靠前

  3. 次優先考慮字段區分度：區分度較高的字段排序靠前，區分度太低的字段不建議包含在索引中

  4. 同一個索引中包含的字段總數不宜超過四個