第8章+数据库系统设计.ppt

(4) 设计目标比较复杂。 总的来说， 数据库设计的目标是在系统的制约条件下， 最大限度地满足应用的需要。 就数据库的物理设计来说， 一般需考虑减少CPU代价、 I/O代价以及存储代价， 而这三种代价又互相影响， 减少某种代价常会导致另一种代价的增加。 对于存储代价， 有些系统只要求不超过某一限制值就行了， 有些则希望尽可能压低存储代价。 数据库的各种不同的应用， 对前述三方面的要求也各不一样, 有些事务执行得慢一点还可以接受， 有些则不行。 以上这些因素如果在设计中都要考虑的话， 则问题将变得非常复杂。 (5) 代价估算比较困难。 CPU代价涉及到系统软件和运行环境， 很难准确估计。 I/O代价和存储代价比较容易估算。 但代价模型与系统有关， 很难形成一套通用的代价估算公式。 代价估算还与数据本身的特性有关， 必须对数据进行统计分析， 才能获得所必需的设计参数。 而在数据库设计阶段， 对数据特性的了解往往是不充分的。 鉴于上述原因， 在手工设计时， 一般按启发式规则选择索引。 即使在数据库的计算机辅助设计工具中， 也是先用启发式规则限制选择范围， 再用简化的代价比较法选择索引。 下面介绍用启发式规则选择索引的一般步骤。 (1) 确定文件的存储结构， 即记录的存放是无序的(堆文件)， 还是按主键排序， 或按某一属性或属性组簇集存放的。 (2) 凡是满足下列条件之一的属性或表， 不宜建立索引。 ① 不出现或很少出现在查询条件中的属性。 ② 属性值很少的属性。 例如属性“性别”只有两个值， 若在其上建立索引， 则平均起来， 每个属性值对应一半的元组， 用索引检索还不如顺序扫描。 ③ 属性值分布严重不均的属性。 例如学生的年龄往往集中在几个属性值上， 若在年龄属性上建立索引， 则在检索某个年龄的学生时， 会涉及到相当多的学生， 用索引查询， 还不如顺序扫描。 ④ 经常更新的属性或表。 因为更新时索引需要维护。 ⑤ 过长的属性， 例如超过30个字节。 因为在过长的属性上建立索引， 索引所占的存储空间较大， 而且索引级数也随之增加， 有诸多不利之处。 如果实在需要在其上建立索引， 必须采取索引键压缩措施。 ⑥ 太小的表， 例如小于六个物理块的表。 因为采用顺序扫描最多也不过六次I／O， 不值得采用索引。 (3) 凡符合下列条件之一， 可以考虑在有关属性上建立索引。 ① 主键和外键上一般都建有索引。 这样做带来如下优点： ·有利于主键惟一性检查。 ·有助于引用完整性约束检查。 在检查引用完整性约束时， 删、 改主键时须检查有无引用此主键的外键， 在增、 改外键时， 要检查是否有对应的主键。 在主键和外键上都建立索引， 显然可以方便这种检查。 ·可以加速以主键和外键为连接属性的连接操作。 这种连接非常普遍， 若在主键和外键上建有索引， 则可减少连接开销。 ② 对于以读为主或只读的表， 只要需要， 且存储空间允许， 可以多建索引。 ③ 对于等值查询(即查询条件以等号为比较符)， 如果满足条件的元组是少量的， 例如小于5％， 可以考虑在有关属性上建立索引。 ④ 对于范围查询(即查询条件以＜、 ＞、 ≤、 ≥等为比较符)， 最好在有关的属性上建立簇集索引。 如果已在其他属性上建立簇集索引， 且满足条件的元组数一般低于15％， 可以考虑在有关属性上建立非簇集索引。 ⑤ 有些查询可以从索引直接得到结果， 不必访问数据块。 对于这种查询， 在有关属性上建立索引是有利的。 这些查询有： ·查询某属性的MIN、 MAX、 AVG、 SUM、 COUNT等聚集函数值(无GROUP BY子句)， 可沿该属性的索引的顺序进行扫描， 直接求得结果。 ·查询某属性值EXISTS或NOT EXISTS， 只要通过该属性的索引就可获得结果， 不必访问数据块。 ⑥ 如果一个(或一组)