关键词: 门诊
数据库系统需求分析(精选6篇)
篇1:数据库系统需求分析
医院门诊管理系统一、引言
门诊是医院管理的重要组成部分,人流量大,手续较为繁琐。在人工的情况下,医护人员要做大量不必要的重复的工作、效率低、准确性差、不方便管理、影响工作效率。这些都会造成病人得不到合理快速的解决方案。随着社会的不断发展进步,计算机的发展亦十分迅速,在各大领域都发挥着不可忽视的作用。因此,我们选择利用计算机设计一个医院的门诊管理系统。它可以实现数据的信息管理,在一定程度上实现自动化。
二、需求分析
本系统的主要功能是对医院门诊患者信息进行有效管理,形成一个完整的体系。主要任务是用计算机来对患者进行管理,如挂号、诊断、计价、收费、取药等。系统可以详细记录病人从挂号处挂号到门诊缴费,以及经医生诊断后取药的过程中的所有信息。
三、主要要求
系统要满足以下几个方面:
(1)病人管理
在此管理模式中,维护病人的基本信息,如姓名、性别、联系方式等。同时也可以删除、修改、添加病人的信息。
(2)挂号系统管理
输入病人信息,系统会自动生成挂号费用,挂号之后会自动生成病号信息到病号信息库中。病历号必须唯一,以供全系统共享调用,整个系统通过这个唯一病历号贯通一体,大夫和病人都可以藉此查询所有的就诊历史信息,并实现划价收费、药房取药等操作。若病号库中已存在该病号,则可以直接进行挂号操作。
(3)医生管理
医生管理模块中存储医生的基本信息。此模块也实现信息化管理医生收发病例。
(4)药品管理
药品发放由药房管理人员完成操作,药房通过收款单来给病人发药。在病人缴费后,可直接到药房取药。发药的同时减少药品库存量。通过查询病号来确定药品名称及数量。
(5)处方管理
处方管理是要完成病历上病情、病史的记载,以及医嘱的开立和实施。
四、系统功能图
门诊管理系统 |
病人管理 |
查询病人信息 |
删除病人信息 |
增加病人信息 |
修改病人信息 |
门诊挂号 |
挂号管理 |
医生管理 |
查询医生信息 |
增加医生信息 |
删除医生信息 |
修改医生信息 |
药房发放药品 |
处方管理 |
处方单录入 |
处方单查询 |
修改处方单 |
查询药品 |
查询发药单 |
药品管理 |
挂号单查询 |
五、数据字典
实体 | 数据项名 | 说明 | 类型 |
病人 Patient | PatientNo | 病人编号 | char(12) |
PatientName | 姓名 | varchar(10) | |
Sex | 性别 | char(1) | |
Age | 年龄 | int | |
ID | 身份证号 | char(18) | |
TEL | 电话 | varchar(12) | |
HP | 过敏药物 | varchar(100) | |
病历 MRecord | M_No | 病历编号 | char(12) |
M_Date | 就诊日期 | Datetime | |
Symptom | 主要症状 | varchar(100) | |
员工 Employee | EmployeeNo | 员工编号 | char(13) |
EmployeeName | 员工姓名 | varchar(10) | |
Sex | 性别 | char(1) | |
Age | 年龄 | int | |
ID | 身份证号 | char(18) | |
TEL | 电话 | varchar(12) | |
Position | 职位 | varchar(10) | |
Salary | 工资 | Numeric(10,2) | |
WorkDate | 工作日期 | DateTime | |
WorkTerm | 工作年限 | int | |
科室 Department | DepartmentNo | 科室编号 | char(5) |
DepartmentName | 科室名称 | varchar(20) | |
Address | 科室位置 | varchar(50) | |
Manager | 负责人 | varchar(10) | |
TEL | 电话 | varchar(12) | |
Introduction | 科室介绍 | varchar(200) | |
挂号单 Register | RegisterNo | 挂号单编号 | char(14) |
RegisterTime | 挂号时间 | Datetime | |
RegisterFree | 挂号费 | Numeric(10,2) | |
药品 Medicine | MedicineNo | 药品编号 | char(15) |
MedicineName | 药品名称 | varchar(25) | |
MedicineClass | 药品类别 | varchar(10) | |
UnitPrice | 单价 | Numeric(10,2) | |
Elements_m | 主要成分 | varchar(200) | |
Function_M | 主要功能 | varchar(200) | |
Usage | 用法用量 | varchar(200) | |
Providcer | 供应商 | varchar(50) | |
ProduceDate | 生产日期 | Datetime | |
Usefullife | 有效日期 | Datetime | |
Matters | 注意事项 | varchar(200) | |
Amount | 库存量 | Int | |
处方 Recipe | RecipeNo | 处方编号 | char(15) |
SickDate | 就诊日期 | Datetime | |
PatientNo | 病人编号 | char(12) | |
ElementNo | 员工编号 | char(13) | |
MedicineName | 药品名称 | varchar(25) | |
Quantity | 药品数量 | Int |
六、数据约束条件
(1)一个医院中有多个诊室,一个诊室中可有多个员工,但一个员工只属于一个诊室。
(2)员工由员工号来唯一标识,存储员工的相关信息,格式为:workDatime+流水号;病人由病人编号唯一标识,存储病人的相关信息,格式为:病人第一次看病时间+流水号;药品由药品编号唯一标识,格式为:p/s+国药准字;挂号由挂号编号唯一标识,格式为:日期+流水号;处方由处方单号唯一标识,格式为:R+日期+流水号。
(3)在同一时间段,药品发放只为一位病人;在同一时间段,医生只为一位病人看病。
(4)员工工作年龄超过18岁,满足工作年龄要求。
(5)联系电话不超过11位数
七、数据流图
病人 |
病人 |
门诊管理系统 |
病人信息 挂号单
缴费 缴费凭证
诊断 处方
取药凭证 药物
病人 |
挂号收费 |
挂号请求
挂号单 挂号信息 挂号记录
缴费 收费记录 收费记录
收费 医生信息
医生记录
接诊 |
看病
处方 诊断信息 诊断记录
取药 |
取药
药物信息
药物 药物记录
八、逻辑设计
关系模式:
(1)病人(病人编号、病人姓名、性别、年龄、身份证号、电话、过敏药物)
(2)病历(病历编号、就诊日期、主要症状)
(3)员工(员工编号、姓名、性别、年龄、身份证号、电话、职位、工资、工作日期、工作年限)
(4)科室(科室编号、科室名称、科室位置、负责人、电话、科室介绍)
(5)挂号单(挂号单编号、挂号时间、挂号费);
(6)药品(药品编号、药品名称、药品类别、单价、主要成分、主要功能、用法用量、供应商、生产日期、有效日期、库存量)
(7)处方(处方编号、就诊日期、病人编号、员工编号、药品名称、药品数量)
九、E-R图
员工编号 |
医生 |
科室 |
病历 |
病历编号 |
病人 |
药品 |
药 品 编 号 |
病人编号 |
科室编号 |
处方编号 |
篇2:数据库系统需求分析
1.目的
1)能够存储大量的图书信息,快速有效的进行书籍数据管理,包括:
① 图书信息的录入、删除及修改。② 图书信息的多关键字检索查询。③ 图书的出借、返还和资料统计。
2)能够对一定数量的读者进行相应的信息存储与管理,这其中包括:
① 读者信息的登记、删除及修改。② 读者资料的统计与查询。
3)能够对需要的统计结果提供打印输出。
4)能够提供一定的安全机制,提供数据信息授权访问,防止随意删改,同时提供信息备份的服务。
2.概述
2.1用户需求分析
1)产品功能
登录系统:注册,注销,退出。
管理:用户管理,借阅管理,图书管理。
查询:读者查询,借阅查询,图书查询。
帮助:使用说明,关于。
2)用户角色 3)操作环境 4)设计实现约束
2.2建立需求模型
上图是用例图的建模过程,下面是该系统的用户需求陈述:
(1)校图书馆准备开发“图书管理系统”,方便广大师生借阅、浏览:
(2)师生需要先注册然后才能借阅图书。用户进行注册时需要输入个人信息,注册成功后,会获得一个由系统提供的标识其身份的标识码。
(3)用户登录进入图书管理系统后,可以通过Web页面查看图书的各种信息,如图书的借阅情况,作者等
(4)用户登录后可以借阅图书,并在系统规定的时间内还书。否则必须缴纳罚款金。用户借阅图书时,系统会注明借阅时间。
(5)图书管理员可以查询图书,查看一些借阅情况,更容易知道哪类图书需求量大,好做到合理的更新增减图书。有用户违规或没按时还书的情况,他们做处理,收罚金。查询图书可以是用户得知图书更具体的位置以节省时间。
(6)管理员可以对书籍进行操控,注册,修改图书及信息;注册,修改读者信息;进行系统维护。
从上述需求陈述中可以发现以下元素: ① 参入者 ·用户 ·管理员 ② 基本用例 ● 注册 ● 登录
● 查询图书 ● 借阅图书 ● 归还图书 ● 更新图书 ● 图书信息 ● 读者信息
上图是用户还书时的用例图。当用户还书时,图书管理员需要检查图书是否被损坏并查看是否按规定时间还书。如果图书没有损坏而且按规定时间还书,那么图书管理员就修改该图书的信息,删除用户借书记录,登记还书时间。如果图书被损坏用户必须交罚金,图书管理员除了收款外还要把图书和用户的信息修改好,并记录图书损坏的程度,以致其它用户借阅时方便。
上图是用户查询图书的用例图。当用户登录系统查询图书时,系统会根据图书信息表查询出图书信息并反馈给用户。用户可以检索到图书馆的馆藏书目、读者基本信息、读者借书、超期读者、罚款记录、最新图书、借阅频率最高的图书信息、图书具体的藏书位置。用户还可以预定图书。
2.3系统需求分析
①功能需求 1 用户登录系统:包括管理员登陆,学生查阅信息登陆
2.在编目的时候自动迅速查找新的书籍是否已编目,并可以快速编目。3.能够用计算机进行快速查找,已确定图书的名称和存放的位置。4.查找出一本已借出的书现在在谁那里。5.各类具体查找功能。
6.统计一本结束正在一段时间内借过多少本书。7.统计一本书在一段时间内被谁借过。
8.在还书时实现计算机自动判断图书借阅是否超期根据条例进行罚款。9.在书丢失时进行赔偿,可以自行设置赔偿条例。
10.大型数据库,要可以灵活设置库的性质(1.是否可借2.借阅时间3.不同的读者节约本书可以进行设置4.增加、删除、修改库)。
11.图书管理员有不同的职位要可以进行权限设置。12.读者信息管理。数据需求
输入图书的数量,图书的信息,图书编号,用户的信息,用户账号。用户查询时输出图书的数量,罚款记录、最新图书、借阅频率最高的图书信息等。外部接口需 2.1用户接口
2.3软件接口
因为可能涉及一些文档、报表的处理应该保持与常用软件的办公软件的接口
2.3硬件接口
因为可能涉及数据的备份应该保持打印机和光盘刻录机的接口
2.4通信接口 安全性需求
图书管理系统的操作也只能由专人进行,只有图书管理部门的工作人员才能拥有权限,特别是图书的借出状况,如果没有安全管理部分,后果难以想象,可能每次登录都需要用户身份的验证。保密需求
篇3:图书系统数据库需求分析与设计
1、图书系统数据库需求分析
对于整个图片管理系统, 可以列出以下数据项和数据结构, 分别见表1、表2。
2、图库管理系统的数据库设计
根据数据库需要的分析, 建立如下3个数据表, 具体每个字段定义如下图所示[2]。
管理员表 (admin) , 其结构如图2所示。
图片类型表 (fenlei) , 其结构如图3所示。
数据库管理系统的功能使用B/S结构设计了一个网络图库管理系统, 对网络图库管理系统做了整体的系统设计与需求分析, 包括图片搜索和浏览, 和在线照片拆下来添加, 删除, 帐户分类和管理, 增加等其他功能。图库管理系统是最常见的一个系统化的方法来管理图片, 照片共享是业务流程的公司或单位的基础。系统化管理的大量图片, 因此我们的主要目标。在这种情况下, 体现了系统的优点, 很显然, 该系统具有简单, 可扩展, 功能强大, 可以轻松地跨系统, 跨区域, 跨平台的操作。
3、后台数据库配置
图片管理系统使用的数据库是SQL Server 2000数据库, 它是由Microsoft公司推出的非常实用的大型数据库系统。这也是本系统优势之一。[29]
下面给出访问SQL Server数据库的连接代码:
结论
使用B/S结构设计了一个网络图库管理系统, 对网络图库管理系统做了整体的系统设计与需求分析, 包括图片搜索和浏览, 和在线照片拆下来添加, 删除, 帐户分类和管理, 增加等其他功能。图库管理系统是最常见的一个系统化的方法来管理图片, 照片共享是业务流程的公司或单位的基础。系统化管理的大量图片, 因此我们的主要目标。在这种情况下, 体现了系统的优点, 很显然, 该系统具有简单, 可扩展, 功能强大, 可以轻松地跨系统, 跨区域, 跨平台的操作。
摘要:图书系统由于其数据量较大, 因此十分适合用数据库系统进行管理。本文通过对图书数据库系统的需求进行分析, 并对数据库系统进行了设计, 给出了一套实用的图书系统数据库的实现方法。
关键词:图书系统,数据库,需求分析
参考文献
[1].李国辉, 胡晓峰.基于内容的检索.计算机世界报, 1998 (18)
篇4:数据库系统需求分析
摘要:目前,大多数高校均有选课系统用来支持学生选课。但当学生存在个性化选课需求无法通过选课系统直接完成时,一般采用与教务管理人员面对面沟通予以解决。本文以上海交通大学建立基于教学管理数据库的个性化需求系统为例,介绍一种新的解决思路和应用实践。
关键词:个性化选课需求 教学管理
中图分类号:TP311.52 文献标识码:B 文章编号:1673-8454(2009)21-0033-04
一、教学管理信息系统及数据库描述
大多数高校均拥有教学管理信息系统,并建立了对应数据库系统对整个教学管理信息系统的数据记录与运行支持。教学管理系统一般包含课程管理子系统、培养计划管理子系统、排课子系统、选课子系统、学籍管理子系统、毕业子系统等。本文探讨的个性化选课需求主要针对选课子系统,以及选课实施过程中又涉及的排课子系统与学籍管理子系统。教学管理信息系统后台由教学管理数据库支撑,教学管理数据库记录各子系统产生的数据并提供给其他子系统使用。[1]
以上海交通大学本科生教学管理信息系统为例。培养计划管理子系统汇总各专业和年级学期课程安排生成学期教学任务书,各院系落实教学任务后通过排课子系统落实排课,所有课程安排通过选课子系统提供给学生选课,学生根据自身专业培养计划要求以及本人修业情况进行选课。
上海交通大学选课子系统分为三个轮次,依次为海选、抢选和第三轮选课。海选一般安排在后半学期,选择下一学期课程,所有课程对所有学生开放,不设名额限制。海选结束后根据课程主要面向对象优先、课程容纳人数为限、实际选课人数随机调整确定选课名单。名单确定后开放抢选阶段,公布学生海选结果及各课程剩余容纳人数,学生选课原则为先来先得,当选课总人数达到课程容纳人数限制时该课程即选满,不再允许学生选入。抢选结束后学生选课结果基本确定。新学期开学后第一周、第二周开放第三轮选课,第三轮选课原则与抢选一致,学生根据上学期学习成绩以及本学期试听情况对已选课程进行调整。
二、个性化选课需求描述
第三轮选课学生存在调整选课的需求,特别是因上学期学习成绩公布后部分学生需安排一些重修课程,这一不确定因素在上一学期的教学任务中无法预计,因此存在原先设定的课程容纳人数不一定能够满足这部分学生的需求,即对部分课程原设定的容纳人数可能需做扩容。扩容过程受教学资源限制、选课秩序稳定限制以及学生需求相对个性的限制。最简单的做法是根据经验,对可能需要重修的课程直接扩容,提供给学生自主选择。实际操作过程中这种做法带来很大问题,即无法保证扩容后的资源分配给真正有需要的学生,往往被并不一定需要或并不一定当前学期需要的学生占用。
为避免这种情况,以往采用的做法是与学生面对面沟通与反馈选课需求,再根据资源限制当场决定是否可以调整选课,学生往往排队等候。这种做法的优点是能实际了解学生需求并直接给予反馈,学生排队也体现先来先得,一定程度上保证有限资源公平分配。缺点是效率较低,往往导致学生长时间排队等待浪费学生时间资源且未必能够得到正面反馈,同时导致相关人员的工作量大幅增加。另一点不足之处在于,学生的需求虽然相对个性但不同学生的需求仍有相同之处,这种相同的需求不能通过排队面对面的方式共同解决。[2]
以“以人为本”的理念为指导,如能更有效地采集学生相对个性化选课需求,同时保证类似排队的公平性,将大大节约学生时间和精力,并能提取个性需求中的共性点,做到事半功倍,实现学生与学校的双赢。[3]通过网络技术与高校已有教学管理信息系统及数据库的结合,这种设想有了实现的可能。上海交通大学通过对学生个性化选课需求的分析,结合本校教学管理信息数据库,设计了基于教学管理数据库的个性化选课需求系统,并投入实际应用。
三、系统设计与开发
1.设计思路
设计个性化需求系统需保留实际排队反映需求的优点,即反映学生个体个性化需求和保证排队公平性,还要达到节约学生及教务处工作人员时间精力的目的,同时要力求系统简洁明了。基于这种思路,记录学生的个性化需求数据表设计包含以下信息:需求提交日期、需求提交时间、学年、学期、学号、教学班、需求类型、需求描述、受理与否、满足与否、反馈描述。
需求提交日期、需求提交时间用于数据处理时排队,保证类似现实排队的公平性;学年、学期用于系统的后续连贯性与扩展性;学号、教学班用于标准化记录学生个体的个性化需求;需求类型、需求描述用于记录学生本人对需求的判断及补充说明,便于后期统计及教务处工作人员更好地理解学生需求;受理与否、满足与否、反馈描述用于对学生反馈其需求是否已受理,是否已满足,以及教务处工作人员对受理情况补充说明。
2.涉及相关数据表
个性化需求数据表中各项数据不是孤立存在的,而是依托已有教学管理数据库中相关数据表,以确保数据即时准确。主要的相关数据表为学生信息表、课程安排表、学生选课表。个性化需求数据表中学号字段将与学生信息表关联定位具体学生;教学班字段将于课程安排表、学生选课表关联定位具体课程安排情况、课程容纳人数限制以及课程已选情况等;若学生需求得到满足,选课情况还将追加写入学生选课表。
3.关联数据开发
系统通过Web方式供学生提交需求,并与教学管理数据库相结合,因此系统开发采用ASP+SQL Server工具进行,分别开发学生平台和管理平台。[4]
如上文所述,该系统开发主要是将现有教学管理数据库中相关数据进行关联整合展现出来,同时将学生查询后的结果予以记录。主要存在以下几类数据关联整合,数据关联整合后通过Web予以展现。
(1)用户信息表(userinfo)和学生信息表(xsjbk)关联。通过用户信息表中用户名字段(username)、密码字段(password)和学生信息表中学号字段(xh)判断是否合法登录以及获取学生姓名(xm)、班级(bh)、专业(zymc)等基本信息。参考SQL查询代码如下:
Select xsjbk.xh,xsjbk.bh,xsjbk.xm,xsjbk.zymc,userinfo.username,userinfo.password
From userinfo inner join xsjbk on userinfo.username=xsjbk.xh
Where userinfo. username=′"&username;&"and userinfo.password=”&password;&”
(2)教师担任表(jsdrk)、教师基本库(jsjbk)、课程代码库(kcmcdmk)的关联。根据这一关联结果再与课程安排表(js_syk)关联,获取课程的具体时间地点安排。教师担任表中涉及的字段包括课程代码(kcdm)、学年(xn)、学期(xq)、教学班号(bsid)、学期学分(xqxf)、教师工号(gh);教师基本库中涉及的字段包括教师姓名(xm)、教师工号(gh);课程代码库中涉及的字段包括课程代码(kcdm)、课程名称(kcmc)等。参考SQL查询代码如下:
select jsdrk.kcbm,jsdrk.xn,jsdrk.xq,jsdrk.bsid,jsjbk.xm,yxdmk.yxmc,kcmcdmk.kcdm,kcmcdmk.kcmc,jsdrk.xqxf from jsdrk left join jsjbk on jsdrk.gh=jsjbk.gh
left join yxdmk on jsdrk.yxdm=yxdmk.yxdm left join kcmcdmk on jsdrk.kcdm=kcmcdmk.kcdm
where jsjbk.xm like ′%"&cxnr;&"%′ and jsdrk.xn=′"&session;("xn")&"′
and jsdrk.xq=′"&session;("xq")&"′ order by jsdrk.kcdm,jsdrk.kcbm
课程安排表(js_syk)再根据上述查询到的教学班号(bsid)、单双周(dsz)、开课周次(xingq)、开课节次(jc)、上课地点(jsdm)等信息,参考SQL查询如下。
select dsz,xingq,jc,jsdm from js_syk where bsid="&rs;("bsid")&" order by dsz,xingq
(3)学生选课需求写入到学生选课需求表(xsxktzb)中。写入内容包括提交日期(riqi)、提交时间(sj)、学号(xh)、教学班号(bsid)、学年(xn)、学期(xq)、需求类型(tzlx)、需求说明(tzsm)等。参考SQL代码如下:
insert into xsxktzb (riqi,sj,xh,bsid,xn,xq,tzlx,tzsm) values(′"&riqi;&"′,′"&sj;&"′,′"&xh;&"′,"&bsid;&",′"&xn;&"′,′"&xq;&"′,′"&tzlx;&"′,′"&tzsm;&"′)
(4)学生选课需求表(xsxktzb)与学生信息表(xsjbk)、教师担任表(jsdrk)、教师基本库(jsjbk)、院系代码库(yxdmk)、课程代码库(kcmcdmk)关联,用于列示学生选课需求。学生选课需求表涉及字段包含学号(xh)、提交日期(riqi)、提交时间(sj)、教学班号(bsid)、受理与否(sfsl)、成功与否(sfcg)、需求类型(tzlx)、调整反馈(tzfk)等;学生信息表涉及字段包括学号(xh)、姓名(xm)等;教师担任表涉及字段包括教学班号(bsid)、教师工号(gh)、开课院系(yxdm)、课程代码(kcdm)等;教师基本库涉及字段包括教师工号(gh)、教师姓名(xm)等;院系代码库涉及字段包括院系代码(yxdm)、院系名称(yxmc)等;课程代码库涉及字段包括课程代码(kcdm)、课程名称(kcmc)等。参考SQL代码如下:
select xsjbk.xh,xsjbk.xm,xsxktzb.riqi,xsxktzb.sj,jsdrk.kcbm,jsdrk.xn,jsdrk.xq,jsdrk.bsid,jsjbk.xm,yxdmk.yxmc,kcmcdmk.kcdm,kcmcdmk.kcmc,jsdrk.xqxf,xsxktzb.tzlx,xsxktzb.sfsl,xsxktzb.sfcg,xsxktzb.tzfk
from xsxktzb left join xsjbk on xsjbk.xh=xsxktzb.xh left join jsdrk on xsxktzb.bsid=jsdrk.bsid
left join jsjbk on jsdrk.gh=jsjbk.gh left join yxdmk on jsdrk.yxdm=yxdmk.yxdm
left join kcmcdmk on jsdrk.kcdm=kcmcdmk.kcdm
where jsdrk.xn=′"&session;("xn")&"′ and jsdrk.xq=′"&session;("xq")&"′
order by sfsl,xsxktzb.id
当选取特定教学班后,上述查询结果再与特定教学班号匹配,得到特定教学班的所有选课需求。列示出来的特定需求在上述查询的结果中增加学生选课需求表(xsxktzb)中的需求说明(tzsm)字段。
4.功能模块
根据关联数据开发结果设计具体的操作平台,根据应用对象不同分为学生平台和管理平台功能模块。
(1)学生平台
学生用与登录教学管理信息系统同样的用户信息登录个性化选课需求系统。
学生登录后,系统根据用户信息自动读取学生学号、姓名以及当前学期设置等基本信息。学生界面以“==以下查询本学期课程安排==”为分隔线,分割线以上为学生根据自身个性化需求已提交的选课申请,学生可随时登录系统查看申请受理状态。学生申请信息包含提交日期时间、课程安排信息、调整原因、受理状态、受理反馈等。当教务处工作人员对学生申请受理后,学生界面中受理状态即会相应予以调整,便于学生及时了解进展状况。
分割线以下提供查询界面,可根据教师姓名或课程名称查询所需要的课程安排。以课程名称查询为例,如查询“运筹学(D类)”课程,结果如图1所示。
根据查询条件,系统查询出所有“运筹学(D类)”课程安排,包含开课院系、任课教师、具体课程安排等信息。学生需填写申请调整原因,以便教务处工作人员更好地理解其调整需求。学生根据自身需求填写申请原因后提交,该申请将即时出现在分割线上方。
学生界面设置简洁明了,通过对教学管理数据库的查询,学生能提交标准格式数据,以供教务处工作人员采集并处理,同时学生还能填写具体申请原因。通过这种简便的方式,准确无误地采集学生个性化的选课需求。
(2)管理平台
教务处工作人员通过管理平台汇总学生提交的需求,如图2所示。选定学年、学期后系统会自动汇总已提交的申请,并根据提交时间先后顺利排序。
汇总的需求包含提交时间、学生信息、课程信息等。其中最为重要的是课程教学班信息,包含任课教师和教学班代号。教务处工作人员根据时间先后顺序选择教学班代号,当选定某个教学班后,所有对该教学班的申请全部列示供批处理,如图3所示。
选定教学班后,系统即将该教学班的具体课程及选课情况做综合描述,包括开课时间、地点、计划容纳人数、已确定选课人数、教室实际容量以及相关备注信息等。根据这些信息以及学生对需求的具体说明,教务处工作人员依次受理,对于能够选入的,直接选入,并做好受理和选课成功标记,供学生查询。对于不能选入的,做好受理相关反馈供学生查询。
四、系统应用与扩展
以上海交通大学应用个性化选课需求系统为例。应用系统之前的新学期第三轮选课持续两周,约有一周半的时间学生每天持续排长队,初步统计每天最多能接待100位学生,经座谈了解,有部分学生因排队浪费时间放弃。学生和教务处工作人员均承担较大压力。
应用个性化选课需求系统后,学生网上提交选课调整申请,不再需要实际排队。教务处工作人员后台批处理学生申请,工作环境大大改善,工作效率提高。第三轮选课的两周内,共接受1731名学生的3477条需求,实际受理过程中分为923个教学班批处理。根据提交日期统计的需求如表1所示。
根据统计可以看出,第一周申请数约为第二周的两倍,每周一和周二为申请高峰期,这段时间教务处工作人员需加强配备,以确保学生及时得到反馈。
系统实际运行收到了较好效果,但还存在可扩展的空间。目前的系统实现了新选课需求数据与教学管理数据库的融合,但学生平台尚未集成入学生选课系统,下一步将考虑学生选课系统与学生平台的无缝集成。
参考文献:
[1]杨延红.信息子系统在管理信息系统中的作用[J].科技信息(学术研究) , 2007(13).
[2]朱健等.新形势下高校教务与教学管理信息反馈科学化模式探讨[J].科教文汇(上半月), 2007(3).
[3]王冰.对信息技术推动下教学管理工作的几点思考[J].黑龙江科技信息,2008(4).
[4]夏瑜等.略论基于B/S模式网络课件练习系统[J].江苏广播电视大学学报,2002(3).
[5]魏平.基于C/S和B/S混合结构的工具管理系统的研究与开发[D].西北工业大学,2004.
篇5:四级数据库技术需求分析复习要点
2、DBAS需求分析是在已经明确的DBAS系统范围基础上,通过对应用问题的理解和分析,采用合适的工具和符号,系统地描述DBAS的功能特征、性能特征和约束,并形成需求规范说明文档;
3、需求分析过程由需求获取、需求分析、需求描述和规范说明、需求验证等组成;
4、DBAS的需求分析包括:
(1) 数据需求分析;
(2) 数据处理需求分析;
(3) 业务需求分析;
(4) 分析数据库系统在性能、存储、安全、备份与恢复等方面的要求;
2.3.1 数据与数据处理需求分析
1、数据需求分析:是从对数据组织与存储的设计角度,辨识应用领域所管理的各类数据项和数据结构,与数据处理需求分析结果一起,组成数据字典;
2、数据处理需求分析:是从数据访问和处理的角度,明确对各类数据项所需进行的数据访问操作,分析结果可表示为数据流图或事务规范;
3、事务规范包括:
(1)事务名称;(2)事务描述;(3)事务所访问的数据项;(4)事务用户;
2.3.2 业务规则需求分析
1、业务规则需求分析:是从DBAS高层目标和整体功能出发,分析系统或系统中一些大粒度子系统应具有的业务类型和功能,明确用户或外部系统与DBAS的交互模式;
2.3.3 性能需求分析
1、DBAS的性能指标:
(1) 数据操作响应时间(或数据访问响应时间):从提交请求到返回结果的时间;
(2) 系统吞吐量:指系统在单位时间内所完成的事务或查询的数量,单位为TPS;
(3) 允许并发访问的最大用户数:在保证响应时间的前提下,系统最多允许多少用户同时访问数据库;
(4) 每TPS代价值,用于衡量系统性价比的指标
2、影响DBAS性能的因素:
(1) 系统硬件资源;
(2) 网络通信设备性能;
(3) 操作系统环境;
(4) 数据库的逻辑设计和物理设计质量,数据库配置参数;
(5) DBAS的配置和性能;
(6) 数据库应用程序自身。
2.3.4 其它需求分析
1、存储需求分析:是指估计DBAS系统需要的数据存储量,包括:(1)初始数据库大小;(2)数据库增长速度;存储总量估算可采用:根据数据字典中每个数据项的结构描述信息,估计每个数据项的容量,将所有数据项的容量累加;
2、安全性需求分析:
(1) DBAS系统应达到的安全控制级别;
(2) 各类用户的数据视图和视图访问权限;
(3) DBAS应有的口令保护机制或其它安全认证机制,用以控制用户登录数据库系统。
3、备份和恢复需求分析:
(1) DBAS运行过程中备份数据库的时间和备份周期;
(2) 所需备份的数据是全部数据库数据,还是一部分;
(3) 备份方式是采用完全备份还是采用差异备份。
篇6:数据分析领域人才需求
另,北京,上海,广州,深圳的人才需求又分别有多少?
或者,改成人才分布也行。
谢谢大神们?
相关文章:
数据信息统计分析系统01-12
智慧数据分析研判系统01-12
高空探测气象系统数据类型分析01-12
《管理信息系统MIS》课程设计教学大纲01-12
铁路售票系统数据分析01-12
网上购物数据分析系统01-12
敏感数据页面审计系统分析与设计01-12
商业智能数据分析系统01-12
气象数据分析系统01-12
会员数据分析系统01-12