医院需求分析文档.doc

《医院需求分析文档.doc》由会员分享，可在线阅读，更多相关《医院需求分析文档.doc（41页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、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角色与

2、权限77优化78数据库管理与维护说明71引言1.1编写目的在完成了对医院各个部门的调查后,同时与多名病人进行了全面深入地探讨和分析的基础上,提出了这份系统需求分析报告.此需求分析报告对医院管理利通做了全面细致的用户需求分析，明确所要开发的系统应具备的功能、性能与界面，使系统分析人员及软件开发人员能清楚地了解用户的需求，并在此基础上进一步提出概要设计说明书和完成后续设计与开发工作。此外，这份需求分析报告中介绍了我们系统的框架结构，明确了该系统的方向及用途，是客户了解我们系统的一份详细资料，本分析报告的预期读者为客户、业务或需求分析人员、测试人员、用户文档编写者、项目管理人员。此分析报告是整个系统

3、开发的依据，它对以后阶段的工作起指导作用。本文也是项目完成后系统验收的依据。1.2术语表序号术语或缩略语说明性定义1PaPatient病人2DoDoctor医生3PbPatient-bed病床4PrPatient-room病房5ZrZhuyuan-register住院登记6TrTrue-record治疗记录1.3 参考资料资料名称作者文件编号、版本资料存放地点数据库原理及应用何玉洁机械工程出版社图书馆SQL Server使用教程范立南清华大学出版社图书馆数据库应用技术张蒲生机械工业出版社图书馆2.数据库环境说明2.1网络逻辑结构本次设计基于的网络逻辑结构是客户/服务器（C/S）体系结构。它由三

4、个主要部分构成：数据库服务器、客户应用程序和网络。基于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

5、对所有部门的详细信息进行管理4 对所有医生的详细信息进行管理1系统的功能实现情况: 用户可在本系统下实现各种用户要求的功能2系统的安全性: 对于系统的重要数据都有密码保护，具有一定的安全性 对用户提供证书支持（此功能在后续版本中实现）3系统的容错性: 用户输错数据都有提示信息，具有较好的容错性能。4系统的封闭性: 用户的封闭性较好，用户基本上在提示信息下输数据4.1.2数据字典数据项数据项含义说明类型长度取值范围取值含义与其他数据项的逻辑关系病案号唯一标识每个病人字符型15000000000000000至999999999999999前两位标明该病人所挂诊的部门，后十三位按顺序编号与住院登记，

6、治疗记录用此数据项相联系医生编号唯一标识每个医生字符型100000000001至9999999999前两位表示所属部门，后八位按顺序编号与治疗记录用此数据项相联系病房编号唯一标识每个病房字符型40001至9999前两位表示所属部门，后两位按顺序编号与病床，住院登记用此数据相联系床位号唯一标识每个病床字符型3001至999前两位表示所属病房，后两位按顺序编号引用病房主码做病床表的外码，与住院登记用此数据相联系日期，病案号唯一标识每个住院登记DATE,字符型10,15日期的取值范围，病案号引用病人表的主码表示每个住院登记的记录联系病人和住院登记病案号，医生编号唯一标识每个治疗记录字符型15，10病

7、案号引用病人表的主码，医生编码引用医生表的主码表示每个治疗记录的情况联系病人和医生数据结构数据结构含义说明组成病人定义了每个病人的有关信息病案号，姓名，性别，地址，电话号码，病房编号，医生编号医生定义了每个医生的有关信息医生编号，姓名，性别，职称，电话号码，部门，月工资病房定义了每个病房的有关信息病房编号，地点，收费标准，所属部门病床定义了每个病床的有关信息病房编号，病床号住院登记定义了每个住院登记的有关信息日期，病案号，入院日期，出院日期，病房编号，床位号，住院费用数据流 数据流：病人诊断情况 说明：病人病情的最终结果 数据流来源：病人 数据流去向：医生组成：病人，住院登记，治疗记录平均流量

8、：每天几百人 高峰期流量：每天几千人数据存储 数据存储：病人入院登记 说明：记录病人的基本情况 流入数据流：住院登记 流出数据流：住院登记 组成：病人，医生，住院登记，治疗记录数据量：每天几百张存取频度：每人一次存取方式：随机存取处理逻辑 处理名称：生成病人就医情况总表说明：说明处理过程输入数据流：病人，治疗记录输出数据流：住院登记处理逻辑：记录病人诊治记录，形成治疗记录，汇总成病人住院登记，再生成总表平均执行频率：每天几百次（说明：以上平均频率需长期观察得到） 数据流图图元医生病人诊治病人属 性病案 号医生属 性医生编 号4.1.3系统功能设想这里的功能划分，是根据第一阶段需求调查基础上进行

9、的初步划分。随着需求调查的深入，功能模块随着对需求了解的明确得到调整。医院管理系统的四个主要部分,可以将系统应用程序划分为对应的4个子模块:包括医生管理系统,病人管理系统,病房管理系统,科室管理系统. 根据各业务子系统所包括业务内容,还可以将各个子系统继续细化划分为更小的功能模块。划分的准则主要遵循模块的内聚性要求和模块间的低聚合性。如图所示表示一个医院管理系统功能模块结构图。应用系统医生管理病人管理病房管理系统管理治疗病人信息医生的详细信息病人的详细信息各科室医生及病人信息所有部门科室信息住院信息4.1.4 业务流程分析简单医院流程图 收费单请住院单请住院申请病人信息图4-1 入院数据流图病

10、人查看信 息病人病案病人分配床 位病房信息产生收费单及住院单治疗方案出示病历病人医生诊 断病人病历病人检查情况给出治疗方案方 案病人图4-2 治疗数据流图申请出院缴费单病人病人病案收费准则病历归 档费用统 计病人图4-3 出院数据流图5.概念设计5.1.1 实体 病房（病房编号，地点，收费标准，所属科室） 病床（病房编号，床位号） 病人（病案号，姓名，性别，地址，电话号码，病房编号，医生编号） 医生（医生编号，姓名，性别，职称，电话号码，部门，工资） 住院登记（日期，病案号，入院时间，出院时间，病房编号，床位号，住院费用）治疗记录（治疗时间，病案号，医生编号，诊断，治疗方案）5.1.2系统局部

11、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图，可以将其转换为以下一组关系模式，

12、其中关系模式的码用下横线标出。将E-R图中1:1的联系与任意一端所对应的关系模式合并。 将E-R图中1：n的联系与n端所对应的关系模式合并，如：将“病床”这一联系并到“病房”关系模式； 将E-R图中m:n的联系转换为一个独立的关系模式。 病房（病房编号，地点，收费标准，所属科室） 此为病房实体型所对应的关系模式。其中病房编号唯一确定一个病房，所以为该关系模式的码。病床（病房编号，床位号） 此为病床实体型所对应的关系模式。由于病房编号是病房关系模式的码，所以在该关系模式中病房编号为外码。病人（病案号，姓名，性别，地址，电话号码，病房编号，医生编号） 此为病人实体型所对应的关系模式。其中病案号为此

13、关系模式的码，而病房编号，医生编号 为该关系模式的外码。医生（医生编号，姓名，性别，职称，电话号码，部门，工资） 此为医生实体型所对应的关系模式。其中医生编号唯一确定一个医生，所以为该关系模式的码。 住院登记（日期，病案号，入院时间，出院时间，病房编号，床位号） 此为住院登记实体型所对应的关系模式。其中，日期和病案号共同确定一个住院登记，病房编号为该关系模式的外码。治疗记录（治疗时间，病案号，医生编号，诊断，治疗方案）此为联系“治疗”所对应的关系模式。其中，病案号和医生编号都是该关系模式的外码。6.1.2各个数据表的表结构设计Patient的数据项描述：数据项名数据项含义类型长度备注病案号病人

14、的编号(pno)int15对应唯一一个病人姓名病人姓名(pname)Char20性别病人性别(psex)char2只能取男或女地址病人住址(paddr)varchar100电话病人电话(ptel)smallint10病房编号病人病房（pro）char4住院时由系统分配医生编号主治医生（ppno）int15一位病人只能对应一位主治医生 Patient-room的数据项描述：数据项名数据项含义类型长度备注编号病房编号(rno)Int15病房编号唯一地点病房位置(radd)char20非空收费标准住院收费（rcha）INT15单位为（元/天）所属部门病房所属部门（rbu）vaechar20一间病房只

15、能属于一个部门Patient-bed的数据项描述：数据项名数据项含义类型长度备注病房编号病房编号（rno）int15唯一确定，引用病房的外码床位号病房床位（rbe）int15唯一确定，一个病房一般有1-3个床位 Doctor的数据项描述：数据项名数据项含义类型长度备注编号医生编号(dno)int15对应唯一一个医生姓名医生姓名(dname)char20非空性别医生性别(dsex)char2只能取男或女职称医生职称(dzhi)varchar20有可能有多个职称电话医生电话(dtel)smallint10部门所属部门(dbu)varchar20工资医生工资（dsa）int20Zhuyuan-reg

16、ister的数据项描述：数据项名数据项含义类型长度备注日期登记日期(rad)char10唯一标识病案号病案号（pno）int15唯一标识，引用病人外码入院时间入院时间（iti）char10出院时间出院时间（gti）char10必须在入院时间之后病房编号病房号（rno）int15引用病房表的外码病床编号病床号（rbe0int15引用病床表的外码 True-record的数据项描述：数据项名数据项含义类型长度备注时间治疗日期(time)char8入院和出院时间之间,唯一标识病案号病案号（pno）int15唯一标识，引用病人外码医生编号主治医生（dno）Int15唯一标志，引用医生外码诊断病情诊断（

17、tre）VARCHAR50医生诊断结果治疗方案治疗方案（mea）VARCHAR200医生给出的治疗方案7、物理设计7.1表汇总表名功能说明表Patient病人表，属性列有病案号、姓名、性别、地址、电话、病房编号、医生编号。主码是病案号，外码是医生编号。病人可以查看关于自己的属性列及住院信息。表Doctor医生表，属性有医生编号、姓名、性别、职称、电话号码、部门。医生编号是主码。医生可以查看自己的属性列及病人病情状况。表Patient-room病房表，属性列有病房编号、地点、收费标准、所属科室。病房编号是主码。病房表的创建便于医生查看治疗病人的住院地点、便于病人明确自己的收费标准。表Patien

18、t-bed病床表，主码为病房编号和床位号。外码为病房编号。此表方便病房管理员进一步掌握各病人的详细床位信息。表True-register治疗记录表，治疗时间、病案号、医生编号共同为主码。此表由病房管理员对于每一位住院的病人进行分配登记。医生查询此表可以了解所医治病人的诊断信息并提出治疗方案。表Zhuyuan-register住院登记表，主码为日期和病案号，属性列有入院时间、出院时间、病房编号、床位号。外码为病案号、病房编号、床位号。7.2表7.2.1表名Patient数据库用户病人主键病案号其他排序字段病人姓名，性别，地址，电话号码，病房编号，医生编号索引字段病案号序号字段名称数据类型（精度范

19、围）允许为空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 var

20、char(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（

21、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)

22、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

23、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(p

24、no) 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低My

25、sql脚本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_p

26、atientAs 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

27、,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,chuyuan

28、date,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 page

29、50)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位字符的加密方法）。输入的口令不应显示在显示终端上。数据信息的保存：利用R

30、DBMS的服务器稳定运行实现各种信息的储存、控制及调节备份、恢复等日常的维护管理工作。在软件园后期的项目中建立异地备份服务器后备份数据进行异地保存。8.1.2操作跟踪针对系统运行出现的异常，跟踪调查出现异常的情况，了解操作意图，有针对性的解决问题。系统日志，便于查看系统的运行情况。 操作日志, 提供用户在系统中增加、修改系统数据信息时记录日志。用于跟踪用户的操作，了解信息的变更，在需要时对事情进行调查8.1.3访问控制页面不可直接访问，防止黑客对页面篡改。页面访问通过连接动作驱动，访问时作权限检查。有效防止用户通过地址栏输入地址对信息非法访问。系统在页面执行过一次后再次访问通过缓冲工作区执行，

31、对页面屏蔽。易用性医院管理系统要简单、易用，具有清晰的导航功能，使操作者快速找到自己想要执行的操作页面。医院管理系统要保证一个非计算机专业的用户，通过自己阅读用户手册，可以使用此系统。8.2角色与权限角色或者执行者（Actor）是指与系统产生交互的外部用户或者外部系统，本系统主要包括病人，医生，病房管理员和系统管理员等角色（Actor）。8.2.1角色管理可以对单个角色进行添加、修改、删除和查询等维护操作，可以针对不同的角色选择对应的权限进行设置。用例描述：角色管理执行者：系统管理员前置条件：系统管理员已登录系统后置条件：角色信息维护后，相应信息记录到数据库中，以供帐号授权使用基本路径：a)

32、进入角色管理界面，显示目前的角色列表；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表查询，插入

33、，修改，删除doctor表查询，插入，修改，删除patient表查询，插入，修改，删除Patient-bed表查询，插入，修改，删除Zhuyuan-record表查询，插入，修改，删除cure-gister表查询，插入，修改，删除8.3应用级用户设计应用级的用户账号密码不能与数据库想通，防止用户直接操作数据库。用户只能用账号登录到应用软件，通过应用软件访问数据库，而没用其他途径操作数据库。8.3.1登录管理登录管理是负责所有用户的登录，用户要登录到综合信息管理平台必须经过登录界面，输入自己的用户名和密码，通过判断这个用户的权限信息，不同的登录人可能具有不同的权限，根据不同的权限现实不同的功能。

34、8.3.2 用户管理当进入用户管理模块时，在用户管理中可以增加或删除用户，编辑用户名，用户密码，修改用户权限，具有不同权限的用户进入系统主界面，界面左侧栏中的图标数有所不同，具体的面标与用户所具有的权限对应。8.3.3 日志查询实现对用户的所有操作过程的历史日志查询。查询结果以列表方式显示，可以根据查询条件进行过滤。8.4用户密码管理用户账号的密码必须进行加密处理，确保在任何地方的查询都不能出现密码的明文。用户帐号采用MD5进行数据加密后再录入数据库，以防止任何地方密码的安全性要求。8.5防止用户直接操作数据库的方法建立应用程序角色，给角色相应的权限，然后应用程序以各自的用户登录就可以了（sc

35、ott是一个系统已经新建好的普通用户用户名scott，密码默认tiger，默认状态是被定,DBA用户执行alter user scott account unlock;可以解锁登陆）8.6性能测试8.6.1 性能需求根据用户对本系统的要求，确定系统在响应时间、可靠性、安全性等方面有较高的性能要求。8.6.2界面需求系统的界面要求如下：）页面内容：主题突出，站点定义、术语和行文格式统一、规范、明确，栏目、菜单设置和布局合理，传递的信息准确、及时。内容丰富，文字准确，语句通顺；专用术语规范，行文格式统一规范。）导航结构：页面具有明确的导航指示，且便于理解，方便用户使用。）技术环境：页面大小适当，能

36、用各种常用浏览器以不同分辨率浏览；无错误链接和空链接；采用CSS处理，控制字体大小和版面布局。）艺术风格：界面、版面形象清新悦目、布局合理,字号大小适宜、字体选择合理，前后一致，美观大方；动与静搭配恰当,动静效果好；色彩和谐自然,与主题内容相协调。8.6.3 响应时间需求无论是客户端和管理端，当用户登录，进行任何操作的时候，系统应该及时的进行反应，反应的时间在5秒以内。系统应能监测出各种非正常情况，如与设备的通信中断，无法连接数据库服务器等，避免出现长时间等待甚至无响应。8.6.4可靠性需求系统应保证7X24内不当机，保证20人可以同时在客户端登录，系统正常运行，正确提示相关内容。8.6.5

37、开放性需求系统应具有十分的灵活性，以适应将来功能扩展的需求。8.6.6可扩展性需求系统设计要求能够体现扩展性要求，以适应将来功能扩展的需求。8.6.7 系统安全性需求系统有严格的权限管理功能，各功能模块需有相应的权限方能进入。系统需能够防止各类误操作可能造成的数据丢失，破坏，同时防止用户非法获取网页以及内容。8.7优化数据库优化的目标无非是避免磁盘I/O瓶颈、减少CPU利用率和减少资源竞争。 8.7.1基于第三范式的基本表设计 在基于表驱动的信息管理系统（MIS）中，基本表的设计规范是第三范式。第三范式的基本特征是非主属性只依赖于主属性。基于第三范式的数据库表设计具有很多优点：1.消除了冗余数

38、据，节省了磁盘存储空间；2.有良好的数据完整性限制，即基于主外码的参照完整限制和基于主码的实体完整性限制，这使得数据容易维护，也容易移植和更新；3.数据的可逆性好，在做连接（Join）查询或者合并表时不遗漏、也不重复；4.因消除了冗余数据（冗余列），在查询（Select）时每个数据页存的数据行就多，这样就有效地减少了逻辑I/O，每个Cash存的页面就多，也减少物理I/O；5.对大多数事务(Transaction)而言，运行性能好；6.物理设计(Physical Design)的机动性较大，能满足日益增长的用户需求。 在基本表设计中，表的主码、外码、索引设计占有非常重要的地位，现在从系统数据库优

39、化角度讨论这些基本概念及其重要意义： （1）主码(Primary Key)：主码被用于复杂的SQL语句时，频繁地在数据访问中被用到。一个表只有一个主码。主码应该有固定值（不能为Null或缺省值，要有相对稳定性），不含代码信息，易访问。把常用的列作为主码才有意义。短主码最佳（小于25bytes），主码的长短影响索引的大小，索引的大小影响索引页的大小，从而影响磁盘I/O。 主码分为自然主码和人为主码。自然主码由实体的属性构成，自然主码可以是复合性的，在形成复合主码时，主码列不能太多，复合主码使得Join操作复杂化、也增加了外码表的大小。人为主码是在没有合适的自然属性码、或自然属性复杂或灵敏度高时，

40、人为形成的。人为主码一般是整型值（满足最小化要求），没有实际意义，也略微增加了表的大小；但减少了把它作为外码的表的大小。 （2）外码（Foreign Key）：外码的作用是建立关系型数据库中表之间的关系（参照完整性），主码只能从独立的实体迁移到非独立的实体，成为后者的一个属性，被称为外码。 （3）索引(Index)：利用索引优化系统性能是显而易见的，主要有以下几个方面：1. 对所有常用于查询中的Where子句的列和所有用于排序的列创建索引，可以避免整表扫描或访问，在不改变表的物理结构的情况下，直接访问特定的数据列，从而减少数据存取时间；2. 利用索引可以优化或排除耗时的分类操作，把数据分散到不同的页面上，就分散了插入的数据