第一章：OA系统概述与需求分析
各位同学好，我是你们这门课的老朋友。今天咱们聊聊OA系统最基础、也最关键的一步——搞清楚它到底是什么，以及怎么把需求理清楚。
说实话，我见过太多项目翻车，不是因为技术不行，而是从一开始就没搞明白「我们要做什么」。所以这一章，咱们把地基打牢。
1.1 什么是OA系统？
OA，全称是Office Automation，办公自动化。说白了，就是把公司里那些纸质流程、人工跑腿的事儿，搬到电脑和手机上。
你想想看，一个员工请假，以前要填纸质单子、找经理签字、找HR备案、再找财务算考勤……一圈下来半天没了。OA系统就是让这些事在线上完成，点几下鼠标，审批流自动跑完。
我个人习惯把OA系统比作「企业的神经系统」。它不直接生产产品，但让所有部门协同起来。没有它，企业就像一个人手脚不协调，效率低得吓人。
核心价值：OA系统解决的是「信息流转」和「流程自动化」的问题。它不是ERP，不搞进销存；也不是CRM，不搞客户管理。它的主场是内部办公流程。
1.2 核心业务模块
一个完整的OA系统，通常包含四大核心模块。我在项目中遇到过不少客户，上来就说「我要全套OA」，结果连自己需要什么都说不清楚。所以咱们先拆开看：
1. 审批模块
这是OA系统的灵魂。请假、报销、采购、合同……所有需要「走流程」的事，都归它管。
- 流程定义：谁发起、谁审批、抄送谁
- 条件分支：金额超过5000要总经理批，低于5000部门经理批
- 会签与或签：需要所有人同意，还是一个人同意就行
嗯，这里要注意：审批流的设计，直接决定了数据库里「流程实例表」和「审批节点表」的复杂度。我见过一个项目，因为没考虑会签，后期改表结构改到崩溃。
2. 考勤模块
打卡、请假、加班、出差……这些数据最终要汇总成考勤报表，跟工资挂钩。
- 打卡记录：上班卡、下班卡、外勤卡
- 请假类型：年假、事假、病假、婚假……每种假期的计算规则不同
- 加班规则：工作日加班1.5倍，周末2倍，节假日3倍
我曾经踩过一个坑：考勤数据量特别大，每天几万条打卡记录。如果表结构设计不合理，月底跑报表时数据库直接卡死。后来我用了分区表，按月分区，才解决问题。
3. 人事模块
员工从入职到离职的全生命周期管理。
- 员工档案：基本信息、合同、学历、证书
- 组织架构：部门、岗位、汇报关系
- 异动管理：转正、调岗、晋升、离职
这里有个容易忽略的点：组织架构是树形结构，数据库里怎么存？我建议用「闭包表」或者「路径枚举」，别用递归查询，性能太差。
4. 行政模块
会议室预订、办公用品申领、车辆管理、固定资产……这些杂事，其实最考验系统设计的灵活性。
- 资源管理：会议室、车辆、设备的状态管理
- 申领流程：办公用品、耗材的申请与发放
- 费用分摊：行政费用按部门分摊
1.3 需求调研方法论
做OA系统，最怕的就是「闭门造车」。你想想看，你坐在办公室里想出来的流程，跟实际业务跑的可能完全两码事。
我个人的调研方法，总结下来就三步：
- 看：去现场看员工怎么干活。比如审批，是纸质单子还是邮件？谁先签谁后签？
- 问：找关键用户聊。别只找领导，要找真正干活的人。我曾经问一个前台「你每天处理多少份快递单」，她说「大概50份，但高峰期有100份」。这个数据直接影响了快递模块的并发设计。
- 验：画原型给用户看。别光说，要让他们点一点。很多时候用户说「就这样」，看到原型才说「不对，这里应该是那样」。
避坑指南：我曾经遇到一个客户，需求文档写了80页，结果上线第一天就发现核心流程错了。为什么？因为写文档的人没去现场看，完全凭想象。所以，一定要「眼见为实」。
1.4 数据流图与业务建模
需求调研完了，怎么把这些零散的信息变成数据库表结构？这里就要用到数据流图和业务建模。
数据流图（DFD）
说白了，就是画清楚「数据从哪里来，到哪里去」。比如请假流程：
- 外部实体：员工、审批人、HR
- 数据流：请假申请→审批通知→考勤更新
- 数据存储：请假单表、审批记录表、考勤汇总表
画数据流图有个好处：你能一眼看出哪些数据是「输入」，哪些是「输出」，哪些需要「持久化」。这直接决定了数据库里要建哪些表。
业务建模
业务建模就是把业务流程抽象成「实体」和「关系」。比如：
- 实体：员工、部门、请假单、审批节点
- 关系：一个员工属于一个部门，一个请假单有多个审批节点
我习惯用ER图（实体关系图）来做这件事。画完ER图，表结构基本就出来了。比如请假单表：
CREATE TABLE leave_request (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
employee_id BIGINT NOT NULL,
leave_type VARCHAR(20) NOT NULL, -- 年假、事假、病假
start_date DATE NOT NULL,
end_date DATE NOT NULL,
reason TEXT,
status VARCHAR(20) DEFAULT 'pending', -- pending, approved, rejected
created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);你看，这个表结构就是从业务模型直接映射过来的。员工ID关联员工表，请假类型用枚举，状态字段记录审批进度。
注意：业务建模时，最容易犯的错误是「过度设计」。比如请假单，有人非要加上「审批级别」「加签人」「抄送人」等字段。其实这些应该放在审批流程表里，而不是塞进请假单表。保持每个表的职责单一，后期维护才轻松。
本章小结
这一章我们聊了OA系统的定义、四大核心模块、需求调研的方法，以及怎么用数据流图和业务建模来指导数据库设计。
说白了，数据库设计不是凭空想出来的，而是从业务需求里「长」出来的。你调研得越细，模型画得越准，后面的建表工作就越顺利。
下一章，咱们就正式进入数据库设计实战，从「用户与组织架构」开始。到时候我会拿一个真实项目里的表结构出来，咱们一起拆解。
好，今天就到这儿。有问题随时交流。