医院需求分析文档

医院管理系统医院管理系统 数据库设计说明书数据库设计说明书 (内部资料 请勿外传) 编编 写：写： 日日 期：期： 检检 查：查： 日日 期：期： 审审 核：核： 日日 期：期： 批批 准：准： 日日 期：期： ITIT 有机公司有机公司 版权所有版权所有 不得复制不得复制 文档编文档编 号号 Kf-0418-2012 版版 本本 A1 密密 级级 商商 密密 A 项目名项目名 称称 医院管理系统医院管理系统 ITIT 有机公司软件有机公司软件 开发事业部开发事业部 项目来项目来 源源 XXXXXXXx 目录目录 医院管理系统医院管理系统.1 数据库设计说明书数据库设计说明书.1 1引言引言.2 1.1编写目的.2 1.2术语表.2 1.3参考资料.3 2数据库环境说明数据库环境说明.3 3数据库的命名规则数据库的命名规则.3 4逻辑设计逻辑设计.3 5物理设计物理设计.4 5.1表汇总.4 5.2表X：XXX 表.4 5.3视图的设计.6 5.4存储过程、函数及触发器的设计.6 6安全性设计安全性设计.6 6.1防止用户直接操作数据库的方法.6 6.2用户帐号密码的加密方法.7 6.3角色与权限.7 7优化优化.7 8数据库管理与维护说明数据库管理与维护说明.7 1引言引言 1.1 编写目编写目的的 在完成了对医院各个部门的调查后,同时与多名病人进行了全面 深入地探讨和分析的基础上,提出了这份系统需求分析报告. 此需求分析报告对医院管理利通做了全面细致的用户需求分析， 明确所要开发的系统应具备的功能、性能与界面，使系统分析人员 及软件开发人员能清楚地了解用户的需求，并在此基础上进一步提 出概要设计说明书和完成后续设计与开发工作。此外，这份需求分 析报告中介绍了我们系统的框架结构，明确了该系统的方向及用途， 是客户了解我们系统的一份详细资料，本分析报告的预期读者为客 户、业务或需求分析人员、测试人员、用户文档编写者、项目管理 人员。 此分析报告是整个系统开发的依据，它对以后阶段的工作起指 导作用。本文也是项目完成后系统验收的依据。 1.2 术语表术语表 序号术语或缩略语说明性定义 1PaPatient 病人 2DoDoctor 医生 3PbPatient-bed 病床 4PrPatient-room 病房 5ZrZhuyuan-register 住院登记 6TrTrue-record 治疗记录 1.3 参考资料参考资料 资料名称资料名称作者作者文件编号、版本文件编号、版本资料存放地点资料存放地点 数据库原理及应用何玉洁机械工程出版社图书馆 SQL Server 使用教程范立南清华大学出版社图书馆 数据库应用技术张蒲生机械工业出版社图书馆 2.数据库环境说明数据库环境说明 2.1 网络逻辑结构网络逻辑结构 本次设计基于的网络逻辑结构是客户/服务器（C/S）体系结构。 它由三个主要部分构成：数据库服务器、客户应用程序和网络。基 于 C/S 的住院管理系统的结构示意图如图所示 2.2 软件支撑环境及开发工具软件支撑环境及开发工具 在 WINDOWS XP 操作系统下完成 包括应用程序的开发、数据库的设计以及设计报告的编写 应用的开发工具有： VC 程序设计语言 SQL Server 2000 Microsoft Office Word 2003 3.数据库的命名规则数据库的命名规则 3.1.1 此数据库完全按照 my sql 数据库设计规范命名。 表名命名依据英文单词全称。 列名命名依据整个列的属性取相应的英文缩写或拼音缩写 4.系统需求简介系统需求简介 4.1.1 总体需求简单介绍总体需求简单介绍 1 建立对医院全面管理的信息系统 2 对所有医生和病人进行管理 3 对所有部门的详细信息进行管理 4 对所有医生的详细信息进行管理 1系统的功能实现情况系统的功能实现情况: 用户可在本系统下实现各种用户要求的功能 2系统的安全性系统的安全性: 对于系统的重要数据都有密码保护，具有一定的安全性 对用户提供证书支持（此功能在后续版本中实现） 3 3系统的容错性系统的容错性: 用户输错数据都有提示信息，具有较好的容错性能。 4系统的封闭性系统的封闭性: 用户的封闭性较好，用户基本上在提示信息下输数据 4.1.2 数据字典数据字典 数据项数据项 数据结构数据结构 数据结构含义说明组成 病人定义了每个病人的有关信息 病案号，姓名，性别，地址， 电话号码，病房编号，医生 编号 医生定义了每个医生的有关信息 医生编号，姓名，性别，职 称，电话号码，部门，月工 资 病房定义了每个病房的有关信息 病房编号，地点，收费标准， 所属部门 病床定义了每个病床的有关信息病房编号，病床号 数据项含义说明类型长度取值范围取值含义 与其他数据项的逻辑 关系 病案号 唯一标识每 个病人 字符型150000 至 9999 前两位标明 该病人所挂 诊的部门， 后十三位按 顺序编号 与住院登记，治疗记录用此数 据项相联系 医生编号 唯一标识每 个医生 字符型10至 前两位表示 所属部门， 后八位按顺 序编号 与治疗记录用此数据项相联系 病房编号 唯一标识每 个病房 字符型40001 至 9999 前两位表示 所属部门， 后两位按顺 序编号 与病床，住院登记用此数据相 联系 床位号 唯一标识每 个病床 字符型3001 至 999 前两位表示 所属病房， 后两位按顺 序编号 引用病房主码做病床表的外码， 与住院登记用此数据相联系 日期，病案 号 唯一标识每 个住院登记 DATE,字 符型 10,15 日期的取值范围， 病案号引用病人 表的主码 表示每个住 院登记的记 录 联系病人和住院登记 病案号，医 生编号 唯一标识每 个治疗记录 字符型15，10 病案号引用病人 表的主码，医生 编码引用医生表 的主码 表示每个治 疗记录的情 况 联系病人和医生 住院登记定义了每个住院登记的有关信息 日期，病案号，入院日期， 出院日期，病房编号，床位 号，住院费用 数据流数据流 数据流： 病人诊断情况 说明： 病人病情的最终结果 数据流来源：病人 数据流去向：医生 组成： 病人，住院登记，治疗记录 平均流量：每天几百人 高峰期流量：每天几千人 数据存储数据存储 数据存储： 病人入院登记 说明： 记录病人的基本情况 流入数据流：住院登记 流出数据流：住院登记 组成： 病人，医生，住院登记，治疗记录 数据量： 每天几百张 存取频度：每人一次 存取方式： 随机存取 处理逻辑处理逻辑 处理名称：生成病人就医情况总表 说明：说明处理过程 输入数据流：病人，治疗记录 输出数据流：住院登记 处理逻辑：记录病人诊治记录，形成治疗记录，汇总成病人住院 登记，再生成总表 平均执行频率：每天几百次 （说明：以上平均频率需长期观察得到） 数据流图图元数据流图图元 4.1.3 系统功能设想系统功能设想 这里的功能划分，是根据第一阶段需求调查基础上进行的初步划 分。随着需求调查的深入，功能模块随着对需求了解的明确得到调 整。 医院管理系统的四个主要部分,可以将系统应用程序划分为对应 的 4 个子模块:包括医生管理系统,病人管理系统,病房管理系统,科室 管理系统. 根据各业务子系统所包括业务内容,还可以将各个子系统 继续细化划分为更小的功能模块。划分的准则主要遵循模块的内聚 性要求和模块间的低聚合性。如图所示表示一个医院管理系统功能 模块结构图。 医生病人诊治 医生 编 号 医生 属 性 病案 号 病人 属 性 应用系统 医生管理病人管理病房管理系统管理 治疗病人 信息 医生的详细信 息 病人的详细 信息 各科室医生及 病人信息 所有部门科室 信息 住院信息 4.1.4 业务流程分析业务流程分析 简单医院流程图简单医院流程图 收 费 单 请 住 院 单 请 住院申请病人信息 图图 4-1 入院数据流图入院数据流图 病人 查看 信 息 病人病案 病人 分配 床 位 病房信息 产生收费 单及住院 单 治疗方案出示病历病人 医生 诊 断 病人病历 病人检查情况 给出治 疗方案 方 案 病人 图图 4-2 治疗数据流图治疗数据流图 申请出院缴费单病人 病人病案 收费准则 病历 归 档 费用 统 计 病人 图图 4-3 出院数据流图出院数据流图 5.概念设计概念设计 5.1.1 实体实体 病房（病房编号，地点，收费标准，所属科室） 病床（病房编号，床位号） 病人（病案号，姓名，性别，地址，电话号码，病房编号，医 生编号） 医生（医生编号，姓名，性别，职称，电话号码，部门，工资） 住院登记（日期，病案号，入院时间，出院时间，病房编号， 床位号，住院费用） 治疗记录（治疗时间，病案号，医生编号，诊断，治疗方案） 5.1.2 系统局部系统局部 ER 图图 n 人 1 人 医生病人 治疗 诊断 治疗方案 图图 4-8 病人与医生联系图病人与医生联系图 治疗时间 n 人 1 人 拥有 病房病床 病房 n 人 1 人 住在 病人 图图 4-9 病人与病房及病房与病床联系图病人与病房及病房与病床联系图 n1 病人住院登记 登记 5.1.3 系统全局系统全局 ER 图图 出院时间 病房病房 地点 收费标准 所属部门 病房编号 n 1 1 n 1 病房编号 床位号 治疗时间 部门 电话号码 职称 性别 姓名 医生编号 图图 4-11 医院住院数据库基本医院住院数据库基本 E-R 图图 n n 1 n 1 病床病床 病人病人 医生医生 病案号 姓名 性别 地址 电话号码 病房编号 病案号 病房编号 床位号 诊断 日期 入院时间 治疗方案 治 疗 住在 住院登记住院登记 拥有 登记 分配 医生编号 住院费用 工资 6.逻辑设计逻辑设计 6.1.1 E-R 图到关系模式转换图到关系模式转换 按照上述的原则，根据设计好的 E-R 图，可以将其转换为以下 一组关系模式，其中关系模式的码用下横线标出。 将 E-R 图中 1:1 的联系与任意一端所对应的关系模式合并。 将 E-R 图中 1：n 的联系与 n 端所对应的关系模式合并，如：将 “病床”这一联系并到“病房”关系模式； 将 E-R 图中 m:n 的联系转换为一个独立的关系模式。 病房（病房（病房编号病房编号，地点，收费标准，所属科室），地点，收费标准，所属科室） 此为病房实体型所对应的关系模式。其中病房编号唯一确定一 个病房，所以为该关系模式的码。 病床（病床（病房编号，床位号病房编号，床位号） 此为病床实体型所对应的关系模式。由于病房编号是病房关系 模式的码，所以在该关系模式中病房编号为外码。 病人（病人（病案号病案号，姓名，性别，地址，电话号码，病房编号，姓名，性别，地址，电话号码，病房编号， 医生编号）医生编号） 此为病人实体型所对应的关系模式。其中病案号为此关系模式 的码，而病房编号，医生编号 为该关系模式的外码。 医生（医生（医生编号医生编号，姓名，性别，职称，电话号码，部门，工，姓名，性别，职称，电话号码，部门，工 资）资） 此为医生实体型所对应的关系模式。其中医生编号唯一确定一 个医生，所以为该关系模式的码。 住院登记（住院登记（日期，病案号日期，病案号，入院时间，出院时间，病房编号，入院时间，出院时间，病房编号， 床位号）床位号） 此为住院登记实体型所对应的关系模式。其中，日期和病案号 共同确定一个住院登记，病房编号为该关系模式的外码。 治疗记录（治疗记录（治疗时间，病案号，医生编号治疗时间，病案号，医生编号，诊断，治疗方案），诊断，治疗方案） 此为联系“治疗”所对应的关系模式。其中，病案号和医生编号 都是该关系模式的外码。 6.1.2 各个数据表的表结构设计各个数据表的表结构设计 PatientPatient 的数据项描述的数据项描述： 数据项名数据项含义类型长度备注 病案号病人的编号 (pno) int15对应唯一一个病人 姓名病人姓名 (pname) Char20 性别病人性别 (psex) char2只能取男或 女 地址病人住址 (paddr) varchar100 电话病人电话 (ptel) smallint10 病房编号病人病房 （pro） char4住院时由系统分配 医生编号主治医生 （ppno） int15 一位病人只能对应一 位主治医生 Patient-roomPatient-room 的数据项描述的数据项描述： 数据项名数据项含义类型长度备注 编号病房编号 (rno) Int15病房编号唯一 地点病房位置 (radd) char20非空 收费标准住院收费 （rcha） INT15单位为（元/天） 所属部门病房所属部门 （rbu） vaechar20一间病房只能属于一 个部门 Patient-bedPatient-bed 的数据项描述的数据项描述： 数据项名数据项含义类型长度备注 病房编号病房编号 （rno） int15唯一确定，引用病房 的外码 床位号病房床位 （rbe） int15唯一确定，一个病房 一般有 1-3 个床位 DoctorDoctor 的数据项描述：的数据项描述： 数据项名数据项含义类型长度备注 编号医生编号 (dno) int15对应唯一一个医生 姓名医生姓名 (dname) char20非空 性别医生性别 (dsex) char2只能取男或 女 职称医生职称 (dzhi) varchar20有可能有多个职称 电话医生电话 (dtel) smallint10 部门所属部门 (dbu) varchar20 工资医生工资 （dsa） int20 Zhuyuan-registerZhuyuan-register 的数据项描述：的数据项描述： 数据项名数据项名数据项含义数据项含义类型类型长度长度备注备注 日期登记日期 (rad) char10唯一标识 病案号病案号 （pno） int15唯一标识，引用病人 外码 入院时间入院时间 （iti） char10 出院时间出院时间 （gti） char10必须在入院时间之后 病房编号病房号 （rno） int15引用病房表的外码 病床编号病床号 （rbe0 int15引用病床表的外码 True-recordTrue-record 的数据项描述的数据项描述： 数据项名数据项名数据项含义数据项含义类型类型长度长度备注备注 时间治疗日期 (time) char8入院和出院时间之间, 唯一标识 病案号病案号 （pno） int15唯一标识，引用病人 外码 医生编号主治医生 （dno） Int15唯一标志，引用医生 外码 诊断病情诊断 （tre） VARCHAR50医生诊断结果 治疗方案治疗方案 （mea） VARCHAR200医生给出的治疗方案 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 区别度默认值约束条件/说明 1pnoInt(15)NY 高主码 2pnameChar(20)NN 中 3psexChar(2)YN 低男必须是“男”或 者“女” 4paddVarchar(100)YN 中 5ptelSmallint(10)YN 中 6proChar(4)NN 低 7ppnoInt(15)YN 低一位病人只能对 应一位主治医生 的医生编号（引 用医生表中的医 生编号外码） Mysql 脚本 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/N 区别 度 默认 值 约束条件/说明 1dnoint(15)NY 高主码 2dnameChar(20)NN 中 3dsexChar(2)YN 中男必须是“男”或 者“女” 4dzhiVarchar(20 ) NN 低 5dtelSmallint(10)YN 中 6dbuVarchar(20 ) NN 低 7dsaInt(20)YN 低 Mysql 脚本 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 表名 proom 数据库用户病房管理员、病人 主键病房编号 其他排序字段地点，收费标准，所属部门 索引字段病房编号 序号字段名称数据类型 （精度范 围） 允许 为空 Y/N 唯一 Y/N 区别 度 默认 值 约束条件/说明 1rnoInt(15)NY 高主码 2raddChar(20)NN 中非空 3 rchaInt(15) YN 低 4 rbum Varchar( 20) NN 低 Mysql 脚本 Create table proom （rno int(15) primary key, Radd char(20) not null, Rcha int(15), Rbum varchar(20), ) 7.2.47.2.4 表名 pbedpbed 数据库用户病房管理员 主键病房编号和床位号 序号字段名 称 数据类型 （精度范 围） 允许 为空 Y/N 唯一 Y/N 区别 度 默认 值 约束条件/说明 1 rnoInt(15) NY 高主码，引用 proom 的外码 2 rbeInt(15) NY 高主码 Mysql 脚本 Create table pbed (rno int(15) references proom(床位号) Rbe int(15) primary key) 7.2.57.2.5 表名 Zhuyuan-register 数据库用户病房管理员、病人 主键日期和病案号 序号字段名 称 数据类型 （精度范 围） 允许 为空 Y/N 唯一 Y/N 区别 度 默认 值 约束条件/说明 1rda Char(10) NY 高主码 2pno Int(15) NY 高主空 ，引用病 人表的外码 3iti Char(10) NN 低 4gti Char(10) NN 低 5rno Int(15) YN 低 引用病房表的 外码 6rbe Int(15) YN 引用病床表的 外码 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-record 数据库用户病房管理员、医生 主键治疗时间，病案号和医生编号 序号字段名 称 数据类型（精 度范围） 允许 为空 唯 一 区别 度 默认 值 约束条件/说明 Y/NY/ N 1 timeChar(8) NY 高主码 2 pnoInt(15) YY 高主码，引用病 人表的外码 3 dnoInt(15) YY 高主码，引用医 生表的外码 4 treVarchar(50) YN 低 5 dnoVarchar(200) YN 低 Mysql 脚本 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) ) 7.1.37.1.3 视图的设计视图的设计 病人能看到的视图病人能看到的视图 每个视图采用一张表格进行描述，其格式如下： 数据库编号：Kf-001-2012 视图编号：P-001-2012 视图英文名称：patient 视图中文名称：病历 视图说明：病人可以看到入院出院日期，就医花费，且只能看到自 己的部分 Create view v_patient As Select patient.pno,pname,rdate,ruyuandate,chuyuandate,rno,bedno,pafee From patient join zhuyuan-record on patient.pno=zhuyuan-record.pno 医生能看到的视图医生能看到的视图 数据库编号：Kf-001-2012 视图编号：D-002-2012 视图英文名称：doctor 视图中文名称：医生 视图说明：医生可以看到工资，负责的病人的治疗概况，且只能看 到自己的部分 Create view v_doctor As Select doctor.dno,dname,dkeshi,dpay,pno,pail,zhiliaofangan From doctor join treat-gister on doctor.dno=treat-gister.dno 系统管理员可以看到的视图系统管理员可以看到的视图 数据库编号：Kf-001-2012 视图编号：ALL-003-2012 视图英文名称：all-data 视图中文名称：全部数据 视图说明：管理员可以看到医生病人的对应关系，病人缴纳费用， 住院时间，所有医生工资， Create view v_all_data As Select patient.pno,pname,doctor.dno,dname,pafee,dpay,dkeshi,zhuyuandate,chu yuandate,paill,date From patient join zhuyuan-record on patient.pno=zhuyuan-record.pno join treat-gister on patient.pno=treat-gister.pno join doctor on treat- gister.dno=doctor.dno 7.1.47.1.4 触发器的设计及函数设计触发器的设计及函数设计 1.录用（新键入）的医生的年龄必须在五十岁以下 crate trigger p_age on 医生 for insert,update as if exists(select * from inserted where page50) begin print医生年龄应小于五十 rollback end 2.医生的最低工资应该大于 1300 元 crate trigger doc_salary1 on 医生 for insert,update as if exists (select * from inserted where 最低工资23) begin print病房号应小于 23 rollback end end 8 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.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.2 用户管理用户管理 当进入用户管理模块时，在用户管理中可以增加或删除用 户，编辑用户名，用户密码，修改用户权限，具有不同权限的用 户进入系统主界面，界面左侧栏中的图标数有所不同，具体的面 标与用户所具有的权限对应。 8.3.3 日志查询日志查询 实现对用户的所有操作过程的历史日志查询。查询结果以列 表方式显示，可以根据查询条件进行过滤。 8.48.4 用户密码管理用户密码管理 用户账号的密码必须进行加密处理，确保在任何地方的查询都 不能出现密码的明文。 用户帐号采用 MD5 进行数据加密后再录入数据库，以防止任何地 方密码的安全性要求。 8.58.5 防止用户直接操作数据库的方法防止用户直接操作数据库的方法 建立应用程序角色，给角色相应的权限，然后应用程序以各自 的用户登录就可以了（scott 是一个系统已经新建好的普通用户用户 名 scott，密码默认 tiger，默认状态是被定,DBA 用户执行 alter user scott account unlock;可以解锁登陆） 8.6 性能测试性能测试 8.6.1 性能需求性能需求 根据用户对本系统的要求，确定系统在响应时间、可靠性、 安全性等方面有较高的性能要求。 8.6.2 界面需求界面需求 系统的界面要求如下： ）页面内容：主题突出，站点定义、术语和行文格式统 一、规范、明确，栏目、菜单设置和布局合理，传递的信息 准确、及时。内容丰富，文字准确，语句通顺；专用术语规 范，行文格式统一规范。 ）导航结构：页面具有明确的导航指示，且便于理解，方 便用户使用。 ）技术环境：页面大小适当，能用各种常用浏览器以不同 分辨率浏览；无错误链接和空链接；采用 CSS 处理，控制字体大 小和版面布局。 ）艺术风格：界面、版面形象清新悦目、布局合理,字号大 小适宜、字体选择合理，前后一致，美观大方；动与静搭配恰当,动 静效果好；色彩和谐自然,与主题内容相协调。 8.6.3 响应时间需求响应时间需求 无论是客户端和管理端，当用户登录，进行任何操作的时候， 系统应该及时的进行反应，反应的时间在 5 秒以内。系统应能监 测出各种非正常情况，如与设备的通信中断，无法连接数据库服 务器等，避免出现长时间等待甚至无响应。 8.6.4 可靠性需求可靠性需求 系统应保证 7X24 内不当机，保证 20 人可以同时在客户端登 录，系统正常运行，正确提示相关内容。 8.6.5 开放性需求开放性需求 系统应具有十分的灵活性，以适应将来功能扩展的需求。 8.6.6 可扩展性需求可扩展性需求 系统设计要求能够体现扩展性要求，以适应将来功能扩展的需求。 8.6.7 系统安全性需求系统安全性需求 系统有严格的权限管理功能，各功能模块需有相应的权限方能进 入。系统需能够防止各类误操作可能造成的数据丢失，破坏，同时 防止用户非法获取网页以及内容。 8.78.7 优化优化 数据库优化的目标无非是避免磁盘 I/O 瓶颈、减少 CPU 利用率 和减少资源竞争。 8.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.3 基本表扩展设计基本表扩展设计 基于第三范式设计的库表虽然有其优越性，然而在实际应用中 有时不利于系统运行性能的优化：如需要部分数据时而要扫描整表， 许多过程同时竞争同一数据，反复用相同行计算相同的结果，过程 从多表获取数据时引发大量的连接操作，当数据来源于多表时的连 接操作；这都消耗了磁盘 I/O 和 CPU 时间。 尤其在遇到下列情形时，要对基本表进行扩展设计：许多过程 要频繁访问一个表、子集数据访问、重复计算和冗余数据，有时用 户要求一些过程优先或低的响应时间。 根据访问的频繁程度对相关表进行分割处理、存储冗余数据、 存储衍生列、合并相关表处理，这些都是克服这些不利因素和优化 系统运行的有效途径。 8.7.4 存储衍生数据存储衍生数据 对一些要做大量重复性计算的过程而言，若重复计算过程得到 的结果相同（源列数据稳定，因此计算结果也不变），或计算牵扯 多行数据需额外的磁盘 I/O 开销，或计算复杂需要大量的 CPU 时间， 就考虑存储计算结果（冗余储存）。现予以分类说明： 若在一行内重复计算，就在表内增加列存储结果。但若参与计 算的列被更新时，