实例3：高校学生会管理系统数据库设计

实例 3：高校学生会管理系统数据库设计1 数据库设计1.1 系统需求分析阶段需求分析简单的说就是分析用户的要求。需求分析是涉及数据库的起点，需求分析的 结果是否准确地反映了用户的实际要求，将直接影响到后面各个阶段的设计，并影响到设 计的结果是否合理和实用。1.1.1 需求分析阶段的目标1了解高校学生会管理的基本内容； 2综合的理解主管学生会老师和学生会干部的不同需求；3了解学生会管理的基本业务流程；4了解学生会人工管理模式与信息系统的工作概况，以及它们之间的区别与联系； 5 通过自身的体验和与主管学生会的老师及其他学生会干部的交流，了解用户对高 校学生会管理系统的业务要求，完整性和安全性要求。1.1.2 需求分析阶段的任务1处理对象：系统处理对象是学生会的干部信息管理、财务管理、日常事务管理和文件信息管理四 个方面。在学生会的干部信息处理中主要涉及几下几个方面的信息：（1）学生会干部基本信息 （Student） ：包括编号、姓名、性别、职务、专业、年级、加 入学生会日期、参加过的活动项目等信息。（ 2）部门基本信息（ Dpartment ）：部门编号、部门名称、部长姓名、副部长人数、部 委人数、部长电话等信息。在财务信息处理中主要涉及几下几个方面的信息：（1）物品基本信息 （Goods） ：包括物品编号、物品名称、购买时间、单价、借出时间， 借物人姓名、归还时间、归还人姓名等信息。（ 2）财务基本信息 （Financial affairs） ：包括财务申请编号、资金用途、申请金额、申 请人、申请部门、申请时间、余额等信息。在日常事务信息处理中主要涉及几下几个方面的信息：（1）事务活动基本信息（ Affairs ）：包括事务活动编号、事务活动名称、职能范围、 承办部门、以往解决方案、是否特色活动等信息。（2）工作计划基本信息（ Working plan ）：包括工作计划编号、工作计划名称、提交部 门、提交人、提交时间、是否紧急活动等信息。在文件信息处理中主要涉文件的基本信息（ File ）：包括文件编号、文件名称、文件类 型、所属部门、负责人、收发对象、存档日期、备注等信息。2处理功能要求高校学生会管理系统主要实现对学生会的科学化、条理化、信息化、高效化管理。其 中包括学生会干部信息、财产物品的使用以及登记，日常事务管理和文件信息管理等四大 功能。具体功能描述如下：（1）学生会干部信息管理主要完成干部信息的查询与更新， 从而实现对学生会干部信 息的科学化管理。（2）财务的管理包括财产和物品的管理，完成对财产物品信息的查询与更新，如举办 活动所需的资金申请、物品使用的登记、物品借还的登记等，从而实现学生会财务的信息 化管理。（3）日常事务管理实现对学生会日常开展工作的管理，完成日常事务的查询与更新， 从而更好地实现以下职能：包括各部门提交的工作计划、活动计划的审核与安排、活动的 筹划、各项活动的人员合理的调度与安排，确保各项活动成功地举办，更有利于学生会各 项日常工作的顺利开展。（4）文件管理完成对学生会所有存档文件的查询与更新， 实现对学生会日常的工作文 件的科学化管理，从而确保各项工作的开展有章可寻，使学生会的工作更富有条理化，避 免一些重复文件的制定，造成资源的浪费。3安全性和完整性要求安全性先通过视图机制，不同的用户只能访问系统授权的视图，这样可提供系统数据 一定程度上的安全性，再通过用户授权机制，通过用户登陆来识别用户级别，根据这个级 别来分配用户权限，达到数据更高层次的安全保密功能。近而可以满足用户的基本数据安 全性要求。完整性要求用于描述各种信息之间的制约关系，以及关联关系，各个数据项的取值范 围以及各个数据项是否可以不取值。根据实际需要，采取一定的手段来满足用户的完整性 需求。详细完整性要求见于系统的逻辑设计阶段。办公室学习部纪检部4业务流程图学生会干部信息管理业务流程图财务管理业务流程图：文艺部体育部生活部社会实践部勤工助学部科技创新部女工部图14学生会组织机构图候选修改信 息存档民主竞选 和考核学生昙换准管学4生会的一+ 老师丿任命亲 学生弓斤一届 自干部 严、图1.1在职学 生干部日常工 作表现卷考制度 给予奖惩学生会干部退任|修改信|修衣信息存档I息存档|学生会干部信息管理日常事务管理业务流程图：文件管理业务流程图：5数据流程图顶层数据流程图：*申请加入打7K学生会. .开展活动申il高校学生会管八干部r申请审批理系统图2.1顶层数据流程图信息处理 结果信息检索主管学生：会老师：第 2 层数据流程图：干部信息23申请审批:曰I4生会的 老师一会干 部会各 部门查看止理修学生会干部信息表图2第二层数据涼程图财务登记表T-文件登记表活动安排表查看信息财物审批开展活魂-孝届学生 干部信息 有效学生.学生会 干部信 息处理财务信 息处理活动信 息处理活动I活动 V安排文件信 息处理第 3 层数据流程图：从学生干部信息管理角度出发第 3 层数据流程图：从财务管理角度出发第 3 层数据流程图：从日常事务管理角度出发第 3 层数据流程图：从文件管理角度出发7数据字典（1）数据项：系统涉及的数据项有 51 项表 1.1（ 高校学生会管理系统 ）数据项列表（汇总统计 ）数据项编号数据项名数据项含义与其它数据项的关系存储结构别名DI-1StuNo学生干部编号char(8)编号DI-2StuName学生干部姓名char(10)姓名DI-3StuSex学生干部性别char(2)性别DI-4StuPosition学生干部职务char(6)职务DI-5StuDepartName学生干部所属部门等于 DepNochar(6)部门数据项编号数据项名数据项含义与其它数据项的关系存储结构别名DI-6StuMajor学生干部所属专业char(20)专业DI-7StuGrade学生干部所在年级char(8)年级DI-8StuPhoneNo学生干部电话char(12)电话DI-9StuStaTime加入学生会时间datetime时间DI-10StuCase参加过的活动项目varchar(50)项目DI-11GoodsNo物品编号char(8)编号DI-12GoodsName物品名称char(16)名称DI-13GoodsBuyTime购买时间datetime时间DI-14GoodsPrice单价char(6)单价DI-15GoodsLendTime借出时间datetime时间DI-16GoodsLender借物人姓名char(10)姓名DI-17GoodsReturner归还人姓名char(10)姓名DI-18GoodsRetTime归还时间datetime时间DI-19FinNo财务申请编号char(6)编号DI-20FinPurpose用途char(30)用途DI-21FinMoney申请金额char(6)金额DI-22FinPerson申请人姓名char(10)姓名DI-23FinDepartment申请部门char(14)部门DI-24FinTime申请时间datetime时间DI-25FinRemain余额char(6)余额DI-26PlaNo工作计划编号等于 FileNochar(6)编号DI-27PlaName工作计划名称char(30)名称DI-28PlaDepartment计划提交部门等于 DepNochar(6)部门DI-29PlaPerson计划提交人char(10)姓名DI-30PlaTime计划提交时间datetime时间DI-31PlaQuality是否紧急活动char(4)是否DI-32AffNo事务活动编号char(6)编号DI-33AffName事务活动名称char(20)名称DI-34AffScope事务活动职能范围char(8)职能范围DI-35AffDepartment主要承办部门等于 DepNochar(6)部门DI-36AffScheme以往解决方案char(50)方案DI-37AffQuality是否特色活动char(4)活动DI-38DepNo部门编号char(6)编号DI-39DepName部门名称char(14)名称DI-40DepMinName部长姓名等于 StuNamechar(8)姓名DI-41DepSminSum副部长人数int人数DI-42DepMemSum部委人数int人数DI-43MinPhoNo部长电话char(12)电话数据项编号数据项名数据项含义与其它数据项的关系存储结构别名DI-44FilesNo文件编号char(6)编号DI-45FilesName文件名称char(20)名称DI-46FilesType文件类型char(14)类型DI-47FilesBelDep所属部门char(6)部门DI-48FilesPerson负责人char(8)姓名DI-49RecDisPartner收发对象char(14)对象DI-50ArcDate存档日期datetime日期DI-51Remarks备注char(30)备注2）数据结构：表 1-2 （ 高校学生会管理系统 ） 数据结构（汇总统计）数据结构编号 数据结构名 数据结构含义 组成DS-1Student学生干部信息DS-2Goods物品信息DS-3FinancialAffairs财务信息DS-4WorkingPlan工作计划信息DS-5Affairs事务活动信息DS-6Department部门信息DS-7Files文件信息StuNo,StuName,StuSex,StuPosition,StuMajor,StuDepartName,StuGrade,StuPhoneNo,StuCase,StuStaTime,GoodsNo,GoodsName,GoodsBuyTime,GoodsPric,Good sLender,GoodsLendTime,GoodsReturner, GoodsRetTimeFinNo, FinPurpose, FinMoney, FinPerson,FinTime,FinDepartment, FinRemainPlaNo, PlaName, PlaDepartment, PlaPersonPlaTime, PlaQualityAffNo, AffName, AffScope, AffDepartmentAffScheme, AffQualityDepNo,DepName,DepMinName, DepSminSumDepMemSum, MinPhoNoFilesNo,FilesName,FileTyp,FilesBelDep, FilesPerson, RecDisPartner, ArcDate, Remarks8处理逻辑描述（判定表或判定树）表 1-3 （高校学生会管理系统）处理逻辑描述处理编号处理功能处理过程学生会干部信息管理模块、财务管理模块、学生PR-1判断用户查询涉及的功能模块会日常事务管理模块、文件信息管理模块：先确 定查询所涉及的功能模块；然后，确定要查询的 内容，确定查询数据流向；最后显示查询结果。PR-2判断用户修改要涉及的模块，同 时把相应的修改数据传到相应的 模块之中学生会干部信息管理模块、财务管理模块、学生 会日常事务管理模块、文件信息管理模块：先确 定更新所涉及的功能模块；然后，把更新信息传 送到相应的模块中；最后，进行相应的更新操作。1.2 概念设计阶段1.2.1 目标将需求分析得到用户需求抽象为信息结构即概念模型的过程就是概念结构设计。概念 设计阶段主要是将需求分析阶段得到的用户需求抽象为信息结构（概念模型 ）的过程,它是整个数据库设计的关键，包括概念模型设计和新系统流程两个阶段。在需求分析阶段所得到 的应用需求应该首先抽象为信息世界的结构，才能更好地、更准确地用某一 DBMS 实现这 些需求。1.2.2 具体任务1选择中层数据流为切入点，通常选择实际系统中的子系统；2设计分 E-R 图，即各子模块的 E-R 图；3生成初步 E-R 图，通过合并方法，做到各子系统实体、属性、联系统一； 4生成全局 E-R 图，消除冲突。1.2.3 结果1各实体及其属性学生会干部图3.1学生会干部实体及其属性图编号购买日期名称单价借出时间归还时间日还人 姓名昔物人 姓名物品图乳2物品实体及其属性图工作计划图3. 4工作计划实体及其属性事务活动图d.5事务活动实体及其属性部门图部门实体及其属性图文件图乳丁文件实体及其属性图2生成分 E-R 图如下所示：3 .合并各分E R图，消除各类冲突，得到初步 E-R图，再消除不必要冗余，得到的基本E-R 图。具体实现如下：a. 消除冲突合并分 E-R 图时并不能简单地将各个分 E-R 图画到一起，而是必须着力消除各个分E-R 图中的不一致，以形成一个能为全系统中所有的用户共同理解和接受的统一的概念模 型。合并分E-R图的主要工作与关键是合理消除各分 E-R图的冲突，冲突主要有三类：属 性冲突、命名冲突和结构冲突。b. 消除冗余在 E-R 图中，可能存在一些冗余的数据和实体间的联系。冗余数据和冗余联系容易破 坏数据库的完整性，给数据库的维护增加困难，应予以消除。但并不是所有的冗余数据与 冗余联系都必须加以消除，有时为了提高效率，不得不以冗余信息作为代价。消除冗余主 要采用分析法和规范化理论。经过以上分析，将所有的分 E-R 图综合成一个系统的总 E-R 图：解释如下： 一个部门可以承办多个事务活动，而一个事务活动只能由一个部门去承办； 一个部门可以包括多个学生会干部，而一个学生会干部只能隶属于一个部门； 一个学生会干部可以参与多项事务活动，而一个事务活动也可以有多个学生干部参与； 一个学生会干部可以提交多份财务申请，而一份财务只能由一个学生会干部申请； 一个学生会干部可以制定多份文件，而一份文件只能由一个学生会干部制定； 一个学生会干部可以提交多份工作计划，而一份工作计划只能由一个学生会干部提交； 一份财务申请的资金可以购买多种物品，而一种物品只能由一次财务申请的资金来购买 一次事务活动需借用多种物品，而一种物品一次只能给被一项事务活动所借用； 一份工作计划可以包括多项事务活动，而一项事务活动只能有一份工作计划中制定。 4新系统流程图否理显示查询结果户级别过三次是否成功?图乳13新系统涼程图学生 会干 部信 息管 理日常 事务 管理日常 事务 管理发出查询 提示信息发出修改 提示信息管理员 qL亠普通用户用户登录退出1.3 逻辑设计阶段1.3.1 逻辑设计阶段的目标以上的概念设计阶段是独立于任何一种数据模型的，但是逻辑设计阶段就与选用的DBMS 产品发生关系了，系统逻辑设计的目标就是将概念设计阶段设计好的基本 E-R 图转 换为选用 DBMS 产品所支持的数据模型相符合的逻辑结构。1.3.2 逻辑设计阶段的任务具体任务是数据组织和数据处理。在数据组织阶段主要要完成的任务是将 E-R 图转换 成为关系模型；模型优化；完成数据库模式定义描述，包括各模式的逻辑结构定义、关系 的完整性和安全性等内容；用户子模式设计。以表格的形式表现出来。数据处理阶段主要 任务是画出系统功能模块图。1数据组织（1）实体型转换为关系模式一个实体型转换为一个关系模式。实体的属性就是关系的属性，实体的码就是关系的 码。学生会干部（编号，姓名，性别，职务，部门，专业，年级，电话，加入学生会日期， 参加过的活动项目）物品（编号，名称，购买时间，单价，借出时间，借物人姓名，归还时间，归还人姓 名）财务（财务申请编号，资金用途，申请金额，申请人，申请部门，申请时间，余额）工作计划（编号，名称，提交部门编号，提交人，提交时间，是否紧急活动）事务活动（编号，名称，职能范围，承办部门，以往解决方案，是否特色活动）部门（部门编号，部门名称，部长编号，副部长人数，部委人数，部长电话）文件（编号，名称，类型，所属部门编号，负责人，收发对象，存档日期，备注）（2）实体间联系转换为关系模式一个 1：1 联系可以转换为一个独立的关系，也可以与任意一段对应的关系模式合并。 如果转化为一个独立的关系模式，则与该联系相连的各个实体的码以及联系本身的属性均 转换为关系的属性，每个实体的码均是该关系的候选码。如果与某一个实体对应的关系合 并，则需要在该关系模式的属性中加入另一个关系的主码和联系本身的属性。一个 m：n 的联系可以转化为一个单独的关系模式，这个单独的关系模式的主码事两 端实体的码，再加上联系的属性。一个 1：n 联系可以转化为一个独立的关系模式， 也可以与 n 端的关系模式合并作如果 与 n 端的关系模式合并，在 n 端的关系模式中加上另一端关系的码和联系属性。为了方便系统地实现和数据库的设计，将所有的关系均作为一个单独的关系模式。（3）通过转化后所得出的关系模型在以下的关系模式当中，关系模式的码用直下划线标出，关系模式的外键用曲下划线 标出。学生会干部（编号，姓名，性别，职务，部门，专业，年级，电话，加入学生会日期， 参加过的活动项目）物品（编号，财务申请编号，名称，购买时间，单价，借出时间，借物人姓名，归还时间，归还人姓名）财务（财务申请编号，资金用途，申请金额，申请人，申请部门，申请时间，余额）工作计划（编号，名称，提交部门编号，提交人，提交时间，是否紧急活动）事务活动（编号，名称，职能范围，承办部门，以往解决方案，是否特色活动）部门（编号，名称，部长编号，副部长人数，部委人数，部长电话）文件（编号，名称，类型，所属部门编号，负责人，收发对象，存档日期，备注）活动使用物品（事务活动编号，物品编号，使用数量）参与活动（事务活动编号，学生会干部编号，出勤情况）（4）数据模型优化经过检查，以上九个关系模型当中前七个的主码都只有一个属性列，所以不从在部分 函数依赖，后两个关系模式也不存在部分函数依赖。而且这九个关系模式也不存在传递函数依赖。因此，它们均已经达到 3NF 。（5）数据库模式定义其中，包括各模式的逻辑结构定义、关系的完整性和安全性等内容。一个关系模式应 当是一个五元组 R，而一般只将其看作一个三元组 R。表2.1数据库模式定义表编号逻辑结构（基本表）定义完整性和安全性T1Student （详见附录 2 1 ）（详见附录 21）T2Goods （详见附录 2 2）（详见附录 22）T3FinancialAffairs （详见附录 2 3 ）（详见附录 23）T4WorkingPlan （详见附录 2 4）（详见附录 24）T5Affairs （详见附录 2 5 ）（详见附录 25）T6Department （详见附录 2 6 ）（详见附录 26）T7Files （详见附录 2 7）（详见附录 27）T8AffairsGoods （详见附录 2 8）（详见附录 28）T 9JoinAffairs （详见附录 2 9）（详见附录2 9）6）用户子模式设计将概念模型转换为全局逻辑模型后，还应该根据用户的习惯和需求设计符合局部用户需要的外模式，即视图设计。表2.2用户子模式设计（View）列表编号用户子模式（View）作用（共性：提供数据保密和安全保护机制 ）V 1StuView查询和修改学生会干部的基本信息V 2DepView查询和修改各部门的基本信息V 3GooView查看物品的借出和归还信息V 4FinView查看活动经费使用情况V 5WPView查看工作计划提交的情况V 6AffView查看以往事务活动方案以供来参看V 7FilesView查看以前存档文件的基本信息V 8AGView查询举办活动物品的使用情况2数据处理 系统功能模块图1.4 物理设计阶段1.4.1 物理设计阶段的目标不同的数据库产品所提供的物理存储环境、存取方法和存储结构有很大的差别，能供设 计人 员设 用的 设计 变量 、参 数范 围也 很不 相同 。物 理设 计 阶段 的目 标是根据 SQL Server2000 具体的功能，设计优化的物理数据库结构，使得在数据库上运行的各种事务响 应时间最小，存储空间利用率高，事务吞吐量大。1.4.2 物理设计阶段的任务紧数据库的物理设计就是为逻辑数据模型选取一个最合适应用要求的物理结构的过 程，在这个阶段中要完成两大任务：（1）确定数据库的物理结构，在关系数据库中主要是存取方法和存储结构； （2）对物理结构进行评价，评价的重点是时间和空间效率。1数据存储方面 为数据库中各基本表建立的索引如下：（1）由于基本表 Student、Goods、Affairs、Dpartment 的主码 StuNo 、GoodsNo 、 AffNo 、DepNo 经常在查询条件和连接操作的连接条件中出现，且它们的值唯一，考虑在 两个属性上建立唯一性索引；（2）AffairsGoods 的主码 AffNo 和 StuNo ，Join Affairs 的主码 AffNo 和 StuNo ，他们 经常在查询条件中出现，且它们的组合值唯一，考虑在它们之上建立组合索引；（ 3）基本表 Financial affairs 、Working plan 的属性值几乎不会有什么变化，更新率 很低，可考虑适当建立索引；（4）基本表 File 的属性值经常发生变化，权衡系统为维护索引付出的代价，可考虑 不建立索引，也可以适当建立索引。2系统功能模块（1）学生会干部信息查询和更新模块 将实现对学生会干部信息的查询和更新（修改、插入、删除）操作，方便于对学生干 部基本信息的全面、科学的管理，能有效的应对学生会干部的变动性和流动性，及时地更换信息。具体的功能模块图如下：（2）财务信息的查询和更新模块 将完成财产和物品基本信息的查询、更新（修改、插入、删除）操作，便于对财产物 品的集中管理，从而更有利于节约举办活动的开支，确保学生会各项工作顺利的开展。具 体的功能模块图如下所示：是否是I断是否遊 命令信息2否/星否修E 成功?查询”-箏I定是查询 :7是更新?注：给用户的信息表示系统给用户的信息图4. 2财务和物品信息的查询、更新功能模块 查询结果修改后的数据存储更新修改结果提示信息在财务或物品 信息表中进行 更新操作在财务或物品 信息表中进行 查询处理用户发出查询或更新 财务或物品的信息（3）日常事务信息的查询和更新模块 将达到对日常事务信息的查询、更新（修改、插入、删除）操作的目的，从而实现将 学生会的日常事务纳入信息化的管理当中， 在日常工作开展中可以有效地节约人力、 物力 财力，减少重复性工作的复杂性，更有利于创建一个科学、高效、高水平的学生会。具体 的功能模块图如下所示：（4）文件基本信息的查询和更新模块 将完成对文件信息的查询和插入、删除、修改等更新操作，从而实现对学生会所有文 件的科学化管理，便于日常工作的开展。具体的功能模块如下所示：是否是终止熾是否趁命令信息2查询/殉定是查询7是更新?否/堤否儆 成功?表示系统给用户的信息（注：给用户的信息 查询结果修改后的数据存储图q.q文件信息的查询、更新功能模块图更新修改结果提示信息在文件信息表 中进行更新操 作在文件信息表 中进行查询处 理用户发出查询或 更新文件的信息1.4.3 物理设计阶段结果表 4-1 存储过程汇总编号存储过程名称定义作用P-1p1_ Student _Insert详见附录2-1在 Student 中插入一元组P-2p2_ Goods _Insert详见附录 2-2在 Goods 中插入一元组P-3p3_ FinancialAffairs _Insert详见附录 2-3在 FinancialAffairs 中插入一元组P-4p4_ WorkingPlan _Insert详见附录 2-4在 WorkingPlan 中插入一元组P-5p5_ Affairs _Insert详见附录 2-5在 Affairs 中插入一元组P-6p6_ Dpartment _Insert详见附录 2-6在 Dpartment 中插入一元组P-7p7_ File _Insert详见附录 2-7在 File 中插入一元组P-8p8_ AffairsGoods _Insert详见附录 2-8在 AffairsGoods 中插入一元组P-9p9_ JoinAffairs _Insert详见附录 2-9在 JoinAffairs 中插入一元组P-10P10_Query_Department详见附录 2-10在 Department 中匹配 (DepNo) 查询P-11P11_Query_Department详见附录 2-11在 Department 中匹配 (DepName) 查询P-12P12_Delete_Department详见附录 2-12在 Department 中删除元组P-13P13 Update Department详见附录2-13在Department中更新操作（其他表的查询、修改、删除与Department 表的大致相同，这里不再具体列出）1.5 数据库实施阶段1.5.1 数据库实施阶段目标用 DBMS 所提供的数据定义语言和其他实用程序将数据库逻辑设计和物理设计结果 描述出来，成为 DBMS 可以接受的源代码，在经过调试生成目标模式1.5.2 数据库实施阶段任务1建立数据库create database University_Student_Union_Management;2建立数据表（1）学生会干部基本信息表的建立create table Student （StuNo char(8)not null unique,StuName char(10)not null,StuPosition char(6)not null,StuSex char(2)null,StuMajor char(14)null,StuDepart char(6)not null,StuGrade char(8)null,StuPhoneNo char(12)not null,StuStaTime datetimenot null,StuCase varchar(50)null,primary key(StuNo),foreign key(StuDepart) referencesDepartment(DepNo)check(StuSex = 男 or StuSex = 女);2）物品基本信息表的建立create table Goods(GoodsNo char(8)not null unique,FinNo char(6)not null,GoodsName char(16)not null,GoodsBuyTime datetimenull,GoodsPrice char(6)not null,GoodsLender char(10)not null,GoodsLendTime datetimenull,GoodsReturner char(10)not null,GoodsRetTime datetimenull,primary key (GoodsNo),foreign key (FinNo) references FinancialAffairs (FinNo);3) 财务基本信息表的建立：create table FinancialAffairs ( FinNo char(16) FinPurpose char(30) FinMoney char(6) FinPerson char(8) FinTime datetime FinDepartment char(6) FinRemain char(6) primary key(FinNo),not null unique, null, not null, not null, null not nullnullforeign key (FinPerson) references Student(StuNo), foreign key (FinDepartment) references Department(DepNo);4) 工组计划基本信息表的建立：create table WorkingPlan( PlaNo char(6) PlaName char(30) PlaDepartment char(6) PlaPerson char(8) PlaTime Datetime PlaQuality char(4)not null unique, not null, not null, null, null, not null,primary key(PlaNo),foreign key(PlaPerson) references Student(StuNo),foreign key(PlaDepartment ) references Department(DepNo);5) 事务活动基本信息表的建立：create table Affairs (AffNo char(6)not null unique,PlaNo char(6)not null,AffName char(20)not null,AffScope char(8)null,AffDepartment char(6)not null,AffScheme char(50)null,AffQuality char(4)not null,primary key(AffNo),foreign key(PlaNo) references WorkingPlan(PlaNo);foreign key(AffDepartment) references Department(DepNo);,6) 部门基本信息表的建立：create table Department ( DepNo char(6) DepName char(14)not null unique, not null,DepMinName char(8)not null,DepSminSum intnull,DepMemSum intnull,MinPhoNo char(12)null,primary key(DepNo),foreign key(DepMinName) references Student(StuNo) )7)文件基本信息表的建立：create table Files(FilesNo char(6)not null unique,FilesName char(10)not null,FilesType char(10)null,FilesBelDep char(6)not null,FilesPerson char(14)not null,RecDisPartner char(14)not nullArcDate datetimenull,Remarks char(30)null,primary key(FilesNo),foreign key(FilesBelDep) references Department(DepNo);8)活动使用物品基本信息表的建立：create table AffairsGoods (AffNo char(6)not null,GoodsNo char(8)not null,Gamount intnull,primary key(AffNo ， GoodsNo),foreign key(AffNo) references Affairs (AffNo),foreign key(GoodsNo) references Goods(GoodsNo);9)学生会干部参与活动基本信息表的建立：create table JoinAffairs (AffNo char(6)not null,StuNo char(8)not null,Present char(8)null,primary key(AffNo, StuNo),foreign key(AffNo) references Affairs (AffNo), foreign key(StuNo) references Student(StuNo);3建立视图 (1)查询学生会干部的基本信息的视图定义如下：create view StuView ( 编号，姓名，性别，职务，部门，专业，年级，电话，加入日期 参加过的活动项目 )asselect *from Student with check option;（2）查询和修改各部门的基本信息视图定义如下：create view DepView （ 编号，名称，部长姓名，副部长人数，部委人数，部长电话 ） as select * from Department with check option;3）查看物品的借出和归还信息的视图定义如下：create view GooView （物品编号，物品名称，借出时间，借物人姓名，归还时间，归 还人姓名 ）asselect GoodsNo ， GoodsName ，GoodsLender ，GoodsLendTime, GoodsReturner ， GoodsRetTimefrom Goods with check option;4）查看活动经费使用情况的视图定义如下：create view FinView （ 财务编号，金额，申请人姓名，申请部门，余额 ） asselect FinNo ， FinMoney ，FinPerson ， FinDepartment ， FinRemain from FinancialAffairs with check option;5）查看工作计划提交的情况的视图定义如下：create view WPView （ 编号，工作计划名称，提交部门，提交人，提交时间 ） asselect PlaNo ，PlaName ，PlaDepartment ， PlaPerson ，PlaTime from WorkingPlan with check option;6）查看以往事务活动方案以供来参看的视图定义如下：create view AffView （ 活动编号，活动名称，承办部门，以往解决方案，是否特色活动 ） asselect AffNo ， AffName ， AffDepartment ， AffScheme ， AffQuality from Affairs with check option;7）查询以前存档文件的基本信息的视图定义如下：create view FilesView （ 文件编号，文件名称，类型，所属部门，负责人，收发对象， 存档日期，备注 ）as select * from Fileswith check option;(8)查询举办活动物品的使用情况的视图定义如下：create view AGView ( 事务活动编号，物品编号，使用数量 )asselect *from AffairsGoodswith check option;4建立索引create unique index StudentNo on Student(StuNo);create unique index GoodsNo on GoodsNo(GoodsNo);create unique index FinancialNo on FinancialAffairs (FinNo);create unique index PlaningNo on WorkingPlan(PlaNo);create unique index AffairsNo on Affairs(AffNo);create unique index DepartmentNo on Department(DepNo);create unique index FilesNo on Files(FilesNo);create unique index AffairsGoods on AffairsGoods(AffNo， GoodsNo);create unique index JoinAffairs on JoinAffairs(AffNo ， StuNo);create cluster index StudentName on Student(StuName);create unique index FileName on Files(FilesName);5数据入库 系统包括学生会干部信息管理、财务管理、日常事务管理、文件管理等四大功能模块， 共有 9张基本表,牵涉到大量数据的录入 ,又由于时间限制 ,采用事先在 Excel 中录入数据 ,然 后使用 SQL Server 2000 数据导入/导出向导功能 ,直接将数据导入到相应的基本表中。 当然， 附录中也给出了各个基本表插入元组的存储功能，详细内容请参阅附录2。1.5.3 数据库实施阶段结果1. 关系模式说明2. 数据定义语句(见附录)2 数据库调试与试运行这次测试用黑盒测试来做的， 我们只要检查程序功能是否按需求分析的规定正常使用， 程序能否合理地接收输入数据而进行正确的操作，并且保持外部信息(如数据库)的完整 性。黑盒测试是穷举测试输入，只有把所有可能的输入都作为测试情况使用，才能以这种 方法查出程序中的所有的错误。实际上的测试情况有无穷多个，人们不仅要测试所有合法 的输入，而且要对那些不合法但是可能的输入进行测试。但是对于数据库的测试我认为不 需要进行非法测试，因为 DDL 语句本身有很强的逻辑性而且句子中有约束条件。从上面的性能测试已说明数据库系统设计的已经符合用户的需求。但由于高校学生会 管理系统关系到这一核心程序，它与具体的语言有关，在没有具体的用户程序代码之前不能做总体的性能测试，但是从数据库的功能测试这一部分的成功测试来看，数据库的性能 也是符合需求的。具体的测试结果请看附录附录 1 数据库逻辑结构定义1学生会干部( Student )基本信息表，用于记录学生会干部的基本信息附表 2.1 学生会干部基本信息表属性名数据类型取值范围是否是主属性或外键完整性StuNochar(8)00000000 99999999是Not nullStuNamechar(10)否Not nullStuPositionchar(6)否Not nullStuSexchar(2)男、女否NullStuMajorchar(14)否NullStuDepartchar(20)是Not nullStuGradechar(8)否NullStuPhoneNochar(12)否Not nullStuStaTimedatetime否Not nullStuCasevarchar(50)否Null2物品( Goods )基本信息表，用于记录学生会物品的基本信息附表 2.2 物品基本信息表属性名数据类型取值范围是否是主属性或外键完整性GoodsNochar(8)00000000 99999999是Not nullFinNochar(6)000000 999999是Not nullGoodsNamechar(16)否Not nullGoodsBuyTimedatetime否NullGoodsPricechar(6)否Not nullGoodsLenderchar(10)否NullGoodsLendTimedatetime否NullGoodsReturnerchar(10)否NullGoodsRetTimedatetime否Null3财务( FinancialAffairs )基本信息表，用于记录财务的基本信息附表 2.3 财务基本信息表属性名数据类型取值范围是否是主属性或外键完整性FinNochar(6)000000 999999是Not nullFinPurposechar(30)否NullFinMoneychar(6)否Not nullFinPersonchar(8)是Not nullFinTimedatetime否NullFinDepartmentchar(6)是Not nullFinRemainchar(6)否Null工作计划(WorkingPlan )基本信息表，用于记录各部提交的工作计划的基本信息:附表2.4工作计划基本信息属性名数据类型取值范围是否是主属性或外键完整性PlaNochar(6)000000 999999是Not nullPlaNamechar(30)否Not nullPlaDepartmentchar(6)是Not nullPlaPersonchar(8)是NullPlaTimedatetime否NullPlaQualitychar(4)否Not null5事务活动 (Affairs) 基本信息表，用于记录学生会各项事务活动的基本信息