ORACLE8 UML 对象建模设计05.pdfVIP

下载 第5章 命 名 约 定 对任何系统来说，应用的一致性和恰当的命名约定是成功的关键因素。必须采用标准来 实现一致性。在建立命名标准时，应牢记以下的一般约定： 1) 选取的名字必须清晰，并且对使用者来说是容易理解的。比如，就数据仓库而言，最 终用户是使用者；但是对一个物理数据库而言，使用者包括系统专业人员和开发人员。名字 对所有这些人员都合适可能非常困难。 2) 名字不应太长。选取的名字需要多次输入，长的名字不仅增加了输入的时间，也增加 了出错的概率，甚至在处理已生成的代码时，长的名字也可能使得代码难以理解。有些产品 允许选取变长的名字，但却只能显示前 1 0个左右的字符。比如，在 Oracle Designer 的某些部分 中，当给一个属性分配一个域名时，长的域名会被截短。 3) 名字应尽可能地表示出对象的有意义的信息。通常给系统元素的名字加上前缀和后缀， 这样对名字的分类组织非常有用。 注意 在应用约定 2) 和 3) 时，必须进行权衡。为了表示出更多的信息，比较容易的 方法就是建立长的名字，但这些名字不易重复使用；另一方面，短的名字仅对最初 设计系统的人员来说容易理解，且其本身也比较含糊。 4) 名字应容易记忆。比如，在整个系统中只使用单词的一种形式，不使用单词的词性变 化形式（如“ - i n g ”形式、“- e d ”形式以及名词的复数形式等）。只使用单词的原形也会使名 字变得短些。 5) 数据库任何地方出现的文本信息都需要精确的命名约定，这包括数据本身。比如，在 数据库的值列表类中，对所有的主码都采用大写形式。 6 必须对所有的元素同时创建完整的命名标准。不能先创建数据库命名标准接着又创建开 发标准，因为这些标准可能会相互制约。标准必须是为整个开发环境而设立的。本书因描述 的是数据库的设计，所以只提到了有关数据库的决定。但是，在传统的开发环境中，框架对 象(弹出式列表、复选框等）、应用文件名等都需要命名约定。 在数据库中，有很多元素都需要一致的命名约定。把这些元素分为两类。 1) 在逻辑（数据模型）方面，类图中出现的元素都需要命名： ■ 模式。 ■ 类图。 ■ 类/表/ 实体。 ■ 属性。 ■ 域。 ■ 操作/方法。 2) 在物理实现方面，下列元素需要命名： ■ 序列。 第 5章 命 名 约 定计计55 下载 ■ 短表命名别名。 ■ 约束。 ■ 索引。 ■ 对象类型。 ■ 表别名。 下面将探讨对这些系统元素所建议的命名约定。 5.1 逻辑 (数据模型) 命名约定 系统可能非常大，可包括成百个表，最大的系统甚至有 1 0 0 0个表。正是在这些大系统中， 经常会看到诸如A X 1 4 5 _ 6 这样令人讨厌的表名。需要把使用的系统划分为一些可管理的部分 和模式。 1. 模式的命名 模式是表的集合，这些表既可以作为数据库也可以作为独立的用户帐户来实现。模式允 许我们在整个系统中对表进行引用。在数据模型中，对每一个主体域都应有一个模式。模式 的数量不应太多。一个模式应包括大约 3 0 ~ 5 0个表。为了便于管理，单个模式包含的表不应多 于1 0 0个。 模式应采用很短的缩写来命名。因为大部分系统的模式都不足 1 0个，因此两个字母的缩 写就足够了，比如用“ C O ”表示“C o r e ”， 用“F I ”表示“F i n a n c e ”。应尽可能地使用模式 逻辑名字的头两个字母。因为要使用“模式名 .表名”这种约定，所以模式名应保持很短。 在多对多联系中，关系中的每一个表都位于不同的模式中，当表由这些多对多的联系导 出时，也会带来一些复杂性，问题就在于把这些有交叉的表置于何处。一个可能实现的算法 就是用最逻辑的表来保存关联表。例如，如果正在给一个工程分配人员，那么就用包含 P r o j e c t表的模式来保存关联；但是，如果正在给人员分配设备，那么就用包含 P e o p l e表的模式 来保存关联。 雇员（E m p l o