数据模型设计步骤：概念模型
引言
熟悉数据库设计的人普遍认同数据库设计可以分为三个主要阶段，包括概念模型设计、逻辑模型设计以及物理模型设计。那么，每个设计阶段应该包含哪些具体步骤？尽管这个问题对指导相关工作的开展而言至关重要，但是人们对此却众说纷纭1。为了找到一个合理的说法，我阅读了几本与数据库设计相关的书籍 (Silberschatz, Korth, 和 Sudarshan 2019; Carlos Coronel 和 Steven Morris 2018; Connolly 和 Beg 2015; Hernandez 2013) ，并对其中的内容进行了比较。经过比较，我认为 Connolly 和 Beg (2015) 提出的设计步骤相对而言最为系统、全面且专业，因此适合作为数据库设计时的主要参考指南。为了提供快速回顾主要设计步骤的途径，我想写几篇短文对该书的相关内容进行概述。需要指出的是，数据库设计是基于需求分析的结果之上的，但需求分析相关话题不在短文的探讨范围之内；此外，为了控制篇幅，短文也不会对数据库设计所涉及的一些基本概念进行过多介绍，有需要的读者可以查阅原书进行深入了解（为方便查阅，我在本文中给出了与相关概念对应的英文名词）。
1 这份调查结果充分反映了这个事实。
此文是几篇短文中的第一篇，描述的是数据库设计中的第一阶段——概念模型设计所涉及的步骤，对应 (Connolly 和 Beg 2015) 第16章的内容。值得一提的是，有时我们可能需要为一个数据库系统设计多个概念模型。这是因为一个数据库系统往往拥有多个用户视图（user view），每个视图会从特定用户角色（如经理、主管等）或应用领域（如销售、人事、库存管理等）的角度定义系统的需求；如果各个视图间相对独立且总体而言比较复杂，就需要采用视图集成（view integration）方法，分别为各个视图构建一个局部概念模型，并在之后的逻辑模型设计阶段对这些局部模型进行合并。相反地，如果不同用户视图间存在明显重叠且总体上不是特别复杂，那么可以采用集中式（centralized）方法，将各视图定义的需求汇集成一个总需求，这样的话只需设计一个能够满足总需求的概念模型即可。
步骤1：确定实体类型
设计概念模型的第一步是确定系统用户关心的主要对象，也就是实体类型（entity type）。确定实体类型的主要方法是仔细分析用户的需求规格说明书，对其中出现的名词和名词性短语进行归纳，进而总结出它们所表示或描述的实体类型。在得到实体类型后，应该为其指定一个简明扼要的名字，然后在ER图（entity relationship diagram）和数据字典中做好相关记录（例如名称、别名、定义等）。
步骤2：确定联系类型
设计概念模型的第二步是确定实体类型之间的主要联系，也就是联系类型（relationship type）。与实体类型相似，联系类型的确定主要也是通过分析需求规格说明书实现的；但与实体类型不同的是，联系类型在说明书中通常以动词或动词性短语来表示或描述，因此在分析时需要着重关注这些词汇。另外，在发现一个联系类型后，应进一步明确其多重性（multiplicity），以便更准确地表示用户的需求。在得到联系类型后，同样应该在ER图和数据字典中做好相关记录（例如名称、多重性、参与联系的各实体类型及其角色等），并检查ER图是否提示了扇形陷阱（fan trap）和断层陷阱（chasm trap）的存在，以便进行相应处理。
步骤3：确定各个实体类型和联系类型所含的属性
设计概念模型的第三步是确定各个实体类型和联系类型所需包含的属性（attribute）。同实体类型的确定方法类似，我们需要关注需求规格说明书中出现的名词或名词性短语；如果这些词汇表示或描述了实体类型或联系类型的特性、性质、标识或特征，即可将其视为属性。在确定了属性之后，应在ER图和数据字典中为每个属性记录以下信息：
- 名称和说明；
- 别名；
- 数据类型和长度；
- 是简单属性（simple attribute）还是复合属性（composite attribute），并且如果是后者的话还要列出其中包含的简单属性；
- 是单值属性（single-valued attribute）还是多值属性（multi-valued attribute）；
- 是基本属性（base attribute）还是派生属性（derived attribute），并且如果是后者的话还应该定义计算方法；
- 默认值。
步骤4：确定属性的定义域
设计概念模型的第四步是确定各属性的取值范围，即定义域（domain）。定义域是满足特定数据类型和长度的所有取值集合的一个子集，因此其对属性取值的约束比上一步骤中定义的数据类型和长度更强。另外，由于多个属性可以共享同一个定义域2，所以定义域需要在上一步骤完成之后再确定。在确定定义域后，应该更新ER图和数据字典，添加各定义域的名称和特性（例如合法值集合、是否可以为空、格式等），并以其替代属性的数据类型和长度信息。
2 以“员工”和“客户”两个实体类型为例，若它们均含有“性别”属性，那么这两个属性可以共享同一个定义域。
步骤5：确定候选键、主键和可替换键
设计概念模型的第五步是为各实体找出候选键（candidate key），并在此基础上确定主键（primary key）和可替换键（alternate key）。在确定主键的过程中，需要注意区分实体的强弱3：如果我们能够为一个实体确定主键，则该实体为强实体（strong entity），否则为弱实体（weak entity）。在此步骤中，我们只需为强实体确定主键即可；弱实体主键的确定需要在之后的逻辑模型设计阶段完成。在确定各实体的主键和可替换键之后，需要在ER图和数据字典中为相关属性做好对应标识。
3 值得一提的是，实体的强弱并不是绝对的；即使弱实体本身不存在可以作为主键的属性，我们仍然可以为其分配一个代理键（surrogate）作为主键，使其转化为强实体。
步骤6：考虑使用增强的建模概念（可选步骤）
设计概念模型的第六步是考虑是否引入增强的建模概念，比如特殊化（specialization）/泛化（generalization）、聚合（aggregation）和组合（composition）。判断是否需要引入这些概念的主要准则是它们能否使模型更加准确且易于理解，但由于这在很大程度上也取决于设计者的主观认识，所以这个步骤并不总是必要的。如果确定要引入增强的建模概念，那么就要对ER图和数据字典进行修改，使用相应的记号和说明表达这些概念。
步骤7：检查模型是否存在冗余
设计概念模型的第七步是检查模型中是否存在冗余，并对所找到的冗余内容进行处理。这一步所涉及的主要活动包括：
- 检查并删除冗余的实体类型。仔细检查模型中存在的一对一（1:1）联系，有时可能会发现存在这种联系的两个实体类型所表示的实际上是同一个对象；在这种情况下，应该删除其中一个实体类型，并将其属性合并入另一个实体类型中。
- 检查并删除冗余的联系类型。两个实体类型之间可能存在不止一条联系路径。在这种情况下，应该仔细检查每条联系路径的含义及其所能提供的信息。如果某条联系路径所表示的含义及信息完全能够通过另一条联系路径表示，那么前者就是冗余的，需要删除。
步骤8：通过用户事务验证概念模型
设计概念模型的第八步是通过用户事务验证模型，确保模型支持所需的事务。验证的主要方法包括：
- 描述事务。通过描述事务，我们可以分析模型是否能够提供实现事务所需的信息，包括实体、联系和属性等。
- 使用事务路径。在ER图上标注每个事务的实现路径，以直观地观察模型对事务的支持情况。
如果经过上述验证发现模型不能够支持所需的事务，那么就需要检查模型中是否遗漏了关键的实体类型、联系类型和属性，并进行必要的补充；另一方面，如果有些实体类型、联系类型和属性不被任何事务使用，那么就要考虑它们存在的必要性，并对模型进行可能的简化。
步骤9：与用户共同复核概念模型
设计概念模型的最后一个步骤是与用户一起对模型进行复核。复核主要围绕ER图和数据字典进行。如果发现模型中存在任何问题，就必须进行相应的修改，而这可能需要重复前面的步骤。复核的过程可能需要重复多次，直至用户确认模型能够充分地满足需求。
小结
本文简要描述了数据库设计的第一阶段——概念模型设计的步骤。值得注意的是，数据库设计是一个需要反复迭代的过程，其优化的过程几乎没有止境。尽管这里介绍的步骤看似是一个程序式的过程，但这并不意味着实际的设计工作必须机械地按顺序开展；这是因为有时从后续步骤里获得的新信息可能会提示我们需要对先前步骤中做的决策进行改变。