数据库评审检查表.docx

数据库评审检查表 序号 检查项目 通过 不通过 忽略 1 数据库设计是否满足软件设计的一般要求？ 注：数据库设计应该满足软件设计的一般要求。主要考虑 2 数据库设计是否与其他设计内容一致？ 注：作为软件设计的一部分，数据库设计应该与其他设计内容保持一致。 3 设计是否充分考虑了新系统与现有系统的关系，与现有系统的接口是否被充分考虑？ 注：在数据库设计中应该充分考虑新系统与现有系统的关系，与现有系统的接口应被充分考虑。 4 如果基础数据的一部分来源于其他系统，那么是否有工具或方案实现快速导入？ 注：如果有必要，应该设计工具或者方案将来源于其他系统的数据快速导入数据库。 5 反规范化（违反3NF）的设计是否有明确的说明，理由是否充分？ 注：反规范化的设计有时是必要的，但是要注明理由。通常的理由包括： 1、为了提高查询效率，在频繁查询但不频繁更新的表中增加冗余列； 2、为了提高查询效率，将大容量表作水平分割（分割行）或垂直分割（分割列）； 3、为了方便进行统计，引入派生列； 4、…… 如无恰当理由，所有设计均应遵循3NF。 6 对反规范化（违反3NF）设计部分的数据完整性是否进行了充分的考虑？ 注：反规范化的设计可能产生数据冗余，因此应该视具体情况建立一定的机制（如触发器、过程）保证反规范化数据的完整性。 7 孤立表的设计理由是否充分？ 注：设计中应该对孤立表的设计理由作出明确的说明。 8 为保证查询和更新效率，是否对大容量表(千万行以上或100列以上)作了必要的设计？ 注：通常在大容量表上采用的设计包括： 1、将大容量表设计成分区表； 2、将大容量表作水平分割（分割行）或垂直分割（分割列）； 3、…… 9 是否避免深度超过三层的视图？ 注：为了保证效率，视图的深度一般不超过三层。可以建立临时表降低视图的深度。 √ 10 是否遵循统一的命名规范？ 注：对所有的数据库元素应该采用统一的命名规范。 11 表、列、视图、触发器、过程的注释是否完整？ 注：应在表和列上建立中文说明；应在复杂视图的脚本中增加注释；应在触发器和过程脚本中增加注释。 12 命名是否避免使用数据库的保留字？ 注：命名应绝对避免使用数据库的保留字。 13 数据类型是否存在溢出的可能？ 注：检查数据的逻辑取值范围是否超出数据的设计类型，重点检查integer,sma..int,char型字段。 14 数据类型的长度是否保留了未来扩展的余量? 注：数据类型应保留一定的扩展余量。由此产生的典型问题包括：电话号码升位、身份证升位、千年虫等。 15 在作为查询条件的列上是否建立了NOT NU..约束？如果没有，理由是否充分。 注：如果把未建立not nu..约束的列作为查询条件，查询结果中往往会漏掉取值为 nu.. 的列。 16 是否谨慎地使用日期型字段？ 注：外部输入或导入的日期应使用varchar型或char型字段。典型的问题是：如果有的日期精确到日，有的日期只精确到年，那么这些数据在日期型字段中得不到准确的记录。 17 主键是否采用系统生成的键？如果不是，理由是否充分。 注：现在的设计越来越倾向于使用系统生成的键作为主键，而不使用带有业务含义的主键。由系统生成的主键字段通常包括：自增长列、序列、GUID。 18 是否尽量避免将可能变动的字段作为主键？ 注：如果不使用系统生成的键，那么应该避免将可能变动的键作为主键。 19 如果外键字段未建立NOT NU..约束，那么理由是否充分。 注：外键字段要么引用关联表的主键，要么为空。如果置空的外键字段有确定的业务含义，那么最好将这样的“业务含义”定义在外键关联表中，并且在外键字段上建立not nu..约束。 20 是否尽量使用数据库的约束机制实现数据的完整性？ 注：应该尽量利用数据库的约束机制（例如键、非空、唯一、check、触发器等）——而不是应用程序，保证数据完整性。 21 索引是否正确地建立在查询操作频繁的表上? 注：应将索引建立在查询操作频繁的表上。建立索引的常用原则还包括： 1、使索引最可能被用在where子句中； 2、查询时不应对索引列作函数运算，否则应建立函数索引； 3、在大型表上建立索引有可能降低查询效率，可以将大表分区后建立分区索引； 4、…… 22 索引是否尽量避免建立在大容量字段上? 注：应尽量避免将索引建立在 memo, .ob 或大文本这样的大容量字段上。 23 索引是否避免建立在小型数据表（少于5个块）上？ 注：在小容量表上建立索引没有意义。 24 是否将索引建立在独立的表空间上？如果不是，理由是否充分。 注：将索引建立在独立的表空间