3.2 数据模型的组件
数据模型由许多不同的组件（对真实世界中事物的抽象）构建而成。最简单的数据模型由实体和关系构成。在数据模型发展的同时，加入了更多的细节，复杂度也随之增加。接下来研究数据模型的各种不同组件以及用于数据建模的术语。
3.2.1 实体
从最基本的层面来说，实体是存在且能够描述的事物。它可以是人、地方、事情、概念或有关企业支撑某些事实的事件。例如，STUDENT、INSTRUCTOR和COURSE都是学院或大学必须了解来完成业务的具体实体。
实体是人、地方、事情、概念或事件。
实体命名指南
在数据模型内部，实体的命名遵循严格的标准很重要。如果开发人员试图使用定义糟糕且非标准的名称来进行交流，将会产生混乱。好的标准通常使用大写英文字母并以单数形式命名实体。实体应看作处于其中的实例模式，而不是该类型实体的所有实例集合。例如，一个包含公司雇员的数据实体应命名为EMPLOYEE，而不是EMPLOYEES。
此外，实体通常是名词或形容词与名词的组合。应尽量减少使用形容词，因为有些时候，形容词可以伪装成一个属性。例如，一个名叫CONTRACT EMPLOYEE的实体可以更好地表示一个实体，名字叫EMPLOYEE且还有一个描述雇员状态的属性（状态的值可以是FULLTIME或CONTRACT）。
实体通常是名词或形容词与名词的组合。
促进选用实体术语的一致性。一般来说，使用业务用户喜欢的术语。如果同一个实体使用了多个术语，且没有明确的共识，那么选择其中一个使用。例如，如果一些用户喜欢VENDOR而另外一些却喜欢SUPPLIER，选择任何一个且在整个数据模型中都使用它。某些时候，当不好为业务选择术语时，可凭借常识来选择。例如，CLIENT或许比USER更好，因为有时会赋予这个词一些负面的含义（毒药用户）。
最后，去掉实体名称中表示特定过程的词语，例如，AGENT比SELLING AGENT更好。需要谨记，数据模型应捕获的是“是什么”而非“如何做”，而“selling”就描述了一个过程。
实体实例
实体的实例称作实体实例。例如，AUTHOR是一个实体，Craig S.?Mullins以及所有描述性的细节就是实体AUTHOR的一个实例。区分抽象的实体与具体的实体实例非常重要。另外，Entity Instance与Entity Occurrence是同义词，都表示实体实例。
实体的实例称作实体实例。
3.2.2 属性
实体所具有的某一特性称为属性。属性的作用有三种：
标识，用于标识的属性是候选键。如果所标识属性的值改变了，该属性就标识另外的实体实例了。用于标识的属性应是一成不变的。
关联，用于关联实体的属性是外部键。该属性是指另一个（或同一个）实体实例的主键的属性。
描述，如果一个属性描述或表示（而非标识或关联）一个实体实例的特点，那么该属性即描述性属性。
一般来说，名词往往表示实体，形容词往往表示属性。然而，该规则并非一成不变的：一定要运用业务知识来确定哪些名词和属性是实体，哪些是属性。每个属性必须标识实体实例，关联一个实体实例到另一个实体实例（在同一个或另一个实体中），或描述实体实例。
属性必须明确地反映其具体的本意。一个属性的实例在本质上必须是原子的。也就是说，一个属性代表一个独特的事实，不能进一步分解。基于此，使用Name作为实体PERSON的属性并不是很好的做法，因为Name还可以分解为名、中间名和姓。
域
每个属性都分配了有效的域。域定义了数据元素有效值的范围。一个有关域的例子：1到10之间的有效正整数。数据类型是域的组成部分，它恰当地指定组成域的数据的类型，如整数、小数、字符、日期和时间等。
如果定义一个属性表示一段代码，该代码段的域（如果可能）应由自记录的值组成。例如，用于表示每周、每月、每季度、每年这些周期频率的属性的域，定义为（“W”、“M”、“Q”、“Y”）比（“1”、“2”、“3”、“4”）更好。前者是自记录的且便于记忆，后者不便于记忆。
域定义了数据元素有效值的范围。
属性命名指南
制定并遵守一种属性命名的标准格式。例如，如果以驼峰式大小写（“FirstName”）的独特格式命名了属性，那么就不要随便将它全部转换成小写（“first_name”）。选择一种格式并一直沿用。实体EMPLOYEE的一些潜在属性名称可能是StreetAddress（或street_address）、ZipCode（或zip_code）和EmployeeId（或employee_id）。问题的关键不是花费很多时间来确定属性命名的明确标准，而是选择一种标准并一直沿用，才可以最大程度地减小混淆和明确沟通。
遵守一种属性命名的标准格式。
属性名称应由一个基本描述性单词加上一个类单词组成。类单词描述了大部分信息系统常见的属性的一个特殊子集。如果有可能，还可以相应使用其他符合资格的单词来定义属性。基本描述性单词可以是实体名，也可以是其他描述性单词。类单词为在用的域的类型建立了有效的类列表。表3-1显示了可能的类示例列表。你可以使用整个类名或者其标准缩写。下面举几个属性名称的例子。
VendorID，这里的Vendor是实体，该属性是一个标识符。
ProductName，这里的Product是实体，该属性的域是字母、字符名称。
ProductYearlySalesAmount，这里的Product是实体，域是一个数额。然而，每个产品实例可能有多个数额。此特殊的属性用Yearly（表示阶段）和Sales（表示卖掉的数额，而非购买的数额）进行了进一步限制。
同音异义词和同义词
根据韦氏词典的英语用法（在线版本）：
Homonyms，名词
1：拼写以及发音相似，意思却不相同（如名词畏惧quail和动词畏惧quail）的两个或多个单词。
Synonyms，名词
1：在一些或所有句子中表示相同或相近意思的两个或多个单词或使用同一语言的表达。
在数据建模中使用同音异义词和同义词会引起混淆。前者必须通过上下文才能理解它的具体含义。当两个单词的拼写和发音均相同时，识别它们的唯一方法就是研究它们是如何使用的。例如，如果单说“watch”一词，你能理解它表示手表呢，还是表示让你看某些东西呢？缺少了上下文，就无从知晓。
后者（同义词）引起混淆的原因则不同。当同一个事物用几种不同的方式表示时，多个词用来表示该事物则会变得不清晰。例如，“client”和“customer”表示同一个意思吗？
尽管两者在商业活动中不能被禁止，在数据建模和数据库设计范围内还是可以禁止的。作为数据建模师的你一定要这么做。然而，不要强迫业务线用户采用该术语来改变他们当前的使用习惯。而是要与数据模型中的保持一致，并允许用户不修改他们的词典就能继续他们当前的实践。然而，一定要记录下同音异义词和同义词的所有商业用法。
类单词不应具有多重意义。
一方面，类单词列表可能不同。另一方面，该列表也可能相同，只是拥有不同的缩写。无论如何，只要制定并坚持使用类单词列表即可。类单词不应具有多重意义。每个域有且只能有一个类单词。此外，定义类单词时应避免使用同音异义词和同义词。还需要记住的是，这些类单词仅对逻辑数据模型至关重要，而由于DBMS对象名称的限制，它们不会用于物理数据库。
属性值
属性的实例称为属性值。值“Craig”就是实体AUTHOR的FirstName属性的属性值。从具体的属性值中区分抽象的属性很重要。
空值与缺少值
对于属性来说，空值代表值丢失或信息未知。如果某个属性值为空，表示两种含义：该属性不适用于某个实体实例，或者该属性适用于所有的实体实例，但信息可能未知。当然，这两种情况也可能同时出现。
例如，假设实体STUDENT包含属性HairColor，另外，该属性可以为空。空的HairColor又代表什么呢？看一下三种潜在的实体实例：黑头发的男人、未知发色的女人以及秃头的男人。未知发色的女人和秃头的男人都可以赋空值，原因却不相同。未知发色的女人的HairColor为空意味着“暂时未知”，而秃头的男人的HairColor为空则意味着“不适用”。
当然了，可以通过扩展颜色的域使之包含值“秃头”来表示秃头男人的HairColor。但如果扩展域不可行呢？例如，实体EMPLOYEE的TerminationDate属性的某个日期，日期的域是日历上所有的日期，它不太可能被赋予一个“未知”的特殊值。而对于实例EMPLOYEE的TerminationDate的值，空值（意味着未知）远比一个有效的日期合适，不管该日期多遥远，不是吗？
空值代表值丢失或信息未知。
不可用的空值可能预示着设计问题
使用空值来表示“不可用”可能预示着数据设计不正确。通过恰当的建模以及数据结构规范化，往往可以消除使用空值来表示某列对于某特定的行不适用。
正确规范化的数据模型应使每个属性值都依赖实体实例的主键。如果某个特殊的属性“不可用”，大概就是设计不规范。有关更多规范化的信息，请查阅本章3.5节。
制定数据模型时一定要考虑空值的细微差别，仔细研究每个属性的为空性。
通常Null会被不恰当地认为空值。使用术语value来描述空并不准确，因为术语null意味着lack值。
3.2.3 码
码由一个或多个属性组成，其值唯一标识实体实例并定义实体间的关联。更准确地说，候选码和主码标识实体。一个实体的主码值与另一个实体的外码值共同标识关联。例如，如果CustNo是实体CUSTOMER的主码，它将用作相关实体（如CUSTOMER_CONTACT）的外码。一个客户可以有多个联系人，所以客户的每个联系人都要注册CustNo。
码不应具有嵌入的含义。码的用途是标识，而非描述。描述由实体的其他属性负责。如果码具有嵌入的含义，含义一旦改变，问题就会出现。此外，任何嵌入含义的值都有可能失去控制，也会引起数据完整性和修改问题。
码由标识实体实例的属性组成，并定义了实体间的关联。
候选码
每个实体都可以拥有多个候选码，但至少要有一个。候选码是一种可唯一标识实体实例的属性或属性的子集。如果属性的值不能用来标识实体的具体实例，那么它就不能作为候选码。
主码
每个实体都有且仅有一个主码。主码从一组候选码中选出且用来标识实体实例。选择恰当的主码至关重要，因为主码将用于定义相关的从属实体的外码。
好的主码包括以下几种特征：
主码必须保证实体实例的唯一性。
主码任何分量的值都不能为空。
基本实体的主码不应具有嵌入的含义。
主码是不可变的，即不可或不易改变。
此外，应控制主码的值。如果值由外部分配，则容易失控，进而可能引起数据问题。其中，确保码的值始终唯一就不太可能。例如，社会安全号码不是理想的标识雇员的主码，因为它在外部分配。或许，由企业内部分配数字标识符是个不错的选择。
外码
外码存在于从属实体内部，用于建立关联。主码标识实体实例，外码则识别实体实例间的关联。对于一对多的关联，外码始终取决于关联较多的一方。对于一对一的关联，确定外码的位置会比较困难。基本原则是分析属性并将码分配给最具特色的实体。如果一对一关联的一方可选，那么该方的实体应包含外码，而另外一方的实体包含主码。
3.2.4 关联
关联定义了不同的实体间是如何相互联系的。关联的名称应说明一个实体与另外的（或同一个）实体联合所起的作用。码定义关联：父实体中是主码，从属实体中是外码。
关联定义了不同的实体间是如何相互联系的。
关联不只是联系实体之间的“线”，还让数据模型变得有意义，因此应赋予有意义的名称。关联的名称如实陈述了实体间的联系。例如，两个实体COURSE和INSTRUCTOR的一对多的关联，每门COURSE有且仅有一名INSTRUCTOR，而一名INSTRUCTOR可能教多门COURSE。关联的名称（本例中“is-taught-by”）加上参与这种关联的实体的名称，就可以组成一个有实际意义的句子。
在E/R图中，关联应从右向左按顺时针方向来读。遵守此约定可保证数据模型的易读性。
基数
基数（cardinality）是存在于一对实体中的实例的数量。另外，基数还可看作适用于某种具体关联的实体实例的数量。通常会使用术语“目”或“度”(degree)而不是基数。关联的每一方都有与其有关的基数或目。
基数是存在于一对实体中的实例的数量。
在最简单的层面，以E/R图所绘制的关联的方式来表达基数。回想一下图3-2中显示的图表技术，基数要么是“一”，要么是“多”。通过使用Martin技术（图中第三行），基数“一”用直线表示，而基数“多”用鱼尾线表示。
在更复杂的层面，数据模型应涵盖每种关联的具体基数的更多信息。一个完整的数据模型，将以整数值记录关联的每一方的最小和最大基数。然而，此种详细的基数信息无需在图表中体现，尤其在概念层面。
可选择性
数据模型还必须涵盖关联是强制的或可选的。这通常称作此关联的可选择性。而关联的每一方都具有可选择性的特征。
关联的每一方都具有可选择性的特征。
对于Martin图表技术来说，在关联的底部绘制横线代表此关联是强制的，而绘制小圈则代表此关联可选。请参阅图3-4中的关联图，此数据模型片段清楚地表明EMPLOYEE是被STORE雇佣的。STORE可以有零个、一个或多个EMPLOYEE，只要有EMPLOYEE，那么与STORE的关联就是强制的。并且，一个EMPLOYEE只可以为一个商家工作。
其他的图表技术使用了不同的方法，或者形状不同，或者使用了具体的整数值。
由此可以看出，使用了定义良好的图表技术和符号的图形化数据模型，可以清楚地表达数据的业务需求。通过掌握数据建模技术，一个对业务并不熟悉的人可以快速学会并沟通企业的基本业务规则。