ORACLE8 UML 对象建模设计18.pdf

下载 第18章 非 规 范 化 一旦一个系统的数据模型建好，并且逻辑上是正确的，我们就可以成功地实现这个模型， 并且创建应用程序。但对实现而言，这种设计并不一定是最佳的，同时也没有理由认为现存 的数据模型一定是不充分的。 提示 必须尽量将物理模型与逻辑模型保持一致。 回顾8 0年代，数据模型不符合范式的情况十分常见。明细记录与主记录混在一起，整体 结构被拆散在没有层次的文件中，简明纯粹的逻辑结构也被输入到只有 C O B O L ／V S A M程序 员熟悉的结构中。之所以出现这种情况是因为那时硬件十分昂贵，而关系型数据库引擎速度 又十分低。顾问报告说，通过大量非规范化，平均能够在 1 0个性能因素中提高一个。传统思 维认为符合范式的模型理论上是好的，但在实践中不会有多大作用。我们创建了符合范式的 逻辑数据模型，并且建立了平面文件数据库。 这个策略导致了灾难性的后果。当这些系统进入商品化生产时，产生了与传统的平面文 件系统同样的问题。特别是它们缺乏灵活性，且做修改的成本很高。任何没有明确设计到数 据库中的功能都需要对数据结构做代价很高的修改。到 8 0年代末期，数据库领域中的人们开 始认识到这种将结构非规范化的方法的错误有多么严重。尽管系统第一次投入生产时性能有 所提高，但维护这些系统的成本还是高得让人难以承受。 但是，也存在着不会严重影响系统响应未来需求的能力的非规范化。本章将概要介绍一 些非规范化技术，这些技术的实现不会严重影响一个高质量的数据模型的灵活性质。 非规范化从来都是有代价的。在大多数例子中，当系统某一部分的性能得以提高时，其 他部分的性能就会有所降低。规范化是一种建模风格，绝大多数建模者都对之有深刻的理解。 非规范化则是一种特殊的艺术，越多的结构被非规范化，对于其他开发者而言就越难以使用 它们进行工作。这个问题比它表面上看起来还要严重。开发者总换来换去，建立一个能够被 将来的开发者阅读和理解的模型是很重要的。 不要轻易采取非规范化。它可能提高性能，也可能不会，但它一定会使模型更难以阅读。 除非是非常仔细地进行这项工作，否则它将降低模型的灵活性。那么究竟为什么要进行非规 范化呢？有如下几种情形使得这项工作变得必要： ■ 性能的原因使必须进行非规范化。一个大型的复杂数据模型在核心表中有千万行记录， 可能只能通过非规范化才能够获得可接受的性能。 ■ 使用非规范化可简化应用逻辑。为生成一个特定的报表或屏幕，可能必须存取多达 1 0 ~ 2 0个表以检索一条特定的信息。如果在数据库的其他地方存储该信息的冗余，我们 就能够极大地降低程序逻辑的复杂度。 如果只是因为第二个原因才进行非规范化，通常是考虑使用一个可更新的视图，而不是 非规范化。不是创建一个冗余列，而是创建一个显示该列的视图。必须小心使用视图，因为 连接视图使得查询变得难以协调。但是，如果能够使用一个简单的单表视图，它的所有额外 列都是通过嵌入的函数生成的，你就能够在视图中连接任何的非函数列，且除了对函数执行 第18章 非 规 范 化计计231 下载 的性能之外，不会对其他性能产生任何明显的影响。连接基于多表的视图经常会导致不可避 免的全表扫描。如果目标是简化应用逻辑，这个策略还是值得一试的。如果能够利用视图充 分实现性能，那么应该使用视图，因为它们不影响数据模型。 为进行非规范化，经常要生成冗余属性。冗余属性是数据库的一个对象类中已经存在的 其他对象的一个函数。冗余属性的一个例子是加入一个扩展价格，它等于现有数量乘以现有 价格。另一个例子是 U P P E R ，其中一个名字的大写键值被冗余地存储。这种方法普遍使用， 从而使大小写敏感的查询可以在 n a m e 域上执行。之所以不能在运行时只将 U P P E R放置到域上 来执行查询的原因是，在一个 W H E R E 从句中放置一个函数到一列上会使索引失效。这个技术 唯一被使用的场合是当必须索引冗余列时。 18.1 非规范化技术概述 我们确认了 11种出于方便编码或性能原因所必需的非规范化。我们将描述每一种方法， 并且提供明确的例子来说明这些技术。 1. 冗余总额域