Day28-09｜6.3.2 数据需求分析：先把数据说清楚，再谈表、库与架构

本文对应《系统架构设计师教程（第2版）》第6章“数据库设计基础知识”6.3.2“数据需求分析”。数据需求分析是数据库设计的起点，目标是明确系统需要保存什么数据、数据从哪里来、由谁负责、如何变化、谁可以访问、怎样被查询和统计，以及数据必须达到什么质量。它把业务人员的自然语言转化为可建模、可约束、可测试和可追踪的需求，是避免数据库“表建出来了但业务仍然说不清”的关键活动。

一、学习目标与考试定位

完成本节后，应能够说明数据需求分析的目标、来源、内容和方法；能够识别实体、属性、关系、状态、数据流、数据生命周期和业务规则；能够编制数据字典和需求追踪矩阵；能够区分功能数据需求、质量需求、安全需求、容量需求和运维需求；能够在案例题中发现字段含义不清、口径不一致、数据来源不明、历史数据丢失和访问需求遗漏等问题；能够在论文中写出从需求调研到数据库模型的完整过程。

软考高级题目经常用“用户提出要有一个客户表”“领导要求系统支持大数据量”“报表需要实时统计”这样的模糊描述作为陷阱。答题不能直接接受字段或技术结论，而要追问数据对象、业务规则、操作频率、数据规模、时效、精度、权限和责任。数据需求没有被验证，后续概念模型和物理架构都可能建立在错误假设之上。

二、数据需求分析的本质

数据需求分析要回答六个基本问题：系统需要记录哪些业务事实；这些事实之间有什么关系；事实如何产生、改变和失效；哪些数据必须保持一致；哪些角色可以访问或修改；数据需要以什么性能、容量和可靠性被提供。

数据需求既包括静态结构，也包括动态行为。客户、订单和商品是结构对象；创建订单、支付、发货和退款是数据状态变化；报表、搜索、对账和审计是数据使用方式。只画实体而不分析状态和操作，容易得到看似完整但无法支撑业务流程的模型。

数据需求还具有时间性。当前状态不能替代历史事实，客户等级、商品价格、组织归属和权限都可能随时间变化。需求分析要明确是否需要保存生效时间、失效时间、版本、操作人和变更原因，避免后期无法回答“当时是什么状态”。

三、数据需求的主要来源

1. 业务流程和用例

从业务流程、用例、用户故事和验收标准提取数据对象与操作。一个用例通常包含输入、处理、输出、规则和异常，能够帮助识别数据的产生、读取和更新方。例如“申请退款”会涉及订单、支付、退款申请、审核记录、账户和通知事件。

2. 现有系统与数据资产

调查现有数据库、文件、接口、报表、日志和人工台账，识别真实字段、重复数据、历史遗留和数据质量问题。现有系统不是天然正确的需求来源，必须确认字段含义、口径、责任人和使用方式，不能把历史表结构原样复制到新系统。

3. 用户与干系人访谈

业务用户关注流程和结果，财务关注金额和凭证，运营关注统计和时效，安全人员关注权限和审计，运维人员关注容量、备份和恢复。访谈要覆盖不同角色和异常场景，避免只听单一部门的局部观点。

4. 法规、标准与组织规范

隐私、审计、财务、行业监管、数据保留、脱敏和跨地域存储等要求都会影响数据需求。合规要求应转化为字段分类、访问控制、日志、加密、留存和删除流程，而不是只在文档中写一句“符合相关法规”。

5. 数据接口与外部依赖

外部平台、供应商、消息系统和设备会带来接口字段、编码、版本、错误码、时效、重复、乱序和重试需求。数据需求分析要明确谁是来源系统、谁是权威系统、谁负责校验和冲突处理。

四、数据需求的主要内容

五、识别实体、属性和关系

实体识别可以从业务名词入手，再根据业务独立性、生命周期和操作判断是否需要独立建模。客户、订单、商品通常是实体；地址既可能是客户的属性，也可能是具有独立历史和共享关系的实体；“订单已支付”是状态，不一定是独立实体；“订单包含商品”是联系，若联系有数量和成交价，就应建模为订单明细。

属性应具有清晰定义、类型、单位、精度、是否可空、默认值、敏感级别和来源。不要把一个字段命名为“状态”却让不同模块分别表示不同含义，也不要用“备注”保存多个结构化业务事实。

关系要明确基数、方向、可选性和生命周期。一个客户可以有多个地址，一个订单选择一个收货地址还是保存下单时快照，需要由业务需求决定；支付与订单可能是一对多，因为存在失败重试；物流轨迹通常是一对多且只追加不修改。

六、数据流与数据来源分析

数据流分析关注数据从哪里产生，经过哪些处理，进入哪些存储，被谁消费，以及异常如何处理。可以结合上下文图、数据流图、接口清单和事件目录分析。

对每类重要数据应记录来源系统、采集方式、传输协议、格式、频率、延迟、校验、去重、失败重试、顺序、权威性和消费者。若多个系统都能修改同一客户信息，必须明确主数据系统和冲突解决策略，否则同步越多，矛盾越多。

数据流需求还要覆盖删除、撤回和更正。用户删除个人信息后，缓存、搜索索引、备份、数据仓库和日志中如何处理；订单金额发现错误后，是否直接修改还是保留冲正记录；这些都属于数据需求，不应留到数据库实施阶段才讨论。

七、数据字典

数据字典是对数据项、数据结构、数据流、数据存储和处理逻辑的说明集合。一个实用的数据字典至少应包含数据项名称、业务定义、技术名称、类型、长度、精度、单位、是否必填、允许值、默认值、来源、责任人、敏感等级、生命周期、使用方和变更记录。

数据字典的价值不只是方便开发。它统一业务口径，支持概念和逻辑模型，帮助测试设计边界，支持权限和脱敏，支撑报表和数据治理，降低人员变动后的理解成本。

数据字典必须有责任人和版本。对于“客户数”“活跃用户”“收入”“有效订单”等指标，要记录计算口径、时间范围、过滤条件和数据来源，避免不同报表使用不同定义。数据字典中的字段和代码值应与接口契约、数据库模式和测试数据保持追踪关系。

八、业务规则与完整性需求

业务规则决定哪些数据状态合法。规则可以来自法律、合同、组织政策和业务流程。例如订单金额必须等于明细汇总减优惠，退款金额不能超过已支付金额，库存不能被扣成负数，发票抬头变更需要审计，用户注销后不能继续创建交易。

分析规则时要区分单字段、同一记录、跨记录、跨表、跨服务和跨时间范围的约束。单字段范围可以用域或检查约束；同一订单金额可在事务内校验；跨服务的支付和订单一致性可能需要事件、状态机和补偿；跨时间的“同一用户一个有效订阅”需要唯一条件或受控事务。

规则还应说明异常处理和优先级。库存不足是拒绝、排队还是预售？外部支付超时是未知、失败还是待确认？数据校验失败是丢弃、隔离、人工处理还是重试？这些答案决定数据状态、错误记录和恢复流程。

九、数据质量需求

常见数据质量维度包括准确性、完整性、一致性、及时性、唯一性、有效性和可追溯性。需求要把维度转化为指标，例如客户手机号格式有效率不低于 99.9%，订单金额与支付流水对账差异为零，核心交易事件延迟 P95 不超过 5 秒，重复客户率低于某阈值。

质量指标要明确抽样或全量口径、测量时间、数据来源、责任人和处置方式。发现重复数据后，谁负责合并；发现同步延迟后，是否允许报表继续提供；发现历史字段缺失后，如何标记未知。只有指标和处置闭环，质量需求才可执行。

数据质量应在源头控制，也要在传输、存储、加工和消费环节监测。数据库约束、接口校验、消息幂等、主数据匹配、数据剖析、对账和异常隔离可以共同构成质量防线。

十、容量、性能与生命周期需求

容量需求不仅是“预计一千万条数据”，还要说明初始规模、日增量、峰值写入、查询并发、保存期限、索引和备份增长。性能需求要区分读写、单条和批量、平均和尾部延迟、在线和离线、正常和故障状态。

生命周期需求描述数据从创建、使用、修改、冻结、归档到删除的过程。热数据需要低延迟，历史数据可以进入低成本存储；归档后是否还能查询，删除是否可恢复，备份保留多久，都影响分区、索引、存储和合规设计。

容量和性能需求应通过场景表达，例如“月末结算期间每秒处理 800 笔入账，95% 请求在 300 毫秒内返回，连续运行 8 小时，日志和备份不影响在线事务”。这种表达才能指导物理设计和测试。

十一、数据安全需求

安全需求分析应进行数据分类分级，明确公开、内部、敏感和高度敏感数据；识别访问主体、用途、权限、审批、审计和脱敏要求；确定传输、存储、备份和导出保护；规定密钥生命周期和泄露处置。

还要关注最小权限、职责分离、行列级访问、租户隔离和数据使用目的。开发测试环境不能随意复制生产敏感数据，日志和报表也不能绕过权限暴露原始字段。安全需求应追踪到外模式、表列、接口、应用授权、密钥和审计记录。

十二、需求验证与需求追踪

数据需求验证可以从完整性、一致性、可行性、可测试性、可追踪性和优先级检查。要问：每个关键流程需要的数据是否都有来源；同一字段是否有唯一口径；规则是否存在冲突；容量和性能是否有依据；安全和恢复是否有验收方式；需求是否能追踪到模型、代码和测试。

需求追踪矩阵可以建立“需求—实体/字段—接口—程序—测试—报表—权限”的关系。发生需求变更时，可以快速分析影响范围。对数据需求尤其重要，因为一个字段含义变化可能影响数据库、消息、缓存、数仓、报表和历史数据。

十三、案例分析：客户数据平台口径失控

某企业建设客户数据平台。营销部门把“活跃客户”定义为最近 30 天登录过的客户，客服部门定义为最近 90 天有服务记录的客户，财务部门定义为最近一年有付费订单的客户。项目团队把三个定义都命名为 active_customer，并从多个系统定时同步。上线后报表数字相互矛盾，管理层无法判断真实客户规模。

问题分析

项目缺少数据需求分析和指标口径治理，没有明确业务定义、时间范围、来源、责任人和版本；多个系统同时提供客户事实，但没有权威数据源和主数据关系；同步策略只有“定时拉取”，没有延迟、重复、失败和冲突处理要求。

改进方案

建立业务术语和指标字典，分别命名登录活跃客户、服务活跃客户和付费客户，记录定义、时间窗口、过滤条件和所有者；明确客户主数据与行为事实的来源关系；为每类数据建立数据流、事件时间、处理时间、去重键、迟到数据和重算规则。报表模型与在线系统解耦，设置数据质量、同步延迟和对账指标；指标变更使用版本和影响分析，历史报表按口径版本保留。

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

练习一

需求只写“系统支持大数据量和高并发”，为什么不能直接用于数据库物理设计？应补充哪些内容？

参考答案：描述没有规模、访问类型、峰值、时延、增长、保存期限和质量阈值，无法选择索引、分区、分片或副本。应补充初始数据量、日增长和峰值增长、读写比例、并发用户或请求率、P95/P99 响应时间、批量与在线场景、数据保留、可用性、RTO/RPO、地域和成本约束，并说明测量方法和验收标准。

练习二

三个系统都能修改客户手机号，数据需求分析时应重点确认什么？

参考答案：确认手机号的业务含义、是否允许共享、唯一性和历史要求；明确客户主数据的权威系统、修改权限、审核流程、来源优先级、冲突解决、事件通知、失败补偿和生效时间；定义格式校验、敏感等级、脱敏、审计和数据删除要求。不能简单让三个系统互相覆盖。

练习三

一个报表要求“实时显示今日收入”，请列出需要澄清的数据需求。

参考答案：要确认收入的业务定义，是下单金额、支付成功金额、结算金额还是退款后净额；确认统计时间按事件发生时间还是入库时间，时区和跨日规则；明确数据延迟目标、迟到和补发处理、退款冲正、重复支付、对账来源、权限、口径版本、并发访问和峰值刷新；确定允许的暂时不一致和最终修正方式。

十五、论文写作素材

论文中可以这样描述数据需求分析：项目启动后，我通过业务流程、用例、现有系统、接口、报表、访谈和法规要求识别数据需求，建立数据对象、属性、关系、状态、生命周期、来源、使用者和责任人清单；对客户、订单、库存、支付和审计等核心数据明确权威来源、事务边界、历史保留和异常处理。

我编制数据字典和指标口径，记录技术名称、业务定义、类型、单位、精度、空值、允许值、敏感级别、来源和变更历史；将性能、容量、质量、安全、备份和恢复要求转化为可测量场景和阈值。通过 E-R 模型、数据流、需求评审和需求追踪矩阵验证完整性、一致性和可行性，并建立需求到字段、接口、代码、测试、报表和权限的追踪关系。

在后续设计和实施中，我依据确认后的需求选择逻辑和物理结构，采用约束、校验、幂等、对账、监控、审计和数据质量规则控制风险；需求发生变化时进行影响分析，更新数据字典、模型、迁移脚本、测试和文档，确保数据架构可追溯、可验证和可演进。

十六、今日复盘

数据需求分析的核心是把模糊业务语言变成明确的数据事实、关系、规则、流转、质量、容量、安全和生命周期要求。数据需求来源包括流程、系统、用户、法规和接口；主要产物包括数据需求说明、数据字典、数据流、指标口径、质量指标和追踪矩阵。分析时要区分当前状态与历史事实，明确权威来源、数据所有者、访问模式和异常处理。

记忆主线：

识别数据对象 → 明确关系和规则 → 梳理来源与流向 → 定义质量、安全和容量 → 建立字典与追踪 → 形成可验证的设计输入。

下一篇进入 6.3.3 概念结构设计，重点学习 E-R 模型、实体、属性、联系、局部视图集成和概念模型优化。