简介面向数据库系统开发与设计课程的事实发现Fact-FindingPPT课件适合数据库原理、系统分析与设计教学及自学场景。资源包内仅含一个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 个工作日加上整理归档完整走下来大概一到两周。这个时间投入看起来很贵但相比设计阶段反复返工的消耗通常很划算。下面这张阶段对应表是很多数据库课程在讲生命周期时常用的对照关系阶段主要输入核心产出初始研究组织目标、现状问题、旧系统资料问题定义、范围边界事实发现访谈记录、文档、观察记录、问卷结果需求清单、业务规则、候选实体概念设计需求清单、业务规则概念模型ERD、数据字典初稿逻辑设计概念模型关系模式、约束定义物理实现关系模式表结构、索引、存储参数初学者最容易把“事实发现”和“需求分析”当成完全不同的两件事。数据库语境里事实发现就是一种系统化的需求收集方法它把软件工程里常见的面谈、调研、观察等手段固定成了一套可复用的流程。叫“事实发现”重点落在“事实”两个字上要的是直接证据不是二手转述不是“我猜应该是这样”。这一差别到了避坑章还会反复出现。3. 五大事实发现技术怎么选成本、覆盖面与产出对比这一章要把手上能用的工具盘一遍。文档审查、面谈、观察、问卷、系统原型五种技术各有适用场景也各有硬伤。没有哪个是万能选项真正的功夫在组合。3.1 文档审查动手之前最值得先做的存量采集文档审查就是把能找到的业务资料收集起来过一遍现有单据、报表、操作手册、流程文件以及旧系统数据库的表结构和字段注释。别小看这一步它的成本在五项技术里最低却能最快帮你建立业务对象的全貌。很多面谈翻车就是因为进场之前连对方讲的“订单”指的是哪张单都不知道。操作上按三个动作走。第一步建文档清单把文档按核心程度排序从最核心的报表和数据表结构开始读。第二步逐份提取对每份文档问三句话“这里面有哪些数据项”“谁产出它”“它最终流向哪里”。数据项记下来角色也记下来角色后面会变成权限设计的依据。第三步标注待验证项。文档里凡是出现“原则上”“一般”“特殊情况下”这类措辞的地方全部标成待验证。这些语句就是业务约束和例外的线索。文档审查的产出是“数据项清单”和“规则线索表”。它的局限也很明显文档只代表纸面规则可能过时。所以文档只能当起点不能当终点所有从文档里挖出来的规则必须拿到面谈或观察里去验证。注意文档里“原则上不允许”这类句子几乎一定对应一条约束或一个例外分支别在标注时放过它。3.2 面谈信息密度最高但最容易被带偏面谈是事实发现的核心手段信息密度最高但也最容易翻车。翻车的原因基本只有一个把面谈当成了聊天。有经验的开发者一般会用半结构化方式准备一份问题提纲但不按顺序死问而是顺着对方描述的业务场景自然追问。关键在问法。不要问“你们有什么需求”这句话太抽象对方往往回一句“系统太慢、表格难用”就冷场。要问“你每天上班后处理一笔订单的第一步是什么扫单号还是先看邮箱”对方顺着操作场景走需求自然就带出来了。追问也有套路每听到一个操作至少追问三次“然后呢”“为什么”“有没有例外”。比如用户说“发货单号是仓库填的”你要追问“所有单子都由仓库填吗填错了谁改走什么流程改之前的数据留痕吗”这些追问得到的回答几乎每一条都能对应到一个外键、一条状态约束或一条日志需求。执行上还有几个约定俗成的细节双人配合一人主导提问一人专门记录主导的人不要低头记录音前必须征得对方同意不同意就不录改为结束后当场复述确认结束后 30 分钟内完成整理超过 24 小时再整理细节会明显失真。提示面谈录音前一定先征得对方同意。没有录音的情况下结束前 5 分钟复述关键结论并请对方纠正是最后一道保险。3.3 观察与跟班还原真实工作流的关键手段面谈和文档能告诉你“应该怎么跑”但用户实际走的路线可能完全不一样。真实业务里常有线下 Excel 台账、口头传递、手工改单之类的“影子操作”这些是面谈问不出来的对方未必刻意隐瞒只是早已习以为常。观察就是用来抓这类事实的手段。观察分参与式和非参与式数据库需求阶段我多数用非参与式在不影响对方工作的前提下安静观察一个完整业务流程跑完。观察不是傻看重点记录三样东西。第一操作顺序用户先开哪个页面、再点哪个按钮、最后填哪张表。第二系统外处理用户会不会先在手边 Excel 里记一笔再录系统这就是潜在的数据不一致来源。第三异常路径某一步校验不通过时用户是按流程退回重走还是手工改库。观察的代价是耗时一个岗位往往要看 3~5 个工作日才能覆盖到不同业务形态尤其是月初、月末和结算日。但用观察换来的规则真实性是面谈和文档很难替代的。3.4 问卷大范围覆盖用户但回收是硬伤问卷适合两种场景一是用户群体分散在多个地点面谈成本太高二是问题标准化需要快速摸清分布比如“有多少人遇到过退款金额对不上”。问卷设计有点反直觉问题越少回收率越高问题越开放越没人答。我的习惯是控制在 20 题以内前 18 题封闭式最后留 1~2 题开放同时一定要给“不适用/不清楚”选项。强制二选一的调研问卷在业务现场很容易收到瞎填的结果。问卷的坑在回收率这件事多少有点玄学不主动跟进时邮件问卷回收率经常连一半都保证不了样本还会向“跟你关系好的人”坍缩。所以发放时要按角色分层抽样每层定目标回收量发放后按名单催收。即使做到这一步问卷结果也只能当旁证不能单独作为设计依据。复杂流程靠问卷是问不明白的最终还是要补面谈或观察。3.5 系统原型用半成品把真实需求“逼”出来原型是应对“用户自己也不知道自己要什么”的武器。很多用户没看到界面之前给不出具体反馈递上一版粗界面哪怕字段名还没定稿对方也能立刻指出“不对这里应该先选门店再选供应商”。原型的作用是制造一个可讨论的对象而不是实现一个可用系统。事实发现阶段的原型目的不是验证技术而是验证业务理解。常见做法是做一个极简页面流能点几个按钮录一条模拟数据剩下靠现场口述补全。原型分两种用途抛弃型和演进型。需求阶段我倾向于抛弃型做完就扔因为做得太细会把讨论焦点从业务规则转移到按钮样式上。无论哪种开场必须声明“这不是最终界面”否则用户会把原型当验收标准后续反馈全部集中在外观而不是功能规则。3.6 一张选型表按项目阶段挑技术技术典型成本耗时覆盖人数产出物适合场景文档审查低1~3 天不限数据项清单、规则线索所有项目的第一动作面谈中高每天 2~4 场管理层加核心用户访谈记录、规则确认最核心的信息来源观察中3~5 个工作日关键岗位操作流程记录、异常清单流程复杂、影子操作多问卷低中约 1 周大范围用户统计结果跨地域、标准化问题系统原型高迭代 2~3 轮参与确认者原型确认记录需求模糊、全新系统选型没有固定答案我一般按项目状态组合旧系统改造先文档审查建基线再面谈验证规则最后观察抓差异全新系统直接面谈加原型快速对齐地理分散的系统问卷加远程面谈观察只挑一两个典型节点做。组合的原则只有一条至少两种技术指向同一条规则才算验证过。4. 按流程落地事实发现一张执行清单从准备走到归档技术清单看得再多不落到执行流程上都是纸上谈兵。事实发现最怕“现场聊得热闹事后没有归档”。把流程拆成准备、执行、归档三阶段每一步都有可复制的动作这道工序才算真正落地。4.1 三阶段推进准备、执行、归档准备阶段确定事实发现的范围边界。具体动作是明确要验证的核心问题清单圈定被访谈对象和材料来源确定每天访谈上限避免连续约人导致记录质量下降。执行阶段按技术组合展开文档审查和面谈可以并行观察穿插在其中。归档阶段每天都做不等全部访谈结束再一次性整理。很多人忽略“停止信号”。我一般以“规则清单是否还有新增”为判断标准如果连续两轮面谈没有出现新事实或者新增内容都只是对已记录规则的补充描述说明事实发现已经饱和可以进入概念设计。反之只要每轮都能收到新规则就说明还没挖干净不要急着画图。注意停止事实发现的信号是连续两轮没有出现新事实而不是“大家都说没空谈了”。4.2 面谈执行清单一份可直接套用的操作表下面这份面谈执行清单可以直接抄到自己的笔记工具里按时间线推进。时间点动作说明提前 3 天发访谈提纲不要只发主题要写“请准备一张你们最近用过的 XX 单据”这类具体任务开场 5 分钟说明目的和保密说清数据用途和时长消除顾虑主体提问先场景后细节让用户按业务顺序叙述中途不打断例外追问对关键环节追问例外问“什么时候会不走这一步”结束前 5 分钟复述确认把最重要的 3 条事实复述一遍请对方指正结束后 30 分钟整理归档用统一模板记录标注来源角色和待验证项提问底稿可以直接从下面这组开始都是验证过能撬开话题的问法“请描述一笔 XX 业务从开始到结束经过哪些步骤”拿流程全貌“哪个字段最重要填错了影响最大”定位核心约束“有没有绕过系统、线下处理的情况”找影子操作“这些数据隔多久会被查一次谁查查多久之前的”定位查询需求和保留策略。记录的原则是原话优先不要边听边用自己的话改写否则很容易把“你的理解”当成“对方的事实”。4.3 从记录到需求清单把原始事实结构化原始记录是乱的不能直接给设计阶段用。当天晚上把记录转成统一的“事实记录卡”模板如下字段内容示例编号F-012来源采购部门面谈日期、角色原话/事实“采购单金额超过 5000 要部门负责人二审”类型处理流程加约束落地预判订单状态增加“待二审”金额字段加阈值规则待验证是否涉及含税金额口径转成事实记录卡之后再做两件事。第一件是汇总去重把多个人说到的同一条规则合并保留不同说法作为备注。第二件是按“实体、属性、关系、规则”四个桶做初分比如把“采购单”“部门负责人”“审核”分别放进实体候选和关系候选。这一步做完后面的概念模型就可以基于清单来画而不是靠记忆。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 张左右概念模型的数据字典初稿基本就同步出来了。逻辑设计阶段写约束时按翻译卡逐条核对漏约束的概率会明显下降。我自己的习惯是每轮事实发现结束至少留半天时间做翻译整理把当天所有记录卡翻一遍标出互相矛盾的、近似重复的、完全相反的表述。这两类表述就是下一轮面谈最有价值的问题。越到项目后期越会体会到发现阶段多花一天把例外问清楚建模阶段就能少改三轮。希望帮到你。本文还有配套的精品资源点击获取