综合信息数据库系统

综合信息数据库系统（精选十篇）

综合信息数据库系统 篇1

关键词：信息交换,综合数据库,信息系统

1 引言

目前政府机构正面临着前所未有的巨大压力。一方面，随着经济的快速发展，政府机构需要在资源有限的情况下更快、更经济、有效地提供服务。另一方面，政府机构需要优化内部工作流程、提高工作效率、更好地收集和共享数据并控制成本。为了应对这些挑战，政府机构需要重新考虑如何转向和实施电子政务策略。而信息作为现代政府的宝贵资源，更是占据着越来越重要的地位，已经成为现代政府科学管理的基础，正确决策的前提，有效调控的手段。能否拥有及时、准确、全面的信息进行宏观调控，已经成为衡量政府机构能力的一个重要指标。

面对纷繁复杂的社会发展趋势，有条件的政府各职能单位也在立足于多年积累的数据和自身的特点业务上，建立了各自的数据库管理平台来适应自身发展。积累了大量的业务数据。这些业务信息系统为提高政府职能单位的工作效率，减少重复性的工作起到了积极的作用，为社会的发展做出了巨大贡献。就全国而言，从省一级由上而下的统一数据规划，形成综合数据管理系统就是要改变条块分割、各自为政的现状，加强与不同部门的协同合作，打破原有按职能部门条块分割的架构，整合不同的数据资源，实现跨地域、跨部门、跨层次乃至跨边界的综合的数据应用，最终为政府自身服务，为企业服务，为公众服务，这是政府加快信息化进程的需要，也是社会发展的必然趋势。

2 总体设计

2.1 系统设计目标

为进一步整合政务系统信息资源，推进我省电子政务建设快速发展，在充分利用现有各类资源的基础上，建立我省统一的电子政务综合数据管理系统。利用集中存储和分布存储两种方式，将目前分散在各委办局的专业数据统一进行整合。利用数据统计、分析、挖掘等手段，按照权限为领导、各级政务部门，以及公众提供数据资源服务，提高数据的利用率，确保数据的真实性，避免重复建设，消除数据孤岛。

2.2 系统设计原则

依照黑龙江省政府各厅局的业务需求，在系统设计方面，遵循了如下原则：

(1）统筹规划，分布实施。

在省电子政务建设领导小组的统一领导下，注重顶层设计，统一规划、统一标准。制定工程的进度，分阶段进行实施。

(2）整合资源，信息共享。

要充分利用现有各类资源，逐步将分散的业务系统的数据资源整合到综合数据平台上来，充分实现信息资源的开发利用和共享，充分利用现有资源和网络平台条件，防止重复建设。

(3）完善标准，规范制度。

根据目前各业务系统数字资源标准建设和执行情况，积极制定我省各类，特别是基础数据资源的数据标准和数据规范。同时要积极制定有关制度和地方法规，依法推进项目建设。

(4）保护现有投资。

力求对各相关职能单位业务系统无影响或最小影响。综合数据管理系统涉及的各相关职能单位都建有相应的业务系统，这些系统中产生的数据是一笔最宝贵的财富，项目实施的过程中，应在尽量保护现有业务系统前提下，对现有系统的影响降至最小。

(5）跨平台建设。

由于涉及的单位众多，各单位使用的操作系统、数据库存在一定的差异，在操作系统、数据库方面存在异构性。要实现数据在各系统间进行交换管理系统必须具有跨平台功能。

(6）安全可靠。

传输的数据是内部数据，且涉及到有关单位的行政管理工作，要保证数据的安全传输。整个系统的运行必须稳定可靠，系统设计必须采取严格的符合国家电子政务有关政策和规划的安全技术与措施。

(7）可扩展。

系统应具有较高的可扩展性，在业务不发生变化的情况下，支持后继工程中更多的部门接入综合数据管理系统。坚持开放性，采用国际标准，易于系统扩展和技术更新。

(8）易用性。

用户界面的设计方面，充分考虑用户的计算机应用习惯和使用水平，使平台界面友好、活泼美观、简洁实用、提示准确、易学易用。

(9）实用性与先进性相结合。

系统建设在功能设计上以实用性为前提，突出系统功能上的实用性和有效性;在技术方面以先进性为前提，通过先进的体系结构和开发技术确保系统的开发质量，以支持系统的可靠运行和可持续发展。

2.3 系统业务组成

综合数据库管理系统包括业务采集、数据转换对比、服务流程定制、业务流程定制、综合发布、配置管理等具体的应用,如图1所示

3 系统架构

3.1 框架设计

系统按照角色进行划分，分别为：政府各职能机构，相关领导，社会各企业，社会公众。通过综合数据管理系统为以上的四种角色提供相应的信息，信息的通道利用服务流程管理系统进行管理，既不同的角色所访问的信息深入程度是不同的，在安全体系保障前提下为各角色提供信息;同时，政府各职能机构也是信息来源的提供者，通过每个机构与综合数据管理系统的接口，利用数据封装的形式将信息传递到综合数据管理系统上。

综合数据管理系统通过业务数据采集与管理来分门别类的进行物理或逻辑形式的存储。信息的存储方式将通过业务信息管理系统按不同的业务模板进行管理。对综合数据管理系统的展示也将通过门户或其他形式展现出来。按照以上的模式，形成统一的综合数据管理平台，为全省各界服务。业务信息管理整合不同单位的简单业务，形成跨部门的、协作的业务流程。在综合数据管理系统的应用中，各相关职能部门除了需要处理自己的业务之外，还需要和其它部门之间开展业务交流和协作。同时通过服务流程管理向最终用户展现其所需要的信息的平台，它可以集成不同来源的信息和应用，为用户提供完整的应用视图。在服务流程管理之上的信息发布系统将为用户提供统一的平台接入、统一身份认证和统一资源调配，对内连接各个业务逻辑，促进各部门间的协同办公。

按照此种设计框架，承接在框架模式下的业务系统可以任意的增减，对服务者角色的变化可以进行随时调整，系统的分布也可以任意的调整，对系统的扩展性和分布性提供了强大的保证。

3.2 设计细节

3.3 系统总体结构

系统的总体结构基于B/S方式的“客户/W W W服务器/应用服务器/数据库存服务器”的四层结构，总体在网络上运行。

通过信息交换系统解决不同的职能单位数据库之间的数据共享、各应用系统之间的数据交换等。为了实现这些任务，信息交换平台在选择时需要解决：应用系统环境的不一致;数据库环境的不一致;数据格式不一致;与各种应用系统的无缝连接;不同系统间缺乏数据传递的统一机制等问题。

源数据通过采集、交换、对比等存储进入数据中心平台，通过数据综合发布平台(表示层)对外发布。如图4所示

在因特网上，职能单位将可公开信息按一定标准发布，提供给其他各职能单位、企业以及公众进行查看。同时信息的来源不需要重复提交，通过内外网交互的中间系统来实现内网信息向外网发布。在省政府专网上各职能部门同样通过信息交换系统将各自的业务信息进行交互，提供其他单位有效信息的同时还收集本单位业务办理需要的信息。

4 系统功能

如前所述，黑龙江省综合数据库管理信息系统主要包括业务采集、数据转换对比、服务流程定制、业务信息管理、数据综合发布、配置管理等具体的应用。

业务数据采集管理子系统主要实现不同政府机关及相关行业之间的信息和数据的采集功能。系统以各相关职能单位为基础，在纵向、横向上能实现平台对上对下的互联互通。同时，系统预留与其他系统的接口，并提供企业级管理的连接接口。能够满足多网络环境、多系统、多数据源条件下的数据采集需求。同时具备较高的系统响应效率和系统扩展性。

数据交换的目的是实现每个合法用户将其所要传输的数据包安全可靠地传输到指定的地方。数据交换支持常见数据库类型、多种业务类型、多种数据传输方式和网络特性，是各类应用系统共享信息资源的公共渠道，是应用系统扩展的接口;数据对比是按照预先定义的标准格式，对不同形式的上报数据进行解析，抽取数据主体进行转换和分类。如同一个企业信息在不同的数据库中表达方式不同，系统采用统一的标准和识别码进行验证。来实现冗余数据的剔除，有效信息的利用等功能。

服务流程定制子系统主要是为提高工作效率的一种模式;由于不同的领导、职能单位以及企业公众关心的数据不同，可查看的权限不同。在面对众多数据查看请求时系统面临着平台、协议、数据的差异，因此也需要通过服务流程定制子系统解决数据共享、集成和重组，而后再通过发布的形式解决数据集成和差异问题。

业务信息管理子系统是将多种业务数据服务组合起来，形成真正具有实用价值的组合服务。业务信息管理子系统能够集成不同部门的业务，开展协同的业务流程，实现跨部门之间的协同办公。

数据综合发布平台是实现对综合数据管理系统信息的统一公示，具备为各级领导、相关职能单位、企业、社会公众提供相关信息定制及查询服务，从而形成标准化等功能。

5 结束语

案例 数据库管理系统综合应用-- 篇2

数据库管理系统综合应用

-------图书管理系统系统一、实验目的：

通过完成从用户需求分析、数据库设计到上机编程、调试和应用等全过程，进一步了解和掌握所讲解的内容。

二、实验简述：

一个简单的图书管理系统包括图书馆内书籍的信息、学校在校学生的信息以及学生的借阅信息。此系统功能分为面向学生和面向管理员两部分，其中学生可以进行借阅、续借、归还和查询书籍等操作，管理员可以完成书籍和学生的增加、删除和修改以及学生借阅、续借、归还的确认。

三、实验要求：

完成该系统的数据库设计；

用SQL实现数据库的设计，并在SQL Server上调试通过。

四、参考答案：

1、需求分析（1）学生

学生的操作流程如图B.1所示。

登录查询书籍预定书籍续借书籍注销图B.1 学生操作分类表

（2）管理员

管理员可完成书籍和学生的增加、删除和修改以及对学生借阅、续借、归还的确认，其操作流程如图B.2所示。

登录书籍信息维护学生信息维护借阅图书确认归还图书确认注销图B.2 管理员操作分类表

2、概念模型设计

数据库需要表述的信息有以下几种：（1）图书信息（2）学生信息（3）管理员信息

（4）学生预定图书信息

（5）学生借阅归还图书信息

可以用E/R模型表述该模型的设计，E/R图如图B.3所示。

姓名学号学生预定续借系别书号借阅作者出版社图书书名归还语种出版年管理员编号姓名图B.3 模型的E-R图

3、逻辑设计

通过E/R模型到关系模型的转化，可以得到如下关系模式：

（1）Book（BookID，Title，Author，Publisher，Pyear，Language）（2）Student（ID，Name，Dept）（3）Assistent（ID，Name）

（4）BBook（BookID，StdID，BDate）（5）RBook（BookID，StdID，RDate）

（6）Lend（StdID，AstID，BookID，LDate）

2（7）Return（StdID，AstID，BookID，RDate）

说明

（1）书号是图书的键码，每本书有惟一的书号，一个学生可同时借阅多本书。一个管理员可处理多个同学的借阅等事宜。

（2）一般情况下，学生、管理员和图书之间的联系为1：1：n，借书关系Lend作为连接关系，其键码为n端实体集的键码，即书号为借书关系的键码。这反映了如果还书时也把当初的借书记录删除，则书号就能惟一识别一个元组。

如果还书时不同时删除借书记录，则意味着同一本书前后可借给不同的学生，于是学生、管理员和图书之间的联系变为m：1：n，这时借书关系的键码为书号和学号的组合。

如果在不删除借书记录的情况下，同一学生再次借同一本书，这时，学生、管理员和图书之间的联系变为m：p：n，于是，借书关系的键码为书号、学号和管理员号的组合。但这里有一个隐含的信息，即同一学生前后两次借同一本书所遇到的管理员不同，而这种不同可能仅仅是“日期”不同。因此，借书日期成了必不可少的成分，也就是说，在这种情况下，属性全集才是借书关系的键码。

总之，借书关系的键码与图书管理模式有关，读者可按照自己的理解确定键码，并编写相应的事务处理流程。其他关系也有类似之处。

（3）要知道图书当前的状态，是在图书馆存放，还是被借阅等，需要在Book的模式中增加对应项用以表示图书当前的状态。比如我们增加State，并且约定取值和状态的对应关系如下：

1）在图书馆中并且没有被预定 2）在图书馆中并且已被除数预定 3）被借出并且没能被预定 4）被借出并且已被预定

4、物理设计

为了提高在表中搜索元组的速度，在实际实现的时候应该基于键码建立索引。下面是各表中建立索引的表项：

Book（BookID）

Student（ID）

5、用SQL实现设计（1）建立Book表 CREATE TABLE Book（BookID

varchar（20）PRIMARY KEY，Title

varchar（50）NOT NULL，Author

varchar（50），Publisher varchar（50），Pyear

char（4），Language char（1）DEFAULT ’c’，State

char（1）DEFAULT ’0’）；

（2）建立Student表 CREATE TABLE Student 3（ID

varchar（6）PRIMARY KEY，Name

varchar（20）NOT NULL，Dept

varchar（20）NOT NULL）；

（3）建立Assistent表 CREATE TABLE Assistent（ID

varchar（6）PRIMARY KEY，Name

varchar（20）NOT NULL，）；

（4）建立BBook表 CREATE TABLE BBook（BID

varchar（20）NOT NULL，StdID

varchar（6）

NOT NULL，BDate

datetime

NOT NULL, CONSTRAINT FK_BBOOK_BID

FOREIGN KEY(BID)REFERENCES Book(BookID), CONSTRAINT FK_BBOOK_StdID

FOREIGN KEY(StdID)REFERENCES Student(ID)）；

（5）建立RBook表 CREATE TABLE RBook（BookID

varchar（20）NOT NULL，StdID

varchar（6）NOT NULL，RDate

datetime

NOT NULL, CONSTRAINT FK_RBOOK_BookID

FOREIGN KEY(BookID)REFERENCES Book(BookID), CONSTRAINT FK_RBOOK_StdID

FOREIGN KEY(StdID)REFERENCES Student(ID)）；

（6）建立Lend表 CREATE TABLE Lend（StdID

varchar（6）NOT NULL，AstID

varchar（6）NOT NULL，BookID

varchar（20）NOT NULL，4 LDate

datetime

NOT NULL, CONSTRAINT FK_LEND_StdID

FOREIGN KEY(StdID)REFERENCES Student(ID), CONSTRAINT FK_LEND_AstID

FOREIGN KEY(AstID)REFERENCES Assistent(ID), CONSTRAINT FK_LEND_BookID

FOREIGN KEY(BookID)REFERENCES Book(BookID)）；

（7）建立Return表 CREATE TABLE Return（StdID

varchar（6）NOT NULL，AstID

varchar（6）NOT NULL，BookID

varchar（20）NOT NULL，RDate

datetime

NOT NULL, CONSTRAINT FK_RETURN_StdID

FOREIGN KEY(StdID)REFERENCES Student(ID), CONSTRAINT FK_ RETURN _AstID

FOREIGN KEY(AstID)REFERENCES Assistent(ID), CONSTRAINT FK_ RETURN _BookID

FOREIGN KEY(BookID)REFERENCES Book(BookID)）；

（8）管理员操作 1）增加学生：

INSERT INTO Student(ID, Name, Dept)VALUES(#StdNo, #Name, #Dept);2）删除学生：

DELETE FROM Student WHERE(ID=#ID);3）修改学生信息：

UPDATE Student SET Name=#Name, Dept=#Dept WHERE(ID=#ID);4）增加书籍：

INSERT INTO Book(BookID, Title, Author, Publisher, Pyear, Language)VALUES(#BookID, #Title, #Author, #Publisher, #Pyear, #Language);5）删除书籍：

DELETE FROM Book WHERE(BookID=#BookID);6）修改书籍信息：

UPDATE Book SET Title=#Title, Author =#Author, Publisher =#Publisher，Pyear =#Pyear, Language =#Language WHERE(BookID=#BookID);7）学生借阅图书： BEGIN TRANSACTION INSERT INTO Lend(StdID, AstID, BookID, LDate)VALUES(#StdID, #AstID, #BookID, #LDate);5 UPDATE BOOK SET State=’2’ WHERE BookID=#BookID COMMIT;8）学生归还图书： BEGIN TRANSACTION INSERT INTO Return(StdID, AstID, BookID, RDate)VALUES(#StdID, #AstID, #BookID, #RDate);UPDATE BOOK SET State=’0’ WHERE BookID=#BookID COMMIT;（9）学生操作 1）预定图书：

CREATE PROC Book_Book

@BookID varchar(20),@StdID char(6), @BDate datetime AS DECLARE @TransName VARCHAR(20)SELECT @TransName=’Book_Book’ BEGIN TRANSACTION @TransName DECLARE @booked int, @book_state_before char(1), @book_state_after char(1)SELECT @booked=count(*)FROM BBook WHERE BID=@BookID IF @booked>0

ROLLBACK TRANSACTION @TransName ELSE BEGIN

SELECT @book_state_before=state FROM Book WHERE BookID=@BookID IF @book_state_before=’0’

SELECT @book_state_after=’1’ ELSE IF @book_state_before=’2’

SELECT @book_state_after=’3’

UPDATE Book SET state=@book_state_after WHERE BookID=@BookID INSERT INTO BBook(BID,StdID,BDate)VALUES(@BookID,@StdID,@BDate)

COMMIT TRANSACTION @TransName END GO 学生预定图书，假设图书已经被预定了，则不允许继续预定。否则的话应该根据图书是在馆内还是被借出去两种情况，修改图书当前的状态。最后在预定表中插入一条记录。修改记录和插入新记录应该发生或都不发生，所以将这个动作封闭成一个事务，保证这个操作的原子性。2）续借图书：

CREATE PROC Renew_Book

@BookID varchar(20),@StdID char(6), @RDate datetime AS DECLARE @TransName VARCHAR(20)SELECT @TransName=’Renew_Book’ BEGIN TRANSACTION @TransName DECLARE @booked int SELECT @booked=count(*)FROM BBook WHERE BID=@BookID 6 IF @booked=0 INSERT INTO RBook(BID,StdID,BDate)VALUES(@BookID,@StdID,@RDate)

COMMIT TRANSACTION @TransName END GO 学生续借图书，假设图书已经被预定了，则不允许续借。否则，在续借记录中插入一条记录就可以了。把这个动作封装成一个存储过程是为了使用方便明了。

由于这个数据库实际上更加偏重于模型化，而不是一个实际环境中的数据库，所以在实现应用模型的时候还需要对这个数据库的模型作一些修改。

6、实验总结

通过这次实验，进一步了解什么情况下使用事务。

综合地质数据库系统的研究与开发 篇3

关键词：旅游信息资源；数据库；系统设计

1引言

20世纪60年代以来，我国地质行业广泛开展地球科学的研究和地质矿产资源的勘查，获得了可观的纸质数据和电子文档。这些地质矿产资料具有阶段性、专业性、种类多和格式复杂等特点，且分散在多个部门，资料的完整性、连续性、继承性差。如何有效对这些数据进行存储、管理和充分利用成为国内外地学工作者共同关心的问题。通过对地质数据进行抽象分类，并利用先进的GIS组件技术以及关系数据库技术进行管理，有效地实现了综合地质数据的保存、管理、查询和利用。

2系统体系结构与功能设计

2.1系统体系结构

综合地质数据库采用C／S与B／S模式相结合的3层架构模式：显示层、业务逻辑层和数据层。显示层主要为客户端提供系统访问接口，即为用户提供数据显示和操作界面。在C／S模式中，显示层由系统客户端软件组成；在B／S模式中，显示层则由ASP.NET WEB窗体和代码隐藏文件组成，Web窗体负责向用户展示操作界面，而代码隐藏文件负责进行各个控件的事件处理。业务逻辑层完成系统主要业务逻辑并实现系统主要功能，不管是C／S模式还是B／S模式，综合地质数据库管理系统的业务逻辑大部分是一致的，故以ActiveX、DLL组件形式实现系统业务逻辑层的各个功能模块，然后将其封装到C／S与B／S服务器的业务逻辑层，以实现代码共享，确保代码一致性，提高开发效率和系统的易修改性。

2.2系统功能

系统以地质数据树为基础，将系统功能分为四大部分：一是地质数据树（地质分类树）的管理；二是地质数据的管理；三是系统与地质数据安全机制管理；四是地学三维建模数据输出管理。用户通过对地质数据树的管理实现地质数据分类管理，地质数据的管理则主要是指对地质数据的元数据和实体数据的管理。

3系统主要功能的实现

3.1地质数据的导入与导出

综合地质数据的导入与导出是在数据库应用与维护过程中经常涉及到的两个重要操作。导出与导入子系统为用户在应用程序层执行地质数据入库、地质数据专题应用提取、地质数据备份与恢复等工作提供了工具。

3.1.1属性数据和实体数据都导入Oracle数据库。这种方案容易理解和实现，将实体数据用BLOB字段进行存储，对数据量小的数据存储比较方便。但是当数据量比较大的时候，将会严重影响系统的效率。

3.1.2属性数据存在Oracle数据库，实体数据存在Serv U文件服务器。这种方案实现相对复杂，但是对于提高系统性能有很大的帮助。该方案在文件服务器上按照地质数据分类目录树的结构建立相应目录，然后将实体数据导入到相应的目录，属性数据导入到数据库。

3.2用户的管理权限

借鉴基于角色的访问控制（RABC）思想，在GeoDBMS中将地质数据树中各个结点视为数据资源对象，在各个结点上为每个用户指派角色，以此实现对地质数据的访问控制。

3.2.1权限管理数据库

该功能的实现涉及到数据库中多个数据表。用户表记录用户的用户名、密码等相关信息；权限表记录用户的操作权限，包括编辑、修改和删除等操作；角色表记录系统中所有角色的信息；角色权限表记录角色与权限的对应关系；用户角色指派表记录用户在地质数据树节点上的权限；地质数据树表记录地质数据树的节点信息以及节点之间的关系。

3.2.2系统结构

3.2.2.1权限浏览：该模块通过读取用户角色指派表信息，获取用户在地质数据树各结点上所被指派的角色，并从角色权限表获取角色所包含的权限，从而实现浏览用户在地质数据树各结点上所拥有权限的功能。

3.2.2.2角色权限设置：系统级管理员可以根据企业职能岗位的特点进行角色的定义、角色权限的分配等功能操作。

3.2.2.3权限管理工具：权限管理工具是系统提供给系统级管理员进行地质数据树权限管理的功能模块。在权限管理工具中，系统级管理员可以进行部门管理、用户管理、用户角色的指派，以及在不删除用户、角色、地质数据树结点的情况下停止用户在树结点上角色所拥有的权限。

3.2.2.4会话管理工具：在综合地质数据库管理系统中，将用户对地质数据树中结点所进行的一次访问（操作处理）称为用户与该结点所执行的一次会话，会话管理工具用于用户与系统的互动，使用户获得地质数据树中各结点的角色和操作权限的功能支撑模块。

参考文献：

[1]黄卫东.图书馆开发旅游信息资源的策略分析［J］.图书情报知识，2000（11）：28-30.

[2]张晶，牛淑红.图书馆开展旅游信息服务策略探讨［J］.图书馆理论与实践，2000（31）：33；49.

[3]张美英，夏斌.旅游信息数据库的需求分析［J］.云南地理环境研究，2000（32）：33-36.

综合信息数据库系统 篇4

为了能够将地籍管理、土地规划、耕地保护、地矿管理、土地利用、基本农田管理、执法监察等国土资源各相关部门关联起来, 实现各部门资源共享, 对现有的国土资源信息化建设成果进行整理, 建设国土资源综合数据库, 并建立国土资源数据综合信息系统。通过信息系统建设, 完善具体宗地历史信息, 提高工作质量, 实现地籍确权工作的矢量化和自动化, 避免工作人员人为因素造成的工作疏忽。

2 数据库设计

2.1 数据内容。

国土资源数据综合信息系统在数据形式上分为空间数据和非空间数据, 在数据内容上由基础地理数据、专题数据 (地籍数据、耕保数据、规划数据、土地整治数据、地矿数据、基本农田数据等) 、栅格影像数据、档案数据组成。

国土资源综合数据库以原始调查成果 (如1:10000、1:500土地调查数据, 遥感监测数据, 基本农田数据等) 为基础, 将原始调查成果直接导入, 同时增加各业务科室相关数据, 进行分层管理。

2.2 数据基础。坐标系:采用“1980年西安坐标系”;

高程基准:采用“1985国家高程基准”。

2.3 数据格式。

空间矢量数据全部采用SQL SERVER数据库存储, 影像数据采用img格式或者Tiff格式, 文档报告类数据主要是Word、Excel和Power Point文档。

3 系统设计

3.1 系统结构。国土资源数据综合信息系统采用B/S结构。

B/S (Browser/Server) 结构即浏览器和服务器结构。它是随着Internet技术的兴起, 对C/S结构的一种变化或者改进的结构, 简化了客户端电脑载荷, 减轻了系统维护与升级的成本和工作量, 降低了用户的总体成本 (TCO) 。

3.2 功能应用。

该系统地图数据的网络发布是在B/S模式下进行的, 同时考虑到系统定位成为国土资源内部提供服务, 非建库软件, 所以功能设计以查询、统计为主, 只提供少量编辑工具。系统通过内部网访问服务器中的数据和信息, 可以利用IE浏览器实现远程浏览地图和属性数据的各种操作, 并能实现数据报表打印等功能。 (表1)

3.2.1 地籍管理部分应用。

系统提供专题/符号化功能, 可以对当前地图进行划拨、出让、流转、集体、租赁、批而未供等多种专题渲染, 然后在行政区列表中选中某行政区, 使地图窗口中单独显示该行政区范围内的数据, 可以实现某镇的专题图, 直观、方便。

系统提供扫描件入库功能, 可以将扫描件按年代、按档案批量入库。浏览扫描件可以通过两种方式, 一种是根据档案号, 然后浏览该档案中所有的扫描件;另一种是通过年代查询, 查询后, 所有扫描件都会放到列表中, 通过列表的点击, 逐一浏览。

3.2.2 规划管理部分应用。

使用规划图形查询后, 在地图窗口中的规划图形上点击, 可以看到对应规划图形数据的主要属性信息, 不同类型的规划数据, 查看到的属性内容也不一样。

规划属性查询包括对土地整治和重点建设项目的属性查询, 支持组合查询, 指定好条件后, 满足条件的查询结果会放到列表里。在列表中, 能实现图形与属性的互动。

3.2.3 耕保管理部分应用。

系统可以从不同角度对基本农田数据进行分析, 可以按照保护级别、按照各地类、按照基本农田坡度、还可以按照行政区统计等等, 统计结果以统计图和统计表格体现。

3.2.4 地矿管理部分应用。

系统能够通过坐标导入或者在地图窗口中绘制一个任意区域这两种方式, 分析该区域中占矿产资源的情况, 包括现有矿山情况、占用保护区情况、地层、公益地质勘查规划区、地质灾害情况等等。

4 技术特点

海量数据的高效组织管理与访问

切实符合土地管理需求的多方面的统计功能

强大的海量数据统计分析能力

结束语

建立国土资源数据综合信息系统, 将土地调查基础数据与国土资源管理相关业务数据挂接, 为实施建设用地“批、供、用、补、查”全面监管提供基础信息平台, 避免日常管理工作中的重复征地和重复发证, 对国土部门日常管理工作的顺利进行, 提高政府管理水平和办事效率具有重要的意义。

参考文献

[1]调兵山市国土资源局.数据库建设指导方案.

[2]沈阳国源科技发展有限公司.调兵山市国土资源数据综合信息系统建设方案.

[3]国土资源部.国土资源信息系统建设规范.

综合信息数据库系统 篇5

（五）2006年11月21日

一、上报数据常见错误

本部分是各单位上报数据中出现频度较高的错误，请对照自己的采集表进行修正。

１、户籍所在地（补充）项目没有填写或者只填某居委会。具体到镇、街道派出所。２、机构信息没有填写。需在机构维护中填写。

3、职务层次：科员、办事员没有填写。

职务名称要按具体填写，比如某人在财务科担任科员，不能笼统填写：“科员或者财务科”，要填：“财务科科员”。

4、“现工作单位及职务”填写不规范。

填写单位规范名称和所在部门的名称，职务填写党委政府或组织人事部门正式文件任命的职务规范名称。

5、任职机构没有填写。

涉及到任职机构的，科员、办事员以及其它层次的都必须填写。

6、奖励情况子集填写不规范。

凡是省部级以下的都填奖励，不是荣誉称号，后边只填与之相对应的项目。奖励类别填：奖励，后边奖励对应的项目，涉及荣誉称号的项目就不用填。

7、实习（见习）填报不准确。

有过实习（见习）或正在实习期的人员必须填写。

8、考核中，实习（见习）期的考核结果一律选“当年新参加工作的”

8、学历子集填写不正确。

学历取得方式必须填写，认真区分“全日制”与“在职”，学历顺序必须填写。初中、高中毕业的要填写毕业学校，相应的时间都要填写。

（１）各类成人高等院校毕业生，应以国家教育行政部门或经共同认可的部门、单位出具的学历证明为填写依据；接受党校教育的，以各级党校出具的学历证明为填写依据，不得随意填写“相当于某某学历”。

（２）“全日制教育”栏填写通过全日制教育获得的学历；“在职教育”栏填写通过全日制教育以外的学习方式获得的学历。

（３）在党校学习获得学历的情况分为两类：一类是国民教育学历，通过全日制教育获得的填入“全日制教育栏”，通过在职学习获得的填入“在职教育”栏；另一类是党校学历，均填入“在职教育栏”，并在相应的学历前加“中央党校”或“省（市、区）委党校”。

（４）1970-1977年恢复高考制度以前入学的高等院校毕业生，填写“大学普通班”学历。

学位的填写：

（１）学位应填写在国内外获得学位的具体名称。（２）“全日制教育”栏填写通过全日制教育获得的学位。（３）“在职教育”栏填写通过全日制教育以外的其他学习方式获得的学位，包括各类成人高等教育（电大、函大、夜大、职大、业大、管理干部学院）、在职攻读硕士或博士研究生、在党校在职学习获得的学位、通过自学考试形式取得的学位。

“毕业院校系及专业”要填写与毕业证书一致的规范名称。

二、岗位标示为“公务员”的人员需要注意问题

1、以下人员按公务员填写，对于身份是否为公务员有疑问的，请向公务员管理科确认（8221957）。

a.参加97年公务员过渡并办理过渡手续的，现在仍是行政编制的；

b.军转安置到机关上，至今一直是行政编制的； c.提拔（调任）为行政单位担任副科级领导职务的； d．选调生以及每年考录公务员；

2、“姓名”填写户籍登记使用的姓名，用字要固定。少数民族译名的文字也要规范固定，不能用同音字代替。

3、“出生日期”按照中组部和省委组织部、市委组织部的有关规定，以组织认定的日期为准，使用阿拉伯数字按“年、月、日”格式填写公历日期，具体到日。

4、职务层次：科员、办事员都要填写，不能空着。职务名称要按具体填写，比如某人在财务科担任科员，不能笼统填写：“科员或者财务科”，要填：“财务科科员”。

5、“现工作单位及职务”，填写单位规范名称和所在部门的名称，职务填写党委政府或组织人事部门正式文件任命的职务规范名称。

6、学历子集的填写：参见第一部分。

7、个人简历中，要按照公务员在不同时期所在单位（包括内设机构）和所担任的职务分开填写，一般职务和单位有变化时都应当有所体现，级别没变，只是职务变化的也要分开填写。如，2000年1月，某甲在某局政工科任科员，2000年10月到财务科任科员，2006年任某局副局长，填写简历时，2000年1月至2000年10月某局政工科科员，2000年10月至2006年1月某局财务科科员，2006年1月至今，某局副局长。

基于数据库技术的物业管理信息系统 篇6

关键词 数据库技术；物业管理；信息

在物业管理中涉及到的数据较多。如为了更好地服务于业主及使用人，需了解业主及使用人的基本信息；为了保障建筑物及设施设备能够正常发挥其功能，需了解建筑物及设施设备的施工安装信息等。这些数据较复杂，除一般的结构化数据外，还有大量非结构化的数据，如图形、模型等，這给数据的有效管理带来了麻烦。在物业管理信息系统中引入数据库技术，解决了这一难题，使得数据的应用与存储独立，保证了数据存取的一致性。

一、数据库技术的历史和发展

数据管理是数据库的核心任务，内容包括对数据的分类、组织、编码、储存、检索和维护。从数据管理的角度看，数据管理到目前共经历了人工管理阶段、文件系统阶段和数据库系统阶段。

1.人工管理阶段

人工管理阶段是指计算机诞生的初期（即二十世纪50年代后期之前）。这个时期的计算机主要用于科学计算，从硬件看，没有磁盘等直接存取的存储设备；从软件看，没有操作系统和管理数据的软件。数据处理方式是批处理。

2.文件系统阶段

文件系统阶段是指计算机不仅用于科学计算，而且还大量用于管理数据的阶段（从50年代后期到60年代中期）。在硬件方面，外存储器有了磁盘、磁鼓等直接存取的存储设备，在软件方面，操作系统中已经有了专门管理数据的软件，称为文件系统，在处理方式上，不仅有了文件批处理，而且能够联机实时处理。

3.数据库系统阶段

数据库系统阶段是60年代后期开始的。在这一阶段中，数据库中的数据不再是面向某个应用或某个程序，而是面向整个企业（组织）或整个应用的。数据库系统解决了人工管理和文件系统的弊端，它把数据的定义和描述从应用程序中分离出去，程序对数据的存取全部由数据库管理系统（DBMS）统一管理。从而保证了数据和程序的逻辑独立性，这样，数据就可以供各种用户共享且具有最小的冗余度，若建立了一个良好的数据库管理系统软件，就可以为多种程序并发使用数据库提供了及时有效的处理，并保证数据的安全性和完整性。

二、物业管理信息系统总体设计

物业管理信息系统软件开发环境用Windows XP作为操作系统，以保证软件研究和开发后有好的交互性；用Access 2003作为后数据库操作语言，可用于各种平台的关系数据库系统，它具有功能强、使用简单、管理方便、运行速度快等优点，很适合于物业管理中的数据库系统；前端开发工具选用Delphi语言，实现有关界面和代码设计，作为当前最流行的基于Windows功能环境、面向对象的可视化应用软件开发工具，在数据库方面的优势尤为突出，Delphi连接数据库的数据引擎为主要有 BDE、ADO、dbExpress和InterBase。其中利用ADO技术可以访问本地或远程数据库，并且它具有速度快、占用内存少、直接使用API函数、支持Web应用开发、支持RDS（Remote Data Service）等优点。

三、物业管理信息系统数据库设计

1.数据库需求分析

根据系统要求和程序功能，系统需要以下数据：（1）业主和住户的信息。业主和住户的信息包括业主和住户的姓名、楼号、门栋、楼层、房号、面积、入住时间、联系方式等。（2）物业的信息。物业的信息包括两个方面：一是由建设单位或业主委员会在接管验收时移交的物业资料，如竣工总平面图，单体建筑、结构、设备竣工图，配套设施、竣工验收资料；设施设备的安装、使用和维护保养等技术资料；二是物业服务企业在物业维修保养过程中积累的资料，如维修计划、维修保养记录等。（3）物业管理方面的信息。物业管理方面的信息包括三个方面：一是管理基础资料，如物业服务合同、业主公约、与专业分包公司签订的专业分包合同、物业管理年度工作计划以及物业服务企业各项报告的批复等；二是管理标准、规章制度、管理服务实施细则等；三是有关员工的资料，如员工的基本情况、工作岗位变动及奖惩情况等；四是物业管理收费资料，如收费项目、欠费标准、交费情况、欠费记录等。

2.数据模块设计

利用Delphi中提供的数据模块窗体，可以避免通过向每个窗体中添加数据访问组件来访问数据库中的数据，在其他窗体需要访问数据库时，只需在其单元文件中引用数据模块的单元文件就可以直接访问到数据集中的数据了。

（1）给数据库建立连接

首先在窗体上添加TADOConnection组件，TADOConnection用于与一个物理数据库连接，它的CS属性用来制定数据提供者或服务提供者打开数据源连接所需要的信息，是多个字符串的集合。

（2）选择数据访问组件

在窗体上添加数据访问组件：TADOTable、TADOQuery等，用于访问磁盘上的实际数据库表或检索操作由一个合法的SQL语句生成的数据集。

（3）选择数据控制组件

利用TDataSourse控件来建立与数据访问组件的连接，它用于显示和编缉数据库中的数据。

数据库的应用在物业管理信息系统中起着重要的作用，它实现了系统中不同模块之间的数据信息共享。随着技术的进步，物业管理信息系统、业主终端系统、BAS系统、设备监控系统、保安消防系统、门禁考勤系统、一卡通消费系统、三表远传等将朝着共同集成的方向发展，这样数据库技术在物业管理信息系统中的应用将更为广泛。

综合信息数据库系统 篇7

关键词：数据库设计,人才信息系统,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) .

车载数据综合分析处理系统 篇8

1.1 开发背景

车载数据综合分析处理系统依托国家863计划重点项目——“最高试验速度400km/h高速检测列车关键技术研究与装备研制”, 总体研究目标是要研制时速400 km高速综合检测列车和建立地面数据分析处理中心, 满足京沪高速铁路等时速350km以上高速铁路基础设施系统调试、验收试验和动态检测的需要, 为构建我国高速铁路基础设施管理和养护维修辅助决策系统奠定基础。

项目要求研发新型车载数据综合分析处理系统, 实现多专业检测数据的统一存储管理集成, 为多专业的病害数据综合分析和评判提供手段, 实现基于精确里程同步的多专业检测数据透明访问、多专业检测数据集中处理、综合报表统一生成、大值病害数据在线报警和车地传输功能。

1.2 系统功能

车载数据综合处理系统由3个子系统构成:检测数据管理子系统、检测数据GIS综合展示子系统、波形综合展示子系统。

检测数据管理子系统实现以下功能: (1) 实时接收里程同步数据, 并向GIS综合展示子系统提供数据接口, 实时展示列车运行位置信息; (2) 向各检测专业用户提供检测大值数据输入界面, 实现大值报警相关数据的统一存储管理, 根据系统配置自动获取轨检、动力学检测的大值报警数据的相关轮轨视频数据、波形数据, 用于实时分析和综合评判; (3) 向各检测专业提供短信发送功能, 检测过程中可向指定手机号或地面接收设备发送报警信息; (4) 实现与无线数据传输系统的传输接口, 实时向地面数据中心转发列车运行定位数据、检测过程中出现的大值报警数据和大值报警附件数据, 可响应地面数据中心的请求传输指定数据; (5) 向各检测专业提供线路设备台账的查询功能; (6) 自动生成检测日报; (7) 配置FTP文件服务器和大容量磁盘阵列, 实现大容量检测波形数据的集中存储和管理。

检测数据GIS综合展示子系统实现以下功能: (1) 实现基于图形化的检测大值报警数据综合查询和形象化显示, 以图形化方式实时展示各检测专业的大值报警数据, 以不同颜色显示大值报警数据的严重程度; (2) 检测过程中实时展示检测列车的运行位置信息和当前检测交路、当前检测任务信息; (3) 用户可选择线路查询当前里程范围内的各检测专业线路设备台账。

波形综合展示子系统实现以下功能: (1) 检测过程中实时接收轨道几何检测、动力学检测、车体加速度检测、接触网检测的波形数据并存储在磁盘阵列上, 并能按里程同步显示接收到的波形数据; (2) 能够根据配置同步显示多专业检测波形数据, 检测过程中为轨道检测、动力学检测、加速度检测、弓网检测提供综合波形展示和相关性分析; (3) 能对比历史检测波形数据。

2 系统软件框架设计

车载数据综合分析处理系统总体由三部分构成:数据库系统、后台数据处理服务进程和用户操作界面。数据库系统采用Microsoft SQL Server2008大容量数据库;后台数据处理服务进程包括时空同步及里程数据接收进程、列车运行定位数据发送服务进程、大值报警波形视频获取进程、大值报警及非关键运行数据发送服务进程、地面请求指令响应服务进程;用户操作界面分为B/S和C/S 2种, B/S方式以IE浏览器为操作界面, 实现大值报警数及附件数据管理、系统监控、综合检测业务管理、GIS综合展示等功能, C/S方式主要实现实时接收里程同步数据、自动获取各种视频波形数据、向无线传输系统转发各种数据等功能。系统总体架构见图1。

2.1 检测数据管理设计

(1) 在一台工作站上安装反射内存卡, 采用VC++语言开发硬件接口和里程同步数据接收程序, 实时读取当前检测列车运行定位信息。实时接收里程同步数据流程见图2。

(2) 向各检测专业用户提供操作界面, 由各检测专业负责人管理大值报警数据和附件数据 (大值报警点波形截图) 并保存在数据库中;向各检测专业用户提供短信报警功能, 检测过程中各检测专业负责人可向指定手机号发送或群发报警短信;在数据库表中建立检测线路的工务、供电、信号设备台账, 提供查询界面, 按线路、里程、铁路局、设备类型等条件查询相关设备台账信息。用户界面采用Ajax技术和JQuery库相结合的动态页面刷新技术, 将用户界面分为菜单区和功能区, 上部是公共菜单区, 下部分是功能区。功能区左部分是检测列车运行信息及检测任务显示区域, 按每秒1次的频率显示接收到的检测列车运行定位里程数据和检测任务信息, 功能区右侧下部是系统的关键服务进程、无线传输系统状态监视区, 功能区右侧上部是用户操作业务功能区, 用户通过操作公共菜单刷新此区域内容。用户操作界面功能布局见图3。

(3) 轨道几何、动力学、接触网这3个检测专业的检测数据相关性最高, 出现大值报警数据时, 需要提供该大值发生时刻前后约30s的轮轨接触视频数据及车头、车尾视频数据和大值发生里程点前后约1km的检测波形数据, 用于综合判断;开发系统服务进程, 自动监视轨道几何、动力学、接触网这3个检测专业的大值报警数据, 自动获取大值发生时刻前后约30s的轮轨接触视频片段数据和波形片段数据, 作为该大值报警数据附件数据保存到数据库中, 当大值报警数据变化时 (检测日期、检测线路、里程点发生变化) , 系统能再次获取相关视频片段数据和波形片段数据。自动获取视频片段和波形片段流程见图4。

(4) 开发专用的通信服务进程, 实现与车载无线传输系统的接口, 向地面中心即时传输列车运行定位数据, 并转发大值报警数据和大值报警附件数据, 通过地面中心即时向全部铁路局发布检测列车运行的最新信息和最新病害数据;检测线路的管辖铁路局、工务段、供电段、电务段可通过地面中心向车载系统发送请求, 即时获取检测相关数据。

车载数据综合分析处理系统与车载无线传输系统的接口采用数据库表形式, 由数据综合分析处理系统通信服务进程将各种数据统一封装成固定格式的数据包记录, 每传输一次数据就向车载无线传输系统通信服务器数据库表插入一条记录, 由无线传输系统负责将此记录传输到地面通信服务器的数据库;同时地面通信服务器将地面中心的指令传输到车载通信服务器的请求指令表中, 由车载数据综合分析处理系统通信服务进程读取请求指令表, 将反馈的数据再次封装成统一格式的数据包记录插入到车载通信服务器数据表中, 实现对地面请求的回应。系统数据传输流程见图5。

(5) 开发统一的通信服务进程, 将大值报警的附件视频数据自动获取、波形片段数据自动获取、定时发送列车运行定位数据、自动发送大值报警数据、自动发送大值报警的各种附件数据、自动回应地面请求数据指令等服务进程封装成Windows标准服务并与服务器操作系统集成, 采用双机热备方式, 提供高稳定可靠的系统服务。

2.2 GIS综合展示设计

检测数据GIS综合展示采用层次化的思想和设计理念, 对整个展示所需涉及的各环节进行分层, 从上到下依次为用户接口层、地图处理层、数据处理层、数据库层, 各层分别完成各自功能, 并向上层提供接口, 这样的设计思路和处理方法有利于系统的开发和扩展。

用户接口层提供人机交互的用户界面, 用户可通过界面访问数据和功能, 并以形象友好的方式返回到用户界面;地图处理层负责从数据处理层获取数据, 形成地图语言, 并以可视化、形象化的方式展示在地图上;数据处理层分业务提供访问各类数据的接口及对数据进行初级处理, 为向上提供可用的经过分析处理后的数据。

GIS展示子系统分层结构见图6。

2.3 波形综合展示子系统设计

波形综合展示子系统软件架构采用基于C/S体系架构, 系统设计采用框架式结构, 包括服务处理层和客户端, 客户端又分为波形数据上传客户端和波形显示客户端, 并可响应其他外部数据请求, 所有业务服务采用服务组件方式提供, 采用多线程解决方案。此框架设计具有良好的重用性和可扩展性, 系统架构见图7。

波形数据上传客户端安装在轨道检测、动力学检测、加速度检测、接触网检测系统的工作站上, 读取各检测专业产生的CIT波形数据, 并通过Socket通信程序发送给服务处理程序。

波形显示客户端以图形化展示的方式实现各类具有里程信息数据的综合展示。借鉴图层概念, 即每个检测波形文件为一个单独图层, 各层均为透明显示, 享有同等绘图空间, 通过在通道配置文件中设置通道基线偏移值确定各通道绘制位置。设备台账类和数据集图层具有单独绘图区域, 既可与波形类图层并列显示, 也可叠加显示。前端展示层还提供放大、测量、打印、截图等常用分析功能, 并提供分析结果标注、无效区段标注及索引设置功能。

服务处理程序由CIT数据文件读取解析处理模块、数据库访问模块和数据分析处理、网络模块等组成。网络模块负责接收各检测专业客户端上传的波形数据并以文件形式存储在服务器磁盘阵列上, 在数据库中记录保存的CIT文件信息;数据文件读取解析处理模块负责对实体数据文件的读取;数据库访问模块封装了对设备台账数据、偏差数据、索引及标注数据等存储于数据库内的记录类数据的访问接口。

网络接口层采用“Socket通信协议+XML数据交换协议”为前端展示层提供数据服务接口, 包括网络传输、通信调度、状态监控、指令处理和数据封装等模块。网络接口层设计了一套数据访问指令集, 波形显示客户端的各种数据调用请求均以指令形式传输到数据处理层。

3 功能特点及实际应用

(1) 检测数据管理子系统通过CSS与Java Script技术结合使用, 在B/S界面下实现了动态菜单, 为用户提供美观、方便、简洁的操作界面, 系统运行界面见图8。

(2) 检测数据管理子系统自动根据轨检大值和动力学大值获取对应里程点的轮轨接触视频数和波形数据, 为检测人员在检测运营过程中准确分析判断大值病害提供依据。自动获取大值报警附件数据后查询界面见图9。

(3) 系统自动向无线传输系统传输检测过程出现的各专业大值报警数据和报警附件数据。系统可根据地面要求传送指定数据, 为地面中心实时分析检测运营中的大值报警数据提供有效手段, 为高速铁路稳定运营和辅助维修提供保障和支持。系统能监视各种数据的发送状态, 监视界面见图10、图11。

(4) GIS综合展示子系统在检测过程中可将检测大值报警数据信息按照不同专业分级别显示在地图上 (系统运行界面见图12) , 便于检测人员及时发现问题。

4 结论

新型车载数据综合分析处理系统在检测过程中为各检测专业人员的现场评判和数据分析提供了多种有效的评价手段和方法, 检测过程中大值报警能及时传输到地面数据中心, 及时向全路发布并实时预警, 实现了检测过程中车载系统与地面数据中心及检测线路的工务段、电务段、供电段一体化, 满足高速铁路检测运营和辅助维修要求, 保障线路的运营安全。

目前车载数据综合分析处理系统除应用在CRH380B--002外, 还应用于CRH380A-001, 并可用于升级0号高速综合检测车和CRH2-010A高速综合检测车的数据综合处理系统, 同时, 也能在地方铁路、城市轨道交通的检测车中推广应用。

参考文献

[1]中国铁道科学研究院.最高试验速度400km/h高速检测列车——关键技术研究与装备研制, 2009

[2]中国铁道科学研究院.400公里检测车综合系统实施方案ver1.4.2, 2009

综合信息数据库系统 篇9

1 分布式数据库的基本概述

针对于网络而言, 分布式数据库也是一种应用, 所谓的分布式数据库它主要是物理上分散而在逻辑上较为集中的一个数据库系统, 在分散这一概念上它主要就是说所使用的计算机网络的位置分布, 但是在其管理上以及控制方面有较为的集中从而形成多个逻辑单位与之联系起来, 进而构成了比较系统的数据库。

分布式数据库有着其自身的一些特点, 它具有着物理分布性和逻辑的整体性以及数据的独立性, 还有就是集中与自治两者相互的结合统一、适当的数据冗余度、全局的一致性等。而在分布式数据库的分类上主要有着两大类, 其一是同构分布式的数据库系统;其二是异构分布式的数据库系统, 而在同构型的数据库系统方面又可以分为同构同质型以及同构异质型。在分布式的数据库系统的体系结构方面主要由几个比较重要的组成部分所组成, 即:多台计算机设备, 并且这些计算机是通过网络来进行连接的;还有就是计算机的网络设备, 网络通讯所需的一组软件;另外就是分布式数据库管理系统以及数据库;最后就是分布式数据库的管理人员及其系统软件文档, 这些部分是分布式数据系统的一个重要的体系结构。

2 分布式数据库综合信息系统关键技术探究

在传统的技术上对于库区以及场所和人员的管理方法等通常都是依靠着人工进行定时巡查以及手工抄录登记等, 这些方式的效率以及安全的程度不是很高, 在这些比较传统的技术手段方面针对独立库区以及单位进行管理的时候就相对比较独立, 信息交换不够, 不能很好的实现统一的管理, 而分布式数据库的综合信息系统技术能够通过计算机以及各种传感器等较为先进的技术来进行实现网络化、自动化等统一的管理, 同时在库区的安全方面也得到了很好的提高。

基于分布式数据库的综合信息系统关键技术比较的广泛, 其中分布式的文件管理技术是对其数据的存储以及管理的一个重要的技术, 在当前的文件管理系统技术的应用方面主要就是在一些海量的用户互联网的企业中, 这一技术所使用的是一些较为经济的服务器搭建而成的文件管理系统, 这样就可以把数据存储在不同的服务器当中, 这一关键技术是通过关联连接以及分块存储和追加更新这些方式对于数据进行存储和管理, 虽然在数据存储上和以往相比有着很大的进步, 但是在较大文件的存储以及管理上还存在着一些不足之处, 为了能够对这些不足之处进行弥补, 就要对其增加缓冲层从而来对其在数据的存储以及保存方面的效率得到有效的提高。

还有就是数据分片技术, 也被称为是数据分割, 它也是分布数据库的一个比较显著的特征, 在对综合信息系统的数据分布的设计过程中, 分片技术是非常的关键, 这一技术还可以分为水平分片技术以及垂直分片技术, 其中水平分片技术它主要是对于全局关系所执行的一个选择的操作, 它把有着相同性质的元组进行分组, 从而构成了若干的不相交的子集;而垂直分片技术主要就是通过投影操作, 从而把其分成若干组, 进而再使得很多的应用只需要来访问一个片段进行执行, 它具有本地性的特性。

另外就是数据分布技术, 又被称为是数据分配, 它和数据分片技术有着紧密的联系, 这一技术的主要目的就是对于访问的局部性得到有效的提高, 也就是通过数据的合理分布最大化的把数据得到存储, 这样就能够对远距离的数据访问得到减少, 在对数据的位置分布得以确定之前, 要对冗余分配或者是非冗余分配进行确定。还有就是数据产讯访问技术, 它主要就是按照分布式的指导思想进行发展而成为对等处理系统的, 在准对等的分布式数据库的系统方面, 在这一服务器的数据库可以对于其它的节点进行提供服务, 在数据查询管理技术方面有着众多的功能, 例如它能够为应用程序提供统一的接口等。同时还有数据同步复制技术以及元数据被动触发更新复制技术和只读型业务数据主动同步复制技术、节点系统时间同步技术等。

3 结语

在当今的计算机技术迅速发展的时代, 对于分布式数据库综合信息系统关键技术的发展还有待进一步的提升, 在当前的这一系统最大的优点就是能够在很大的程度上满足以及适应应用节点分布于不同的地域信息系统对数据库的性能以及成本的要求, 在对其进行研究的时候要根据其自身的特点才能够有效的解决相关的问题。

参考文献

[1]张俊勇, 张鸣虹, 黄庆和, 周萍.分析测试实验室信息管理系统的设计与实现[J].计算机与现代化, 2013 (10) .

[2]左翔, 姜文彪.分布式数据库系统的设计与优化[J].赤峰学院学报 (自然科学版) , 2012 (20) .

综合信息数据库系统 篇10

1 现有信息化应用系统存在的问题

我院现有信息化应用系统,可分为两大类。一是为教学教务服务的应用系统,包括数字化学习平台、教学评价管理系统、课程进度表管理系统等。这类系统管理着以教学为核心的所有数据,可以实时跟踪和记录每位教师的教学信息,如授课内容、学时、地点、教学质量、学生评价等;学生利用学习平台自主学习情况等。另一类应用系统则是为教职工提供服务的应用系统,如信息发布系统、办公自动化系统、各种管理系统、查询系统、预约系统等,为广大师生工作和生活提供便捷的信息化服务。

然而由于各系统推出的时间不同,又相对独立,使得多数应用系统都有自己的数据库,要维护各自的数据,这给维护工作带来了极大的不便;而且因为系统之间的独立性,使得用户使用系统时,都要分别登录每个系统,造成不便,各系统间数据也难以共享。为此有必要研发一个适合学院自身情况的统一应用平台,整合正在使用的应用系统,建立统一的基础数据库,以实现数据共享,提高服务质量。

2 信息化综合平台的建设目标和内容

根据学院信息化需求,依托现有的成熟技术,规划建设的信息化综合平台包括以下内容:(1)统一基础数据库,包括学生信息、教师信息、附属医院教师信息、职工信息、课程信息、班级信息以及教研室、课程模块信息等,基础数据库数据更新的方式以提供数据的“权威管理部门”的更新为准同步获取,即与学院人事系统、学生管理系统、教务管理系统等对接实现实时更新。(2)建立综合平台,对学院现有应用系统进行整合,相关应用系统的数据实现共享,做到一个综合平台,一次登录,多种应用,自主定制,个性服务,实时推送。(3)依托该平台,逐步建立师生信息化档案系统,提供更高层次和可持续的信息化服务。(4)研发新的应用系统,增加平台的服务功能。

3 平台建设实施方案

3.1 平台内容设计

信息化综合平台主要有三个功能,一是建立和实现分散系统的接口管理,将这些系统的信息、用户入口与统一应用平台进行无缝整合,共享用户数据和基础数据。二是建立应用系统的管理中心,包括日志管理、服务管理,并将各个应用系统的基础数据统一在平台上进行管理,并利用各自的接口进行基础数据共享,保证基础数据统一、唯一,避免一个用户多套账号、多次登录的问题。三是建立应用服务中心,统一窗口,为师生提供学院所有的信息化服务,并为以后的信息化系统建设提供接口标准、开发格式,缩短开发周期。

实现上述设计和系统架构的难点在于分散系统公共接口的设计和应用系统数据的共享服务。这两项内容的实现,能够统一各个系统的登录操作,实现系统之间的交互,由此可以实现教师、学生在各个系统中的信息汇总,即师生应用档案,这将为广大师生提供更好更便捷的信息化服务,如教师档案系统能够根据基础数据的变化,更新教师授课内容、课时等,为绩效工资的评定提供基础服务。

(1)分散系统公共接口设计。各个系统最初设计的都是自备独立的基础数据管理,应用数据管理,但统一成综合应用平台后要将各个系统未来的基础数据,包括用户、班级、课程、单位等信息,统一交由平台的基础数据库管理,各个应用系统仅需要利用公共接口获取数据即可。平台采用PHPRPC轻型Web Service的方式[2],建立平台基础库各个数据的PHPRPC接口,各个应用系统安装PHPRPC客户端,请求平台基础库的所有数据,等同于访问系统内部的函数。我们为每个应用系统设置了独立的密钥,对接口传输的数据、请求的业务代码都进行密钥捆绑,并用MD5加密后传递,有效保障接口数据安全。

(2)应用系统数据共享服务。统一应用平台如果仅是统一基础数据库,那么这个平台的作用也仅限于接口中心,作用有限。因此,还需实现各个应用系统数据共享,并可在统一平台的窗口中及时浏览各个应用系统的信息,这样的统一策略才是目的所在。应用系统的数据共享,同样采用PHPRPC接口方式通过处理,不过这里是在每个应用中进行PHPRPC服务建设,将各个应用系统所需要的数据进行接口实现,并统一在应用平台中进行读取。每个教师、学生登录综合平台后,都可以看到本人在各个系统中的信息情况,如课程信息、评价信息、网盘信息、教学信息等。有了基础数据的共享和应用平台的统一,就可根据各系统的数据更新提供更加综合的服务,如教师、学生的档案系统。当公共接口设计和应用数据共享服务完成后,应用平台就可以为每个教师的教学信息、教学质量、评价效果进行归档,对学生的学习情况、评价效果、成绩等进行归纳及归档。这样可以形成师生在教学中的宝贵档案,而且能够跟踪到档案的每个细节。

3.2 平台实施方案

平台所承载的各独立应用系统,现都稳定运行,为了不影响现有系统的运行,平台的实施将分步进行。

(1)整合和处理所有应用系统的基础数据,建立标准统一、单点更新、多处共享的基础数据库。现有的各个应用系统,由于针对的用户群不同,基础数据并不完全一样,有的甚至没有交叉。因此整合基础数据是平台实施的重要一步,也是实施难点之一。根据现有系统数据情况,以数据最全的通讯录系统、数字化学习平台的基础数据为主,前者重点是学院的教职工基础数据,后者是涵盖学院所有师生,包括附属医院教师的信息。整合后建立教职工工号,以工号为用户名登录,学生以学号为用户名登录。

(2)实现基础数据库接口,完成新老系统的基础库统一管理。研发综合平台基础数据库的数据访问接口和统一登录窗口的方法是,对旧系统,考虑到这些系统还保留着很多与用户ID有关的应用信息,因此需要在登录时进行用户匹配,再生成系统的访问Session;而对于新系统,直接使用基础数据库的用户信息、工号、学号,减少基础数据库的建立。

(3)实现应用系统接口,采集各个系统的信息数据,建立教师、学生档案。利用PHPRPC,实现各个应用系统的信息共享接口,综合平台调用这些接口,实现每个账号的动态信息图,针对教师、学生建立完整的应用信息档案,方便将来学生的简历以及教师教学经历等信息的生成。

4 结束语

随着学院计算机网络应用系统的快速增加,数据实时更新和共享越来越重要,通过整合建立信息化综合平台,是提高数据共享和实时更新的重要手段,也是加快教育教学信息化发展的需要。只有实现数据的集中管理,应用数据的共享,才能提高信息化的服务效率,同时在资源方面、用户使用方面得到更大的优化。数据集中统一更新和管理,也有利于研发人员研发更多的应用,如教师教学档案,将是每个教师教学情况及相关数据的集中体现,大到工作量统计数据,小到教学细节、学生评价,虽然是在不同的系统中生成,但可以通过共享实现统一展示,对教务管理部门和教师都是非常好的服务。

平台目前还有很多细节需要完善,接下来的工作重点是在完善Web服务的基础上,选择重点和适合的应用,开发成支持智能手机系统的客户端,提供移动服务。

参考文献

[1]杨棉华,何萍,郑少燕.国际化视野下卓越医生培养的探索与实践[J].中国高等医学教育,2013(1):1-4.