企业官网建设流程全解析

简介：面向数据库系统开发与设计课程的事实发现（Fact-Finding）PPT课件，适合数据库原理、系统分析与设计教学及自学场景。资源包内仅含一个PPT文件，容量约570KB，已有109人学习浏览。课件以数据库系统开发生命周期为线索，说明在数据库规划、系统定义、需求收集与分析等阶段应收集的事实类型和对应文档，例如用户需求说明书、逻辑与物理数据库设计、性能测试结果等，并重点讲解检查文档、面谈、观察业务运转、研究、问卷调查五种常用技术，覆盖开放式与限制式问题设计、问卷适用场景等实用要点。内容结合StayHome录像出租公司案例，展示了员工注册、会员管理、录像租借等具体业务中如何运用事实发现方法，帮助读者理解公司运营模式、用户行为和服务需求，从而把需求调研落到数据库设计早期阶段，为后续数据库建模与设计奠定基础；适合作为课程讲义、课前预习或课后复习材料，也可用于教学演示。

1. 事实发现：数据库设计里最容易被低估的一道工序

在很多数据库课程里，chap06“事实发现”正好卡在 ER 模型和关系模式之后。很多人的第一反应是：这章怎么突然偏向管理流程了。真实项目里的经验正好相反——模型改来改去、需求反复确认、阶段返工，根子几乎都不在画图水平，而在动手画图之前事实没有问够、没有问对。事实发现就是专门解决这个问题的环节，它把业务里的数据内容、处理流程、业务规则和约束条件系统性挖出来，整理成概念设计和逻辑设计可以直接用的输入。往下就用一线落地的方式讲清楚它是什么、怎么做、坑在哪。

2. 事实发现到底在找什么：信息需求、处理规则与业务约束

事实发现（fact-finding）这套方法论，在数据库领域被单独列一章，不是因为它在技术上有多深，而是因为它是整个生命周期里最不可控的一段：ER 图画错了可以改，表结构建错了可以迁移，需求收集漏了一条关键规则，往往要到联调甚至上线之后才爆出来，代价最大。

2.1 第一性目标：把业务规则翻译成数据约束

事实发现表面上是“了解业务”，本质上是在收集可以被翻译成数据库结构的事实。比如业务里有规则“同一个客户对同一个产品在同一张订单里只能出现一次”，翻译到表结构就是联合唯一约束；规则“单价不能低于 0”，翻译到列上就是 CHECK 约束；规则“没有客户的订单不允许创建”，翻译过来就是外键约束加非空约束。

这里容易忽略的是“约束粒度”。听到一条规则，要顺手判断它落在哪一层：是列级约束，还是行级约束，还是跨表的参照完整性约束。判断得越早，后面积累的误读越少。我的习惯是，在做事实发现记录时，每记一条规则就在旁边标一个“列/行/表/跨表”的预判词，不用写 SQL，只要把层级写对，后面建模的人就能少走弯路。

这也解释了为什么这门课把这章放在模型设计前面：不是让你先学一堆理论再去做需求收集，而是提醒你，ER 图和关系模式本身是“约束的载体”，而约束的原材料，全部来自事实发现阶段。

2.2 三类必问事实：业务数据、处理流程、边界与例外

做事实发现时，我习惯把要问的内容分成三类，避免面谈时被业务方带着漫谈。

第一类是业务数据，包括实体、属性、取值单位、精度和关系。比如“库存量是指可卖量还是物理库存”“金额是含税还是不含税”。这类事实直接决定字段和表的形态。常用问法包括：“这个数字包含哪些明细”“它的单位是什么，有没有精度要求”“一个客户能不能有多个联系人，联系人有没有独立地址”。第二类是处理流程，包括数据从哪来、经过哪些状态、谁有权限改、什么时候删。比如“一张采购单从生成到取消要经过哪几个状态”。这类事实产出状态机、触发条件和权限设计。第三类是边界与例外，解决“什么情况下正常流程不适用”的问题，比如“订单取消后，部分已发货的商品怎么办”“单子金额超标时是不是一定要走二审”。第三类最贵，因为主流程人人会讲，例外往往是靠追问和观察逼出来的。

业务里有个很典型的例子：主管说“订单原则上不能删，只能取消”，你接着问“取消后的订单还要不要留档”，对方答“要”。这一来一回，同时确定了三件事：订单表没有 DELETE 权限，只有状态流转；取消操作必须留记录；需要一个状态字段或一张操作日志表。一条对话，就能定下一组约束。

2.3 事实发现在数据库生命周期里的位置：模型设计与初始研究之间

数据库生命周期一般从初始研究开始，一直到设计、实现、测试、运行维护。事实发现正好卡在“初始研究”和“概念设计”之间：前面需要了解组织目标、现有系统和问题定义，后面需要产出需求清单和业务规则清单，供概念设计阶段绘制 ER 模型。

实际项目里，这一阶段不是一次走完的。第一轮通常配合文档审查把存量摸清，第二轮用面谈和观察验证并补充例外，第三轮带着原型回访确认理解是否一致。常见的时间节奏是：中小型业务模块，文档审查 1~2 天，面谈每场 45 分钟排 3~5 场，观察 2~3 个工作日，加上整理归档，完整走下来大概一到两周。这个时间投入看起来很贵，但相比设计阶段反复返工的消耗，通常很划算。下面这张阶段对应表，是很多数据库课程在讲生命周期时常用的对照关系：

初学者最容易把“事实发现”和“需求分析”当成完全不同的两件事。数据库语境里，事实发现就是一种系统化的需求收集方法，它把软件工程里常见的面谈、调研、观察等手段固定成了一套可复用的流程。叫“事实发现”，重点落在“事实”两个字上：要的是直接证据，不是二手转述，不是“我猜应该是这样”。这一差别，到了避坑章还会反复出现。

3. 五大事实发现技术怎么选：成本、覆盖面与产出对比

这一章要把手上能用的工具盘一遍。文档审查、面谈、观察、问卷、系统原型，五种技术各有适用场景，也各有硬伤。没有哪个是万能选项，真正的功夫在组合。

3.1 文档审查：动手之前最值得先做的存量采集

文档审查就是把能找到的业务资料收集起来过一遍：现有单据、报表、操作手册、流程文件，以及旧系统数据库的表结构和字段注释。别小看这一步，它的成本在五项技术里最低，却能最快帮你建立业务对象的全貌。很多面谈翻车，就是因为进场之前连对方讲的“订单”指的是哪张单都不知道。

操作上按三个动作走。第一步，建文档清单，把文档按核心程度排序，从最核心的报表和数据表结构开始读。第二步，逐份提取，对每份文档问三句话：“这里面有哪些数据项”“谁产出它”“它最终流向哪里”。数据项记下来，角色也记下来，角色后面会变成权限设计的依据。第三步，标注待验证项。文档里凡是出现“原则上”“一般”“特殊情况下”这类措辞的地方，全部标成待验证。这些语句就是业务约束和例外的线索。

文档审查的产出是“数据项清单”和“规则线索表”。它的局限也很明显：文档只代表纸面规则，可能过时。所以文档只能当起点，不能当终点，所有从文档里挖出来的规则，必须拿到面谈或观察里去验证。

注意：文档里“原则上不允许”这类句子，几乎一定对应一条约束或一个例外分支，别在标注时放过它。

3.2 面谈：信息密度最高，但最容易被带偏

面谈是事实发现的核心手段，信息密度最高，但也最容易翻车。翻车的原因基本只有一个：把面谈当成了聊天。有经验的开发者一般会用半结构化方式，准备一份问题提纲，但不按顺序死问，而是顺着对方描述的业务场景自然追问。

关键在问法。不要问“你们有什么需求”，这句话太抽象，对方往往回一句“系统太慢、表格难用”就冷场。要问“你每天上班后处理一笔订单的第一步是什么？扫单号，还是先看邮箱？”对方顺着操作场景走，需求自然就带出来了。追问也有套路：每听到一个操作，至少追问三次“然后呢”“为什么”“有没有例外”。比如用户说“发货单号是仓库填的”，你要追问：“所有单子都由仓库填吗？填错了谁改？走什么流程？改之前的数据留痕吗？”这些追问得到的回答，几乎每一条都能对应到一个外键、一条状态约束或一条日志需求。

执行上还有几个约定俗成的细节：双人配合，一人主导提问，一人专门记录，主导的人不要低头记；录音前必须征得对方同意，不同意就不录，改为结束后当场复述确认；结束后 30 分钟内完成整理，超过 24 小时再整理，细节会明显失真。

提示：面谈录音前一定先征得对方同意。没有录音的情况下，结束前 5 分钟复述关键结论并请对方纠正，是最后一道保险。

3.3 观察与跟班：还原真实工作流的关键手段

面谈和文档能告诉你“应该怎么跑”，但用户实际走的路线可能完全不一样。真实业务里常有线下 Excel 台账、口头传递、手工改单之类的“影子操作”，这些是面谈问不出来的，对方未必刻意隐瞒，只是早已习以为常。观察就是用来抓这类事实的手段。

观察分参与式和非参与式，数据库需求阶段我多数用非参与式：在不影响对方工作的前提下，安静观察一个完整业务流程跑完。观察不是傻看，重点记录三样东西。第一，操作顺序，用户先开哪个页面、再点哪个按钮、最后填哪张表。第二，系统外处理，用户会不会先在手边 Excel 里记一笔再录系统，这就是潜在的数据不一致来源。第三，异常路径，某一步校验不通过时，用户是按流程退回重走，还是手工改库。

观察的代价是耗时，一个岗位往往要看 3~5 个工作日才能覆盖到不同业务形态，尤其是月初、月末和结算日。但用观察换来的规则真实性，是面谈和文档很难替代的。

3.4 问卷：大范围覆盖用户，但回收是硬伤

问卷适合两种场景：一是用户群体分散在多个地点，面谈成本太高；二是问题标准化，需要快速摸清分布，比如“有多少人遇到过退款金额对不上”。问卷设计有点反直觉：问题越少回收率越高，问题越开放越没人答。我的习惯是控制在 20 题以内，前 18 题封闭式，最后留 1~2 题开放，同时一定要给“不适用/不清楚”选项。强制二选一的调研问卷，在业务现场很容易收到瞎填的结果。

问卷的坑在回收率，这件事多少有点玄学：不主动跟进时，邮件问卷回收率经常连一半都保证不了，样本还会向“跟你关系好的人”坍缩。所以发放时要按角色分层抽样，每层定目标回收量，发放后按名单催收。即使做到这一步，问卷结果也只能当旁证，不能单独作为设计依据。复杂流程靠问卷是问不明白的，最终还是要补面谈或观察。

3.5 系统原型：用半成品把真实需求“逼”出来

原型是应对“用户自己也不知道自己要什么”的武器。很多用户没看到界面之前给不出具体反馈，递上一版粗界面，哪怕字段名还没定稿，对方也能立刻指出“不对，这里应该先选门店再选供应商”。原型的作用是制造一个可讨论的对象，而不是实现一个可用系统。

事实发现阶段的原型，目的不是验证技术，而是验证业务理解。常见做法是做一个极简页面流，能点几个按钮录一条模拟数据，剩下靠现场口述补全。原型分两种用途：抛弃型和演进型。需求阶段我倾向于抛弃型，做完就扔，因为做得太细会把讨论焦点从业务规则转移到按钮样式上。无论哪种，开场必须声明“这不是最终界面”，否则用户会把原型当验收标准，后续反馈全部集中在外观，而不是功能规则。

3.6 一张选型表：按项目阶段挑技术

选型没有固定答案，我一般按项目状态组合：旧系统改造，先文档审查建基线，再面谈验证规则，最后观察抓差异；全新系统，直接面谈加原型快速对齐；地理分散的系统，问卷加远程面谈，观察只挑一两个典型节点做。组合的原则只有一条：至少两种技术指向同一条规则，才算验证过。

4. 按流程落地事实发现：一张执行清单从准备走到归档

技术清单看得再多，不落到执行流程上都是纸上谈兵。事实发现最怕“现场聊得热闹，事后没有归档”。把流程拆成准备、执行、归档三阶段，每一步都有可复制的动作，这道工序才算真正落地。

4.1 三阶段推进：准备、执行、归档

准备阶段确定事实发现的范围边界。具体动作是：明确要验证的核心问题清单，圈定被访谈对象和材料来源，确定每天访谈上限，避免连续约人导致记录质量下降。执行阶段按技术组合展开，文档审查和面谈可以并行，观察穿插在其中。归档阶段每天都做，不等全部访谈结束再一次性整理。

很多人忽略“停止信号”。我一般以“规则清单是否还有新增”为判断标准：如果连续两轮面谈没有出现新事实，或者新增内容都只是对已记录规则的补充描述，说明事实发现已经饱和，可以进入概念设计。反之，只要每轮都能收到新规则，就说明还没挖干净，不要急着画图。

注意：停止事实发现的信号，是连续两轮没有出现新事实，而不是“大家都说没空谈了”。

4.2 面谈执行清单：一份可直接套用的操作表

下面这份面谈执行清单可以直接抄到自己的笔记工具里，按时间线推进。

提问底稿可以直接从下面这组开始，都是验证过能撬开话题的问法：“请描述一笔 XX 业务从开始到结束经过哪些步骤”，拿流程全貌；“哪个字段最重要，填错了影响最大”，定位核心约束；“有没有绕过系统、线下处理的情况”，找影子操作；“这些数据隔多久会被查一次，谁查，查多久之前的”，定位查询需求和保留策略。记录的原则是原话优先，不要边听边用自己的话改写，否则很容易把“你的理解”当成“对方的事实”。

4.3 从记录到需求清单：把原始事实结构化

原始记录是乱的，不能直接给设计阶段用。当天晚上把记录转成统一的“事实记录卡”，模板如下：

转成事实记录卡之后再做两件事。第一件是汇总去重，把多个人说到的同一条规则合并，保留不同说法作为备注。第二件是按“实体、属性、关系、规则”四个桶做初分，比如把“采购单”“部门负责人”“审核”分别放进实体候选和关系候选。这一步做完，后面的概念模型就可以基于清单来画，而不是靠记忆。

4.4 把典型业务规则翻译成数据库约束

事实发现阶段不需要写完整 SQL，但最好在记录卡上顺手做初步翻译，预判规则的落地层级。下面这个例子很典型。需求清单里有一条规则：“产品单价不能为负，且不能超过设定的最高售价。”

-- 业务规则：产品必须有名称且价格有效 CREATE TABLE product ( product_id CHAR(8) PRIMARY KEY, product_name VARCHAR(60) NOT NULL, unit_price NUMERIC(10,2) NOT NULL, max_price NUMERIC(10,2) NOT NULL, CHECK (unit_price >= 0), CHECK (unit_price <= max_price) );

这里 unit_price 的 NOT NULL 对应“产品必须标价”，两个 CHECK 分别对应“单价非负”和“不超过最高售价”。注意 max_price 本身也是业务字段，它的允许取值范围、由谁维护，同样需要在事实发现阶段确认。约束不是逻辑设计阶段自己拍脑袋定的，而是从发现记录里逐条搬过来的，这个顺序一旦倒过来，表结构就很容易脱离业务。

5. 事实发现避坑清单：5 个高频翻车现场与排解

这一章集中说踩坑。以下五个场景在需求收集过程中反复出现，每一条都按“现象、原因、解决”展开，可以直接当排查手册用。

5.1 面谈成了“新闻招待会”，两小时记不到三条有效需求

现象：对方泛泛而谈，问“有什么需求”就回“系统太慢，表格难用”，两小时下来没有一条可落地的规则。

原因：问题太抽象，没有锚定到具体场景。对方不是不说，而是不知道从哪说起。

解决：把问题从“系统诉求”切换成“业务场景”。比如请对方描述“一张采购单从你手上到归档，中间经过哪些人”，一旦开始描述流程，自然就会带出“金额超过多少要审核”“哪个环节最耗时”等事实。如果对方还在绕，就用封闭式问题逼一个具体数字：“是超过 5000 要审，还是超过 10000？”只要有一个具体数字出现在对话里，面谈就进入实质阶段了。

5.2 只访谈了管理层，一线执行的真实流程全被漏掉

现象：访谈对象全是各层级管理者，拿到的流程描述都很规范，但实际现场跑起来却有一堆额外处理动作，系统上线后才发现对不上。

原因：管理层讲的是“应该怎么做”，一线执行的是“实际怎么做”。两者之间的差，往往是数据模型最容易漏掉的部分。

解决：在每个关键业务岗位至少安排一次观察，没条件观察时，也要保证访谈对象同时覆盖“下指令的人”和“干活的人”。访谈里直接问一句“有没有哪种情况，你的处理方式和上级告诉我的不太一样”，这句话常常能问出真实运作。

5.3 把旧系统文档当真相，忘了文档也会过时

现象：文档审查显示旧系统“订单号全局唯一”，但旧库里实际已有重复数据。按文档设计出的唯一约束，在数据迁移时直接失败。

原因：文档反映的是系统设计时的规则，不代表运营多年后的真实数据状态。系统跑得越久，文档和现状的偏离越严重。

解决：从文档里提取的关键规则，必须做抽样核对。方法很简单，任取最近三个月的数据，看有没有违反该规则的记录。抽查结果在规则清单里标注“已验证”或“未验证”，未验证项带进面谈确认。这条经验尤其适用于唯一性、非空、状态转换这类最终会变成约束的事实。

5.4 问卷回收率过低，样本坍缩成“熟人圈”

现象：问卷发出 200 份，回收 42 份，其中 30 份来自同一个部门。统计结果看起来有规律，但根本代表不了总体。

原因：群发后没有跟进，回收动力不足；样本分布没有按角色分开统计。问卷设计得过深，也容易让用户中途放弃。

解决：发放前按角色分层抽样，给每层定目标回收量；发放后按名单催收，优先把缺口补到目标线上。催收仍不理想时，宁可放弃问卷结果也不强行引用，把它降级为参考材料。更稳妥的定位是把问卷当“验证工具”而不是“发现工具”：先用面谈总结出规则，再用问卷验证这些规则在更大范围的成立比例，这样即使回收率有波动，对设计结论的影响也可控。

5.5 观察时用户“表演式操作”，看到的不是真实流程

现象：观察现场时用户操作非常规范，离开现场又恢复原来那些线下处理习惯，导致观察记录与后续实际运行完全对不上。

原因：用户知道有人在观察，会下意识展示标准操作；或者担心记录变成考核依据，隐藏掉自行处理的部分。

解决：开场说明观察目的是优化流程而不是考核个人绩效；连续观察多日，每天选不同时段，尤其要覆盖月末、月初这类业务高峰，高峰时段更容易看到真实处理方式；每次观察结束后补一句“刚才如果我旁边没人，这一步你会怎么处置”。观察结果必须和面谈记录交叉验证，凡是只有观察记录而没有被访者确认的规则，一律标成“待验证”。

6. 进阶技巧：让发现成果直接长出数据模型草图

6.1 从发现记录直接推概念模型

事实发现做完，最常见的困惑是“下一步从哪开始”。我习惯在事实记录卡上直接做标记：频繁出现的名词，如客户、订单、产品、仓库，圈成候选实体；出现“的”字结构的名词短语，如“订单编号”“客户名称”，圈成候选属性；记录里的动作动词，如审核、发货、退回，圈成候选关系。这样标记完，ER 草图的骨架就已经出来了。

举一个通用例子。记录里有一句话“订单审核通过后自动锁定库存并生成发货单”。从这句话可以同时推出：实体“订单、库存、发货单”，关系“审核、锁定、生成”，以及一条约束“审核通过后触发状态联动”。把这些结果填回记录卡，概念设计阶段要做的就不是凭空画图，而是对已收集事实做结构化整理，效率和准确性都会高很多。

6.2 用“规则翻译卡”让需求和表结构对齐

最后一个我比较坚持的习惯，是给每条关键规则建一张“规则翻译卡”，把原话、规则类型、约束层级预判三栏写到一起。面谈当天晚上就完成，不拖到第二天。翻译卡积累到 20 张左右，概念模型的数据字典初稿基本就同步出来了。逻辑设计阶段写约束时，按翻译卡逐条核对，漏约束的概率会明显下降。

我自己的习惯是，每轮事实发现结束，至少留半天时间做翻译整理，把当天所有记录卡翻一遍，标出互相矛盾的、近似重复的、完全相反的表述。这两类表述，就是下一轮面谈最有价值的问题。越到项目后期越会体会到，发现阶段多花一天把例外问清楚，建模阶段就能少改三轮。希望帮到你。

本文还有配套的精品资源，点击获取