医院需求分析文档.doc

IT有机公司软件开发事业部
文档编号
Kf-0418-2012
版本
A1
密级
商密A
项目名称
医院管理系统
项目来源
XXXXXXXx

医院管理系统
数据库设计说明书
(内部资料 请勿外传)
编 写：

日 期：

检 查：

日 期：

审 核：

日 期：

批 准：

日 期：

IT有机公司
版权所有 不得复制

目录
医院管理系统 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术语表
序号
术语或缩略语
说明性定义
1
Pa
Patient病人
2
Do
Doctor医生
3
Pb
Patient-bed病床
4
Pr
Patient-room病房
5
Zr
Zhuyuan-register住院登记
6
Tr
True-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．系统的容错性:
用户输错数据都有提示信息，具有较好的容错性能。
4．系统的封闭性:

用户的封闭性较好，用户基本上在提示信息下输数据
4.1.2数据字典
§数据项
数据项
含义说明
类型
长度
取值范围
取值含义
与其他数据项的逻辑关系
病案号
唯一标识每个病人
字符型
15
000000000000000至999999999999999
前两位标明该病人所挂诊的部门，后十三位按顺序编号
与住院登记，治疗记录用此数据项相联系
医生编号
唯一标识每个医生
字符型
10
0000000001至9999999999
前两位表示所属部门，后八位按顺序编号
与治疗记录用此数据项相联系
病房编号
唯一标识每个病房
字符型
4
0001至9999
前两位表示所属部门，后两位按顺序编号
与病床，住院登记用此数据相联系
床位号
唯一标识每个病床
字符型
3
001至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系统局部E—R图

n人
1人
医生
病人
治疗
诊断
治疗方案
图4-8 病人与医生联系图
治疗时间

n人
1人
拥有
病房
病床
病房
n人
1人
住在
病人
图4-9 病人与病房及病房与病床联系图

n
1
病人
住院登记
登记
5.1.3系统全局E—R图
出院时间
病房
地点
收费标准
所属部门
病房编号
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各个数据表的表结构设计

Patient的数据项描述：

数据项名
数据项含义
类型
长度
备注
病案号
病人的编号(pno)
int
15
对应唯一一个病人
姓名
病人姓名(pname)
Char
20

性别
病人性别(psex)
char
2
只能取‘男’或‘女’
地址
病人住址(paddr)
varchar
100

电话
病人电话(ptel)
smallint
10

病房编号
病人病房
（pro）
char
4
住院时由系统分配
医生编号
主治医生
（ppno）
int
15
一位病人只能对应一位主治医生

Patient-room的数据项描述：

数据项名
数据项含义
类型
长度
备注
编号
病房编号
(rno)
Int
15
病房编号唯一
地点
病房位置(radd)
char
20
非空
收费标准
住院收费
（rcha）
INT
15
单位为（元/天）
所属部门
病房所属部门
（rbu）
vaechar
20
一间病房只能属于一个部门

Patient-bed的数据项描述：

数据项名
数据项含义
类型
长度
备注
病房编号
病房编号
（rno）
int
15
唯一确定，引用病房的外码
床位号
病房床位
（rbe）
int
15
唯一确定，一个病房一般有1-3个床位

Doctor的数据项描述：

数据项名
数据项含义
类型
长度
备注
编号
医生编号
(dno)
int
15
对应唯一一个医生
姓名
医生姓名
(dname)
char
20
非空
性别
医生性别
(dsex)
char
2
只能取‘男’或‘女’
职称
医生职称
(dzhi)
varchar
20
有可能有多个职称
电话
医生电话
(dtel)
smallint
10

部门
所属部门
(dbu)
varchar
20

工资
医生工资
（dsa）
int
20

Zhuyuan-register的数据项描述：

数据项名
数据项含义
类型
长度
备注
日期
登记日期
(rad)
char
10
唯一标识
病案号
病案号
（pno）
int
15
唯一标识，引用病人外码
入院时间
入院时间
（iti）
char
10

出院时间
出院时间
（gti）
char
10
必须在入院时间之后
病房编号
病房号
（rno）
int
15
引用病房表的外码
病床编号
病床号
（rbe0
int
15
引用病床表的外码

True-record的数据项描述：

数据项名
数据项含义
类型
长度
备注
时间
治疗日期(time)
char
8
入院和出院时间之间,唯一标识
病案号
病案号
（pno）
int
15
唯一标识，引用病人外码
医生编号
主治医生
（dno）
Int
15
唯一标志，引用医生外码
诊断
病情诊断
（tre）
VARCHAR
50
医生诊断结果
治疗方案
治疗方案
（mea）
VARCHAR
200
医生给出的治疗方案

7、物理设计
7.1表汇总
表名
功能说明
表Patient
病人表，属性列有病案号、姓名、性别、地址、电话、病房编号、医生编号。主码是病案号，外码是医生编号。病人可以查看关于自己的属性列及住院信息。
表Doctor
医生表，属性有医生编号、姓名、性别、职称、电话号码、部门。医生编号是主码。医生可以查看自己的属性列及病人病情状况。
表Patient-room
病房表，属性列有病房编号、地点、收费标准、所属科室。病房编号是主码。病房表的创建便于医生查看治疗病人的住院地点、便于病人明确自己的收费标准。
表Patient-bed
病床表，主码为病房编号和床位号。外码为病房编号。此表方便病房管理员进一步掌握各病人的详细床位信息。
表True-register
治疗记录表，治疗时间、病案号、医生编号共同为主码。此表由病房管理员对于每一位住院的病人进行分配登记。医生查询此表可以了解所医治病人的诊断信息并提出治疗方案。
表Zhuyuan-register
住院登记表，主码为日期和病案号，属性列有入院时间、出院时间、病房编号、床位号。外码为病案号、病房编号、床位号。

7.2表[]
7.2.1

表名
Patient
数据库用户
病人
主键
病案号
其他排序字段
病人姓名，性别，地址，电话号码，病房编号，医生编号
索引字段
病案号
序号
字段名称
数据类型（精度范围）
允许为空Y/N
唯一Y/N
区别度
默认值
约束条件/说明
1
pno
Int(15)
N
Y
高

主码
2
pname
Char(20)
N
N
中

3
psex
Char(2)
Y
N
低
男
必须是“男”或者“女”
4
padd
Varchar(100)
Y
N
中

5
ptel
Smallint(10)
Y
N
中

6
pro
Char(4)
N
N
低

7
ppno
Int(15)
Y
N
低

一位病人只能对应一位主治医生的医生编号（引用医生表中的医生编号外码）
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.2
表名
Doctor
数据库用户
医生
主键
医生编号
其他排序字段
医生姓名，性别，职称，电话，部门，工资
索引字段
医生编号
序号
字段名称
数据类型（精度范围）
允许为空Y/N
唯一Y/N
区别度
默认值
约束条件/说明
1
dno
int(15)
N
Y
高

主码
2
dname
Char(20)
N
N
中

3
dsex
Char(2)
Y
N
中
男
必须是“男”或者“女”
4
dzhi
Varchar(20)
N
N
低

5
dtel
Smallint(10)
Y
N
中

6
dbu
Varchar(20)
N
N
低

7
dsa
Int(20)
Y
N
低

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.3

表名
proom
数据库用户
病房管理员、病人
主键
病房编号
其他排序字段
地点，收费标准，所属部门
索引字段
病房编号
序号
字段名称
数据类型（精度范围）
允许为空Y/N
唯一Y/N
区别度
默认值
约束条件/说明
1
rno
Int(15)
N
Y
高

主码
2
radd
Char(20)
N
N
中

非空
3
rcha
Int(15)
Y
N
低

4
rbum
Varchar(20)
N
N
低

Mysql脚本
Create table proom
（rno int(15) primary key,
Radd char(20) not null,
Rcha int(15),
Rbum varchar(20),
)

7.2.4

表名
pbed
数据库用户
病房管理员
主键
病房编号和床位号
序号
字段名称
数据类型（精度范围）
允许为空Y/N
唯一Y/N
区别度
默认值
约束条件/说明
1
rno
Int(15)
N
Y
高

主码，引用proom的外码
2
rbe
Int(15)
N
Y
高

主码
Mysql脚本
Create table pbed
(rno int(15) references proom(床位号)
Rbe int(15) primary key)
7.2.5

表名
Zhuyuan-register
数据库用户
病房管理员、病人
主键
日期和病案号
序号
字段名称
数据类型（精度范围）
允许为空Y/N
唯一Y/N
区别度
默认值
约束条件/说明
1
rda
Char(10)
N
Y
高

主码
2
pno
Int(15)
N
Y
高

主空 ，引用病人表的外码
3
iti
Char(10)
N
N
低

4
gti
Char(10)
N
N
低

5
rno
Int(15)
Y
N
低

引用病房表的外码
6
rbe
Int(15)
Y
N

引用病床表的外码
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.6
表名
True-record
数据库用户
病房管理员、医生
主键
治疗时间，病案号和医生编号
序号
字段名称
数据类型（精度范围）
允许为空Y/N
唯一Y/N
区别度
默认值
约束条件/说明
1
time
Char(8)
N
Y
高

主码
2
pno
Int(15)
Y
Y
高

主码，引用病人表的外码
3
dno
Int(15)
Y
Y
高

主码，引用医生表的外码
4
tre
Varchar(50)
Y
N
低

5
dno
Varchar(200)
Y
N
低

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.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,chuyuandate,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.4触发器的设计及函数设计
1.录用（新键入）的医生的年龄必须在五十岁以下
crate trigger p_age
on 医生 for insert,update
as
if exists(select * from inserted
where page〉50)
begin
print’医生年龄应小于五十’
rollback
end

2.医生的最低工资应该大于1300元
crate trigger doc_salary1
on 医生 for insert,update
as
if exists (select * from inserted
where ‘最低工资<1300)
begin
print’最低工资应大于1300’
rollback
end

3.病房里的病房号必须小于23
crate trigger room_rno
on 病房号 for insert,update
as
if exists(select * from inserted,
where ‘rno>23’)
begin
print’病房号应小于23’
rollback
end
end
8安全设计
8.1.1安全防护
·对数据库存储敏感信息：
针对本系统我们对用户密码进行加密，以保证各级用户对系统访问的安全性。生成的口令不可逆转（用MD5加密是一种32位字符的加密方法）。输入的口令不应显示在显示终端上。
·数据信息的保存：
利用RDBMS的服务器稳定运行—实现各种信息的储存、控制及调节备份、恢复等日常的维护管理工作。在软件园后期的项目中建立异地备份服务器后备份数据进行异地保存。
8.1.2操作跟踪
针对系统运行出现的异常，跟踪调查出现异常的情况，了解操作意图，有针对性的解决问题。
系统日志，便于查看系统的运行情况。
操作日志, 提供用户在系统中增加、修改系统数据信息时记录日志。用于跟踪用户的操作，了解信息的变更，在需要时对事情进行调查
8.1.3访问控制
·页面不可直接访问，防止黑客对页面篡改。页面访问通过连接动作驱动，访问时作权限检查。有效防止用户通过地址栏输入地址对信息非法访问。系统在页面执行过一次后再次访问通过缓冲工作区执行，对页面屏蔽。
易用性
·医院管理系统要简单、易用，具有清晰的导航功能，使操作者快速找到自己想要执行的操作页面。
·医院管理系统要保证一个非计算机专业的用户，通过自己阅读用户手册，可以使用此系统。

8.2角色与权限
角色或者执行者（Actor）是指与系统产生交互的外部用户或者外部系统，本系统主要包括病人，医生，病房管理员和系统管理员等角色（Actor）。
8.2.1角色管理

可以对单个角色进行添加、修改、删除和查询等维护操作，可以针对不同的角色选择对应的权限进行设置。
用例描述：角色管理
执行者：系统管理员
前置条件：系统管理员已登录系统
后置条件：角色信息维护后，相应信息记录到数据库中，以供帐号授权使用
基本路径：
a) 进入角色管理界面，显示目前的角色列表；
b) 点击不同的角色，可以显示这个角色的信息以及相应权限，必要时可以修改其权限；
c) 可以增加、修改、删除角色。
8.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.3应用级用户设计
应用级的用户账号密码不能与数据库想通，防止用户直接操作数据库。用户只能用账号登录到应用软件，通过应用软件访问数据库，而没用其他途径操作数据库。
8.3.1登录管理
登录管理是负责所有用户的登录，用户要登录到综合信息管理平台必须经过登录界面，输入自己的用户名和密码，通过判断这个用户的权限信息，不同的登录人可能具有不同的权限，根据不同的权限现实不同的功能。
8.3.2 用户管理
当进入用户管理模块时，在用户管理中可以增加或删除用户，编辑用户名，用户密码，修改用户权限，具有不同权限的用户进入系统主界面，界面左侧栏中的图标数有所不同，具体的面标与用户所具有的权限对应。
8.3.3 日志查询
实现对用户的所有操作过程的历史日志查询。查询结果以列表方式显示，可以根据查询条件进行过滤。
8.4用户密码管理
用户账号的密码必须进行加密处理，确保在任何地方的查询都不能出现密码的明文。
用户帐号采用MD5进行数据加密后再录入数据库，以防止任何地方密码的安全性要求。
8.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.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. 利用索引可以优化或排除耗时的分类操作，把数据分散到不同的页面上，就分散了插入的数据