主题
第四章 数据库设计与规范化理论
1. 数据库设计概述
数据库设计是指在给定的应用环境下，根据用户需求，在特定的数据库管理系统上构建最优的数据库模式，建立数据库及其应用系统，使之能够有效地收集、存储、管理和处理数据，满足各类用户的应用需求。数据库设计是整个信息系统开发过程中至关重要的一环，其质量直接影响系统的运行效率、数据的完整性和系统的可维护性。
1.1 数据库设计的基本步骤
按照规范化的设计方法，完整的数据库设计通常分为以下六个阶段，每个阶段有其明确的目标和产出物。
第一阶段是需求分析。这是整个设计过程的基础和起点。设计人员需要深入用户的业务现场，通过调研、访谈和问卷等方式，全面了解用户的数据需求（需要存储哪些数据）、处理需求（数据将如何被使用和加工）、安全性需求（哪些数据需要保密）和完整性需求（数据之间应满足什么约束关系）。此阶段的主要产出物是数据字典和数据流图 (DFD)。数据字典详细记录了每个数据项的名称、含义、类型、取值范围和数据量估计等元信息。数据流图则以图形化的方式描述了数据在系统中的流转、加工和存储过程。这些文档是后续所有设计工作的唯一合法依据，其质量直接决定了后续设计的成败。
第二阶段是概念结构设计。这一阶段的任务是将需求分析得到的结果抽象为一个不依赖于具体 DBMS 的概念模型。概念模型独立于计算机硬件和软件，是现实世界到信息世界的第一层抽象。最常用的概念建模工具是 E-R 模型。概念结构设计的产出物是全局 E-R 图。
第三阶段是逻辑结构设计。这一阶段的任务是将概念模型转换为特定 DBMS 所支持的数据模型（通常是关系模型），形成数据库的逻辑模式。在此过程中需要运用规范化理论对关系模式进行优化，消除数据冗余和操作异常。逻辑设计还包括为各种用户或应用定义合适的外模式（视图）。
第四阶段是物理结构设计。这一阶段需要为逻辑模式选择合适的物理存储结构和存取方法。具体工作包括确定数据的存储方式（如行存储还是列存储）、建立合适的索引（选择索引列、索引类型和索引组织方式）、确定数据的分区策略以及配置数据库系统的各种运行参数（如缓冲池大小、并发连接数等）。物理设计的目标是在满足功能需求的前提下，使系统具有最佳的时间和空间性能。
第五阶段是数据库实施。包括使用 DDL 语句创建数据库结构、编写数据加载程序将初始数据装入数据库、编写和调试应用程序，以及进行系统联调和试运行。
第六阶段是数据库运行和维护。数据库投入正式运行后，需要持续进行性能监控和调优、安全性审计、数据备份与恢复演练，以及在业务需求发生变化时对数据库模式进行适当的调整和扩充。
这六个阶段看似是顺序展开，实际上往往会反复迭代。一个设计方案很少能在第一次讨论时就完全正确，因为真实业务中的很多概念在最初并不清晰。例如“活跃用户”“订单完成时间”“有效成绩”“当前部门”这类术语，表面上人人都懂，真正落到字段定义和统计口径时却常常出现分歧。也正因为如此，需求分析阶段不能只停留在“收集字段”，而必须同步澄清关键术语的业务定义、计算口径和边界条件。若语义不清，后续即使表结构写得再工整，也只是在错误问题上做规范化。
1.2 数据库设计的方法论特点
数据库设计既涉及技术层面（如数据模型、索引设计、查询优化等），也涉及管理层面（如业务流程分析、组织协调等）。在实际项目中，数据库设计通常不是一次性完成的，而是需要经历多轮迭代。随着对应用理解的加深和原型系统运行中问题的发现，设计方案会不断被修正和完善。
因此，数据库设计最常见的两种误区都需要避免。第一种是“唯范式论”，认为范式越高就一定越先进，于是不分场景地不断拆表；第二种是“唯性能论”，认为只要查询快就可以牺牲结构清晰性，结果把多个事实长期混杂在一起。更稳妥的做法是把规范化视为默认基线，因为它能帮助我们建立清晰、可验证的事实边界；把反规范化视为受控例外，只在确有明确访问模式和成本收益依据时才采用。换句话说，设计不是在理论和工程之间二选一，而是在清晰结构的前提下逐步对齐性能需求。
2. 概念结构设计：E-R 模型
E-R 模型由 P.P. Chen 于 1976 年提出，是目前最广泛使用的概念数据模型。它以实体、属性和联系为基本建模元素，用直观的图形化方式描述现实世界的数据结构。
2.1 E-R 图的基本元素
实体 (Entity)：客观存在且能够相互区别的事物。实体可以是具体的对象（如一名学生、一本书），也可以是抽象的概念（如一门课程、一个项目）。在 E-R 图中用矩形表示。
属性 (Attribute)：实体所具有的某一特性。用椭圆表示，并用线段与所属的实体相连。能够唯一标识实体实例的属性或属性组合称为该实体的码（即键），在 E-R 图中通过在属性名下加下划线来标注。
属性还可以进一步细分为以下类型：简单属性与复合属性（复合属性由若干简单属性组成，例如地址可以分解为省份、城市和街道）；单值属性与多值属性（多值属性可以取多个值，例如一个人的电话号码可能有多个）；派生属性（其值可以由其他属性计算得出，例如年龄可以由出生日期计算）。
联系 (Relationship)：实体之间或实体内部的关联。用菱形表示，菱形内标注联系名，并用线段分别与相关的实体连接。联系本身也可以具有属性。
2.2 联系的类型
联系按参与实体的比例关系，分为一对一 (1:1)、一对多 (1:n) 和多对多 (m:n) 三种基本类型。确定联系类型是概念设计中的关键步骤，因为不同类型的联系在後续转换为关系表时遵循不同的转换规则。
此外还存在以下特殊情况：同一实体集内部的联系（如员工之间的领导与被领导关系，这属于同一实体自身的一对多联系）；涉及三个或更多实体的多元联系（如供应商、零件和项目之间的三元联系，表示某个供应商为某个项目供应了某种零件及其数量）。
2.3 扩展的 E-R 概念
弱实体 (Weak Entity)：一个不能仅凭自身的属性来唯一标识的实体。弱实体的存在依赖于另一个实体（称为属主实体或强实体）。弱实体的主键通常由其自身的部分键加上属主实体的主键共同组成。例如，家庭成员是相对于员工的弱实体，家庭成员的标识需要结合员工编号和成员姓名才能唯一确定。
ISA 联系（泛化与特化）：表示实体类型之间的分类关系。一个高层实体类型可以按照某种特征细分为若干低层实体类型。例如，员工可以特化为技术人员和管理人员，低层实体继承高层实体的全部属性，并可以拥有自己的特有属性。
2.4 局部 E-R 图的集成
在大型系统中，通常由不同的设计人员分别完成各自负责的业务领域的局部 E-R 图，最后需要将所有局部 E-R 图合并为一个统一完整的全局 E-R 图。合并过程中需要识别和解决三类冲突：属性冲突（同名属性的类型或取值范围不一致）、命名冲突（同义异名或同名异义）和结构冲突（同一事物在不同视图中被抽象为不同的元素类型）。
局部 E-R 图集成之所以困难，根源往往不在画图技术，而在不同部门对同一业务对象的理解并不完全一致。销售部门眼中的“客户”可能更强调成交和线索状态，客服部门眼中的“客户”可能更强调服务记录和投诉历史，财务部门眼中的“客户”又更强调结算主体和开票信息。若不在集成阶段把这些视角统一起来，数据库后续就会出现“一词多义”或“同义多词”的问题，进而影响字段命名、主键选择和统计口径。概念设计真正承担的任务，是在技术实现之前先统一认知边界。