ORACLE8 UML 对象建模设计03.pdf

下载 第3章 为什么使用对象建模 在关系数据库设计中，用来创建数据库逻辑模型的标准方法是使用实体关系模型（ E R模 型）。可以利用E R模型的灵活性来创建健壮的数据模型，但是关系模型在体现与数据相关的 业务规则上提供的词汇相对较少。 随着面向对象技术的发展，出现了其他一些建模技术和符号。并不是因为对象建模是当 前的一个趋势，为了追求时髦才去拥护它，而是因为许多建模人员包括作者都感觉到了使用 E R建模结构所带来的障碍和局限性。 E R D不能提供足够丰富的专业术语来适应新的结构。现 在是重新调整数据建模方法的时候了，有三种选择： ■ 扩展E R D 的符号来支持面向对象。 ■ 逻辑设计时使用现有的E R D符号，而建立物理数据模型时使用更多的选择。 ■ 使用U M L或其他建模符号。 第一种选择是可行的，但是需要大量的工作来支持面向对象的扩展。有人会认为 U M L可 作为E R D符号的扩展，但这需要在E R建模的思维方式上做很大的变化。 第二种选择也没有任何错误。如果 E R D 已经足够好了，O r a c l e和其他提供商就没有理由不 采用这种方式。但这并不是问题的全部，因为即使你没有计划使用 Oracle 8 的对象扩展，但 U M L 图表提供的一些功能确实比 E R D有更大的优势。U M L 同E R D 一样是一种逻辑建模工具， 没有理由在表及 Oracle 7 数据库的传统方式中不使用 U M L 图表。事实上，各种原因都会促使 你使用它。虽然你的工作可能因为政策或技术的原因无法升级为 Oracle 8 或不使用 O r a c l e对 象，你仍然可以使用U M L来设计数据库。 Oracle 8 是 Oracle 7 的升级版。Oracle 8 不仅提供了关系对象特性，也提供了许多新的特 性，即使不使用关系对象特性也应当移植到 Oracle 8环境中。 Oracle 8 的对象扩展是将E R D转变为U M L 的明显推动力。利用当前Oracle 8存在的对象扩 展，以及与 Oracle 8后面的版本保持一致的面向对象结构的完全应用， U M L （或其他建模标 记）都将需要使用。第三种选择即使用 U M L 或别的等效的建模标记应是最好的方法。面向对 象理论使建模方式发生了重大变化，应当利用这些理论的进步。 U M L 作为一种建模语言的标准，很大地促进了 U M L 的使用。关系和对象方法都存在很多 建模工具，面向对象的研究人员带领开发着一种通用建模语言，以使每一个人都可以使用这 种语言。即使数据库的研究人员已完全掌握了 U M L ，在看法上也会存在一些区别。因此，采 用通用行业标准的优势是不容忽视的。 3.1 实体关系建模的局限性 了解现存标准并没有固有的错误是非常重要的。 E R D 已为工业的发展尽心服务超过 1 0年 了，许多建模人员选择使用 E R D 是因为它的简便实用和雅致的风格，如果数据建模人员对本 书提出的这种总体结构和使用 Oracle 8对象扩展不感兴趣，那么传统的 E R D对他们的需要来说 可能已经足够了。 36计计第一部分 基 础 下载 但是，从更广的角度来看， E R D建模方式存在着一些问题。 E R D存在的问题首先体现在 它的命名上。E R D建模的中心思想是，可以仅通过实体和它们之间的关系合理地体现一个组 织的数据模型。但从表面上看，这样做似乎对描述一个组织的信息过于简单化，并且词汇量 也远远不足。U M L 的一个重要优势在于增加了处理信息。即使不从这一点考虑， E R D建模在 关系数据方面仍然存在着其他严重局限性。 “联合”或“交叉”实体明显是两种不同类型的实体，它们出现在多对多关系中，但是用 传统的E R D无法表示这些区别，同样也无法区分时间相关实体（即时间是唯一标识符的一部 分）。虽然在多种情况下，这种区分可以增强图表的功效。 本节指出了E R D 建模的许多局限性，希望读者能理解为什么迫切需要使用更加灵活、健 壮、面向对象的U M L来代替当前E R D建模这种工业标准。 选择U M L 无论如何，U M L 是对象