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. 同一个索引中包含的字段总数不宜超过四个