Figure 3.20: Rolename example.
球员PLAYER的键属性 “player-team-id.team-id”给我们演示定义和显示角色名的语法，第一半 (点号之前)是角色名，第二半是外来键的原始名称，有时称基本名称。
role-name.base-name
就象任何其他属性一样，角色名通过关系迁移。如下例所示，演示了在各种比赛中各个球员的得分情况。
Figure 3.21: Diagram with rolenames migrated.
这里，我们为SCORING-PLAY的主键创建一个新角色，如图3.22所示。
角色的”链”沿着所有路径从SCORING-PLAY回朔到TEAM。然而，注意只有一个链的”链接”被显示。
13
Figure 3.22: Diagram with new rolenames.
4 命名、定义实体、属性
4.1 命名为什么重要?
命名为什么重要？因为它包含中几乎所有的实体和属性。
在信息做模型中非常地重要，通常在系统开发中，为对象选择清楚和容易辨认的名字，命名和定义实体、属性如此重要，以臻于我将用这一章来讨论。
有关标题: 单数名称 清楚的名称
单数名称
Entity names are always singular. We have made a point to do this throughout all the examples. Doing so facilitates reading the model with declarative statements such as “A FLIGHT zero or more PASSENGERs” and “A PASSENGER
Attribute names are singular too, e.g., “person-name,” “employee-SSN,” “employee-bonus-amount.” The reason for naming attributes in the singular is partly a matter of a consistent naming policy and partly to avoid certain kinds of normalization errors. You might have an intuitive sense that something was amiss if you saw an attribute name like “person-hobbies.” How many? How do we tell one from another? How would we represent them in a sample instance table? And so on. Your intuition would be correct ?there is something wrong. We will
14
return to this in our discussion of normalization in a later chapter.
清楚的名称
清楚地表达实体和属性的名称是非常重要的，例如，人 、消费者、职员，虽然它们都表示一些个体，但其意义是有差别的，他们有不同的特性。
小心地挑选名称，不要把两个不同的东西叫做相同的名字。
为了符合业务习惯，使用不清楚的名称，应给这个名称一个新的别名。 有时发现不首先给出它的定义是难于给实体和属性取一个好名称的，通常，给实体和属性一个好的定义与取一个好名称一样重要。一个意味深长的名称来自对模型的理解和经验。
在图3.10中，我们给人和地址的联合或交叉点命名为地址-使用，我们是如何选择这个名字呢?
Figure 3.10: From previous chapter.
大多数人也许喜欢把这个实体命名为”个人-地址”，问题是这个实体即不表示个人也不表示地址，它让我们误以为这个实体是一些个人或地址的分类。
这个实体真正代表的是个人地址的使用，我们要保存的信息是”使用”，地址-使用表达大多数信息，但它有一点不足，个人-地址-使用将已告诉我们更多的信息。
记住信息模型是对业务规则的描述，无论何时都要尽可能地选择一个意味深长的业务名称，然而可能没有这样的业务名称 (业务也许不喜欢 “个人地址使用”)?
这种情况，最好直接给出适合实体目的的名称。
4.2 实体定义
所有实体都应当定义，虽然 ERwin并不强迫使用这个定义(作没有伴随定义的框图是件快意的事)，写一个好的定义似乎比作框图更困难。每个人都知道什么是人，对吧?给人写一个定义，便于以后检查。
在实际中，你会发现采用结构化的长定义有助于读者了解被定义的东西，某些这样的定义达几页纸 (如：人)。你可能想采用下列 “标准”作为定义结构的起点，即使 IDEF1X不为定义提供标准。
15
有关标题: 描述 业务例子
描述
描述应当清楚、简明，告诉我们是否是我们要定义的东西，通常，这样的描述相当地短，然而注意，描述不能太概括或使用没有定义的概念，这里是一对例子，一个质量好的，一个可疑的。
“商品是东西哪一个有值哪一个能被决定在交换.” 这不是太可惜了.
我们可以惊讶于什么 “交换”是,并且我们可以需要了解一点儿更多什么 “值”是,但是我们能通常知道那东西是商品如果某人是,或将是,自愿的经营东西为它.
如果某人愿意给我们三花生和根使为有粘性大理石,然后我们知道那大理石是商品. 并且如此是花生和根有粘性.
“消费者是某人谁买东西从我们的公司.” 这太好.
第一,能 “某人”是另一个公司?
第二,消费者不得不有已经已买东西从我们到被考虑一? 怎么样 “潜力”为销售以后,即使有毫不现在? 等等.
业务例子
对要定义的东西提供典型的企业例子是一个好主意，但要避免用例子来定义，虽然有点“不专业”，但好例子能够帮助读者理解定义，如注释花生，大理石有助于读者理解商品COMMODITY的概念，定义说商品是有“价值”的东西，例子可以帮助读者理解，价值并不总是“钱”。
通常应当给定义加入注释，如，它的状态，何时做的修改，来源等，它作为定义的一部分是非常有用的记录。注释解释了被定义实体类似的东西，而不是其中的每一个实例，例如：消费者CUSTOMER和可能的主顾PROSPECT是有区别的，初看时它们好象是相同的东西，但他们的确不同。
如图3.10所示，对联合实体下定义是有点困难的，定义为ADDRESS-USAGE。联合实体记录的是“交叉点”数据------是被“联合”的一对键，可象下面一样尝试。
\“人使用的地址”
No. The only problem is, this is not an ADDRESS! How about: 问题是这不是地址，咱办？
\人使用的地址信息
Closer, but still not correct. Information about an ADDRESS is recorded as attributes of ADDRESS. How about:
接近了，但仍然不正确，地址信息是ADDRESS的属性，咱办？
16
\“人所用地址用途的信息”
Yes. Remember that associative entities often represent many-to-many relationships which have been broken down into a pair of one-to-many relationships with the associative entity in the middle.
正确，联合实体经常用于表示多对多的关系，多对多关系被拆分成中间带有联合实体的两个一对多关系。
4.3 属性定义
和实体一样，清楚地定义所有属性是很重要的，应用相同的规则------比较要定义的东西，我们能够判断它是否合适，
As with entities, it is important to define all attributes clearly. The same rules apply?------by comparing a thing to a definition, we should be able to tell if it fits. Again, this is more difficult than it may first sound.
例如：什么是\的最好定义？我们总是认为“这是每个人都知识的”，但人名与绰号仍然是有区别的，什么是名字？
Is it a title by which the PERSON is commonly addressed? Or what is listed on a birth certificate? Or with the government for tax and other purposes? Or what? Or are all of these \
是找人的标题？，是列在出生证上的？，给政府纳税和别的目的？，还是别的什么？或是所有这些“用途”？
Beware of things like \was opened.\
Attribute definitions generally should have the same basic structure as entity definitions (i.e., description, examples, comments, etc.). Description and comments certainly apply. Business examples are useful sometimes. Business examples lead us to the world of domains. 通常，属性的定义应当与实体定义的基本结构一样（如：描述，例子，注释等），描述和注释肯定要用，有时业务实例也是有用的，业务实例把我们带入域的世界。
4.4 域
域可以被看作是允许属性接受的一组值，这些值有抽象和企业意义，例如：\如果定义为“the preferred form of address chosen by the PERSON”，那么域就是所有字符串的集合，人们也可用短语、编号、描述或其它这样的东西、也可用传统的“名字”如Ben或Tom来称呼自己。
在IDEF1X的正式描述中，通常关系模型中，据说属性定义在域之上，属性的定义如代码，标识符，数量等，但这通常不用于业务例子。包含属性域的描述通常都是好主意，定义域时也应列出属性可以采用的“值”，假设我们定义属性\如下：
Customer-status：描述消费者与商行间关系的代码 下列域的说明没有多在帮助。
17