数据库课程设计避坑指南：五种事实发现技术拆解与StayHome案例实战

简介这份数据库课件面向高校数据库课程学习者与系统开发入门者聚焦数据库系统开发生命周期中的事实发现Fact-Finding环节帮助读者理解如何在规划、系统定义、需求收集与分析等早期阶段有效获取业务需求。课件系统梳理了各开发阶段需捕获的数据类型与对应文档如任务描述、用户需求说明书、ER模型、数据字典及物理设计等并重点讲解检查文档、面谈、观察业务运转、研究和问卷调查五种事实发现技术的特点、适用场景与优缺点。同时以StayHome录像出租公司为案例串联员工注册表、录像清单、会员注册表与租借表等实际业务场景展示技术落地方式。资源包为1个ppt文件约570KB结构紧凑、重点突出适合课堂讲授或自学复习。目前已有109人学习可作为数据库课程配套讲义与需求分析方法的速查参考。1. 事实发现一份被低估的数据库课件为什么值得你花两小时拆完很多人做数据库课程设计第一步就翻车——不是 SQL 写不出来而是根本不知道用户到底要什么。需求靠脑补ER 图画完被导师一句“这个业务场景你调研过吗”打回重做。这份《chap06事实发现.ppt》解决的正是这个前置问题它把数据库系统开发生命周期早期最关键的“信息采集”环节拆成了可操作的技术清单。课件覆盖五种事实发现技术——检查文档、面谈、观察业务运转、研究、问卷调查并配了 StayHome 录像出租公司的完整案例。适合正在做数据库课程设计、需求分析作业或者刚入行需要补需求调研基本功的从业者。它不是 SQL 教程而是教你在动手建表之前怎么把业务摸清楚。2. 五种事实发现技术从文档到问卷每种技术的适用边界在哪2.1 检查文档最低成本的信息入口课件把“检查文档”排在五种技术的第一位逻辑很直接——这是唯一不需要跟人打交道、不需要协调时间、不需要预约就能启动的调研方式。文档分三类描述问题和需求的内部备忘录、邮件、会议记录、问题描述文档、描述受影响业务的组织架构图、任务陈述、业务目标、手工表单和报表样例、描述当前业务数据流的DFD、数据字典、程序文档、用户培训手册。实操中我一般按这个顺序翻先看组织架构图搞清楚谁是谁再看现有表单和报表理解数据长什么样最后翻问题记录和效率回顾报告定位痛点。这个顺序的好处是你带着上下文去看问题记录比一上来就翻 bug 列表效率高得多。注意文档的时效性是个大坑。课件里没强调但实际项目中你拿到的可能是三年前的流程图业务早就变了。翻到任何文档都要问一句“这份东西最后一次更新是什么时候”。2.2 面谈最有用也最容易搞砸课件明确写了“面谈是最常用的通常也是最有用的事实发现技术”。但它同时点出一个关键前提需要良好的交流能力能够和不同价值观、不同喜好、观点、动机和个性的人打交道。这句话翻译成实操语言就是——面谈翻车的概率远高于你的预期。面谈分两种类型无组织面谈和有组织面谈。无组织面谈只有一个通用目标问题很少课件直接给了负面评价——“不能抓住问题的焦点不利于数据库分析和设计”。有组织面谈则要求谈话人准备特定问题。问题模式也分两种开放式和限制式。开放式让受访者自由发挥比如“为什么你对会员注册表不满意”限制式要求短回答或特定选择比如“会员注册表的信息是否精确”。我的经验是第一轮面谈用开放式摸清全貌第二轮用限制式确认细节。反过来做第一轮就把人问死了后面拿不到新信息。2.3 观察业务运转看到的是真实流程不是理想流程课件对这项技术的描述很克制——“最有效的事实发现技术之一”能观察业务运转模式和高峰期状态。但没展开的是观察最大的价值在于发现“说的”和“做的”之间的差距。面谈时用户告诉你“我们每天下班前统一录入”你蹲点一看实际是随时来随时录因为不录下一个人没法查库存。观察的时机选择很关键。课件提到“了解业务高峰期的运转状态”这是对的。高峰期暴露的是系统瓶颈和变通做法平峰期看到的是理想流程。两个时段都要看对比才有信息量。2.4 研究与问卷一个向外看一个向内收研究是向外看——计算机行业杂志、参考书、互联网看别人怎么解决同类问题有没有现成的软件包。这项技术容易被忽略因为大家习惯直接问用户。但用户往往只知道自己的痛点不知道行业里已经有什么成熟方案。先研究再面谈你问的问题质量会高一个档次。问卷调查是向内收——用特定目的的小册子集中一大群人的意见。课件分了自由形式和固定形式。自由形式给答卷人更大自由度比如“你当前收到的是什么报表它们有什么用”固定形式答案是特定的比如“现在的录像出租报告的形式非常理想不必改动”选是或否。问卷的适用场景很明确当你需要从大量用户那里收集标准化信息时。如果用户只有三五个面谈比问卷高效得多。问卷的设计成本高回收质量不可控别为了用而用。3. 把事实发现嵌进开发生命周期每个阶段该收什么、该产出什么3.1 六个阶段的采集清单与文档产出课件用一张表把开发阶段、捕获数据、产生文档三者的对应关系列得很清楚。这张表是整份课件里最值得反复看的部分因为它把“什么时候该干什么”变成了可核对的清单。开发阶段捕获的数据示例产生的文档示例数据库规划数据库工程的目标和目的任务描述和数据库系统的目的系统定义主要用户视图描述工作角色/业务应用领域数据库系统的边界和范围定义、所支持的用户视图需求收集和分析用户视图的要求、系统说明含性能和安全要求用户和系统的需求说明书数据库设计用户对逻辑设计的反馈、目标 DBMS 提供的功能逻辑数据库设计ER 模型、数据字典、表、物理数据库设计应用程序设计用户对界面设计的反馈应用程序设计程序和界面的描述DBMS 选择目标 DBMS 提供的功能DBMS 评估和推荐构建原型用户对原型的反映修改了的用户需求和系统说明书实现目标 DBMS 提供的功能、当前数据格式、目标 DBMS 导入能力数据转换和加载测试测试结果测试方法、测试结果分析操作维护性能测试结果、新的或变更的用户和系统需求用户手册、性能结果分析、修改的用户需求与系统说明书这张表的使用方法每进入一个新阶段先看“捕获的数据”这一列确认你手头有没有这些信息再看“产生的文档”这一列确认上一阶段的产出有没有交付。缺哪补哪别跳步。3.2 StayHome 案例一个完整的业务建模样本课件用 StayHome 录像出租公司贯穿始终这家公司 1982 年成立于西雅图有 100 个部门、2000 名员工。案例给出了五类核心业务实体员工注册表、员工列表、可出租录像清单、会员注册表、会员清单、录像租借表。几个关键业务规则值得注意每个分公司有一名经理和数名主管经理负责日常事务主管监督员工每盘录像用分类编号唯一标识同一盘录像有多份拷贝每份拷贝用录像编号区分顾客可以在不同分公司分别注册每次注册都要填表会员一次最多借 10 盘录像。这些规则直接决定了数据库设计的约束条件。比如“同一盘录像多份拷贝”意味着视频实体和拷贝实体要分开建表“不同分公司分别注册”意味着会员和分公司之间是多对多关系且注册行为本身可能是一个独立实体。如果你做课程设计时拿到的是类似租赁场景这套实体划分可以直接参考。3.3 从事实到 ER 图一个可复现的转换流程课件没有给 ER 图但给了足够的事实素材。我按标准流程把它转一遍你可以跟着走第一步从“员工注册表”和“员工列表”提取实体员工、分公司、职位。员工属于分公司员工有职位。第二步从“可出租录像清单”提取实体录像分类编号、拷贝录像编号。录像和拷贝是一对多。第三步从“会员注册表”和“会员清单”提取实体会员、注册记录。会员和分公司通过注册记录关联。第四步从“录像租借表”提取实体租借记录。租借记录关联会员和拷贝记录租借时间和归还时间。-- 基于 StayHome 案例的核心表结构示意 -- 分公司表每个分公司有经理 CREATE TABLE branch ( branch_id INT PRIMARY KEY, branch_name VARCHAR(100) NOT NULL, manager_id INT, -- 外键指向员工表 address VARCHAR(200) ); -- 员工表经理和主管都是员工 CREATE TABLE employee ( emp_id INT PRIMARY KEY, emp_name VARCHAR(50) NOT NULL, position VARCHAR(30), -- 经理/主管/普通员工 branch_id INT REFERENCES branch(branch_id) ); -- 录像表分类编号唯一标识一部影片 CREATE TABLE video ( catalog_no VARCHAR(20) PRIMARY KEY, title VARCHAR(200) NOT NULL, category VARCHAR(50) ); -- 拷贝表同一部影片的多份拷贝录像编号区分 CREATE TABLE copy ( video_no INT PRIMARY KEY, catalog_no VARCHAR(20) REFERENCES video(catalog_no), status VARCHAR(20) DEFAULT available -- available/rented/lost ); -- 会员表可在不同分公司注册 CREATE TABLE member ( member_id INT PRIMARY KEY, member_name VARCHAR(50) NOT NULL, phone VARCHAR(20) ); -- 注册记录会员在某个分公司注册 CREATE TABLE registration ( reg_id INT PRIMARY KEY, member_id INT REFERENCES member(member_id), branch_id INT REFERENCES branch(branch_id), reg_date DATE NOT NULL ); -- 租借记录一次最多借 10 盘需要业务层校验 CREATE TABLE rental ( rental_id INT PRIMARY KEY, member_id INT REFERENCES member(member_id), video_no INT REFERENCES copy(video_no), rent_date DATE NOT NULL, due_date DATE NOT NULL, return_date DATE );这段 DDL 的逻辑说明分公司和员工之间是一对多员工表通过 branch_id 归属分公司branch 表的 manager_id 反向指向员工形成互相引用的关系实际建表时需要先建 branch 再建 employee或者用 ALTER TABLE 补外键。录像和拷贝拆成两张表是因为课件明确说了“同一盘录像有多份拷贝”不拆的话无法追踪每份拷贝的租借状态。注册记录独立成表是因为“一个顾客可以在不同分公司分别注册”注册行为本身有日期属性不是简单的多对多映射。租借记录关联的是拷贝而非录像因为租出去的是具体那一盘带子。参数说明status 字段用 available/rented/lost 三态比布尔值更贴近实际录像带会丢。due_date 在插入时由业务逻辑计算常见做法是 rent_date 加 7 天但课件没给租期这里留作可配置项。一次最多借 10 盘的限制在数据库层用触发器或应用层校验都可以我一般放应用层因为错误提示更友好。4. 避坑与排查事实发现阶段最容易翻车的五个地方4.1 只做面谈不做观察需求文档和实际流程两张皮现象需求说明书里写“会员到店后由前台查询库存并办理租借”开发出来的系统也是这个流程。上线后店员抱怨“根本没法用”因为实际高峰期前台同时接三四个会员根本来不及查库存都是先拿带子后补录。原因面谈时用户描述的是“应该怎么做”不是“实际怎么做”。人在被问流程时会下意识按理想流程回答。解决面谈之后必须安排至少一次现场观察重点看高峰期。观察时记录三个东西实际操作顺序、等待时间、变通做法比如纸条记会员号。这三样东西才是需求文档该写的。4.2 问卷设计成“确认题”拿回来的全是无效数据现象问卷发出去 50 份回收 48 份但 90% 的答案都是“满意”“没意见”“挺好的”。分析不出任何有效需求。原因问卷题目全是限制式且默认现状合理。比如“现在的录像出租报告的形式非常理想不必改动”这种题只能拿到“是”拿不到改进方向。解决限制式题目用来确认已知事实开放式题目用来发现未知需求。一份问卷里开放式题目至少占三分之一。另外问卷前面加一道“你日常工作中最花时间的三个操作是什么”这种题能逼出真实痛点。4.3 面谈对象选错拿到的需求只代表一个部门现象只面谈了分公司经理需求文档写出来全是管理视角的报表和审批流。系统上线后一线员工抵触因为他们的操作负担反而增加了。原因课件里写了“必须选择合适的谈话人选”但没展开。经理关注的是汇总和管控一线员工关注的是操作效率和少填表。只问一方需求必然偏。解决每个用户角色至少面谈一个人。StayHome 案例里至少有经理、主管、前台店员三种角色对应的需求完全不同。面谈前先画一张角色-职责矩阵确保每个角色都被覆盖。4.4 文档检查跳过数据字典后期字段对不上现象开发到一半发现“会员编号”在旧系统里是 8 位数字新系统设计成了自增整数历史数据导不进去。返工改表结构连带改了一堆关联代码。原因检查文档时只看了业务描述和流程图没翻数据字典和现有表结构。课件的文档分类里明确列了“数据字典”和“数据库应用程序设计”这两样是字段级信息的来源。解决检查文档阶段强制自己输出一份现有字段清单包括字段名、类型、长度、约束、示例值。新系统设计时逐字段对照能复用的复用要改的提前标记迁移方案。4.5 研究环节跳过重复造轮子现象花了三周设计了一套录像租赁的库存管理逻辑后来发现开源社区有现成的租赁管理模块功能覆盖了 80% 的需求。原因直接进入面谈和设计没有先做行业研究。课件把“研究”列为五种技术之一但实际项目里最容易被跳过因为它不直接产出需求条目。解决在面谈之前花半天时间做研究。搜索关键词用“业务领域 开源 数据库设计”比如“video rental database schema”。看别人的表结构、看有没有现成的 ER 图、看行业标准。研究产出不用多一页纸的“别人怎么做的”就够了但这一页纸能帮你省掉大量试错。5. 从课件到实战把事实发现技术用进你的下一个课程设计课件最后一页停在 StayHome 案例的租借表没有给完整的 ER 图和建表脚本。这恰恰是它作为教学材料最实用的地方——它给了你事实素材但把建模的活留给你自己干。我建议你拿到这份课件后按这个顺序走一遍先通读第 3 页到第 13 页的技术分类把五种技术的定义和适用场景过一遍然后精读第 14 页到第 20 页的 StayHome 案例把每个业务规则用一句话写下来最后合上课件自己画 ER 图、写建表语句再打开课件对照看有没有漏掉约束。一个具体的验证方法把你画的 ER 图拿给一个没看过课件的人让他根据你的图回答三个问题——会员能不能在两家分公司同时注册同一部影片的两份拷贝能不能分别租给两个人一个会员一次最多能借几盘如果他能不看文档直接答出来说明你的模型把业务规则表达清楚了。如果答不出来回去补约束。我自己的习惯是每做完一个课程设计把需求调研阶段的原始记录面谈笔记、问卷、观察记录和最终的表结构放在一起存档。过一学期再看能清楚看到哪条需求来自哪次调研哪张表对应哪个业务规则。这个习惯帮我避开了很多“拍脑袋设计”的坑。从那以后我每次做数据库设计都强制走一遍“文档→面谈→观察→研究→问卷”的完整流程哪怕只花半天也比直接开干强。希望帮到你。本文还有配套的精品资源点击获取