企业官网建设流程全解析

简介：这份数据库课件面向高校数据库课程学习者与系统开发入门者，聚焦数据库系统开发生命周期中的事实发现（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 六个阶段的采集清单与文档产出

课件用一张表把开发阶段、捕获数据、产生文档三者的对应关系列得很清楚。这张表是整份课件里最值得反复看的部分，因为它把“什么时候该干什么”变成了可核对的清单。

这张表的使用方法：每进入一个新阶段，先看“捕获的数据”这一列，确认你手头有没有这些信息；再看“产生的文档”这一列，确认上一阶段的产出有没有交付。缺哪补哪，别跳步。

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 图拿给一个没看过课件的人，让他根据你的图回答三个问题——会员能不能在两家分公司同时注册？同一部影片的两份拷贝能不能分别租给两个人？一个会员一次最多能借几盘？如果他能不看文档直接答出来，说明你的模型把业务规则表达清楚了。如果答不出来，回去补约束。

我自己的习惯是，每做完一个课程设计，把需求调研阶段的原始记录（面谈笔记、问卷、观察记录）和最终的表结构放在一起存档。过一学期再看，能清楚看到哪条需求来自哪次调研，哪张表对应哪个业务规则。这个习惯帮我避开了很多“拍脑袋设计”的坑。从那以后我每次做数据库设计，都强制走一遍“文档→面谈→观察→研究→问卷”的完整流程，哪怕只花半天，也比直接开干强。希望帮到你。

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