计算机专业教材-第4章类和实体.pdf

下载 第二部分 数据库的组成部分 第4章 类 和 实 体 对类和类之间关系的正确识别是数据模型的关键所在。本章将讨论如何发现、识别、以 及描述类。要想将建模过程缩减为一个简单的、逐步进行的过程是不太可能的。从本质上讲， 建模是一项艺术。对一个给定的复杂情况而言，不存在唯一正确的数据模型，然而却存在好 的数据模型；与之相对，也存在着差的数据模型。一个企业或机构的某个数据模型可能会优 于另一个数据模型，但就如何为一个特定的系统建立数据模型，却没有唯一的解决方案。 好模型的目标是将工程项目整个生存期内的花费减至最小。将目光集中在最大限度地降 低开发费用上是一个错误。好的模型会考虑到随时间的推移系统将可能发生的变化，因而设 计时也要很容易地能适应这些变化。 建模过程也是十分主观的，有不同的建立数据模型的风格。设计者会对同类问题提出不 同的处理方法。最优数据模型不只是被模型化的情况的一个函数，它还依赖于如下因素 : ■ 开发组的技能。结构越复杂，对开发人员的技能要求越高。 ■ 设计环境。大多数C A S E产品在其所能生成的结构方面都有所局限，设计者可能需要将 设计调整为C A S E友好的。 ■ 开发环境。开发工具（尤其是4 G L ）在其能轻易支持的结构种类方面存在局限，由C A S E 生成的应用在这方面则更为有限，设计者可能希望修改设计以适应所选择的开发环境。 ■ 系统期望的生存期。短期的项目（如支持奥林匹克运动会或工程项目的一个系统）用 于长期的可能性会小一些。 ■ 项目的时间/ 费用压力。尽管灵活的模型降低了长期项目的费用，但如果具有很大压力， 如需要在该系统的第一版保持短时间和低开发费用的话，某些灵活性就要牺牲掉了。 由于工具变得更为丰富以及U M L概念的出现，与使用 E R D相比，建模变得更像一门艺术 了。现在这些新的关系类型使得对同一情况建模有了更多的方法。 尽管本章讨论类的识别，关系在另一单独章节（第 8章）中讨论，但我们不想造成这样一 种印象，即顺序处理是设计数据库的正确方法。事实上，不能通过简单地先识别类，然后再 识别这些类之间的关系来设计，这两个过程必须同时出现。即使过去使用 E R D 时，首先确定 所有实体，然后用关系将它们连接在一起也是不可能的。然而，许多不良数据模型却正是用 这种方法建立的。 本章将给出特定的实例，同时给出问题及答案来帮助正确地识别类、属性和主码。 4.1 识别类 第3章列出了对象的几个定义。从本质上讲，类（对象组）是某一特定组织关注的、数据 库要对之进行跟踪的事物。通常，在 E R D 风格的建模过程中，分析员会暗自发问 : “需要明确 44计计第二部分 数据库的组成部分 下载 什么? ” 从某种程度上讲，对象建模人员也可以从同样的问题开始。然而，对象建模人员必 须同时想到人们所关注的项目的抽象。例如，在零售系统中，我们设置了发票购买、购货单 等与组织相关的类，所有这些类要被归纳到“商品流动”类当中。这个简单的抽象使得能够 将模型的大小降低 3 0 % 。因此，在识别人们关注的项目的同时，识别与这些项目相关的抽象 也是十分重要的。 下面给出一系列例子以及相应的问题及答案，以此更完整地说明识别类的方法。 例1: 一个设备需要维护。在这个特定组织中，所需要的维护产生了一个工作单。这个工 作单可以被分割成许多任务，其中每个任务又可继续被分割成若干动作。最后，每个动作又 被分割成若干个步骤。这些任务、动作、步骤可以应用到整个设备上，或应用到这个设备的 某些部件或子部件上。通常，工作单应用于整个设备，而任务、动作、步骤则应用于该设备 的某个部件。 问题：这个例子中相应的类有哪些? 答案：显而易见的类有: ■ 设备（E q u i p m e n t ）。 ■ 部件（A s s e m b l y ）。 ■ 子部件（S u b a s s e m b l y ）。 ■ 工作单（Work Order ）。 ■ 任务（Ta s k ）。 ■ 动作（A c t i o n ）。 ■ 步骤（S t e p ）。