数据库系统设计（精选十篇）
数据库系统设计 篇1
关键词：数据库设计,人才信息系统,SQL Server
一、需求分析
1.1业务流程图。业务流程图是用一些符号及连线来表示一个具体业务的处理过程。业务流程图是一种描述系统内部各单位、人员之间业务关系、信息流向的图表。业务流程图描述的是完整的业务流程, 以业务处理过程为中心, 按照业务的实际处理步骤和过程来绘制[1]。
1.2数据流图。数据流图以图形的方式描绘数据在系统中流动和处理的过程。它描绘出信息流和数据从输入到输出的过程中所经受的变换。通过对人才信息系统的业务流程图进一步抽象和概括, 得到系统的顶层数据流图。
1.3数据字典。数据字典是对所设计系统中数据做详细的描述, 是各类数据结构和属性的清单。它与数据流图互为注释。作为数据流图的细节方面的补充说明, 数据字典和数据流图一起构成一个完整的系统需求模型。数据字典一般应包括对数据项, 数据结构、数据存储和数据处理的说明。以下列出系统的部分数据字典条目。
1) 数据项。数据项名称:人员编号;别名:人才编号;符号名:ID;数据类型:字符型;长度:50;其余的数据项不再一一列出。2) 数据结构。名字:培训;别名:培训经历;描述:每个人的培训经历;位置:人才系统数据库;更多的数据结构不再一一列出。3) 数据存储。名字:人员基本信息表;别名:人才信息表;描述:记录人员的个人基本信息情况;定义:员基本信息表=编号+姓名+性别+出生日期+民族+籍贯+婚姻状况+学历+职称+培训经历+获奖经历;位置:人才数据库。4) 数据处理条目。加工名称:录入人员基本信息;流入数据流:人员基本信息;流出数据流:人员信息查询报表;处理逻辑:如果人员填写了人员基本信息表, 在人才信息系统中执行以下操作:管理人员登录系统, 按类别录入人员基本信息, 查看人员是否提供其它信息, 如有, 按要求录入, 录入完成可按要求查询输出。
二、概念设计
概念设计的目的是根据需求分析, 对收集到的数据进行分类、组织, 建立概念模型[2]。形成实体、实体的属性, 确定实体与实体之间的联系。实体间的联系有三种:一对一联系、一对多联系、多对多联系。
三、逻辑设计
逻辑设计的任务是把概念设计阶段中设计的E-R图转换为与选用DBMS产品所支持的数据模型相符合的逻辑结构, 即关系模型。根据概念模型向关系模型的转换规则, 将本系统的关系模型设计如下:
1) 人员 (人员编号, 姓名, 性别, 出生日期, 民族, 籍贯, 政治面貌, 身份证号, 婚姻状况, 教育程度, 最高学位, 工作单位, 专业技术职务, 职位, 联系地址, 联系电话, 电子邮箱) ;2) 培训 (培训编号, 培训名称, 培训单位) ;3) 参加培训 (培训编号, 人员编号, 培训开始时间, 培训结束时间) ;4) 奖项 (奖项编号, 奖项名称, 颁奖单位) ;5) 获奖 (获奖编号, 人员编号, 获奖时间) ;6) 专家 (专家编号, 专家名称) ;7) 专家情况 (专家编号, 人员编号, 专家获取时间) ;8) 学习经历 (学习经历编号, 人员编号, 学习开始时间, 学习结束时间, 专业, 学习地点) ;9) 工作经历 (工作经历编号, 人员编号, 开始时间, 结束时间, 工作单位, 担任职务) ;10) 家庭主要成员 (家庭成员编号, 成员姓名, 成员单位, 人员编号, 关系) ;11) 职称变动 (职称变动编号, 人员编号, 职称名称, 获得时间, 聘用单位) 。
四、物理设计与数据库实施
数据库物理设计是为逻辑数据模型选取一个适合应用环境的物理结构, 并对物理结构进行时间和空间效率的评价。数据库实施, 就是根据数据库的逻辑结构设计和物理结构设计的结果, 在具体的DBMS支持的计算机系统上建立实际的数据库模式, 装入数据并进行测试和运行的过程。这里DBMS选择Microsoft SQL Server作为工具来实现。
本系统涉及的表有很多, 数据量较大。考虑到数据库的安全性, 将数据文件和日志文件分别存放在不同的磁盘中。除了默认的主文件组之外, 为数据库添加两个文件组, 方便数据的管理和分配, 加快数据的读取速度。
参考文献
[1]李希建.煤矿安全管理信息系统分析[J].贵州工业大学学报 (自然科学版) , 2005, 34 (2) .
在线答题系统数据库设计 篇2
选择题由choice_question和choice_answer组成，分别用于存储选择题的题目信息和考生的答题记录。
choice_question的各列分别用于存储题目的序号（主键，自增）、分数、题目、选项ABCDE、正确答案。choice_answer中的user_id、ques_id、answer分别表示用户id、题目id，作为外键分别指向qs_user表中的id和choice_question表中的id，为了提高当用户修改题目答案，即修改answer的速度，我们将user_id和ques_id作为主键，并建立索引。
判断题部分的judge_answer和judge_question设计思路和选择题部分是一样的。config表用户保存考试的开始和结束时间。所谓的修改考试的开始和结束时间，不过是不断update这条记录罢了。qs_admin，用户保存管理员的用户名和密码，管理员的密码加密规则是这样的。密文 = sunstr(md5(明文+“gxdr”),5,20);qs_user用于存储考生的信息
数据库系统设计 篇3
关键词：数据库；通信分系统设计
0 引言
在中国民用航空领域中，航空气象数据库系统需要具有飞行气象情报及气象资料的交换、备供、存储等能力，由相关网络设施、通信分系统及数据库分等部分组成。石家庄正定国际机场目前使用的该系统，与民航北京气象中心联网，接收并汇交相关气象情报及资料，向其汇交本地雷达、自观、报文等气象资料，同时接收其下发的国内、国际飞行所需的综合航空气象情报信息，为石家庄航空安全提供保障。下面将以通信分系统为例，以软件设计角度对系统需求、概要、详细设计等三个阶段进行简单解析，从而更加容易理解该系统的通信分系统。
1 系统整体结构设计
由上图所示，石家庄机场的航空气象数据库系统主要由气象数据收集处理和信息应用组成，展示时气象信息使用用户通过局域网，以web网页或飞行文件综合方式获取航空中所需气象情报。
业务处理部分主要包括气象数据库和通信分系统，可通过通信系统收集处理民航报告、常规报告、自动观测资料（AWOS）、风温廓线仪、自动站资料、Bufr资料、Grib资料、Fax资料、卫星云图资料、本地图形图像资料、多媒体资料、雷达等资料，随后，通过预报综合平台及网页版的形式进行气象信息业务的展示。数据库管理子系统采用客户机服务器方式，可对资料处理、数据库等进行实时监控和管理。有资料处理子系统和数据库管理子系统。
2 通信分系统需求设计
通信分系统是航空气象数据库系统中最重要的组成部分，它负责全系统的气象资料接收、检查与处理、发送，及请求的应答。本通信分系统分为通信系统以及监控维护操作平台。为数据库分系统和数据交换服务器提供数据源，支持一个数据源同时向多个本地相同数据库提供数据的功能。在系统设计时满足了以下需求。
2.1 在通信分系统中需要配备一个通信前置机，数据传输同时支持AFTN、PSTN和网络传输模式。
2.2 以安全可靠为重点，监控系统对监控的内容出现异常的情况下，以声音、闪烁或者不同颜色进行告警。
2.3 对气象资料的处理达到准确、及时，保证地区中心通信主机与地区中心数据交换服务器上的数据实时、完整、一致。
2.4 充分考虑操作的方便，将监控和操作与通信分系统整合到一起，开发以鼠标为主、键盘为辅的图形化操作界面。应有详尽的联机操作手册，界面设计合理，逻辑清晰，使用方便，颜色的搭配应美观大方。
2.5 与其他分系统间的接口要尽量简单，使各分系统故障时不影响其他分系统为基本考虑，并易于界定故障点。
2.6 利用通信中间件的开放性，与其他分系统的信息传输，尽量采用通信中间件。
2.7 通信分系统应用软件应设有守护程序，确保通信应用软件的主进程不间断运行。
3 通信分系统概要设计
通信分系统在概要设计时要求有以下约束条件。
3.1 安全可靠为重点，对气象资料的处理达到准确、及时。
3.2 充分考虑操作的方便，将监控和操作与通信分系统整合到一起，开发以鼠标为主、键盘为辅的图形化操作界面。应有详尽的联机操作手册，界面设计合理，逻辑清晰，使用方便，颜色的搭配应美观大方。
3.3 与其他分系统间的接口要尽量简单，使各分系统故障时不影响其他分系统为基本考虑，并易于界定故障点。
3.4 利用通信中间件的开放性，与其他分系统的信息传输，尽量采用通信中间件。通信分系统应用软件应设有守护程序，确保通信应用软件的主进程不间断运行。
4 通信分系统详细设计
通信分系统的详细设计，是根据上述功能需求书、功能规格说明书和概要设计说明书完成的，对通信分系统各个进程间的控制流程和数据流程，说明了组成各个进程的主要模块，每个模块的具体功能、输入、输出参数和数据流程，以及通信分系统与数据库分系统、图形图象制作分系统之间的接口、输入输出、数据流程。
4.1 系统程序结构
通信分系统的业务处理部分，包括通信主机上的通信软件和通信分系统的监视、维护和操作界面。业务处理部分是实时系统，负责不同气象要素收集、发送缺漏报文图形文件要报处理，通过MQ管道技术和多进程方式，提高数据处理效率，通过内消息队列管理，交换进程间信息及参数。异步线路资料的发送接收；气象资料的检查与处理；电报公报报告信息处理；监控、维护维修监控平台综合化；MQ通道管理报文处理发送；数据库落地文件的生成等，都是该通信子系统所包括的功能。
4.2 通信业务处理结构示意图（图2）
4.3 通信业务处理部分功能列表
4.4 通信分系统起始程序（inimss）
以系统起始程序为例，该程序对整个分系统使用的全程区进行起始，并按起始表格文件（$homw/ini/mssini.ini）的指定，在全程区生成所有表格，同时本程序还要起始作为信息交换的工作区（即各子分区）。
在本分系统中，大部分进程需要使用全程区进行控制信息（排队）及数据信息交换。为了方便全程区的使用，在每个使用全程区的程序中需要生成一个程序头，存放全程区各个表格的指针。对于该表格的生成，本分系统提供一个函数xmapse.c。xmapse.c的输入参数为全程区的名字，结果是将程序头进行起始，而该程序头的指针是pgl。
4.5 监控导航
依据航空气象用户尤其是设备保障用户的需求，提高监控维护的直观性和高效性，需要将运行状态、维护维修界面图形化，以监控部分导航条项为例，它提供监控功能的总导航，包括进程状态、线路状态、缓冲区及文件系统状态、排队状态、MQ队列及通道状态，操作系统状态。加载并显示相关界面，并将通过通信链路接收到的后台程序定时发送的监视信息显示在相关界面上。
5 结束语
通信分系统软件是航空气象数据库系统工程中的一个重要系统，在设计开发过程中，从用户的功能需求、非功能需求和系统的外部接口关系为设计依据，遵循工程的总体概念、体系结构和总体布局，完成了通信分统软件进行功能分解和部件级（CSC）模块等设计。
通过对通信分系统的解读思路，更可以完成对整个航空气象数据库系统的分析，通过深入解读分析系统的办法，提高了系统安全，因为这是深入做该系统安全保障的重要手段。
参考文献：
面向对象数据库系统设计 篇4
作为数据库, 最重要的估计是数据查询了, 面向对象数据同样如此。在这里, 我设计了以下查询语法:get (…) if (…) , 其中get里面是要查询的类, 类的属性等, 相当于SQL里面的select…where…。比如有类A, A中有一个属性a (数字型, 关于类型后面会说) 。则获取所有A类实例中所有a的值小于0的实例集合的查询语句是:get (A) if (A.a<0) ;
执行该语句应该要返回所有类A实例中所有a小于0的实例集合。具体使用方法如下:
(一) 单类查询
即在一个类中进行查询。如:get (A) if (A.a<0) ;就返回是所有类A实例中所有a小于0的实例集合。而不带条件的查询是get (A) ;这将返回类A的所有实例。
(二) 多类查询
如:get (A, B) ;将返回类A和类B的所有实例的数据。
(三) 方法查询 (暂不实现)
(四) 表达式计算
如:get (3+3) ;返回的将是6。
(五) 复杂查询
如:get (A.a+B.b, C, C.a/A.a) if (A.a
二、数据操作 (OML)
(1) 插入数据:new类名 (构造函数参数列表) ;这样即生成了一个实例 (即插入一个实例) 。举例如下:
Test t=new Test (1, 2, 3) ;//假如类Test的构造参数是三个数字类型的参数。
(2) 更新数据:直接调用该类实例的引用的属性复制即可实现更新。举例如下:
t.a=3;//假如类Test有个公有成员a且是数字型的。
可以有更复杂的、有逻辑的更新, 如:if (Test.a>3) {Test.a=1;//将所有符合条件的Test类的实例的a字段复制为1, 是集合操作。}
又如:while (t.a>0) {Test.a——;//只要实例t的字段a的值还大于0, 则所有Test的实例的值继续减一。}
(3) 删除数据:free (类名) if (删除条件表达式) 。如果没有if, 则删除此类的所有实例。free (Test) if (Test.a>0) ;这将删除类Test的实例t。
(4) 数据定义 (ODL)
定义语言包括类的定义和对象的定义。语法模仿的Java的语法。具体如下:
定义类:
class:定义类, 语法如下:class类名{
属性定义:其中包括变量权限声明, 值定义, 类型声明, 目前仅支持三种类型, 字符串型, 数字型和比特型。
方法定义:方法定义, 跟Java类似, 但目前仅留接口, 不做实现。}
下面是一个实例:
class Test{private num a;//数字型;public str b;//字符串型;protected byte c;//比特型, 变长比特型, 用来存储大容量数据;public void test Method (num a) {//方法定义, 目前暂不实现a++;this.a=a;}“;//”一定要加“;”号, 否则不能结束。
alter:更新类。语法如下:alter类名.字段名或者方法名=
{//字段或者方法的新式描述, 如果没有任何信息, 则表示删除该字段或者方法};举例如下:
alter Test.a{public num a;//如果不是命名为a, 而是b, 则将删除a字段, 新建b字段。
该语句将把字段a的访问权限从私有变为公有。下面是更新方法:alter Test.test Method{public void test Method (num a) {//方法更新, 目前暂不实现a++;this.a=a——};
drop:删除类。此关键字只有一个语法, 即:
drop类名;如:
drop Test;//即表示删除Test类。
(5) 数据控制使用try{//行为}catch () {}的语法形式, 用来控制事务。在try块中的行为必须全部执行成功数据库才会更改, 相当于事务提交。如果发生异常 (即不能全部执行成功) , 则事务回滚。同时还要执行catch块中的信息。一般说来, catch块中留空则只回滚事务。
参考文献
数据库课程设计+飞机订票系统 篇5
1.概述（设计题目与可行性分析）
1.1设计题目：飞机订票系统
1.2可行性分析
飞机订票系统是为机场工作人员和客户提供订票退票等与机票相关内容的管理系统，方便机场工作人员对机票的管理，以提高机场工作人员对机票管理工作的效率。当前飞机订票问题：手工订票所产生的客座率低。而我们的目标是：建立一个飞机订票系统数据库。
1.2.1研究现有系统，画现有系统的流程图
了解当前系统能够完成的功能及组成
航班管理：票据管理
售票点：直接面向用户 航班管理
票据管理
票库
订票库
订票管理
出售管理
打印机票
售票点1 售票点n
现有系统：票据都分布在各个售票点
1.2.2导出新系统的高层逻辑结构
数据流图的基本符号：
数据源/终点（人机界面）：
加工处理：
文件名
文件： 数据流名
数据流： 票价信息
机票
查订票号
订票处理
客户信息
出票处理
订票记录
顾客
订票信息
订票号
库存信息
票价信息
票价管理
航班管理
航班信息
操作员
航班信息
保存
新系统的数据流图：
说明：流向文件的数据流的名可以省略
1.2.3可行性分析报告
随着Internet的迅速发展和用户数量的急剧增加，互联网对于企业和事业单位的运营和发展日益重要，网上交易也逐渐被人们认可，并成为未来交易的发展方向。在这种情况下，很多原有的C/S模式的系统也逐步向B/S模式靠拢，飞机订票系统也不例外。
飞机订票系统是飞机旅游服务信息系统的一个重要组成部分。为旅客提供优质便捷的服务，为了提高飞机客运的售票效率，丰富飞机客运的营销手段，飞机售票总站的下属代售点可以通过公用的互联网资源，建立数据库，实现网上的售票，查询及管理工作。
2.系统目标和设计原则
2.1系统目标：
建立一个飞机订票系统数据库。
2.1.1系统简介：
本系统是专为乘坐飞机的旅客准备的，旅客只需把自己的信息（姓名.性别.工作单位.身份证号.旅行时间.旅行目的地）预先交给旅行社，旅行社就可以将信息输入本系统，系统就可以为旅客安排航班，打印出取票通知和帐单。旅客只要在飞机起飞的前一天凭取票通知单和帐单交款取单，系统校对无误即印出机票给旅客。
2.2设计原则
2.2.1根据实际情况考虑三种可行性
技术可行性、经济可行性、操作可行性
2.2.2提出侯选方案、提出各种各样的实现方案
主机（纯主机型、C/S型）、开发环境、网络方案、对提出的每个方案进行成本估计
硬件、软件费用投资（根据各公司的报价）开发成本估计（任务估算法）
运行费用、投资回收期
纯收入：通过本系统的运行、投资回收后的收入
3、描述推荐理由：分别从技术、经济、用户、投资方的不同角度考虑
3.支撑环境规划
3.1整体系统运作图
3.2运行环境
服务器：硬件配置：CPU Intel P4 1.2G以上
内存256 硬盘 80G以上
软件配置：Windows 2000/2003 SERVER SQL SERVER 2000 4.系统功能结构
1、录入：可以录入航班情况（数据可以存储在一个数据文件中，数据结构、具体数据自定）
2、查询：可以查询某个航线的情况（如，输入航班号，查询起降时间，起飞抵达城市，航班票价，票价折扣，确定航班是否满仓）；可以输入起飞抵达城市，查询飞机航班情况；
3、订票：（订票情况可以存在一个数据文件中，结构自己设定）可以订票，如果该航班已经无票，可以提供相关可选择航班；
4、退票：可退票，退票后修改相关数据文件；
客户资料有姓名，证件号，订票数量及航班情况，订单要有编号。
5、修改航班信息：当航班信息改变可以修改航班数据文件。
5.数据库设计
5.1概念结构设计
E-R图如下：
5.2逻辑结构设计
1．航空公司表：AIRLINE 2．客户表CUSTOMER
3、飞机表PLANE 4．航线表LINE 5．航班表FLIGHT 6．订票表BOOKTICKET
5.3实现设计
实现以下操作：
1、注册航空公司：
2、增加飞机：
3、增加航线：
4、增加航班：
5、增加客户：
6、建立一个订票的存储过程，存储过程名为Book_Ticket，请完成以下存储过程，实现订票的操作：
a)指定要订的航班号(HID)及客户的编号（KID）；
b)先查看客户是否为特殊客户，如果不是，票价不打折扣；
c)否则如果客户航程超过5万公里，票价7折，超过15万公里，票价打5折；
d)查看客户订票以后，所有乘客的票数是否超过总的座位数，如果超过，回滚订票操作；
e)要求在操作过程中使用到事务技术。
CREATE PROCEDURE Book_ticket @HID VARCHAR（20）
@HID VARCHAR（20）
AS DECLARE @TRANS_NAME VARCHAR(20)select @TRANS_NAME=’ ’
BEGIN TRANSACTION DECLARE @Bookid int,@seats int,@IsSpec char(1)/*定义订票里程DIST、折扣率discount、总的订票里程distance、票价PRICE（实型）*/ select @Isspec=Isspec,@distance=Points FROM Customer where select @discount=1 IF @ BEGIN
END /*选择出票价*/ SELECT @PRICE=PRICE FROM FLIGHT WHERE /*加入客户订票信息*/
/*将客户新订票里程的信息累计到用户信息里面*/
UPDATE SET WHERE /*查看客户订票后，是否超过可容纳的座位数目，如果超过，取消所有操作*/ SELECT booked=count(*)FROM WHERE FID= /*查看额定座位容量*/ SELECT @seats=seatsnum FROM WHERE
IF @BOOKED>@SEATS
ELSE
COMMIT TRANSACTION GO 7.运行这个订票操作的存储过程（自己设定客户及航班）
book_ticket , 8.事务运行成功后，再显示各表的数据，按表分别写出来。
6.总体实施计划
6.1可行性研究：
研究现有系统，画现有系统的流程图，编写可行性分析报告
6.2进行数据库设计：
概念结构设计，逻辑结构设计，实现设计
6.3概要设计：
从数据流图导出初始结构图，设计优化 6.4详细设计：
结构化的程序设计，采用流程图的形式
6.5保密设计
1.每个用户需要注册才能进入航空订票信息系统，并进行网上订票的。用户必须
用自己真实的身份进行注册。
2.系统要另外在备一份数据库，防止系统出现错误而使数据信息丢失的可能性。
3.系统要安装防火墙，防止黑客入侵破坏系统。还有就是安装杀毒软件，防止
病毒入侵而导致系统瘫痪。
6.6维护设计
系统设置提供管理员操作页面：
1.提供管理员密码,方便维护操作.2.固定时间对系统进行维护和检测.3.若系统出现瘫痪时,可出动备用系统维持运转.4.定期对系统进行更新整顿清空.7.总结
这次数据库课程设计的“飞机订票系统”，通过近一周的上机操作，充分应用了所学的数据库的知识，并去图书馆查阅了一些书集和上网搜索一部分相当资料，粗略设计出该系统。总体上来说，这次课程设计还是比较成功的，充分运用了所学的软件工程设计、数据库的设计，设计出E-R图、流程图、数据库基本表，从整体规划出了系统的运行环境和系统实现的功能。
当然，由于学艺不精，在课程设计的过程也碰到的一些问题。其中，画E-R图时，各实体中的关系的确定，由于对系统还不够了解而找不到一个准确的词来形容；总体规划时，材料太多，不易整理；相关数据库技术方面没有多注意，这次课程设计的重点只在对整个系统的总体思路设计。
其实这些通过最近的课程设计觉得最重要一点就是：我们一定要自己动手，这样才能真正的学到东西。书本知识固然重要，但我们更要学会将书本知识应用到实际的工作中。实践中才会发现错误，也才能改进，才能达到学习的最终目的。
最后感谢在这次课程设计中帮助过我的老师，同学!8.参考文献
物流信息系统
赵刚 四川大学人民出版社 2002/9 物流信息管理
尹涛 东北财经大学出版社
2005/1 数据库系统概论
王珊 萨师煊 高等教育出版社 2006/5 数据库技术与应用－Access2000篇 郭力平人民邮电出版社
2002/8 软件设计师教程 陈平禇华
数据库应用系统的性能设计优化策略 篇6
关键词：数据库应用系统；性能；设计；优化
中图分类号：TP311.13 文献标识码：A文章编号：1007-9599 (2011) 06-0000-01
The Performance Design Optimization Strategies
of Database Application System
Lin Shubin
(Agricultural School of Zhangzhou City,Zhangzhou363000,China)
Abstract:With the expanding database applications,enterprise-class database applications have become an important data storage and query method.Database performance and design optimization for the data structure to simplify and optimize the query process is important.This article discusses the importance of SQL databases optimization,detailed
analysis of the SQL database optimization strategy.
Keywords:Database applications system;Performance;Design;
Optimization
在一个基于数据库的应用系统的运行过程中，影响系统效率的原因是多方面的，对于目前常用的三层（N层）Web结构应用架构来说，如果系统运行效果不理想，需要判断性能损失来自于操作系统、Web层应用系统或者数据库，单独测试以确定瓶颈所在。
一、优化SQL数据库的意义
如果脱离Web层应用组件测试仍然存在性能问题，需要进一步跟踪数据库应用，判断开销主要来源于SQL还是PL/SQL，然后再进一步做性能分析。在数据库方面的原因 ，可能来源于数据库结构设计是否合理，磁盘空间和表空间的规划是否合理，SGA区设置是否合理，数据库参数设置是否合理，以及SQL语句的编写质量等。一般来说，数据库的结构设计、空间规划及参数调整、甚至是项目结构调整通常根据系统的需求而定，主要由系统分析员和数据库管理员来共同完成。实际上，不同的SQL实现方式之间的效率差异可能会非常大，尤其是在大数据量复杂数据库环境下表现尤为明显，对于千万级别数据量的数据库，执行一条关联几个大表的SELECT语句可能会消耗几十分钟，SQL语句的低效直接导致系统性能低下。高效的SQL语句来自于满足SQL语句的优化原则，使用充分的连接条件，优化的WHERE子句，以及适当的索引设计。可以利用一些工具，例如执行计划及跟踪文件等，帮助调试SQL语句以获得最优效果。下面先了解在构造SQL语句时应当遵循的一般优化原则。
二、SQL优化策略
（一）在SQL语句中，查询所有列时尽量不使用“*”’符号
我们在查询某个表的所有列时，经常使用SELECT*FROM table这种方式，注意“*”，符号的确是SQL语法许可的查询所有列的方式，但是这种查询方式，数据库服务器需要额外地去查询数据字典，把“*”符号转换为表的所有列，再将查询结果返回给用户。这个额外地查询数据字典的动作是会消耗系统时间的，所以建议在写SQL语句时，把实际列名写出，即使包含全部列，也就是使用SELECT deptno，dname，loc FROM dept而不用SELECT*FROM dept。
（二）编写SQL时使用相同的编码风格
SQL语句被发送到服务器进程后，要经过语句解析、语句执行以及返回结果几个步骤。在语句解析阶段，首先判断在共享的SGA区中是否能找到完全相同的SQL语句，如果找到就省去解析步骤，直接使用现有的执行计划，否则再去执行解析步骤。所谓完全相同是指SQL中的字段位置、大小写、空格个数等完全等价，SQL中所指的对象必须完全相同。
（三）使用TRUNCATE语句替代DELETE
如果要删除表的全部记录，可以使用不带WHERE子句的DELETE语句实现。但TRUNCATETABLE速度更快，并占用更少的系统资源和事务日志资源。DELETE属于DML语句，每次删除一行，同时在事务日志中记录删除动作，在UNDOSEGMENT中保存删除的信息，以备操作撤销，而TRUNCATE语句只在事务日志中记录所释放的数据页，不保留任何所删除的数据，所以速度比DELETE更快。执行DELETE语句后，表所占用的空间是不释放的，而TRUNCATE语句释放表所占用的全部空间。所以TRUNCATE是执行删除全部表记录时效率比较高的操作。
（四）在确保业务逻辑的前提下及时COMMlT提交事务
因为业务逻辑的要求，经常需要在事务中执行一系列DML语句，建议在保证业务逻辑一致的前提下，尽可能的多用COMMIT提交事务，这样可以及时结束事务，释放事务所占用的资源，例如回滚段中的空间占用、DML语句造成的锁、重做日志缓存区的空间以及Oracle Server为维护事务的内部开销。
（五）EXISTS和IN
在编写SQL语句时，经常需要在子查询中获取一个值列表，在主查询中使用IN去比较列数据是否在值列表中，这种方式实现SQL比较简单和结构清晰。OracleServer采用的是先对子查询中的表做全表扫描，获得查询结果，然后再执行主查询。而EXIST则是首先执行主查询，再运行子查询直到找到第一个匹配项。在大多数SQL调优的观点中，建议在业务密集的SQL当中尽量不采用I_N操作符，而使用EXIST替代IN，效率会提高。具体在选择IN或EXIST操作时，要根据主表和子表的数据量大小来具体考虑。如果两个表数据量相差悬殊，EXIST适合外表小而内表大的情况，N适合外表大而内表小的情况。
三、结束语
数据库是数据资料管理、存储与处理的重要技术，数据库系统的性能是决定信息资源使用效率的根本，如果在保证数据查询准确的同时提高数据查询的速度，是影响数据库系统应用效率的重要因素，只有完成性能优化才能保证数据库的高效利用，达到更高的资源应用要求、产生更高的价值。
参考文献：
[1]张君枫.Oracle数据库性能调整与优化[J].电脑知识与技术,2008,29
[2]朱建东,翁正平,柳庆武.Oracle数据库在属性数据管理中的另类用法[J].微机发展,2005,06
实时数据库系统结构设计 篇7
数据库技术作为信息管理系统的一种重要工具,从1969年IBM公司的层次数据库系统MJS的出现至今,经过短短40年历程,已从第一代的网状、层次数据库,第二代的关系数据库发展到第三代以面向对象为主要特征的现代数据库系统。
1988年发表的ACM SIGMOD Record实时数据库系统专刊揭示了TRDBS研究领域的诞生。所谓实时数据库系统(TRDBS)是指其事务和数据都有定时特性或显式的定时限制的数据库系统,即系统的正确性不仅依赖于逻辑结果,而且还依赖于逻辑结果产生的时间。RTDBS是数据库和实时系统的结合,它无缝集成两者的概念和要求以同时处理定时性和一致性,在对数据库管理和实时处理技术两者均有要求的各种领域有着极其广泛的应用前景,对多种工程或过程以及时间关键型应用更是必要而迫切的。实时数据库系统既可作为独立的系统存在,也可作为大型数据库系统中的嵌入部件[1,2,3]。
从面向应用的角度,采用基于“微内核”的实时数据库系统结构,研究基于“微内核”分层的TRDBS应用结构及实时数据库的功能模块实现和基于“微内核”的扩充机制时很有意义的。
2 实时数据库系统结构
实时数据库是整个RTDBS应用架构的核心,是设计与实现一个完整的实时数据库应用系统的关键,从系统功能模块组成结构看,如图1所示其主要模块有:
(1)实时应用:具有定时限制的数据库任务,实时事务的产生源。
(2)实时事务管理管理:实时事务的产生、执行、结束的整个生存期。
(3)实时并发控制:实现实时的并发控制算法。
(4)实时调度:实现实时的优先级调度算法。
(5)实时资源管理:包括CPU管理和缓冲区管理及实时数据管理,也包括各种数据操作、存储数据管理和恢复管理机制。
(6)实时I/O调度:考虑定时限制的磁盘调度算法。
(7)数据库状态更新:数据库必须提供尽可能最新的外部世界映像,也必须提供其它以前的状态。
(8)数据值时间一致:系统必须确保事务读取的数据是时间一致的。
3“微内核”结构设计
所谓“微内核”结构是指实时数据库系统核心仅负责事务分发、调度处理及资源管理,系统可以通过灵活可靠的方式挂接各种连接服务管理(包括网络服务、资源服务等)、主动机制实现程序、分布式应用服务及配置工具等外围子系统或扩展应用软构件,它们与RTDB运行核心分离。这样RTDB服务器可以为其它子系统和上层应用提供不间断的、高效的实时数据服务,同时针对不同应用结构提供极强的可伸缩性和可扩展性。
RTDBS核心采用的“微内核”结构,如图2所示,TRDB核心本身是一个高效可靠的实时数据管理系统,它的外部对用户提供开放式接口,用户可以通过应用编程接口API或实时数据建模语言(TRL)编制的应用程序访问数据库。如用户可编写类似触发器机制的主动性应用程序[4],系统事件将触发用户编写的主动性应用程序对事件实时处理。将实时数据库应用系统设计为三层体系结构,分别为服务设备层、实时数据服务层和客户访问层。
(1)服务设备层由实时数据库系统中不同的物理设备组成,它们通过预定义的通信协议实现与实时数据库上的通信系统进行连接和通信。
(2)实时数据服务层是整个应用系统的核心和关键部分,主要负责接收、处理和存储来自服务设备层的实时数据。它的扩展服务有:通过数据整合或集成方式,用户可将实时数据定期发布到通用关系数据库中,将实时数据库作为其存储的一部分;用户可以通过API或标准查询接口对实时数据库进行访问,也可以利用系统中提供的其它接口工具进行统计、报警和实时数据的网络发布等。
(3)客户访问层主要指实时数据库浏览软件及对不同服务设备和应用环境进行配置和实时监控的组态软件等软构件在实时数据服务层的实时应用。
4 实时数据库“微内核”机制的扩充
采用“微内核”结构使RTDBS易于扩展,可以方便地构建面向应用的开放性实时数据库平台。下面从主动性能实现、分布式机制、与大型数据库连接及对多平台适应性等方面描述RTDB扩充的必要性及设计实现方法。
(1)主动机制的实现
实时系统一般都是反应式系统,实时监控的传感器收集实时数据,触发驱动实时监控系统工作运行。作为实时系统的实时数据库要同时存储数据库和控制知识,完善集成主动规则机制,实现实时数据库的反应式行为。集成于实时数据库中的主动规则,一般使用ECA(Event-Condition-Action)规则模型,同时对规则模型增加时间约束的表达和处理能力,并规定主动规则触发执行的优先级,保证规则执行的可终止性和结果的确定性。
RTDBS核心提供的数据访问接口可以用来编制类似触发器机制的主动应用程序,也可在实时数据库的功能层之间编写软中间件程序对相应的驱动事件进行主动处理。
(2)分布式应用机制的实现
分布式数据库是一组数据集,逻辑上它们属于同一个系统,而物理上却分散在用计算机网络连接的多个站点上,并统一由一个分布式数据库管理系统管理。通过合理地分布数据,使得数据存储于其常用的站点上,既缩短了响应时间,减少了通信费用,又提高了数据的可用性。数据的冗余存储还提高了存取数据的并发程度,大大提高系统的数据吞吐量和响应速度。
通常采用C/S架构在实时数据库“微内核”结构基础上实现分布式应用,实现方法是:在一个数据管理网络中使用多个实时数据库服务器节点为客户应用提供服务,每个服务器节点上运行稳定可靠的实时数据库核心,只需对网络上的节点配置进行修改就可以方便地提供分布式服务。网络通信的可靠性和实时事务的分布分别由挂接在“微内核”上的网络通信模型和负载平衡模型来保证。
(3)与大型数据库的连接
在保证实时数据库实时性的前提下,实时数据库可与商用数据库进行数据整合或无缝集成,以充分利用大型商业数据库强大的内置功能。实时数据库与商用数据库的整合可以由RTDBS核心中提供的开放式数据库访问接口来实现,但是两者的集成需要解决商用数据库与实时数据库的同步问题,解决思路是在商用数据库中驻留实时数据库的完全备份。实际应用中可根据应用系统的需求和环境采取合适的连接方法。采用“微内核”机制的RTDBS由于分离出了实时数据库核心,可方便地通过组态配置“剪裁”实用的外围子模块,也可采用通用的数据管理方法和系统资源服务以尽可能屏蔽底层应用环境,只需极少量移植TRDBS“微内核”就能从一种系统环境应用于另一种系统环境。
5 总结
实时数据库系统融合了数据库系统和实时系统的特征,在网络管理、过程控制及智能设备等领域都有着十分广泛的应用。本文在简要介绍了实时数据库概念的基础上,“微内核”分层的TRDBS应用结构及实时数据库的功能模块实现和基于“微内核”的扩充机制进行了较深人的探讨,并提出了具有一定创新性的解决方案和创新思想。随着现代数据库技术的发展和RTDBS应用领域的进一步深人,基于“微内核”的实时数据库系统以其灵活性和开放性的架构必将有着更广泛的应用。
参考文献
[1]刘云生.现代数据库技术.国防工业出版社,2001.
[2]何新贵,唐常杰等,特种数据库技术.科学出版社,2000.
[3]马国华.实时数据库及其管理系统.自动化博览,2002.
管理信息系统的数据库设计 篇8
一、管理信息系统概述
管理信息系统简称MIS, 它是从管理、信息、系统三个概念的基础上发展起来的一个用于管理方面的系统[2]。它综合运用计算机科学、应用数学、管理学、决策理论以及运筹学等学科知识, 面向管理, 利用系统的观点和数学的方法及计算机应用三大要素, 形成具有系统型、交叉型和边缘型特点的一门学科[3]。管理信息系统不仅是技术系统, 也是一种基于计算机的人机系统和社会系统, 它为管理决策的科学化提供服务[4]。因而管理信息系统极为适应当今信息技术快速发展的特点和信息科学化管理的需要, 受到越来越多的重视和应用。
二、管理信息系统的数据库设计
(一) XX科研系统数据库的需求分析
数据库的需求分析简单地说就是分析用户的要求。需求分析是设计数据库的起点, 需求分析的结果是否准确地反映了用户的实际要求, 将直接影响到后面的各个阶段的设计, 并影响到设计结果是否合理和实用。
XX科研系统的数据库的需求分析是在用户提供需求说明书的基础上, 通过对系统功能和结构的理解, 经过我们与用户面对面的进行分析得来的。由需求分析可以得到其数据库设计的内容为:
1) 基础数据。基础数据模块主要是对一些基本的数据信息进行分类处理, 其中包含很多部分。例如:学院、机构、重点研究基地、人、职称、学历、项目来源、项目分类、学科分类、结算办法、退费比例、鉴定方式、奖励种类、奖励等级、发明类型、论文分类等31个基本组成类别。2) 合同管理。合同管理模块中主要是对合同的一些基本信息进行管理, 数据项和数据结构简单分析如下:合同:项目类型 (纵向、横向) 、项目状态 (立项、申请) 、合同总数 (数据库中现有的合同数量) 、合同号、合同名称、合同金额 (合同总金额、我校金额、转出经费) 、实到经费等。3) 经费管理。经费管理模块主要是按照经费的处理流程来进行分析设计, 分为到款、入账、结算、转账、退费和分配几个小的模块。4) 论文管理。论文管理模块包括著作论文、期刊论文和会议论文三个小的模块。5) 成果管理。成果管理模块包括鉴定、奖励和专利信息三个小模块。
(二) XX科研系统数据库的概念结构设计
数据库的概念结构设计是将分析得到的用户需求抽象为概念模型的过程。XX科研系统数据库的概念结构设计是在结合了需求分析和系统功能的基础上得到的, 采用的是E-R模型来表示, 由于论文篇幅有限, 本次仅列出总体的E-R模型。 (图1)
(三) XX科研系统数据库的逻辑结构设计
根据数据库概念结构设计得到的XX科研系统数据库E-R模型, 可以得到以下的逻辑结构模型。
1) 基础数据。学院 (院所名称, 科研负责人, 邮编, 传真等) 。机构 (机构名称, 批准部门, 所属学院, 学科分类, 组成形式, 联系电话, 实验室面积, 固定资产, 机构评估情况等) 。人 (姓名, 性别, 出生日期, 研究基地, 主要研究开发领域及成果等) 。职称 (编号, 名称, 代码) 。2) 合同管理。合同 (合同号, 合同名称, 项目类型, 项目状态, 合同起止时间, 是否归档, 最终结题方式, 研究进度, 项目完成情况等) 。3) 经费管理。到款 (到款日期, 来款单位, 到款日期, 来款金额等) 。结算 (结算日期, 合同号, 经费负责人, 结算办法, 经费卡号, 来款单位, 结算金额等) 。转账 (转账日期, 所属院系, 经费卡号, 转账金额, 合同号, 转入单位, 转入银行, 转入账号等) 。
论文管理模块和成果管理模块的关系模型类似于以上所列出的几个模块, 就不在列举了。
(四) XX科研系统数据库的物理结构设计
关于XX科研系统的数据表结构设计, 则依然是从基础数据模块、合同管理模块、经费模块、论文管理、成果管理五个部分入手设计进行;对于其关系模式存取方法的选择, 由于XX科研系统是多用户共享的系统, 这样对同一个关系要建立多条存取路径才能满足多用户的应用要求, 所以本人在XX科研系统数据库物理设计中采用的是索引存取方法。为了更好的提高XX科研系统查询的效率, 鉴于其合同和经费模块是科研系统中常用较多的两个模块, 因此对其涉及的几个主要的表包括合同 (projeet) 、到款 (outlet) 、入账 (outlet_in) 、结算 (outlet_js) 、转账 (outlet_22) 、退费 (outlet_tf) 等主要属性建立索引。同时根据系统的实际应用情况, 在XX科研系统的数据库中将表和建立的索引分开存放, 以此来达到提高物理1/0读写的效率的目的。
三、总结
文章主要分析和研究了管理信息系统数据库的设计部分。因此通过对其数据库设计的重点分析后, 我们可以看出在数据库的开发过程中, 对其数据库部分的设计必须要详细的分析, 这样才可能为后续整个管理信息系统的稳定运行提供后台保障。同时在具体的设计中要全方面考虑, 不能单纯的从技术角度, 还要结合管理和开发的资源及开发人员的能力等方面。
摘要：我们知道, 管理信息系统最为重要的支撑就是其数据库的搭建, 作为管理信息系统开发中的重要内容, 数据库结构设计的好坏会直接影响相关应用系统的运行效率及整个系统最终实现的效果。因此, 本文将重点分析这一模块的系统设计, 对其设计的需求, 及后续的逻辑和物理设计进行分析, 同时为了研究的必要, 文章以一个XX科研机构的管理信息系统 (简称:“XX科研系统”) 作为案例进行具体设计环节的分析及讨论。
关键词：管理信息系统,数据库设计,关系数据库
参考文献
[1]李彬, 何静, 张岩.管理信息系统的数据库设计[J].光盘技术, 2008.
[2]孟志伟.管理信息系统的数据库设计[J].数据库技术, 2009.
[3]杨瑞.基于WEB的教学信息动态管理系统的设计与实现[D].电子科技大学, 2012.
一种动态血压数据库系统设计 篇9
20世纪80年代末, 动态血压监测 (Ambulatory Blood Pressure Monitoring) 技术已趋成熟并应用于临床, 在高血压诊断、疗效观察及预后评估等方面提供了一些客观有效的依据及丰富的信息, 对高血压的早期正确诊断及有效治疗具有重要意义[1,2]。十多年来, 动态血压监测记录仪在我国县以上医院越来越普及, 但是动态血压监测记录的应用价值却未能在临床得以充分发挥。其主要原因, 一是目前尚未确立动态血压诊断的标准;其次是动态血压记录监测值未能有效地与临床高血压诊治及脑卒中防治密切结合。为此, 根据临床工作需要, 在既往建立简易的动态血压数据库基础上, 重新研制此通用型ABPM数据库系统, 使动态血压监测[3,4]更好地为临床诊治、保健咨询、积累临床数据及科研服务。这里简单地介绍此ABPM数据库系统。
该ABPM数据库系统是以日本产 (A&D) TM2421 ABPM仪记录的原始数据作为ABPM数据库系统的来源资料建立的。此仪器同时采用柯氏和欧氏两种方法监测动态血压, 其监测记录数据可转化到Excel表格[5,6]中 (或者说可以用Excel表打开) 。该ABPM数据库系统将Excel表格中的原始数据导入Access表中 (其他型号的ABPM仪, 只需将数据转变为Excel表形式就能使用该ABPM数据库系统) , 因为在多数情况下, 欧氏法测量记录的血压数值较准确, 故该数据库设计只导入欧氏法检测记录的数据, 并同时进行分析。
1 ABPM数据库系统
该ABPM数据库是以Visual Basic[7,8,9], Microsoft Office作为平台, 以SQL语言作为数据库查询语言。从临床应用上, ABPM数据库系统可分为3个部分:患者信息管理、ABPM数据的统计及报告、管理及检索。
1.1 患者信息管理
将每个被测者的详细情况以调查信息表形式录入ABPM数据库系统, 建立患者档案, 以利于临床对每个患者的检索查询、诊断、有效治疗 (治疗前后比较) 、保健咨询 (前后检测结果对比) 及管理与研究等。调查信息表包括患者的个人信息、病史信息、生活习惯信息 (饮食习惯、烟酒嗜好、锻炼状况等) 、家族史信息 (患者祖辈及亲属疾病史信息) 等8个信息表 (共120多项) 。为方便调查信息的录入和与国外研究机构进行合作交流, 调查信息表的绝大部分信息用英文填写, 只是在输出被测者的动态血压统计结果时采用中文信息。
ABPM数据库系统对患者信息的管理十分灵活, 即对调查信息表中的8个信息表分别进行管理, 其中包括患者每个调查信息表的录入、修改、搜索及删除功能。也就是说, 对患者的调查信息可以完整, 也可以简化, 只要输入患者的基本信息 (姓名、性别、年龄等) 就能实现对该患者的有效检索管理。患者调查信息录入简便, 在患者信息管理窗口中, 大部分信息采用下拉式列表框输入, 从而使录入信息速度及准确率有了明显的提高。此外, 在每个信息窗口中都用Data控件, 并与数据库中信息表的记录相连, 因此可以在每个信息窗体中浏览不同患者的信息。
ABPM数据库系统中设有患者检索窗口, 只要输入患者的姓名即可查对既往就诊史。在患者调查信息表窗体中设有搜索功能, 能够快速检索患者信息, 浏览既往信息及既往检测结果, 也便于管理及修改特定患者的信息记录, 同时为避免操作人员的误操作, 所有的信息框只有在添加、修改功能下方为可用状态。
1.2 ABPM数据的统计处理及报表输出
该ABPM数据库系统是将Excel表格中的ABPM原始数据导入到Access表中, 并同时对监测的原始数据进行分析处理。对于其他类型ABPM仪的数据进行处理的前提是将测得的ABPM数据按照下列两种格式转换到Excel表中。
格式一:在Excel中, 表头的顺序是日期、时间、柯氏收缩压、柯氏舒张压、柯氏心率、欧氏收缩压、欧氏舒张压、欧氏心率。
格式二:在Excel中, 表头的顺序是日期、星期、时间、柯氏收缩压、柯氏舒张压、柯氏心率、欧氏收缩压、欧氏舒张压、欧氏心率。
血压值的有效读数范围为收缩压 (SBP) 60～280 mmHg、舒张压 (DBP) 40～160 mmHg, 所以在处理数据时, 将此范围之外的记录作为无效记录。ABPM数据库分别统计出患者白天、夜间和全天的血压及心率平均值、大于 (SBP) 140/ (DBP) 90 mmHg的百分比、最高和最低血压值 (SBP和DBP) 及其发生时间等, 可以预览报表, 并将报表打印输出。
此外, 在数据库中专门设计“统计”表, 用来存放ABPM统计结果, 上述ABPM的各种统计结果也存放至统计表中, 因此也就实现了对监测结果的分类、检索和查询功能。
1.3 管理与检索
该ABPM数据库系统通过3个窗体实现对信息和数据的管理、查询和检索功能:
(1) 综合管理
进入“查询窗体”后可以快速直观地了解ABPM数据库的总体情况及统计类别[10]。
关于所有受测者的统计, 即分别统计出受测者总数及其中男、女性人数。受测者中不同年龄阶段的统计, 即分别统计出不同年龄阶段中男、女性人数及在该年龄段中男性所占的比例。女性受测者中不同年龄阶段的统计, 即统计出不同年龄阶段中女性受测者的人数及该年龄阶段的女性受测者占所有女性受测者的比例。男性受测者中不同年龄阶段的统计, 即统计出不同年龄阶段中男性受测者的人数及该年龄阶段的男性受测者占所有男性受测者的比例。关于所有患者的统计, 即统计出患者中男女患者的人数及男性患者占所有患者的比例。关于患者中不同年龄阶段的统计, 即分别统计出患者不同年龄阶段中男、女性人数及在该年龄段中男性所占的比例。
ABPM诊断高血压的判断标准为:日间、夜间、全天 SBP>140 mmHg所占百分比>10%;日间、夜间、全天 DBP>90 mmHg所占百分比>10%;SBP均值:全天>130 mmHg, 日间>135 mmHg, 夜间>125 mmHg;DBP均值:全天> 80 mmHg, 日间>85 mmHg, 夜间> 75 mmHg;血压统计值符合上述条件之一者诊断为高血压患者。
(2) 临床查询
它是ABPM数据库实现对患者进行既往检测结果查询、治疗前后对比、疗效观察等提供的有效工具。
它提供了两种查询内容, 即患者的监测次数查询和序列号查询;提供了两种查询方式, 即姓名查询或以序列号查询。因此, 用它可以快速确定患者是初次监测, 还是重复监测, ABPM的次数。使用ABPM数据库序列号可以迅速地检索出以往ABPM数据, 以便作为前后对照、治疗前后对比及确定疗效等, 使ABPM数据更有效地为临床服务, 为有效降压治疗提供可靠的保证。
(3) 科研应用
该ABPM数据库是临床积累病例、分类管理、快速筛选, 获取有用科研数据等的强有力工具。
选择“统计管理”在“信息查询”窗体选择该项后单击“进入查询/统计状态”即进入“基本信息查询”页面。这里操作者可根据不同的检索方式获取所需要的信息和研究分组等。在数据库中的两个综合表:“患者所有信息表”和“中风危险因素筛选模板”, 实现了综合检索与查询功能。“患者所有信息表”囊括了受测者的个人信息表中的全部信息和ABPM结果统计数据;“中风危险因素筛选模板”可对受测者的大部分可检索性信息以及ABPM结果进行项目检索、分类查询及分组等, 实现高效快速获取有效数据的功能。“中风危险因素筛选模板”中罗列了受测者的个人信息 (如:性别、年龄、身高、体重、BMI、饮食咸淡、吸烟、饮酒、职业、现病史、既往史、家族史等) , 直到ABPM结果的多项查询途径, 根据研究需要可分别对任一项目进行单独检索或对多项进行综合检索。举例:根据吸烟状况作单一因素筛选分组, 可在“吸烟”下拉框中选择“No”或“吸烟”, 迅速选择查询出所有非吸烟者或吸烟者分组;根据吸烟状况也可作多因素筛选分组, 如分别筛选性别及年龄, 除在上述 “吸烟”下拉框中选择“No”或“吸烟”外, 再分别在“性别”下拉框中选择“male”或“female”和在“年龄”下拉框中选择相应的年龄段, 即可获得有关吸烟者或不吸烟者的不同性别、年龄的分组。
ABPM提供了丰富的观测数据[11], 根据监测时间设置间隔的不同, 24小时定时监测记录的SBP, DBP和心率 (HR) 值数以百计, 计算机可以快速统计处理这些观测指标, 提供科研数据。除上述临床报告统计数据 (如:24小时、白天和夜间的SBP, DBP及心率的均值, 大于140/90 mmHg的百分比, 最高和最低SBP和DBP血压值及其发生时间等) 外, 还有平均血压 (MBP) 、脉压 (PP) 及其24 h、白天 (D) 和夜间 (N) MBP, PP的均值;血压变异性 (BPV) 表示一定时间内血压波动的程度, 分别以24 h、白天和夜间的SBP, DBP的标准差表示, 包括24 h SBPV, dSBPV, nSBPV, 24hDBPV, dDBPV, nDBPV等;血压变异系数分别以24小时、白天和夜间的SBP, DBP的标准差/均值表示;夜间/白天血压比值采用夜间和日间的SBP, DBP, MBP, PP均值, 分别计算其比值;血压负荷表示血压超过某个阈值 (正常值) 水平次数的比例, 也就是说, 24 h、日间和夜间内SBP或 DBP超过正常范围次数的百分数;24 h血压波动曲线及曲线下面积等。
国外也有大规模的临床ABPM研究基于医院数据库系统, 国内廖禹林等编制了BY960动态血压数据管理程序, 是用于ABPM数据的处理系统, 该通用型ABPM数据库系统综合管理患者信息与ABPM数据处理, 为临床提供ABPM报告、管理、查询及科研检索等有效的工具。该ABPM数据库将为国内ABPM正常值标准的建立、高血压的有效防治及中风的预防发挥作用。
2 结 语
该ABPM数据库是以Visual Basic, Microsoft Office作为平台, 以SQL语言作为数据库查询语言。该数据库有着友好的用户界面, 操作简便直观, 而且功能较全, 有着简易、快速的综合分析及分类分析能力, 为临床提供了一个ABPM报告、管理、临床查询及科研检索等综合功能的有效工具, 基本满足临床诊断及科学研究的需要, 具有重要的医学意义及应用价值。
参考文献
[1]张维忠.动态血压监测[A].刘力生.高血压[C].北京:人民卫生出版社, 2001.
[2]谢晋湘.24 h动态血压监测在抗高血压治疗中的应用与中国APTH临床试验[A].刘力生.高血压[C].北京:人民卫生出版社, 2001.
[3]黄克铭, 王慧, 宗惠英.血压和动态血压监测[M].上海:上海科学技术文献出版社, 2001.
[4]张开滋.临床心电信息学[M].长沙:湖南科学技术出版社, 2002.
[5]李飞.Excel 2002基础与应用[M].成都:电子科技大学出版社, 2007.
[6]谢柏青.Excel应用教程[M].北京:高等教育出版社, 2000.
[7]陈文军, 陈晓铭.Visual Basic.NET数据库编程[M].北京:清华大学出版社, 2005.
[8]陶宏才.数据库原理及设计[M].北京:清华大学出版社, 2004.
[9]徐保民.数据库系统原理与应用[M].北京:清华大学出版社, 2005.
[10]戚文航.原发性高血压[A].叶任高.内科学[C].北京:北京人民卫生出版社, 2000.
智能视频监控系统数据库设计 篇10
随着平安城市的建设和城市监控的普及,视频监控系统渐渐地融入了我们生活的各个方面。视频监控规模的不断增长,使得监控人员需要处理的视频信息越来越多,导致了监控人员视觉的疲劳和神经的紧张,严重的影响了监控效率。而智能视频分析技术应用到监控系统中,将风险的分析和识别转交给计算机或者芯片,使监控人员从“死盯”监视器的工作中解脱出来,极大的提高了监控水平。拥有高级智能分析的智能视频监控系统,不仅能大大增强监控的能力、降低不安全隐患,同时节省了人力物力,降低了成本[1]。。对于报警事件以及事前,事后报警信息的搜索也变得十分简单[2]。
监控人员可以在不同的摄像机场景中设置不同的报警规则,当目标在场景中出现了违反预定义规则的行为时,智能分析终端会把报警信息发送给监控客户端[3],客户端视频界面会出现告警信息来提示监控人员,同时智能分析终端会把此时的报警图片发送给存储服务器,以便日后查询和打印。整个监控阶段,系统会把监控的视频存储在存储服务器中,方便日后下载和查询。
用户可以在不同摄像机的场景中预设不同的报警规则,一旦目标在场景中出现了违反预定义规则的行为,系统会自动出现告警信息,提示监管人员进行进一步的确认和处理。
智能视频监控系统中的大量数据依靠数据库,数据库的设计对整个系统非常重要。本文将按照数据库的设计方法,详细介绍智能视频监控系统数据库的设计过程。
1 数据库需求分析
数据库需求分析的设计好坏直接关系到系统各项功能能否实现[4]。智能视频监控系统的主要功能是实现对视频场景中违反预定义规则的事件进行报警和查询。
智能视频监控系统的数据处理流程见图1。
(1)管理员需求
(1)管理员通过密码认证后登录系统,实时监控视频,查询和打印历史报警图片,浏览和下载监控录像。
(2)超级管理员可执行(1)中的操作,可以添加、修改和删除数据,如监控终端设备的名称、位置。管理员的账号、姓名、性别和操作权限。
(3)普通管理员不可以添加、修改和删除数据,只可以执行(1)中的操作。
(2)视频数据和报警图片存储需求
(1)智能视频分析终端会把实时的视频文件保存到存储服务器中,并把视频报警设备的信息、视频文件的开始时间、结束时间和保存路径存入数据库中。
(2)当视频场景中违反预定义规则的事件时,智能分析终端会把此时的图片保存到存储服务器中,把报警设备的信息、图片的抓拍时间、报警类型和路径存入数据库中。
(3)历史文件查询需求
(1)管理员可以通过监控设备的名称、位置、报警类型、报警时间来查询报警图片和打印图片及相关信息。
(2)管理员可以通过监控设备的名称、位置、录像的时间范围来查询历史监控录像,浏览和下载。
2 概念结构设计
概念设计的过程是将需求分析得到的用户需求,抽象为信息结构及概念模型过程。最好的工具就是E—R图模型,它是对现实世界的一种抽象,主要成分是:实体、联系和属性[4]。
本系统的概念结构设计主要是根据需求分析对每类数据进行属性分解和关系分析,并根据系统数据流程,设计出E—R图。
根据上述需求分析,本系统设计规划得出的实体有:管理员实体、报警设备实体、设备监控位置实体、报警图片实体、历史录像文件实体。对每类数据进行属性分解和关系分析,并根据系统数据流程,设计出各个实体的E-R图。
图2为管理员E-R图,图3为报警设备E-R图,图4为报警类型E-R图,图5为管理权限E-R图,图6为设备位置E-R图,图7为报警图片E-R图,图8为历史录像E-R图。
实体与实体之间的关系E-R图见图9。
3 逻辑结构设计
在实体以及实体之间的关系的基础上,形成数据库中的表格和各个表格之间的关系[5],设计如下七个表:管理员信息表、管理权限表、报警设备信息表、报警类型信息表,报警设备位置表,报警图片信息表和历史图像信息表。
图片的名称是以设备ID和报警时间组合而成的,例如某张JPG格式的报警图片,设备ID为4并且报警时间是2011-09-01 20:12:23,则图片名为4_20110901_201223.jpg。图片的存储路径是指完整的存储路径包括图片名称,例E://AlarmPic/4_20110901_201223.jpg。这样每张图片就有一个唯一的路径与其对应。
录像文件的名称是以设备ID和开始录像的时间组合而成的,例如某录像文件的编码格式为H.264、设备ID为2、开始录像的时间是2011-09-11 12:00:00,则录像文件名为2_20110911_120000.h264。录像文件的存储路径也是指完整的存储路径包括文件名称,例E://VideoFile/2_20110911_120000.h264。每个录像文件有一个唯一的路径与其对应。
4 数据库开发工具
通过对系统的需求分析,本系统采用基于客户机/服务器结构的SQL Server 2005关系型数据库。SQL Server 2005是基于Client/Server体系结构关系型数据库管理系统,它具有可伸缩性、可用性和可管理性。它使用Transact-SQL语句在Server和Client之间传送请求[6],这种结构如图10所示。
5 结论
本文以数据库设计理论为基础,首先对智能视频监控系统进行了需求分析,接着,在需求分析的基础上,规划出系统的实体,设计了E-R图;最后,将E-R图转化为对应的表。
设计一个性能良好的数据库不是件简单的事情,首先使用优秀的数据库方法学是最基本的,其次在很大程度上依赖于设计者的经验,最后采用反复探索、逐步求精方法、逐步优化。这样最终才能设计出一个高性能且稳定性好的数据库。
参考文献
[1]anzerkampfwagenIV.现代安防离不开智能分析[J],中国公共安全(综合版):2010,(7):1-1.ANZERKAMPFWAGENIV.Modern Security can not Leave the Intelligence Analysis[J],Public Security of Chain(Comprehensive Edition):2010,(7):1-1.(in Chinese)
[2]范亚男,葛卫丽.智能视频监控系统发展及应用[J],价值工程,2010,(17):98-98.Fan Y N,GE W L.Development and Application of In-telligent Video Surveillance System[J],Value Engineer-ing,2010,(7):1-1.(in Chinese)
[3]杨红军.智能视频监控系统的设计研究[J].科技情报开发与经济.2010,20(4):110-110.YANG H J.Design and Research of Intelligent Video Surveillance System[J].Development and Economic Sci-ence and Technology Information.2010,20(4):110-110.(in Chinese)
[4]刘宏杰,王校民.数据库设计实例研究[A].2005-2006年石油行业计算机新技术应用交流会[C].北京:石油工业出版社,2006.358-359.LIU H J,WANG X M.Examples of Database Design[A].2005-2006Oil Industry New Computer Technology Appli-cation Exchange[C].Beijing:Publishing House of Oil Indus-try,2006.358-359.(in Chinese)
[5]教育部考试中心.全国计算机等级考试四级教程[M].北京:教育部考试中心,2010.Ministry of Education Test Center.National Computer Rank Examination Level4Tutorial[M].Beijing:Ministry of Education Test Center,2010.
