Day28-08｜6.3.1 数据库设计的基本步骤：从业务需求到可运行的数据系统

本文对应《系统架构设计师教程（第2版）》第6章“数据库设计基础知识”6.3.1“数据库设计的基本步骤”。数据库设计是把业务需求转化为数据结构、约束、访问方式、存储实现和运行方案的系统过程。它不是画完 E-R 图就结束，也不是由 DBA 单独负责的表结构工作。系统架构师需要把业务目标、数据治理、质量属性、应用接口、数据库平台和生命周期管理串起来，保证设计能够实施、验证、演进和恢复。

一、学习目标与考试定位

完成本节后，应能够说出数据库设计从需求分析到运行维护的主要阶段；明确每个阶段的目标、输入、输出、参与角色和评审重点；能够区分数据需求分析、概念结构设计、逻辑结构设计和物理设计；能够分析数据库设计中“先建表后补需求”“只关注字段不关注约束”“没有考虑迁移和恢复”等问题；能够在案例题和论文中完整描述数据库设计流程。

考试常见题型是给出一个业务系统，让考生选择正确的设计步骤、指出某一阶段产物或分析设计缺陷。高级案例还会要求考虑高并发、分布式、数据迁移、权限、备份、历史数据和性能。答题不能只列阶段名称，要说明阶段之间的输入输出关系，以及如何通过评审、原型、测试和迭代降低风险。

二、数据库设计的总体流程

经典数据库设计通常包括：需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库实施、数据库运行和维护。实际项目往往是迭代的，性能原型、数据质量检查、权限审查和迁移演练可能在多个阶段反复进行。

三、需求分析：从业务语言识别数据需求

数据库设计的第一步不是确定表名，而是理解业务。需求分析要识别业务对象、属性、关系、状态、生命周期、数据来源、数据消费者、查询和更新场景、数据量、增长速度、保留期限、敏感等级和质量要求。

1. 数据需求

数据需求说明系统需要保存什么事实。例如客户身份、订单、明细、支付、库存、物流、操作记录和业务规则。要注意区分当前状态和历史事实：客户当前等级会变化，订单成交价格通常是历史事实；库存可用量是状态，库存流水是过程记录。

2. 数据操作需求

要收集新增、查询、修改、删除、批量导入、导出、统计和归档等操作，并记录频率、并发、时延和事务边界。一个“查询订单详情”可能包含订单、客户、明细、支付和物流多个数据聚合；一个“扣减库存”不仅是更新数字，还涉及并发、幂等和异常恢复。

3. 数据质量和安全需求

需求阶段就要明确准确性、完整性、一致性、及时性、可追溯性和可恢复性；对身份证、手机号、支付信息和健康数据等敏感字段，定义访问角色、加密、脱敏、审计和保留期限。若安全和质量后置，逻辑模型和物理设计可能需要大面积返工。

4. 需求确认与追踪

需求要由业务、产品、架构、开发、测试、数据和运维共同确认。每条关键数据需求应能追踪到实体、字段、约束、接口、测试和报表，避免“需求文档说一套、数据库实现另一套”。

四、概念结构设计：建立业务世界的抽象

概念结构设计独立于具体数据库产品，重点是表达业务实体、属性和联系。E-R 模型是常用工具，实体表示客观对象，属性表示特征，联系表示实体之间的关系。

设计时要确定实体的边界和粒度。比如“订单”是一次交易的整体，“订单明细”是订单与商品的联系实例，“支付记录”可能是一个订单的多次支付尝试，而不是订单的一个简单属性。粒度不清会导致字段混杂、重复和状态冲突。

还要确定联系的基数和可选性：一个客户可以有多个订单，一个订单是否必须属于客户；一个订单至少有一条明细吗；商品可以属于多个分类吗；员工是否可以同时任职多个部门。基数错误会直接影响外键、非空、唯一和业务验证。

概念模型要表达业务规则，但不宜过早加入索引、分区、数据库厂商类型等物理细节。架构师应使用业务人员能理解的语言和图表，通过评审确认模型语义。

五、逻辑结构设计：从概念模型落到数据结构

逻辑结构设计根据选定的数据模型，将概念实体和联系转换为表、文档、图节点、边或其他逻辑结构。对关系数据库而言，要确定关系模式、属性、域、主键、候选键、外键、约束、视图、范式和事务边界。

1. 关系转换

每个独立实体通常转换为一个关系；一对多联系通常在多的一方增加外键；多对多联系转换为独立的联系关系；一对一联系根据生命周期、访问和可选性决定合并或拆分。联系中的属性必须放在能够准确表达其语义的位置。

2. 规范化与约束

通过函数依赖分析消除部分和传递依赖，减少冗余和更新异常；通过主键、外键、唯一、非空和检查约束表达数据不变量。规范化不是唯一目标，针对高频读取可以设计受控读模型，但必须明确权威数据源和同步方案。

3. 逻辑事务与接口

逻辑设计要与应用事务和服务边界协同。若订单和支付必须在同一数据库事务内，模型和部署要支持这一边界；若分别属于不同服务，应通过状态机、消息、幂等和补偿实现一致性。不要因为两张表存在关系，就默认它们必须跨服务共享数据库。

4. 视图和数据服务

为不同角色和应用设计外模式、视图或数据服务，隐藏内部结构、限制权限并稳定契约。报表视图、读模型和交易模型可以不同，但要建立血缘、刷新策略、延迟目标和重建能力。

六、物理结构设计：让逻辑结构满足质量属性

物理设计把逻辑模型落实到具体数据库平台和部署环境，关注数据存储位置、索引、分区、分片、副本、表空间、压缩、缓存、连接、归档和参数。

1. 存储与容量

根据数据规模、增长率、冷热特征和保留期限规划存储，计入表数据、索引、日志、临时空间、备份、复制和增长余量。容量模型应说明峰值、日增长、历史保留和扩容窗口。

2. 索引与访问路径

根据高频查询、过滤、连接、排序和唯一性设计索引，使用执行计划和代表性数据验证。索引不是越多越好，写入密集表、低选择性字段和频繁更新字段都要慎重。

3. 分区、分片与副本

分区可改善管理和局部扫描，分片可扩展容量和吞吐，副本可提高读取能力和故障切换。每项技术都带来数据倾斜、跨分片事务、复制延迟、切换一致性和运维复杂度，必须在容量和故障模型下验证。

4. 安全和可用性

物理设计还要考虑加密、密钥、网络隔离、备份位置、跨可用区、灾备、监控和审计。生产数据库不能只设计“能跑”，还要设计“故障后能恢复”。

七、数据库实施

实施阶段包括创建数据库对象、编写和执行 DDL、建立索引和约束、导入初始数据、配置权限、开发访问程序、建立测试数据和验证环境。脚本应可重复执行、幂等或有明确版本，不能依赖个人手工步骤。

数据迁移要先做源数据剖析，识别重复、缺失、非法值、编码、时间和单位问题；然后制定清洗、映射、转换、校验、增量同步和回滚方案。全量迁移完成不代表成功，还要进行行数、金额、摘要、关联、业务抽样和应用验收对账。

实施应包含数据字典、部署清单、配置记录、监控和备份初始化。上线前执行功能、性能、安全、并发、恢复和迁移演练，确认质量门禁和回滚条件。

八、运行维护

数据库运行维护包括日常监控、性能优化、备份恢复、权限审计、空间管理、数据质量、故障处理、模式变更和版本升级。监控指标应覆盖连接数、CPU、内存、I/O、锁等待、慢查询、缓存命中率、复制延迟、日志增长、备份结果和数据同步延迟。

性能问题处理应遵循测量—分析—改进—验证闭环。对慢查询查看执行计划，对锁问题分析事务和访问顺序，对容量问题建立增长预测；调整索引、分区、SQL、缓存或硬件后，验证业务指标和副作用。

模式变更通过配置管理和变更控制执行，采用兼容字段、双写、回填、灰度、校验和回滚。权限实行最小授权，敏感数据访问和导出可审计。备份要定期恢复演练，灾备切换和回切都要有操作手册和责任人。

九、数据库设计中的迭代与原型

传统流程强调阶段顺序，现代项目更强调风险驱动和迭代。概念模型可以先建立最小可用版本，逻辑模型通过评审和原型逐步细化，物理设计通过真实规模压测校正。对高风险技术、复杂查询、迁移和灾备应尽早验证。

迭代不等于没有文档和控制。每轮迭代都要明确目标、假设、输入、输出、决策、未解决风险和变更记录。数据库设计的关键基线包括数据字典、逻辑模型、物理模型、迁移脚本和质量指标。

十、案例分析：从零建设统一订单数据库

某企业建设统一订单平台，需求方只提供了一张“订单信息表”，其中混合客户资料、商品列表、支付状态、物流地址和发票信息。项目团队直接按这张表建库，后续发现一个客户多地址、一个订单多次支付、商品价格随时间变化、报表和在线查询互相影响，数据库难以扩展。

问题分析

项目跳过了数据需求分析和概念结构设计，把展示页面结构当成了数据模型；没有识别实体粒度、生命周期、历史事实和联系属性；没有区分交易负载与分析负载；也没有明确支付重试、物流状态和地址快照的事务边界。

改进方案

先访谈业务角色，建立客户、订单、订单明细、支付尝试、收货地址、物流事件和发票等概念实体，明确关系基数和历史语义；逻辑层定义稳定主键、外键、状态约束、金额精度和事务边界；物理层根据查询、写入、增长和可用性设计索引、分区、读模型和分析同步。实施时执行数据迁移和清洗，建立脚本、权限、监控、备份和回滚；运行后持续监控慢查询、锁、同步、数据质量和恢复能力。

十一、综合知识练习与详细答案

练习一

请说明数据需求分析、概念结构设计和逻辑结构设计的区别。

参考答案：数据需求分析识别需要管理的数据、业务规则、操作、查询、质量和安全要求；概念结构设计在不依赖具体数据库的前提下抽象实体、属性、联系、基数和语义；逻辑结构设计选择关系、文档或图等逻辑模型，将概念结构转换为表、键、约束、视图、聚合和事务边界。三者从需求事实逐步落到可实现的数据结构，不能用一张页面表直接替代前两个阶段。

练习二

物理设计已经确定索引和分区，为什么仍然需要性能测试？

参考答案：索引和分区只是设计假设，实际性能还受数据分布、统计信息、执行计划、并发、锁、缓存、I/O、网络和增长影响。必须用代表性数据和业务负载测量响应时间、吞吐、资源、写入开销和故障表现，确认指标是否满足；若不满足，需要调整 SQL、索引、分区、缓存、读写隔离或架构方案。

练习三

数据库实施前发现源数据存在重复客户和非法手机号，应如何处理？

参考答案：先进行数据剖析和问题分类，定义去重规则、主数据匹配、人工确认、非法值处理和审计要求；建立清洗和转换脚本，保留原始数据及映射日志；迁移后进行数量、关键金额、关联关系、抽样和业务对账；对无法自动判断的数据设置人工复核。不能直接忽略错误或用随机值填充，否则会把数据质量问题永久带入新系统。

十二、论文写作素材

论文可按完整生命周期组织：我先通过访谈、流程分析和数据剖析识别业务实体、关系、状态、查询和更新场景，明确容量增长、性能、可用性、安全、保留和恢复目标；在概念设计阶段建立 E-R 模型，确认实体粒度、基数、生命周期和数据所有权；在逻辑设计阶段完成关系转换、主外键、函数依赖、约束、视图和事务边界设计。

物理设计阶段根据访问模式和质量目标设计索引、分区、分片、副本、归档、备份和监控，并通过原型、容量建模和压测验证；实施阶段将 DDL、迁移脚本、权限和配置纳入版本管理，采用数据清洗、校验、灰度、对账和回滚；运行维护阶段持续监控性能、锁、空间、复制、同步、备份和安全审计，模式变更经过影响分析、审批、测试和恢复验证。

十三、今日复盘

数据库设计的基本步骤是需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库实施以及运行维护。需求阶段解决“需要什么数据和规则”，概念阶段解决“业务对象如何关联”，逻辑阶段解决“用什么结构和约束表示”，物理阶段解决“如何在平台上高效可靠地存储访问”，实施和维护则保证设计真正可运行、可迁移、可恢复和可演进。

记忆主线：

需求定语义，概念定边界，逻辑定结构，物理定性能，实施保落地，维护保持续；每个阶段都有输入、输出、评审和验证。

下一篇进入 6.3.2 数据需求分析，进一步学习数据需求的来源、内容、方法、数据流和数据字典。