医院需求分析文档

IT有机公司软件开发事业部文档编号Kf-0418-2012版本A1密级商密A项目名称医院管理系统项目来源XXXXXXXx医院管理系统数据库设计说明书(内部资料 请勿外传)编 写： 日 期：检 查：日 期：审 核：日 期：批 准：日 期：IT有机公司版权所有 不得复制目录医院管理系统1数据库设计说明书11引言21.1编写目的21.2术语表21.3参考资料32数据库环境说明33数据库的命名规则34逻辑设计35物理设计45.1表汇总45.2表X：XXX表45.3视图的设计65.4存储过程、函数及触发器的设计66安全性设计66.1防止用户直接操作数据库的方法66.2用户帐号密码的加密方法76.3角色与权限77优化78数据库管理与维护说明71引言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 20033.数据库的命名规则3.1.1 此数据库完全按照 my sql数据库设计规范命名。表名命名依据英文单词全称。列名命名依据整个列的属性取相应的英文缩写或拼音缩写4.系统需求简介4.1.1总体需求简单介绍1 建立对医院全面管理的信息系统2 对所有医生和病人进行管理3 对所有部门的详细信息进行管理4 对所有医生的详细信息进行管理1系统的功能实现情况: 用户可在本系统下实现各种用户要求的功能2系统的安全性: 对于系统的重要数据都有密码保护，具有一定的安全性 对用户提供证书支持（此功能在后续版本中实现）3系统的容错性: 用户输错数据都有提示信息，具有较好的容错性能。4系统的封闭性: 用户的封闭性较好，用户基本上在提示信息下输数据4.1.2数据字典数据项数据项含义说明类型长度取值范围取值含义与其他数据项的逻辑关系病案号唯一标识每个病人字符型15000000000000000至999999999999999前两位标明该病人所挂诊的部门，后十三位按顺序编号与住院登记，治疗记录用此数据项相联系医生编号唯一标识每个医生字符型100000000001至9999999999前两位表示所属部门，后八位按顺序编号与治疗记录用此数据项相联系病房编号唯一标识每个病房字符型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图出院时间病房地点收费标准所属部门病房编号n11n1病房编号床位号治疗时间部门电话号码职称性别姓名医生编号图4-11 医院住院数据库基本E-R图nn1n1病床病人医生病案号姓名性别地址电话号码病房编号病案号病房编号床位号诊断日期入院时间治疗方案治疗住在住院登记拥有登记分配医生编号住院费用工资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)int15对应唯一一个病人姓名病人姓名(pname)Char20性别病人性别(psex)char2只能取男或女地址病人住址(paddr)varchar100电话病人电话(ptel)smallint10病房编号病人病房（pro）char4住院时由系统分配医生编号主治医生（ppno）int15一位病人只能对应一位主治医生 Patient-room的数据项描述：数据项名数据项含义类型长度备注编号病房编号(rno)Int15病房编号唯一地点病房位置(radd)char20非空收费标准住院收费（rcha）INT15单位为（元/天）所属部门病房所属部门（rbu）vaechar20一间病房只能属于一个部门Patient-bed的数据项描述：数据项名数据项含义类型长度备注病房编号病房编号（rno）int15唯一确定，引用病房的外码床位号病房床位（rbe）int15唯一确定，一个病房一般有1-3个床位 Doctor的数据项描述：数据项名数据项含义类型长度备注编号医生编号(dno)int15对应唯一一个医生姓名医生姓名(dname)char20非空性别医生性别(dsex)char2只能取男或女职称医生职称(dzhi)varchar20有可能有多个职称电话医生电话(dtel)smallint10部门所属部门(dbu)varchar20工资医生工资（dsa）int20Zhuyuan-register的数据项描述：数据项名数据项含义类型长度备注日期登记日期(rad)char10唯一标识病案号病案号（pno）int15唯一标识，引用病人外码入院时间入院时间（iti）char10出院时间出院时间（gti）char10必须在入院时间之后病房编号病房号（rno）int15引用病房表的外码病床编号病床号（rbe0int15引用病床表的外码 True-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.2表7.2.1表名Patient数据库用户病人主键病案号其他排序字段病人姓名，性别，地址，电话号码，病房编号，医生编号索引字段病案号序号字段名称数据类型（精度范围）允许为空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.2表名Doctor数据库用户医生主键医生编号其他排序字段医生姓名，性别，职称，电话，部门，工资索引字段医生编号序号字段名称数据类型（精度范围）允许为空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.3表名proom数据库用户病房管理员、病人主键病房编号其他排序字段地点，收费标准，所属部门索引字段病房编号序号字段名称数据类型（精度范围）允许为空Y/N唯一Y/N区别度默认值约束条件/说明1rnoInt(15)NY高主码2raddChar(20)NN中非空3rchaInt(15)YN低4rbumVarchar(20)NN低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区别度默认值约束条件/说明1rnoInt(15)NY高主码，引用proom的外码2rbeInt(15)NY高主码Mysql脚本Create table pbed(rno int(15) references proom(床位号)Rbe int(15) primary key)7.2.5表名Zhuyuan-register数据库用户病房管理员、病人主键日期和病案号序号字段名称数据类型（精度范围）允许为空Y/N唯一Y/N区别度默认值约束条件/说明1rdaChar(10)NY高主码 2pnoInt(15)NY高主空 ，引用病人表的外码3itiChar(10)NN低4gtiChar(10)NN低5rnoInt(15)YN低引用病房表的外码6rbeInt(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.6表名True-record数据库用户病房管理员、医生主键治疗时间，病案号和医生编号序号字段名称数据类型（精度范围）允许为空Y/N唯一Y/N区别度默认值约束条件/说明1timeChar(8)NY高主码2pnoInt(15)YY高主码，引用病人表的外码3dnoInt(15)YY高主码，引用医生表的外码4treVarchar(50)YN低5dnoVarchar(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.3视图的设计病人能看到的视图每个视图采用一张表格进行描述，其格式如下：数据库编号：Kf-001-2012视图编号：P-001-2012视图英文名称：patient视图中文名称：病历视图说明：病人可以看到入院出院日期，就医花费，且只能看到自己的部分Create view v_patientAs Select patient.pno,pname,rdate,ruyuandate,chuyuandate,rno,bedno,pafeeFrom patient join zhuyuan-record on patient.pno=zhuyuan-record.pno医生能看到的视图数据库编号：Kf-001-2012视图编号：D-002-2012视图英文名称：doctor 视图中文名称：医生视图说明：医生可以看到工资，负责的病人的治疗概况，且只能看到自己的部分Create view v_doctorAs Select 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_dataAs Select patient.pno,pname,doctor.dno,dname,pafee,dpay,dkeshi,zhuyuandate,chuyuandate,paill,dateFrom 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.dno7.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)begin print病房号应小于23rollbackend 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. 利用索引可以优化或排除耗时的分类操作，把数据分散到不同的页面上，就分散了插入的数据；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时间，就考虑存储计算结果（冗余储存）。现予以分类说明： 若在一行内重复计算，就在表内增加列存储结果。但若参与计算的列被更新时，必须要用触发器更新这个新列。 若对表按类进行重复计算，就增加新表（一般而言，存放类和结果两列就可以了）存储相关结果。但若参与计算的列被更新时，就必须要用触发器立即更新、或存储过程或应用代码批量更新这个新表。 若对多行进行重复性计算（如排名次），就在表内增加列存储结果。但若参与计算的列被更新时，必须要用触发器或存储过程更新这个新列。 总之，存储冗余数据有利于加快访问速度；但违反了第三范式，这会增加维护数据完整性的代价，必须用触发器立即更新、或存储过程或应用代码批量更新，以维护数据的完整性。 8.7.5数据库对象的放置策略 数据库对象的放置策略是均匀地把数据分布在系统的磁盘中，平衡I/O访问，避免I/O瓶颈。 访问分散到不同的磁盘，即使用户数据尽可能跨越多个设备，多个I/O运转，避免I/O竞争，克服访问瓶颈；分别放置随机访问和连续访问数据。 分离系统数据库I/O和应用数据库I/O。把系统审计表和临时库表放在不忙的磁盘上。 把事务日志放在单独的磁盘上，减少磁盘I/O开销，这还有利于在障碍后恢复，提高了系统的安全性。 把频繁访问的“活性”表放在不同的磁盘上；把频繁用的表、频繁做Join操作的表分别放在单独的磁盘上，甚至把把频繁访问的表的字段放在不同的磁盘上，把访问分散到不同的磁盘上，避免I/O争夺； 利用段分离频繁访问的表及其索引（非聚族的）、分离文本和图像数据。段的目的是平衡I/O，避免瓶颈，增加吞吐量，实现并行扫描，提高并发度，最大化磁盘的吞吐量。利用逻辑段功能，分别放置“活性”表及其非聚族索引以平衡I/O。当然最好利用系统的默认段。另外，利用段可以使备份和恢复数据更加灵活，使系统授权更加灵活。8.1.2并发控制 数据库中的数据是可以共享的资源，因此会有很多用户同时使用数据库中的数据，那么在多用户系统中，可能同时运行多个事务。事务运行需要时间，那么当多个事务同时运行时，彼此之间就会产生相互干扰的情况。 要处理这些情况，就需要加入封锁协议：一级，二级，三级封锁协议，两端锁协议。10.数据库管理与维护说明10.1数据库管理员职责数据库管理员职责：一、 一般监视 1 监控数据库的警告日志。Alert.log,定期做备份删除。 2 Linstener.log的监控，/network/admin/linstener.ora。 3 重做日志状态监视，留意视图v$log，v$logfile，该两个视图存储重做日志的信息。 4 监控数据库的日常会话情况。 5 碎片、剩余表空间监控，及时了解表空间的扩展情况、以及剩余空间分布情况，如果有连续的自由空间，手工合并。 6 监控回滚段的使用情况。生产系统中，要做比较大的维护和数据库结构更改时，用rbs_big01来做。 7 监控扩展段是否存在不满足扩展的表。 8 监控临时表空间。 9 监视对象的修改。定期列出所有变化的对象。 10 跟踪文件，有初始化参数文件、用户后台文件、系统后台文件 二、 对数据库的备份监控和管理 数据库的备份至关重要，对数据库的备份策略要根据实际要求进行更改，数据的日常备份情况进行监控。由于我们使用了磁带库，所以要对legato备份软件进行监控，同时也要对rman备份数据库进行监控。 三、 规范数据库用户的管理 定期对管理员等重要用户密码进行修改。对于每一个项目，应该建立一个用户。DBA应该和相应的项目管理人员或者是程序员沟通，确定怎样建立相应的数据库底层模型，最后由DBA统一管理，建立和维护。任何数据库对象的更改，应该由DBA根据需求来操作。 四、 对SQL语句的书写规范的要求 一个SQL语句，如果写得不理想，对数据库的影响是很大的。所以，每一个程序员或相应的工作人员在写相应的SQL语句时，应该严格按照SQL书写规范一文。最后要有DBA检查才可以正式运行。 五、 DBA深层次要求 一个数据库能否健康有效的运行，仅靠这些日常的维护还是不够的，还应该致力于数据库的更深一层次的管理和研究：数据库本身的优化，开发上的性能优化；项目的合理化；安全化审计方面的工作；数据库的底层建模研究、规划设计；各种数据类型的处理；内部机制的研究等等很多值得探讨的问题。