医院需求分析文档.pdf

文档编文档编号号项目名项目名称称项目来项目来源源Kf-0418-2012Kf-0418-2012版版本本A1A1密密级级商商密密 A AITIT 有机公司软件开有机公司软件开发事业部发事业部医院管理系统医院管理系统XXXXXXXxXXXXXXXx医院管理系统医院管理系统数据库设计说明书数据库设计说明书(内部资料请勿外传)编编写：写：检检查：查：审审核：核：批批准：准：日日 期：期：日日 期：期：日日 期：期：日日 期：期：ITIT 有机公司有机公司版权所有版权所有不得复制不得复制目录目录医院管理系统医院管理系统.1 1数据库设计说明书数据库设计说明书.1 11 1引言引言.3 31.1编写目的.31.2术语表.错误错误!未定义书签。未定义书签。1.3参考资料.错误错误!未定义书签。未定义书签。2 2数据库环境说明数据库环境说明.错误!未定义书签。3 3数据库的命名规则数据库的命名规则.错误!未定义书签。4 4逻辑设计逻辑设计.错误!未定义书签。5 5物理设计物理设计.错误!未定义书签。5.15.25.35.4表汇总.错误错误!未定义书签。未定义书签。表X：XXX表.错误错误!未定义书签。未定义书签。视图的设计.23存储过程、函数及触发器的设计.错误错误!未定义书签。未定义书签。6 6安全性设计安全性设计.错误!未定义书签。6.1防止用户直接操作数据库的方法.316.2用户帐号密码的加密方法.错误错误!未定义书签。未定义书签。6.3角色与权限.错误错误!未定义书签。未定义书签。7 7优化优化.错误!未定义书签。8 8数据库管理与维护说明数据库管理与维护说明.4 40 01 1引言引言1.11.1 编写目的编写目的在完成了对医院各个部门的调查后,同时与多名病人进行了全面深入地探讨和分析的基础上,提出了这份系统需求分析报告.此需求分析报告对医院管理利通做了全面细致的用户需求分析，明确所要开发的系统应具备的功能、性能与界面，使系统分析人员及软件开发人员能清楚地了解用户的需求，并在此基础上进一步提出概要设计说明书和完成后续设计与开发工作。此外，这份需求分析报告中介绍了我们系统的框架结构，明确了该系统的方向及用途，是客户了解我们系统的一份详细资料，本分析报告的预期读者为客户、业务或需求分析人员、测试人员、用户文档编写者、项目管理人员。此分析报告是整个系统开发的依据，它对以后阶段的工作起指导作用。本文也是项目完成后系统验收的依据。1.21.2 术语表术语表序号12345术语或缩略语PaDoPbPrZr说明性定义Patient 病人Doctor 医生Patient-bed 病床Patient-room 病房Zhuyuan-register 住院登记6TrTrue-record 治疗记录1.31.3 参考资料参考资料资料名称资料名称数据库原理及应用SQL Server 使用教程数据库应用技术作者作者何玉洁范立南张蒲生文件编号、版本文件编号、版本机械工程出版社清华大学出版社机械工业出版社资料存放地点资料存放地点图书馆图书馆图书馆2.2.数据库环境说明数据库环境说明2.12.1 网络逻辑结构网络逻辑结构本次设计基于的网络逻辑结构是客户/服务器（C/S）体系结构。它由三个主要部分构成：数据库服务器、客户应用程序和网络。基于C/S 的住院管理系统的结构示意图如图所示2.22.2 软件支撑环境及开发工具软件支撑环境及开发工具 在 WINDOWS XP 操作系统下完成 包括应用程序的开发、数据库的设计以及设计报告的编写 应用的开发工具有：VC 程序设计语言 SQL Server 2000 Microsoft Office Word 20033.3.数据库的命名规则数据库的命名规则3.1.1此数据库完全按照 my sql 数据库设计规范命名。表名命名依据英文单词全称。列名命名依据整个列的属性取相应的英文缩写或拼音缩写4.4.系统需求简介系统需求简介4.1.14.1.1 总体需求简单介绍总体需求简单介绍1 建立对医院全面管理的信息系统2 对所有医生和病人进行管理3 对所有部门的详细信息进行管理4 对所有医生的详细信息进行管理1 1系统的功能实现情况系统的功能实现情况:用户可在本系统下实现各种用户要求的功能2 2系统的安全性系统的安全性:对于系统的重要数据都有密码保护，具有一定的安全性对用户提供证书支持（此功能在后续版本中实现）3 3系统的容错性系统的容错性:用户输错数据都有提示信息，具有较好的容错性能。4 4系统的封闭性系统的封闭性:与其他数据项的逻辑数据项含义说明类型长度取值范围取值含义关系前两位标明000000000000000该病人所挂至诊的部门，后999999999999999十三位按顺序编号0000000001 至9999999999前两位表示所属部门，后八位按顺序编号前两位表示所属部门，后两位按顺序编号前两位表示所属病房，后两位按顺序编号表示每个住院登记的记录表示每个治疗记录的情况病案号唯一标识每个病人字符型15与住院登记，治疗记录用此数据项相联系医生编号唯一标识每个医生字符型10与治疗记录用此数据项相联系病房编号唯一标识每个病房字符型40001 至 9999与病床，住院登记用此数据相联系床位号唯一标识每个病床字符型3001 至 999引用病房主码做病床表的外码，与住院登记用此数据相联系日期，病案号唯一标识每个住院登记DATE,字符型10,15日期的取值范围，病案号引用病人表的主码联系病人和住院登记病案号，医生编号唯一标识每个治疗记录字符型病案号引用病人表的主码，医生编15，10码引用医生表的主码联系病人和医生用户的封闭性较好，用户基本上在提示信息下输数据4.1.24.1.2 数据字典数据字典数据项数据项数据结构数据结构数据结构病人含义说明定义了每个病人的有关信息组成病案号，姓名，性别，地址，电话号码，病房编号，医生编号医生编号，姓名，性别，职称，电话号码，部门，月工资病房编号，地点，收费标准，所属部门病房编号，病床号日期，病案号，入院日期，出医生病房病床住院登记定义了每个医生的有关信息定义了每个病房的有关信息定义了每个病床的有关信息定义了每个住院登记的有关信息院日期，病房编号，床位号，住院费用数据流数据流数据流：病人诊断情况说明：病人病情的最终结果数据流来源：病人数据流去向：医生组成：病人，住院登记，治疗记录平均流量：每天几百人高峰期流量：每天几千人数据存储数据存储数据存储：病人入院登记说明：记录病人的基本情况流入数据流：住院登记流出数据流：住院登记组成：病人，医生，住院登记，治疗记录数据量：每天几百张存取频度：每人一次存取方式：随机存取处理逻辑处理逻辑处理名称：生成病人就医情况总表说明：说明处理过程输入数据流：病人，治疗记录输出数据流：住院登记处理逻辑：记录病人诊治记录，形成治疗记录，汇总成病人住院登记，再生成总表平均执行频率：每天几百次（说明：以上平均频率需长期观察得到）数据流图图元数据流图图元医 生编 号医生诊治病人医 生属 性病 案号病 人属 性4.1.34.1.3 系统功能设想系统功能设想这里的功能划分，是根据第一阶段需求调查基础上进行的初步划分。随着需求调查的深入，功能模块随着对需求了解的明确得到调整。医院管理系统的四个主要部分,可以将系统应用程序划分为对应的 4 个子模块:包括医生管理系统,病人管理系统,病房管理系统,科室管理系统.根据各业务子系统所包括业务内容,还可以将各个子系统继续细化划分为更小的功能模块。划分的准则主要遵循模块的内聚性要求和模块间的低聚合性。如图所示表示一个医院管理系统功能模块结构图。应用系统医生管理病人管理病房管理系统管理治疗病人信息医生的详细信息病人的详细信息住院信息各科室医生及病人信息所有部门科室信息4.1.44.1.4 业务流程分析业务流程分析简单医院流程图简单医院流程图病人病案病人住院申请查 看病人信息信 息分 配床 位产生收费单及住院单收 住费 院单 单病人病房信息图图 4-14-1 入院数据流图入院数据流图病人病历病人出示病历医 生给出治治疗方案诊 断疗方案病人病人检查情况图图 4-24-2 治疗数据流图治疗数据流图病人病案病人申请出院病 历费 用缴费单病人归 档统 计收费准则图图4-34-3 出院数据流图出院数据流图5.5.概念设计概念设计5.1.15.1.1 实体实体 病房（病房编号，地点，收费标准，所属科室）病床（病房编号，床位号）病人（病案号，姓名，性别，地址，电话号码，病房编号，医生编号）医生（医生编号，姓名，性别，职称，电话号码，部门，工资）住院登记（日期，病案号，入院时间，出院时间，病房编号，床位号，住院费用）治疗记录（治疗时间，病案号，医生编号，诊断，治疗方案）5.1.25.1.2 系统局部系统局部 E ER R 图图治疗方案医生1治疗n病人治疗时间诊断图图 4-84-8 病人与医生联系图病人与医生联系图n住在1病人病房病房1拥有n病床图图 4-94-9 病人与病房及病房与病床联系图病人与病房及病房与病床联系图病人1登记n住院登记5.1.35.1.3 系统全局系统全局 E ER R 图图病房编号病床病床床位号n1日期出院时间住院费用病房编号入院时间分配n住院登记住院登记床位号病案号拥有病房编号1地点病房病房收费标准登记n医生编号姓名所属部门1病案号1医生医生性别职称住在1电话号码n治疗n病人病人工资姓名性别部门地址电话号码治疗时间病房编号诊断医生编号图图 4-114-11 医院住院数据库基本医院住院数据库基本 E-RE-R 图图治疗方案6.6.逻辑设计逻辑设计6.1.1 E-R6.1.1 E-R 图到关系模式转换图到关系模式转换按照上述的原则，根据设计好的 E-R 图，可以将其转换为以下一组关系模式，其中关系模式的码用下横线标出。将 E-R 图中 1:1 的联系与任意一端所对应的关系模式合并。将 E-R 图中 1：n 的联系与 n 端所对应的关系模式合并，如：将“病床”这一联系并到“病房”关系模式；将 E-R 图中 m:n 的联系转换为一个独立的关系模式。病房（病房编号，地点，收费标准，所属科室）病房（病房编号，地点，收费标准，所属科室）此为病房实体型所对应的关系模式。其中病房编号唯一确定一个病房，所以为该关系模式的码。病床（病房编号，床位号）病床（病房编号，床位号）此为病床实体型所对应的关系模式。由于病房编号是病房关系模式的码，所以在该关系模式中病房编号为外码。病人（病案号，姓名，性别，地址，电话号码，病房编号，病人（病案号，姓名，性别，地址，电话号码，病房编号，医生编号）医生编号）此为病人实体型所对应的关系模式。其中病案号为此关系模式的码，而病房编号，医生编号 为该关系模式的外码。医生（医生编号，姓名，性别，职称，电话号码，部门，工医生（医生编号，姓名，性别，职称，电话号码，部门，工资）资）此为医生实体型所对应的关系模式。其中医生编号唯一确定一个医生，所以为该关系模式的码。住院登记（日期，病案号，入院时间，出院时间，病房编号，住院登记（日期，病案号，入院时间，出院时间，病房编号，床位号）床位号）此为住院登记实体型所对应的关系模式。其中，日期和病案号共同确定一个住院登记，病房编号为该关系模式的外码。治疗记录（治疗时间，病案号，医生编号，诊断，治疗方案）治疗记录（治疗时间，病案号，医生编号，诊断，治疗方案）此为联系“治疗”所对应的关系模式。其中，病案号和医生编号都是该关系模式的外码。6.1.26.1.2 各个数据表的表结构设计各个数据表的表结构设计PatientPatient 的数据项描述的数据项描述：数据项名数据项含义病案号病人的编号(pno)姓名病人姓名(pname)性别病人性别(psex)地址病人住址(paddr)电话病人电话(ptel)病房编号医生编号病人病房（pro）主治医生（ppno）类型int长度15备注对应唯一一个病人Char20char2只能取男或女varchar100smallint10charint415住院时由系统分配一位病人只能对应一位主治医生Patient-roomPatient-room 的数据项描述的数据项描述：数据项名编号数据项含义病房编号(rno)类型Int长度15备注病房编号唯一地点病房位置(radd)char20非空收费标准住院收费（rcha）INT15单位为（元/天）所属部门病房所属部门（rbu）vaechar20一间病房只能属于一个部门Patient-bedPatient-bed 的数据项描述的数据项描述：数据项名病房编号数据项含义病房编号（rno）类型int长度15备注唯一确定，引用病房的外码床位号病房床位（rbe）int15唯一确定，一个病房一般有 1-3 个床位DoctorDoctor 的数据项描述：的数据项描述：数据项名编号数据项含义医生编号(dno)类型int长度15备注对应唯一一个医生姓名医生姓名(dname)char20非空性别医生性别(dsex)char2只能取男或女职称医生职称(dzhi)varchar20有可能有多个职称电话医生电话(dtel)smallint10部门所属部门(dbu)varchar20工资医生工资（dsa）int20Zhuyuan-registerZhuyuan-register 的数据项描述：的数据项描述：数据项名数据项名日期数据项含义数据项含义登记日期(rad)病案号病案号（pno）入院时间入院时间（iti）出院时间出院时间（gti）病房编号病房号（rno）病床编号病床号（rbe0int15引用病床表的外码int15引用病房表的外码char10必须在入院时间之后char10int15唯一标识，引用病人外码类型类型char长度长度10备注备注唯一标识True-recordTrue-record 的数据项描述的数据项描述：数据项名数据项名时间数据项含义数据项含义治疗日期(time)类型类型char长度长度8备注备注入院和出院时间之间,唯一标识病案号病案号（pno）int15唯一标识，引用病人外码医生编号主治医生（dno）Int15唯一标志，引用医生外码诊断病情诊断（tre）VARCHAR50医生诊断结果治疗方案治疗方案（mea）VARCHAR200医生给出的治疗方案7 7、物理设计、物理设计7.1 表汇总表名表名表 Patient功能说明功能说明病人表，属性列有病案号、姓名、性别、地址、电话、病房编号、医生编号。主码是病案号，外码是医生编号。病人可以查看关于自己的属性列及住院信息。医生表，属性有医生编号、姓名、性别、职称、电话号码、部门。医生编号是主码。医生可以查看自己的属性列及病人病情状况。病房表，属性列有病房编号、地点、收费标准、所属科室。病房编号是主码。病房表的创建便于医生查看治疗病人的住院地点、便于病人明确自己的收费标准。病床表，主码为病房编号和床位号。外码为病房编号。此表方便病房管理员进一步掌握各病人的详细床位信息。表 Doctor表 Patient-room表 Patient-bed表 True-register治疗记录表，治疗时间、病案号、医生编号共同为主码。此表由病房管理员对于每一位住院的病人进行分配登记。医生查询此表可以了解所医治病人的诊断信息并提出治疗方案。编号、床位号。外码为病案号、病房编号、床位号。表 Zhuyuan-register住院登记表，主码为日期和病案号，属性列有入院时间、出院时间、病房7.27.2 表表7.2.17.2.1表名PatientPatient病人数据库用户主键其他排序字段索引字段序号字段名称病案号病人姓名，性别，地址，电话号码，病房编号，医生编号病案号数据类型（精度范围）允许为空Y/N唯一Y/N区别度默认值约束条件/说明123456pnoInt(15)NY高男主码pnamepsexpaddptelproppnoChar(20)Char(2)NYNNNNNN中低中中低低必须是“男”或者“女”一位病人只能对应一位主治医生的医生编号（引用医生表中的医生编号外码）Varchar(100)YSmallint(10)YChar(4)Int(15)NY7Mysql 脚本Create table(Pno int(15)primary key not null，Pname char(20），Psex char(2)default男 check(男,女),Padd varchar(100),Pro char(4),Ppno int(15)foreign key)7.2.27.2.2表名数据库用户主键其他排序字段索引字段序号字段名称DoctorDoctor医生医生编号医生姓名，性别，职称，电话，部门，工资医生编号数据类型允唯一区别默认约束条件/说明（精度范许Y/N度值围）为空Y/Nint(15)NY高主码Char(20)NN中1234567dnodnamedsexdzhidteldbudsaMysql 脚本Char(2)Varchar(20)Varchar(20)Int(20)YNNNNNN中低中低低男必须是“男”或者“女”Smallint(10)YNY Create table（dno int(15)primary key,dname char(20),dsex char(2)default 男 check(男,女),dzhi varchar(20),dtel smallint(10),dbu varchar(20),dsa int(20),)7.2.37.2.3表名数据库用户主键其他排序字段索引字段序号字段名称proomproom病房管理员、病人病房编号地点，收费标准，所属部门病房编号数据类型允许唯一区别（精度范为空Y/N度围）Y/NInt(15)NY高Char(20)NN中Int(15)Varchar(20)默认值约束条件/说明1234rnoraddrcharbumMysql 脚本主码非空YNNN低低Create table proom（rno int(15)primary key,Radd char(20)not null,Rcha int(15),Rbum varchar(20),)7.2.47.2.4表名数据库用户主键序号字段名称12rnorbepbedpbed病房管理员病房编号和床位号数据类型允许唯一区别（精度范为空Y/N度围）Y/NNY高Int(15)Int(15)N默认值约束条件/说明Y高主码，引用proom 的外码主码Mysql 脚本Create table pbed(rno int(15)references proom(床位号)Rbe int(15)primary key)7.2.57.2.5表名数据库用户主键序号字段名称123456rdapnoitiZhuyuan-registerZhuyuan-register病房管理员、病人日期和病案号数据类型允许唯一区别（精度范为空Y/N度围）Y/NChar(10)NY高Int(15)默认值约束条件/说明NYNNNN高低低低主码主空，引用病人表的外码gtirnorbeChar(10)NChar(10)NInt(15)Int(15)YY引用病房表的外码引用病床表的外码Mysql 脚本Create table Zhuyuan-register(rda char(10)primary key,Pno int(15)references patient(pno)not null,Iti char(10),Gti char(10),Rno int(15)references proom(rno),Rbe int(15)references pbed(rbe),)7.2.67.2.6表名数据库用户主键序号字段名称True-recordTrue-record病房管理员、医生治疗时间，病案号和医生编号数据类型（精允许唯区别度范围）为空一度默认值约束条件/说明123timepnodnoChar(8)Int(15)Int(15)Varchar(50)Y/NY/NNY高YYYY高高主码主码，引用病人表的外码主码，引用医生表的外码45trednoMysql 脚本YN低N低Create table True-record(time char(8)primary key,Pno int(15)references patient(pno),Dno int(15)references doctor(dno),tre varchar(50),mea varchar(200)Varchar(200)Y7.1.37.1.3 视图的设计视图的设计病人能看到的视图病人能看到的视图每个视图采用一张表格进行描述，其格式如下：数据库编号：Kf-001-2012视图编号：P-001-2012视图英文名称：patient视图中文名称：病历视图说明：病人可以看到入院出院日期，就医花费，且只能看到自己的部分Create view v_patientAsSelectpatient.pno,pname,rdate,ruyuandate,chuyuandate,rno,bedno,pafeeFrompatientjoinzhuyuan-recordonpatient.pno=zhuyuan-record.pno医生能看到的视图医生能看到的视图数据库编号：Kf-001-2012视图编号：D-002-2012视图英文名称：doctor视图中文名称：医生视图说明：医生可以看到工资，负责的病人的治疗概况，且只能看到自己的部分Create view v_doctorAsSelect doctor.dno,dname,dkeshi,dpay,pno,pail,zhiliaofanganFrom doctor join treat-gister on doctor.dno=treat-gister.dno系统管理员可以看到的视图系统管理员可以看到的视图数据库编号：Kf-001-2012视图编号：ALL-003-2012视图英文名称：all-data视图中文名称：全部数据视图说明：管理员可以看到医生病人的对应关系，病人缴纳费用，住院时间，所有医生工资，Create view v_all_dataAsSelectpatient.pno,pname,doctor.dno,dname,pafee,dpay,dkeshi,zhuyuandate,chuyuandate,paill,dateFrompatientjoinzhuyuan-recordjoinjointreat-gisterdoctoronononpatient.pno=zhuyuan-record.pnopatient.pno=treat-gister.pnotreat-gister.dno=doctor.dno7.1.47.1.4 触发器的设计及函数设计触发器的设计及函数设计1.录用（新键入）的医生的年龄必须在五十岁以下crate trigger p_ageon 医生 for insert,updateasif exists(select*from inserted where page50)beginprint医生年龄应小于五十rollbackend2.医生的最低工资应该大于 1300 元crate trigger doc_salary1on 医生 for insert,updateasif exists(select*from insertedwhere 最低工资23)beginprint病房号应小于 23rollbackendend8 8 安全设计安全设计8.1.18.1.1 安全防护安全防护对数据库存储敏感信息：针对本系统我们对用户密码进行加密，以保证各级用户对系统访问的安全性。生成的口令不可逆转（用 MD5 加密是一种 32 位字符的加密方法）。输入的口令不应显示在显示终端上。数据信息的保存：利用 RDBMS 的服务器稳定运行实现各种信息的储存、控制及调节备份、恢复等日常的维护管理工作。在软件园后期的项目中建立异地备份服务器后备份数据进行异地保存。8.1.28.1.2 操作跟踪操作跟踪针对系统运行出现的异常，跟踪调查出现异常的情况，了解操作意图，有针对性的解决问题。系统日志，便于查看系统的运行情况。操作日志,提供用户在系统中增加、修改系统数据信息时记录日志。用于跟踪用户的操作，了解信息的变更，在需要时对事情进行调查8.1.38.1.3 访问控制访问控制页面不可直接访问，防止黑客对页面篡改。页面访问通过连接动作驱动，访问时作权限检查。有效防止用户通过地址栏输入地址对信息非法访问。系统在页面执行过一次后再次访问通过缓冲工作区执行，对页面屏蔽。易用性医院管理系统要简单、易用，具有清晰的导航功能，使操作者快速找到自己想要执行的操作页面。医院管理系统要保证一个非计算机专业的用户，通过自己阅读用户手册，可以使用此系统。8.28.2 角色与权限角色与权限角色或者执行者（Actor）是指与系统产生交互的外部用户或者外部系统，本系统主要包括病人，医生，病房管理员和系统管理员等角色（Actor）。8.2.18.2.1 角色管理角色管理可以对单个角色进行添加、修改、删除和查询等维护操作，可以针对不同的角色选择对应的权限进行设置。用例描述：角色管理执行者：系统管理员前置条件：系统管理员已登录系统后置条件：角色信息维护后，相应信息记录到数据库中，以供帐号授权使用基本路径：a)进入角色管理界面，显示目前的角色列表；b)点击不同的角色，可以显示这个角色的信息以及相应权限，必要时可以修改其权限；c)可以增加、修改、删除角色。8.2.28.2.2 角色创建角色创建角色角色可以访问的表与列可以访问的表与列操作权限操作权限病人patient 表patient-room 表zhouyuan-record 表cure-gister 表查询查询查询查询医生doctor 表cure-gister 表查询查询查询，插入，删除病房管理员proom 表Patient 表查询，插入，删除Patient-bed 表查询，修改zhuyuan-record 表Cure-gister 表查询，修改查询，插入，修改，删除系统管理员Patient-room 表doctor 表patient 表Patient-bed 表Zhuyuan-record 表查询，插入，修改，删除查询，插入，修改，删除查询，插入，修改，删除查询，插入，修改，删除查询，插入，修改，删除cure-gister 表查询，插入，修改，删除8.38.3 应用级用户设计应用级用户设计应用级的用户账号密码不能与数据库想通，防止用户直接操作数据库。用户只能用账号登录到应用软件，通过应用软件访问数据库，而没用其他途径操作数据库。8.3.18.3.1 登录管理登录管理登录管理是负责所有用户的登录，用户要登录到综合信息管理平台必须经过登录界面，输入自己的用户名和密码，通过判断这个用户的权限信息，不同的登录人可能具有不同的权限，根据不同的权限现实不同的功能。8.3.28.3.2 用户管理用户管理当进入用户管理模块时，在用户管理中可以增加或删除用户，编辑用户名，用户密码，修改用户权限，具有不同权限的用户进入系统主界面，界面左侧栏中的图标数有所不同，具体的面标与用户所具有的权限对应。8.3.38.3.3 日志查询日志查询实现对用户的所有操作过程的历史日志查询。查询结果以列表方式显示，可以根据查询条件进行过滤。8.48.4 用户密码管理用户密码管理用户账号的密码必须进行加密处理，确保在任何地方的查询都不能出现密码的明文。用户帐号采用 MD5 进行数据加密后再录入数据库，以防止任何地方密码的安全性要求。8.58.5 防止用户直接操作数据库的方法防止用户直接操作数据库的方法建立应用程序角色，给角色相应的权限，然后应用程序以各自的用户登录就可以了（scott 是一个系统已经新建好的普通用户用户名scott，密码默认 tiger，默认状态是被定,DBA 用户执行 alter userscott account unlock;可以解锁登陆）8.68.6 性能测试性能测试8.6.18.6.1 性能需求性能需求根据用户对本系统的要求，确定系统在响应时间、可靠性、安全性等方面有较高的性能要求。8.6.28.6.2 界面需求界面需求系统的界面要求如下：）页面内容：主题突出，站点定义、术语和行文格式统一、规范、明确，栏目、菜单设置和布局合理，传递的信息准确、及时。内容丰富，文字准确，语句通顺；专用术语规范，行文格式统一规范。）导航结构：页面具有明确的导航指示，且便于理解，方便用户使用。）技术环境：页面大小适当，能用各种常用浏览器以不同分辨率浏览；无错误链接和空链接；采用 CSS 处理，控制字体大小和版面布局。）艺术风格：界面、版面形象清新悦目、布局合理,字号大小适宜、字体选择合理，前后一致，美观大方；动与静搭配恰当,动静效果好；色彩和谐自然,与主题内容相协调。8.6.38.6.3 响应时间需求响应时间需求无论是客户端和管理端，当用户登录，进行任何操作的时候，系统应该及时的进行反应，反应的时间在 5 秒以内。系统应能监测出各种非正常情况，如与设备的通信中断，无法连接数据库服务器等，避免出现长时间等待甚至无响应。8.6.48.6.4 可靠性需求可靠性需求系统应保证7X24内不当机，保证20人可以同时在客户端登录，系统正常运行，正确提示相关内容。8.6.58.6.5 开放性需求开放性需求系统应具有十分的灵活性，以适应将来功能扩展的需求。8.6.68.6.6 可扩展性需求可扩展性需求系统设计要求能够体现扩展性要求，以适应将来功能扩展的需求。8.6.78.6.7 系统安全性需求系统安全性需求系统有严格的权限管理功能，各功能模块需有相应的权限方能进入。系统需能够防止各类误操作可能造成的数据丢失，破坏，同时防止用户非法获取网页以及内容。8.78.7 优化优化数据库优化的目标无非是避免磁盘 I/O 瓶颈、减少 CPU 利用率和减少资源竞争。8.7.18.7.1 基于第三范式的基本表设计基于第三范式的基本表设计在基于表驱动的信息管理系统（MIS）中，基本表的设计规范是第三范式。第三范式的基本特征是非主属性只依赖于主属性。基于第三范式的数据库表设计具有很多优点：1.消除了冗余数据，节省了磁盘存储空间；2.有良好的数据完整性限制，即基于主外码的参照完整限制和基于主码的实体完整性限制，这使得数据容易维护，也容易移植和更新；3.数据的可逆性好，在做连接（Join）查询或者合并表时不遗漏、也不重复；4.因消除了冗余数据（冗余列），在查询（Select）时每个数据页存的数据行就多，这样就有效地减少了逻辑I/O，每个 Cash存的页面就多，也减少物理 I/O；5.对大多数事务(Transaction)而言，运行性能好；6.物理设计(Physical Design)的机动性较大，能满足日益增长的用户需求。在基本表设计中，表的主码、外码、索引设计占有非常重要的地位，现在从系统数据库优化角度讨论这些基本概念及其重要意义：（1）主码(Primary Key)：主码被用于复杂的 SQL 语句时，频繁地在数据访问中被用到。一个表只有一个主码。主码应该有固定值（不能为Null 或缺省值，要有相对稳定性），不含代码信息，易访问。把常用的列作为主码才有意义。短主码最佳（小于25bytes），主码的长短影响索引的大小，索引的大小影响索引页的大小，从而影响磁盘 I/O。主码分为自然主码和人为主码。自然主码由实体的属性构成，自然主码可以是复合性的，在形成复合主码时，主码列不能太多，复合主码使得 Join 操作复杂化、也增加了外码表的大小。人为主码是在没有合适的自然属性码、或自然属性复杂或灵敏度高时，人为形成的。人为主码一般是整型值（满足最小化要求），没有实际意义，也略微增加了表的大小；但减少了把它作为外码的表的大小。（2）外码（Foreign Key）：外码的作用是建立关系型数据库中表之间的关系（参照完整性），主码只能从独立的实体迁移到非独立的实体，成为后者的一个属性，被称为外码。（3）索引(Index)：利用索引优化系统性能是显而易见的，主要有以下几个方面：1.对所有常用于查询中的 Where 子句的列和所有用于排序的列创建索引，可以避免整表扫描或访问，在不改变表的物理结构的情况下，直接访问特定的数据列，从而减少数据存取时间；2.利用索引可以优化或排除耗时的分类操作，把数据分散到不同的页面上，就分散了插入的数据；3.主码自动建立了唯一索引，因此唯一索引也能确保数据的唯一性（即实体完整性）；4.索引码越小，定位就越直接；5.新建的索引效能最好，因此定期更新索引非常必要。索引也有代价：有空间开销，建立它也要花费时间，在进行Insert、Delete和 Update*作时，也有维护代价。索引有两种：聚族索引和非聚族索引。一个表只能有一个聚族索引，可有多个非聚族索引。使用聚族索引查询数据要比使用非聚族索引快。在建索引前，应利用数据库系统函数估算索引的大小。聚族索引（Clustered Index）：聚族索引的数据页按物理有序储存，占用空间小。选择策略是被用于 Where 子句的列：包括范围查询、模糊查询或高度重复的列（连续磁盘扫描）；被用于连接Join 操作的列；被用于 Order by 和 Group by 子句的列。聚族索引不利于插入操作，另外没有必要用主码建聚族索引。非聚族索引（Nonclustered Index）：与聚族索引相比，占用空间大，而且效率低。选择策略是，被用于Where 子句的列：包括范围查询、模糊查询（在没有聚族索引时）、主码或外码列、点（指针类）或小范围（返回的结果域小于整表数据的 20%）查询；被用于连接 Join操作的列、主码列（范围查询）；被用于Order by 和 Group by 子句的列；需要被覆盖的列。对只读表建多个非聚族索引有利。索引也有其弊端，一是创建索引要耗费时间，二是索引要占有大量磁盘空间，三是增加了维护代价（在修改带索引的数据列时索引会减缓修改速度）。（4）锁：锁是并行处理的重要机制，能保持数据并发的一致性，即按事务进行处理；系统利用锁，保证数据完整性。因此，我们避免不了死锁，但在设计时可以充分考虑如何避免长事务，减少排它锁时间，减少在事务中与用户的交互，杜绝让用户控制事务的长短；要避免批量数据同时执行，尤其是耗时并用到相同的数据表。锁的征用：一个表同时只能有一个排它锁，一个用户用时，其它用户在等待。若用户数增加，则 Server 的性能下降，出现“假死”现象。如何避免死锁呢？从页级锁到行级锁，减少了锁征用；给小表增加无效记录，从页级锁到行级锁没有影响，若在同一页内竞争有影响，可选择合适的聚族索引把数据分配到不同的页面；创建冗余表；保持事务简短；同一批处理应该没有网络交互。（5）查询优化规则：在访问数据库表的数据(Access Data)时，要尽可能避免排序（Sort）、连接(Join)和相关子查询*作。经验告诉我们，在优化查询时，必须做到：尽可能少的行；避免排序或为尽可能少的行排序，若要做大量数据排序，最好将相关数据放在临时表中*作；用简单的码（列）排序，如整型或短字符串排序；避免表内的相关子查询；避免在 Where 子句中使用复杂的表达式或非起始的子字符串、用长字符串连接；在 Where 子句中多使用“与”（And）连接，少使用“或”(Or)连接；利用临时数据库。在查询多表、有多个连接、查询复杂、数据要过滤时，可以建临时表（索引）以减少I/O。但缺点是增加了空间开销。除非每个列都有索引支持，否则在有连接的查询时分别找出两个动态索引，放在工作表中重新排序。8.7.38.7.3 基本表扩展设计基本表扩展设计基于第三范式设计的库表虽然有其优越性，然而在实际应用中有时不利于系统运行性能的优化：如需要部分数据时而要扫描整表，许多过程同时竞争同一数据，反复用相同行计算相同的结果，过程从多表获取数据时引发大量的连接操作，当数据来源于多表时的连接操作；这都消耗了磁盘 I/O 和 CPU 时间。尤其在遇到下列情形时，要对基本表进行扩展设计：许多过程要频繁访问一个表、子集数据