数据库三大范式

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/u012410733/article/details/62212363

作为一个web开发者,搞懂数据库是很有必要的。而弄明白关系数据库的三大范式是很有用的。只有清楚了数据库三大范式的设计初衷我们才能够设计出更好的表结构。

1、第零范式

第零范式就是指没有使用任何范式的设计,其添加数据的行为非常诡异,看看下表便知:

假设一个学生学习了三门课程,每门课程都有成绩,那么,采用第零范式的设计将会是如下情况:

student_id name_1 score_1 name_2 score_2 name_3 score_3
1 语文 90 数学 90 英语 98

这样的话,会使得往表中添加数据变得非常麻烦,每次添加一个新的数据,都要添加相应的字段,而且,因为表中其他的记录可能不需要这么多字段,因此会浪费很多空间。如表所示:

student_id name_1 score_1 name_2 score_2 name_3 score_3
1 语文 90 null null null null
2 语文 90 数学 90 英语 98

由此可以看出,不对数据库任用任何范式是非常愚蠢的,因为不仅会产生大量无用的表字段,而且会使得表结构非常难以维护。由此,引出第一范式的介绍

2、第一范式 – 列不可分

第一范式就是指表中的所有字段都是原子的、不可再分的。将第零范式中重复的字段抽取出来,作为表的数据,从而形成一个稳定的、冗余数据少得表结构。

由此,可以得出符合第一范式的表结构应该是:

Student

student_id student_name score
1 英语 90
1 数学 90
1 语文 98

此时,表的结构变得稳定了,而且表中的冗余信息相对第零范式也少了很多。可是,第一范式只是关系数据库设计的最低满足的范式,第一范式中仍然可能有很多的冗余信息,由此,需要引入第二范 式。

3、第二范式 – 非主属性完全依赖主属性

第二范式是满足非主属性完全依赖于主属性。因此,满足第二范式的表当然也是满足第一范式的,第二范式的目的就是消除表中的部分依赖。

这里,有几个概念要解释下,

3.1、完全函数依赖

设有属性集K和P,若K中的所有属性共同能够推出P中的任意属性,且对于K的任何真子集,都不能推出P中的任意属性,则成K完全函数依赖P。

3.2、部分函数依赖

与上相似,只是,K中存在真子集使得,该子集能推出p中任意属性。概念性的东西,往往都难懂,举个例子,方便大家理解:

假如有一张学生成绩表,包含如下属性(学生Id,课程Id,课程分数,学生名字),其中,主键为(学生id,课程id),表中的数据如下:

Student

student_id college_id score student_name
1 2 90 张三
1 1 100 张三

从上面的表数据易知,不满足第二范式的表至少有以下几个缺点:

  1. 数据重复,浪费空间,因为每存一条记录,都要存学生的名字,这样就是得存在大量重复的数据。
  2. 插入异常,若学生还没有成绩,那么这个学生就没有名字。
  3. 更新异常,删除异常等

解决方法:可以分为以下三张表。

Student

student_id student_name

College

college_id college_name

Student_College

student_id college_id score

4、第三范式 – 属性不依赖于其它非主属性

第三范式是指在满足第二范式的情况下,属性不依赖于其它非主属性 , 消除传递依赖

所谓传递依赖,就是指x–>y,y–>z,那么可以得到y–>z.

传递依赖常发生在主键、外键、外键相关的属性上,例如,假设有这样的表

  1. 学生表(学生id,学生姓名,院系id,院系名) ,此处主键为(学生id),外键为(院系id)
  2. 院系表(院系id,院长名称),主键为 (院系id)

Student

student_id student_name college_id college_name
1 carl 1 地理学院
2 alan 1 地理学院
3 kevin 2 外国语学院

College

college_id college_name
1 地理学院
2 外国语学院

从上面的表数据易知,不满足第三范式的表至少有以下几个缺点:

  1. 数据重复,浪费空间,因为学生表每存一条记录,都会记录住院系的名字,存在大量的重复数据。
  2. 插入异常,若新建一个院系,而该院系没有学生的话,该院系就没有名字。
  3. 更新异常,删除异常等

5、反范式

在日常项目中如果完全按照上面的范式设计数据库那么在效率上会存在很大的问题。例如:查询所有的记录信息,这是如果有外检一对多,多对多等关系势必影响系统效率。

另一方面,如果完全遵守范式要求,虽然在一定程度上降低了数据库的yongyu度。但是系统的可维护性会大大的下降。

如果仅仅是这量反面就有足够的理由去做反范式要求了,与其遵守范式要求,不如将更多的业务封装在代码层,这样做的好处就不言而喻了。

反范式设计的目的:用空间去换时间。空间在这里的成本其实是远远低于时间成本的,随着项目的发布,空间成本会越来越低。

6、数据库设计总结

  1. 表的数目不要太多,一般20-30张就够了。如果表的数目太多,则可以考虑采用同化操作,即将大体相同的实体放入到一张表中。
  2. 当数据库中的信息非常庞大时,不要使用外键(逆规范化),因为由此可能带来非常大的性能损失。
  3. 一般以消耗存储空间来换取效率。

三大范式只是一般设计数据库的基本理念,可以建立冗余较小、结构合理的数据库。如果有特殊情况,当然要特殊对待,数据库设计最重要的是看需求跟性能,需求>性能>表结构。所以不能一味的去追求范式建立数据库。

简洁、明晰!数据库设计三大范式应用实例剖析

01-12

引言rnrn  数据库的设计范式是数据库设计所需要满足的规范,满足这些规范的数据库是简洁的、结构明晰的,同时,不会发生插入(insert)、删除(delete)和更新(update)操作异常。反之则是乱七八糟,不仅给数据库的编程人员制造麻烦,而且面目可憎,可能存储了大量不需要的冗余信息。rnrn  设计范式是不是很难懂呢?非也,大学教材上给我们一堆数学公式我们当然看不懂,也记不住。所以我们很多人就根本不按照范式来设计数据库。rnrn  实质上,设计范式用很形象、很简洁的话语就能说清楚,道明白。本文将对范式进行通俗地说明,并以笔者曾经设计的一个简单论坛的数据库为例来讲解怎样将这些范式应用于实际工程。rnrn  范式说明rnrn  第一范式(1NF):数据库表中的字段都是单一属性的,不可再分。这个单一属性由基本类型构成,包括整型、实数、字符型、逻辑型、日期型等。rnrn  例如,如下的数据库表是符合第一范式的:rn rnrn  而这样的数据库表是不符合第一范式的:rn rnrn  很显然,在当前的任何关系数据库管理系统(DBMS)中,傻瓜也不可能做出不符合第一范式的数据库,因为这些DBMS不允许你把数据库表的一列再分成二列或多列。因此,你想在现有的DBMS中设计出不符合第一范式的数据库都是不可能的。rnrn  第二范式(2NF):数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖(部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况),也即所有非关键字段都完全依赖于任意一组候选关键字。 rnrn  假定选课关系表为SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分),关键字为组合关键字(学号, 课程名称),因为存在如下决定关系:rnrn  (学号, 课程名称) → (姓名, 年龄, 成绩, 学分)rnrn  这个数据库表不满足第二范式,因为存在如下决定关系:rnrn  (课程名称) → (学分)rnrn  (学号) → (姓名, 年龄)rnrn  即存在组合关键字中的字段决定非关键字的情况。rnrn  由于不符合2NF,这个选课关系表会存在如下问题:rnrn  (1) 数据冗余:rnrn  同一门课程由n个学生选修,"学分"就重复n-1次;同一个学生选修了m门课程,姓名和年龄就重复了m-1次。rnrn  (2) 更新异常:rnrn  若调整了某门课程的学分,数据表中所有行的"学分"值都要更新,否则会出现同一门课程学分不同的情况。rnrn  (3) 插入异常:rnrn  假设要开设一门新的课程,暂时还没有人选修。这样,由于还没有"学号"关键字,课程名称和学分也无法记录入数据库。rnrn  (4) 删除异常:rnrn  假设一批学生已经完成课程的选修,这些选修记录就应该从数据库表中删除。但是,与此同时,课程名称和学分信息也被删除了。很显然,这也会导致插入异常。 rnrn  把选课关系表SelectCourse改为如下三个表:rnrn  学生:Student(学号, 姓名, 年龄);rnrn  课程:Course(课程名称, 学分);rnrn  选课关系:SelectCourse(学号, 课程名称, 成绩)。rnrn  这样的数据库表是符合第二范式的,消除了数据冗余、更新异常、插入异常和删除异常。rnrn  另外,所有单关键字的数据库表都符合第二范式,因为不可能存在组合关键字。rnrn  第三范式(3NF):在第二范式的基础上,数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。所谓传递函数依赖,指的是如果存在"A → B → C"的决定关系,则C传递函数依赖于A。因此,满足第三范式的数据库表应该不存在如下依赖关系:rnrn  关键字段 → 非关键字段x → 非关键字段yrnrn  假定学生关系表为Student(学号, 姓名, 年龄, 所在学院, 学院地点, 学院电话),关键字为单一关键字"学号",因为存在如下决定关系:rnrn  (学号) → (姓名, 年龄, 所在学院, 学院地点, 学院电话)rnrn  这个数据库是符合2NF的,但是不符合3NF,因为存在如下决定关系:rnrn  (学号) → (所在学院) → (学院地点, 学院电话)rnrn  即存在非关键字段"学院地点"、"学院电话"对关键字段"学号"的传递函数依赖。rnrn  它也会存在数据冗余、更新异常、插入异常和删除异常的情况,读者可自行分析得知。rnrn  把学生关系表分为如下两个表:rnrn  学生:(学号, 姓名, 年龄, 所在学院);rnrn  学院:(学院, 地点, 电话)。rnrn  这样的数据库表是符合第三范式的,消除了数据冗余、更新异常、插入异常和删除异常。rnrn  鲍依斯-科得范式(BCNF):在第三范式的基础上,数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符合第三范式。rn 假设仓库管理关系表为StorehouseManage(仓库ID, 存储物品ID, 管理员ID, 数量),且有一个管理员只在一个仓库工作;一个仓库可以存储多种物品。这个数据库表中存在如下决定关系:rnrn  (仓库ID, 存储物品ID) →(管理员ID, 数量)rnrn  (管理员ID, 存储物品ID) → (仓库ID, 数量)rnrn  所以,(仓库ID, 存储物品ID)和(管理员ID, 存储物品ID)都是StorehouseManage的候选关键字,表中的唯一非关键字段为数量,它是符合第三范式的。但是,由于存在如下决定关系:rnrn  (仓库ID) → (管理员ID)rnrn  (管理员ID) → (仓库ID)rnrn  即存在关键字段决定关键字段的情况,所以其不符合BCNF范式。它会出现如下异常情况:rnrn  (1) 删除异常:rnrn  当仓库被清空后,所有"存储物品ID"和"数量"信息被删除的同时,"仓库ID"和"管理员ID"信息也被删除了。rnrn  (2) 插入异常:rnrn  当仓库没有存储任何物品时,无法给仓库分配管理员。rnrn  (3) 更新异常:rnrn  如果仓库换了管理员,则表中所有行的管理员ID都要修改。rnrn  把仓库管理关系表分解为二个关系表:rnrn  仓库管理:StorehouseManage(仓库ID, 管理员ID);rnrn  仓库:Storehouse(仓库ID, 存储物品ID, 数量)。rnrn  这样的数据库表是符合BCNF范式的,消除了删除异常、插入异常和更新异常。 rn rn  范式应用rnrn  我们来逐步搞定一个论坛的数据库,有如下信息:rnrn  (1) 用户:用户名,email,主页,电话,联系地址rnrn  (2) 帖子:发帖标题,发帖内容,回复标题,回复内容 rnrn  第一次我们将数据库设计为仅仅存在表:rnrnrn   rn  这个数据库表符合第一范式,但是没有任何一组候选关键字能决定数据库表的整行,唯一的关键字段用户名也不能完全决定整个元组。我们需要增加"发帖ID"、"回复ID"字段,即将表修改为:rn rnrn  这样数据表中的关键字(用户名,发帖ID,回复ID)能决定整行:rnrn  (用户名,发帖ID,回复ID) → (email,主页,电话,联系地址,发帖标题,发帖内容,回复标题,回复内容)rnrn  但是,这样的设计不符合第二范式,因为存在如下决定关系:rnrn  (用户名) → (email,主页,电话,联系地址)rnrn  (发帖ID) → (发帖标题,发帖内容)rnrn  (回复ID) → (回复标题,回复内容)rnrn  即非关键字段部分函数依赖于候选关键字段,很明显,这个设计会导致大量的数据冗余和操作异常。 rn rn  我们将数据库表分解为(带下划线的为关键字):rnrn  (1) 用户信息:用户名,email,主页,电话,联系地址rnrn  (2) 帖子信息:发帖ID,标题,内容rnrn  (3) 回复信息:回复ID,标题,内容rnrn  (4) 发贴:用户名,发帖IDrnrn  (5) 回复:发帖ID,回复IDrnrn  这样的设计是满足第1、2、3范式和BCNF范式要求的,但是这样的设计是不是最好的呢?rnrn  不一定。rnrn  观察可知,第4项"发帖"中的"用户名"和"发帖ID"之间是1:N的关系,因此我们可以把"发帖"合并到第2项的"帖子信息"中;第5项"回复"中的"发帖ID"和"回复ID"之间也是1:N的关系,因此我们可以把"回复"合并到第3项的"回复信息"中。这样可以一定量地减少数据冗余,新的设计为:rnrn  (1) 用户信息:用户名,email,主页,电话,联系地址rnrn  (2) 帖子信息:用户名,发帖ID,标题,内容rnrn  (3) 回复信息:发帖ID,回复ID,标题,内容rnrn  数据库表1显然满足所有范式的要求;rnrn  数据库表2中存在非关键字段"标题"、"内容"对关键字段"发帖ID"的部分函数依赖,即不满足第二范式的要求,但是这一设计并不会导致数据冗余和操作异常;rnrn  数据库表3中也存在非关键字段"标题"、"内容"对关键字段"回复ID"的部分函数依赖,也不满足第二范式的要求,但是与数据库表2相似,这一设计也不会导致数据冗余和操作异常。rnrn  由此可以看出,并不一定要强行满足范式的要求,对于1:N关系,当1的一边合并到N的那边后,N的那边就不再满足第二范式了,但是这种设计反而比较好!rnrn  对于M:N的关系,不能将M一边或N一边合并到另一边去,这样会导致不符合范式要求,同时导致操作异常和数据冗余。 rn对于1:1的关系,我们可以将左边的1或者右边的1合并到另一边去,设计导致不符合范式要求,但是并不会导致操作异常和数据冗余。rnrn  结论rnrn  满足范式要求的数据库设计是结构清晰的,同时可避免数据冗余和操作异常。这并意味着不符合范式要求的设计一定是错误的,在数据库表中存在1:1或1:N关系这种较特殊的情况下,合并导致的不符合范式要求反而是合理的。rnrn  在我们设计数据库的时候,一定要时刻考虑范式的要求。rnrn http://develop.csai.cn/dbms/200701121001271242.htm

帮个忙那个数据库表怎么做 要做几个 要遵循三大范式

05-05

nt Mixed Format rn三、项目的功能性需求rn3.1 功能性需求分类rnrn功能类别 子功能rn系统 系统设置rn 其它设置rn 数据转存rn 员工出勤记录rn 用户管理rn 修改密码rn 权限级别功能设定rn 注销rn 重新启动rn 退出rnFeature B Function B.1rn Function B.2rn …rn… rnrnrn3.2系统rn关于使用该系统时的一些基础设置rn3.2.1系统设置rn名称、标识符 rn功能描述 主要设置当前店的相关信息,比如店铺的类型rn优先级 rn输入 rn操作序列 rn输出 rn补充说明 店铺的类型:总店,分店,店的名称等rn3.2.2其它设置rn名称、标识符 rn功能描述 主要设置系统和本机中比较常用的功能项,普通级别的用户都可以登录进行设置,比如“是否输入销售员工号”,是则进入销售界面时弹出一小窗口以便输入销售员工的工号,否则无输入窗口弹出。rn优先级 rn输入 rn操作序列 rn输出 rn补充说明 店铺的类型:总店,分店,店的名称等rnrn3.2.3数据转存rn名称、标识符 rn功能描述 将过时的数据转存到另外的备份表中,以提高常用数据库的效率,如销售类、库存类报表等。界面上默认时间均为15个月,除销售转存数据不可小于2个月,其它转存数据不可小于三个月。rn优先级 rn输入 rn操作序列 rn输出 rn补充说明 对于当前表,可分为两类:数据量比较大的,如销售类、库存类报表,通常只存放一到两个月;数据量不大,更新频率不高的,如入货单,可存放半年。前提条件是日结后。rn3.2.4员工出勤记录rn名称、标识符 rn功能描述 记录员工上下班时刻,可根据员工代号或时间段时行查询、打印相关上下班信息;使用Ctrl+W可在任何操作界面中直接调出考勤记录快捷方式;rn用户先选择上下班状态,再通过扫描仪将自己的员工号输入电脑中,系统将根据所输入的数据记录该员工上班或下班的时刻;rn 可查询记录rn优先级 rn输入 rn操作序列 rn输出 rn补充说明 rn3.2.5用户管理rn名称、标识符 rn功能描述 当有新同事加入,便需要在电脑上增加用户名并指定其可使用的权限,然后他才可以在规定的范围内使用电脑。rn可进行【权限快选】,继承已经存在用户的权限组,起到快捷编辑新增用户的权限;rn查询rn删除rn修改rn优先级 rn输入 rn操作序列 rn输出 rn补充说明 根据【系统设置】项中“是否检查员工”来启用模式,当设置项为“T”时,新增用户需验证员工号并把员工号作为用户的帐号,否则无需判断是否有员工号,只需系统中不存在相同的用户帐号即可新增。rn3.2.6修改密码rn名称、标识符 rn功能描述 rn优先级 rn输入 rn操作序列 rn输出 rn补充说明 rn3.2.7系统设置rn名称、标识符 rn功能描述 当前用户输入原始密码,确认成功方可输入新的密码,确认密码必须与新密码一致,否则无法更改。rn优先级 rn输入 rn操作序列 rn输出 rn补充说明 rn3.2.8 权限级别功能设定rn名称、标识符 rn功能描述 在本系统内根据权限名称设置权限级别,比如:Admin超级用户,所有系统使用项都默认选中;普通用户:只可登录、查看、销售基本操作;报表级别:只可查看打印报表项等,权限项设置较为灵活,按各自管理方式划分权限,通过设定各级权限可使用的功能,从而限制各用户的可使用范围。rn增、删除、改、查rn优先级 rn输入 rn操作序列 rn输出 rn补充说明 rn3.3文档管理rn支持货品的基础设置rn3.3.1款号维护rn名称、标识符 rn功能描述 主要编辑商品款号rn1、以列表显示所有款号信息rn2、修改:在列表中选择要修改的款号进入修改界面。可修改基本信息、推广内容、价格;修改价格时如果款号的商品条码中存在不同价格系统将提示用户是否要将不同的商品条码价格修改为一致,否则不修改,是则将新价格更新到相应条码库中;款号代码为不可修改;rn3、查询:具有唯一查询和模糊查询的功能。如:输入401101与4011查询界面不一样。rn4、可根据选择进行排序rn优先级 rn输入 rn操作序列 rn输出 rn补充说明 rn3.3.2商品条码维护rn名称、标识符 rn功能描述 编辑商品条码资料的功能项rn1、列表界面:列出所有商品条码rn2、增加新条码:条码的生成由款号代码、颜色代码、尺码组成,所以新增的款号代码必须存在库中,新增过程中新输入的颜色代码、尺码代码将自动更新到该款号的颜色及尺码管理库中。rn3、修改条码信息,主要是条码的其它信息,如内容描述、折扣或促销价等。折扣和促销价不可同时使用,同时两者的输入值受到系统设置中的最大折扣率的限制。rn4、有选择排序功能rn优先级 rn输入 rn操作序列 rn输出 rn补充说明 rn3.3.3颜色与尺码维护rn名称、标识符 rn功能描述 主要编辑商品的颜色代码、尺码代码;方便根据不同商品进行存储;每新增一款号颜色代码、尺码代码系统则自动产生一条或以上新的商品条码。rn优先级 rn输入 rn操作序列 rn输出 rn补充说明 rnrn3.3.4部类维护rn名称、标识符 rn功能描述 编辑部类相关资料,实现增加、修改、查询rn列表:列出所有部类信息rn新增:部类代码+牌子为唯一值。rn修改:部类代号、牌子不能修改,主要修改部类的名称和部类类型rn查询:具有唯一与模糊查询的功能,根据部类代号或者部类名称进行查询rn排序:根据不同字段进行排序rn优先级 rn输入 rn操作序列 rn输出 rn补充说明 rnrn3.3.5种类维护rn名称、标识符 rn功能描述 编辑种类相关资料rn列表:列出所有分类信息rn新增:分类代号+牌子为唯一值rn修改:分类代号不能修改,主要修改分类名称和分类类型rn优先级 rn输入 rn操作序列 rn输出 rn补充说明 rnrn3.3.6付款方式维护rn名称、标识符 rn功能描述 主要编辑付款基本资料rn列表:显示所有付款各类信息rn新增:进入新增界面rn修改:在列表中选择要修改的付款方式,进入修改界面rn删除:在列表中选择要删除的付款方式进行删除,如果该付款方式已经产生交易则不能删除rn查询:根据付款名称或付款代号进行搜索rn排序:根据付款代号,付款名称等组合升序或降序重新排序列表中的记录rn优先级 rn输入 rn操作序列 rn输出 rn补充说明 rnrn3.3.7店号维护rn名称、标识符 rn功能描述 分店编号的维护:基本资料,主要编辑各店的店类型、地址、联系电话等基本信息。rn列表:rn增加:增加新子店,可选择其他主店或者自己当主店,新增的子店必须是在库中不存在的rn修改:子店号不可修改,可以修改主店号或将自己升级为主店rn查询:具有唯一与模糊查询的功能;根据店号、主店号、店名查询相关信息rn优先级 rn输入 rn操作序列 rn输出 rn补充说明 rnrn3.3.2系统设置rn名称、标识符 rn功能描述 rn优先级 rn输入 rn操作序列 rn输出 rn补充说明 rnrn3.3.2系统设置rn名称、标识符 rn功能描述 rn优先级 rn输入 rn操作序列 rn输出 rn补充说明 rnrn3.3.2系统设置rn名称、标识符 rn功能描述 rn优先级 rn输入 rn操作序列 rn输出 rn补充说明 rnrn3.3.2系统设置rn名称、标识符 rn功能描述 rn优先级 rn输入 rn操作序列 rn输出 rn补充说明 rnrn3.3.2系统设置rn名称、标识符 rn功能描述 rn优先级 rn输入 rn操作序列 rn输出 rn补充说明 rnrn3.3.2系统设置rn名称、标识符 rn功能描述 rn优先级 rn输入 rn操作序列 rn输出 rn补充说明 rnrn3.3.2系统设置rn名称、标识符 rn功能描述 rn优先级 rn输入 rn操作序列 rn输出 rn补充说明 rnrn3.3.2系统设置rn名称、标识符 rn功能描述 rn优先级 rn输入 rn操作序列 rn输出 rn补充说明 rnrn3.3.2系统设置rn名称、标识符 rn功能描述 rn优先级 rn输入 rn操作序列 rn输出 rn补充说明 rnrn3.3.2系统设置rn名称、标识符 rn功能描述 rn优先级 rn输入 rn操作序列 rn输出 rn补充说明 rnrn3.3.2系统设置rn名称、标识符 rn功能描述 rn优先级 rn输入 rn操作序列 rn输出 rn补充说明 rnrn3.3.2系统设置rn名称、标识符 rn功能描述 rn优先级 rn输入 rn操作序列 rn输出 rn补充说明 rnrn3.3.2系统设置rn名称、标识符 rn功能描述 rn优先级 rn输入 rn操作序列 rn输出 rn补充说明 rnrn3.3.2系统设置rn名称、标识符 rn功能描述 rn优先级 rn输入 rn操作序列 rn输出 rn补充说明 rnrn3.3.2系统设置rn名称、标识符 rn功能描述 rn优先级 rn输入 rn操作序列 rn输出 rn补充说明 rnrn3.3.2系统设置rn名称、标识符 rn功能描述 rn优先级 rn输入 rn操作序列 rn输出 rn补充说明 rnrn3.3.2系统设置rn名称、标识符 rn功能描述 rn优先级 rn输入 rn操作序列 rn输出 rn补充说明 rnrn3.3.2系统设置rn名称、标识符 rn功能描述 rn优先级 rn输入 rn操作序列 rn输出 rn补充说明 rnrn3.3.2系统设置rn名称、标识符 rn功能描述 rn优先级 rn输入 rn操作序列 rn输出 rn补充说明 rnrn3.3.2系统设置rn名称、标识符 rn功能描述 rn优先级 rn输入 rn操作序列 rn输出 rn补充说明 rnrn3.3.2系统设置rn名称、标识符 rn功能描述 rn优先级 rn输入 rn操作序列 rn输出 rn补充说明 rnrn3.3.2系统设置rn名称、标识符 rn功能描述 rn优先级 rn输入 rn操作序列 rn输出 rn补充说明 rnrn3.3.2系统设置rn名称、标识符 rn功能描述 rn优先级 rn输入 rn操作序列 rn输出 rn补充说明 rnrnrnrn……rn7. 项目的非功能性需求rn7.1 用户界面需求rn需求名称 详细要求rn rn rn… rn7.2 软硬件环境需求rn需求名称 详细要求rn rn rn… rn7.3 项目质量需求rn主要质量属性 详细要求rn正确性 rn健壮性 rn可靠性 rn性能,效率 rn易用性 rn清晰性 rn安全性 rn可扩展性 rn兼容性 rn可移植性 rn… rn7.n 其他需求rnrnrn3、运行平台rn3.1硬件要求rn能够运行在实现主流配置的PC机(如PIII以上CPU,512M以上内存)上,并能顺畅运行,不停顿或运行缓慢等现象。rn3.2软件要求rn操作系统要求:rnWindows 2000、Windows 2003、Windows XP、Windows Vistarn.Net Framework要求:rn.Net Framework 2.0、.Net Framework 3.0、.Net Framework 3.5rnrnrnrn4、项目组成员rn全部项目组成员如下: rn职务代码 职务描述 成员rnPM 项目经理 刘丹rnPL 项目组长 李四rnSE 软件工程师 王五、陈六rnPG 程序员 赵明、李刚、王一rnTester 测试员 Tom、Lily、田中一郎rnrnrnrnrnrnrnrnrn5、日程安排rn 项目开发详细日程以及阶段成果物如下:rn任务 参与者 起止日 成果物rn需求分析 张三、李四 2008/8/5~2008/8/5 需求说明书rn概要设计 李四 2008/8/5~2008/8/5 概要设计说明书rn详细设计 王五、陈六 2008/8/5~2008/8/5 详细设计说明书rn编码 赵明、李刚、王一 2008/8/5~2008/8/5 程序代码rn综合测试 Tom、Lily、田中一郎 2008/8/5~2008/8/5 测试用例rn提交 张三 2008/8/5~2008/8/5 成品软件、用户手册

没有更多推荐了,返回首页

私密
私密原因:
请选择设置私密原因
  • 广告
  • 抄袭
  • 版权
  • 政治
  • 色情
  • 无意义
  • 其他
其他原因:
120
出错啦
系统繁忙,请稍后再试