当前位置：首页 > news >正文

数据库设计_理论部分_需求分析

news 2025/10/13 9:03:33

前言

理解数据库设计中的"需求分析",他的重要性,如何实现,和其中的关键点

参考书:"<数据库原理及应用>(MySQL版) 第二版"

概述

在企业信息化过程中,需求分析是第一步,也是最重要的一步.这一阶段是系统分析员和用户双方共同收集数据库所需的信息内容和用户对处理的需求,并以需求说明书的形式确定下来,作为以后系统开发的指南和系统验证的依据.

举一个例子,在学生基本情况表中,少了"性别"这一属性.如果有另一张以"性别"为依据的表,则做不出来.如果此时已经将学生的元组填入学生基本情况表,那么如何补救呢?重新做一新张,并且把原来表的数据取出来传入新表,如果学生的个数很多,那么工作量可能是巨大的,费时费力.这是需求分析没做到位产生的失误.

需求分析的参与

需求分析的问题在于,用户提出"我想要什么",但不知道计算机怎样工作来满足他的需求.程序员表示"我能做",而不知道做的内容是什么.在"要什么"和"做什么"之间存在矛盾.

尽管本书一直强调需求分析要认真细致,似乎认为此项工作的大部分应该由程序提供方完成.笔者的眼中,需求分析主要由用户提供,系统分析员做辅助.因为参考书本来是站在程序员的角度理解需求,所以这样做也无可厚非.

举个例子:用户是在餐厅吃饭的顾客,系统分析员相当于餐厅店小二,两者通过菜单交流.而菜单就相当于需求分析这一阶段的结果:需求说明书.菜单和需求说明书不完全等同.菜单是餐厅现成的,顾客不能更改.而需求说明书需要双方确认细节.

如果客户提出,"照着这个做,大概就行了"这样的话语,多半是不行的,因为需求是模糊的.就像餐厅顾客点了一道鱼香肉丝,原本这道菜要放醋和白糖.结果菜上来后顾客发现少了味道,一问才知道本店的这道菜不放白糖,怕顾客吃了升血糖.所以需求一定要准确,否则做出来的东西不是想要的.

需求分析的内容

1.企业组织结构

参考书提到需求分析前需要规划,要求对企业做全面调查,了解企业组织架构.例如:

每个部门继续细化,如

职务	数量	岗位说明
财务总监	1	全面主持财务部日常工作,定期向总裁办公室汇报
财务经理	2	按销售区域分管财务工作
会计	5	每日财务报表整理,提交财务经理审核

财务部人员配置表

如前所述,这些资料需用户提供,交由数据库设计做参考.理由很简单,系统分析人员既没有相关资料内容,也没有了解这些资料的权限.

2.明确具体用户及其职责

具体用户,站在企业的角度,对应着某个职位;站在程序员角度,指的是数据库中的"角色".例如上面财务部有3个具体用户.每个具体用户有着相应的职责并由表格来表示.

示例

举个例子.制造部有3个车间,每个车间设一个车间主任.A车间主任是张三,下面有李四和王五两个员工,产品有零件A.张三手里有以下几张表:加工表,员工情况表,车间每日生产报表,车间月度工作报表,员工每日工作报表,员工月度工作报表,如下所示:

表1.加工表

加工编号	加工名称	预期工时
lj00001	车外圆	0.5
lj00002	镗孔	1

表2.员工情况表

员工编号	姓名	职务
ygM0001	张三	车间主任
yg00002	李四	车工
yg00003	王五	车工

表3.员工每日工作报表(假设以下是2025.9.1日的表)

员工编号	加工编号	总数	完成数	报废数
yg00002	lj00001	10	10	0
yg00002	lj00002	3	3	0
yg00003	lj00001	20	19	1

表4.车间月度生产报表(9月)

日期	加工编号	总数	完成数	报废数
2025.9.1	lj00001	30	29	1
2025.9.1	lj00002	3	3	0
2025.9.2	lj00001	32	32	0
2025.9.2	lj00002	4	4	0
…	…	…	…	…

表5.车间年度生产报表(2025年)

月份	加工编号	总数	完成数	报废数
2025.8	lj00001	800	799	1
2025.9	lj00002	100	100	0
…	…	…	…	…

=============================内容分割线↓===================================

注意:"日报表"表示该表内所有元组内容加起来是一个工作日的内容,因此每个元组是某员工某个加工的生产情况(主键是员工号+加工编号+总数).以此类推,"月报表"中的元组是工作日数据,"年报表"的元组是月数据.

=============================内容分割线↑===================================

日报表和月报表

这里讨论一点和示例有关的内容(和数据库没多大关系).月报表和日报表的关系是什么?设每月工作日为n,则n张"日报表"的内容="月报表"内容.写出车间每日生产报表

表6 车间每日生产报表(2025.9.1)

加工编号	总数	完成数	报废数
lj00001	30	29	1
lj00002	3	3	0

可以看出是表4前2个元组形成的表,从月度报表中写个SELECT语句也很容易得到.

这里引出第一个需求分析中的矛盾问题:是否有必要设计车间每日生产报表?他的解决需要用户和系统分析员沟通.如果用户方管理严格,每日生产报表需要单独存档,则需要设计,用"CREATE TABLE xxx SELECT xxx(属性或组合) FROM xxx(表名)"---见参考书P45.元组内容从表3计算自动得出.

日报表和月报表的引申---表的合并和拆分

从日报表和月报表的关系,可以看出多张形式相同的表可以合成一张表,操作方法是新增一个属性,把表名中的数值作为属性值填入.例如将日生产报表合成月度生产报表,把日期化成属性,表名中的日期值填入属性中.

与之相对应的是,一张表可以拆分成多张表,操作方法是把某个属性去掉,并将属性值作为表名形成新表.例如车间月度生产报表,拆去日期属性,变成n(工作日个数)张车间日生产报表.笔者将在E-R模型的调整中详细说明表的合并和拆分的用法.

注意:表的合并和拆分是一种"可选",和关系模型范式的1NF(属性多值)有区别,多值"必须"拆分

表内容的填写

上述几张表中,表1,表2,表3是车间主任手动编写,其他表的内容由程序员编写程序自动算出.

解决盲区

假设上面几张表是A车间主任和系统分析员之间最终确定方案,是否可以完全解决问题了呢?如果A车间调整了生产计划,加入了零件B,那么原有的"加工表"不再适用,要么添加一张新表,要么改变原来的加工表.问题来了,用户方说我已经把要求提了,系统分析员觉得我是完全按照需求走的,情况变化也和我没关系啊.

问题出在哪里?用E-R图可以分析.

A车间和零件A是1:1的关系,如果有人问加工表里没体现A车间和零件A啊,因为他们是1:1的关系(这里是n:1也是可以的,为了简化理解写成1:1),所以在"A车间"里作为表是可以略去---参考"表的拆分",为了适应可能的变化,表1改为以下形式

表1(修改后)加工表

加工编号	零件名称	加工名称	预期工时
lj00001	零件A	车外圆	0.5
lj00002	零件A	镗孔	1

新的加工表一眼看去有数据冗余,但这是无法避免的,好处是有新零件加入后依然适用.

盲区的解决是一种"未雨绸缪"的准备,考验分析员的能力.也再次体现了需求分析的重要性.如果肯定A车间没有其他零件加工,那么采用原有表的格式更好.

3.添加访问限制

对系统中的每个角色,限定各自访问数据库的权限.内容可参考前面的贴

需求分析的结果

根据每个具体用户的职责和限制,综合起来就能得到需求分析的结果---需求说明书.需求说明书的作用相当于用户和程序员之间沟通的桥梁,大家都能看得懂都能理解的一种文件,重点是用户方的认可,最好是签字盖章作为验收的依据.

需求说明书没有一种特定的形式,笔者自创了一种:仍然是表格,例如

需求分析之车间主任
序号	模式	表名	同时读取/修改
1	责任	加工表	是
2	责任	员工情况表	是
3	责任	员工每日工作报表	是
4	访问	员工每月福利表	否
5	访问	员工考勤表	否

附加说明:"责任"表示由角色(车间主任)填写的表,"访问"表示角色可以访问的表,如表中的"员工每月福利表"来自总裁办公室,"员工考勤表"来自人力资源部."同时读取/修改",每张表都有读和写两个权限,对写来说是否同时可以读,对读来说是否同时可以写.对应表中的内容,序号1,2,3角色写的内容同时可以读,序号4,5角色读的内容不能写(修改)

此外车间月度生产报表和车间年度生产报表由数据库程序员写,在用户看来是自动生成的,由原始数据计算得出,不能人为修改,一定程度上保证数据的可靠.对这两张表的访问没有体现在上表中.当然如果要求可以修改,就让车间主任自己写,程序员提供两张表的格式.