数据库管理系统（精选12篇）
数据库管理系统 篇1
1 背景分析
目前, 产品化的数据库管理系统是以关系型数据库为主流, 技术相对成熟。面向对象的数据库管理系统尽管技术上处于先进, 数据库易于研发、维护, 但至今为止, 还没有成熟的产品。占主导位置的关系型数据库管理系统包括ORACLE、SYBASE、SQL Server、INFORMIX与INGRES, 这些产品都支持UNIX、VMS、WINDOWS等不同平台, 但支持的程度不一样。
通常系统的设计与研发阶段, 设计人员、研发人员与测试人员仅会把工作重点放在系统的功能实现上, 而此时因为测试数据较小, 难以衡量系统的运行性能的优劣, 然而如果系统进入实际运行阶段, 大量的业务数据通常会使系统的性能逐步降低, 此时再来考虑怎样提升性能则会花费更多的人力及财力。所以, 设计出高质量的数据库结构就变得特别关键。
2 数据库服务器选择
对于占主导位置的SQL Server、Oracle、SYBASE、DB2和INFORMIX数据库, 分别从性能、运用风险、开放性、易维护性与价格等方面来分析比较。
2.1 性能
SQL Server老版本服务器多用户时性能较差, 新版本的性能有了显著的提升, 各项处理能力都有了显著的提升, 占有数项TPC-C (事务处理性能委员会) 纪录, 并支持集群。Oracle数据库性能最佳, 占有Windows NT平台下的TPC-D (基准测试, 衡量联机事务处理系统的一个测试指标) 及TPC-C的世界纪录。SYBASE数据库性能较好, 满足Sun、IBM、HP、Compaq及Veritas集群设施的性能, 达到高可用性;性能比SQL Server稍差, 然而在UNIX平台下的并发性要高于SQL Server, 适用于安全性要求较高的应用系统。DB2适合于数据仓库与在线事务处理, 性能较好, 支持胖客户端和应用模式。INFORMIX性能较好, 支持集群, 达到高可用性, 适用于安全性要求极高的应用系统, 特别是在金融业、证券行业的应用。
2.2 运用风险
SQL Server属于完全重写的代码, 性能及版本兼容性有了较大的改善, 同Oracle、DB2的性能差距显著减小。该产品的产生经历了大量用户长期的测试, 对产品的安全及稳定进行了全面的检测, 安全稳定性有了显著的改善。Oracle长时期的研发经验, 完全向下版本兼容, 基本没有风险。能够安全的进行系列产品的升级, 在企业、政府中获得普遍应用。而且假如在WINNT平台上不能满足数据的要求, 能够安全的将数据转移到UNIX平台上来。SYBASE向下版本兼容, 然而ct-library程序不易移植。研发周期较长, 升级较为复杂, 稳定性较佳, 数据安全有保障, 风险较小。在安全要求极高的金融、证券领域获得了普遍应用。DB2在巨型企业获得普遍的应用, 向下版本兼容性较好, 应用风险较小。INFORMIX研发周期较长, 升级较为复杂, 稳定性较佳, 数据安全有较高保障, 应用风险较小。在安全要求极高的金融、证券领域中获得了普遍应用。
2.3 开放性
SQL Server仅能在Windows平台上部署、运行, C/S结构, 操作系统的稳定对数据库是非常关键的。仅支持Windows平台, 能够用ADO、DAO、OLEDB、ODBC、JDBC等网络数据库连接技术沟通。Windows平台的可靠性和安全性通过了最高级别的C2认证, 在处理大数据量的重要业务时具备较好的性能。Oracle能在所有主流平台上部署、运行 (包含Windows) , 完全支持目前所有的工业标准。利用完全开放策略, 可以进行多层次网络计算, 对多种工业规范提供支持, 能够用ODBC、JDBC、OCI等网络数据库连接技术沟通。能够使客户选用最适合的解决方案, 对开发商完全支持。SYBASE能在所有主流平台上部署、运行, C/S结构, 能够用ODBC、JDBC、Jconnect、Ct-library等网络数据库连接技术沟通, 在金融业中获得了普遍的应用。但因为早期Sybase同OS集成度不高, 所以VERSION11.9.2以下版本需要较多OS及DB级补丁, 在多平台的混合环境下会产生一定问题。DB2能在所有主流平台上部署、运行 (包含windows) 。有较佳的开放性, 最适于海量数据。支持跨平台能力和多层结构, 支持ODBC、JDBC等类型应用系统, 在大型的国际企业中获得最为普遍的应用。IINFORMIX仅运行于UNIX平台, 包括SUNOS (Sun的操作系统最初称呼) 和HPUX (Hewlett C Packard UNIX的缩写, 属于惠普公司的UNIX操作系统) , 在金融业获得普遍的应用。
2.4 易维护性与价格
SQL Server从易维护性与价格上SQL Server占有较大优势。基于Microsoft产品的一贯风格, SQL Server的图形管理界面导致了显著的易用性, 微软的数据库管理员培训工作相对充分, 能够轻松的找到技术较好的数据库管理员, 数据库管理费用相对低, SQL Server的价格也是较低的。Oracle从易维护性与价格体来说, Oracle的价格是相对高的, 管理相对复杂, 因为Oracle的应用相当普遍, 经验丰富的Oracle数据库管理员能够相对容易的找到, 因而实现Oracle的良好管理。所以, Oracle的性价比在商用数据库中是最佳的。SYBASE的价格是相对低的, 然而SYBASE的在企业及政府中的应用较少, 较难找到经验丰富的管理员, 运行管理费用偏高。DB2价格较高, 管理员较少, 在中国的应用相对少, 只在金融业获得一定应用, 运行管理费用都非常高, 比较适用于大型企业的数据仓库应用。INFORMIX价格在这些数据库服务器中居于中间, 同SYBASE类似, 在企业及政府中应用相对较少, 只在金融业获得了普遍的应用。经验丰富的管理人员偏少, 运行管理费用偏高。
3 数据库设计
数据库结构设计在该数据库管理系统研发过程中占据非常关键的地位, 下面从数据库设计原则、数据库设计方法与步骤、逻辑数据模型设计等三方面简述该数据库管理系统数据库设计。
3.1 数据库设计原则
该数据库管理系统的数据库参照以下设计原则:
(1) 数据库设计要达到标准化与规范化。数据结构的标准化与数据关系的规范化有助于消除冗余数据。
(2) 表中数据类型的合理化。合理的数据类型有助于提升该数据库管理系统数据库的运行性能。
(3) 数据表命名的规范化。每个关系型数据库对数据表的命名都有一定要求, 在对数据表命名时利用大小写敏感的形式, 而且数据表命名长度不应过长, 这样能够使该数据库管理系统可以应用在多个不同的数据库平台。
(4) 数据库性能的完善。在运行环境已经固定的因素下, 数据库的性能成为影响该人事数据库管理系统运行性能的主要条件。可以利用两个步骤开展数据库设计:先是进行逻辑设计, 而后进行物理设计。逻辑设计要求消除所有的冗余字段, 可以完整地说明数据库表之间的关系。然而对于多表之间关联的查询, 去除所有冗余会损耗系统性能, 也会增大系统研发难度。因此, 找到一个平衡点成为数据库设计的关键, 在物理设计中开发人员要分析关联数据表的数据量大小与访问频率, 并对数据表中用来关联查询的关键字段留存适当的冗余, 以提升数据库的性能。
3.2 数据库设计方法与步骤
数据库的建设分成概念数据模型设计、逻辑数据模型设计与物理数据结构设计等三个阶段, 其目的是达到合理的数据表结构, 使数据的存取操作更为有序, 数据的编辑、查询更为方便, 从而实现该数据库管理系统数据库的建设。
(1) 概念数据模型设计。概念数据模型反映的是系统最终用户对于数据存储的观点, 代表了系统用户综合性的信息需求, 它用数据类的方式表达企业级的数据需求, 数据类描述了在业务环境中聚集起来的几个重要的类别数据。概念数据模型包括主要的实体和实体之间的关系。描述概念数据模型最常用的是“实体-关系”图 (即E-R图) , E-R图主要是由实体、属性及关系等三个要素组成的。
(2) 逻辑数据模型设计。逻辑数据模型是指系统分析师、设计师对数据存储的见解、看法, 是对前一阶段概念数据模型的分解与细化。逻辑数据模型是按照业务规则决定的, 是业务对象、业务对象的数据项以及业务对象之间关系的描述。逻辑数据模型包括所有的实体与关系, 决定每个实体的属性, 指明每个实体的主键和外键。
(3) 物理数据模型设计。物理数据模型是对真实数据库的表达。数据库对象包括表, 视图、字段、数据类型、长度、主键、外键、索引以及是否可为空, 还有默认值。概念数据模型到物理数据模型的转换是将概念模型中的对象转换为物理模型的对象。
4 总结
开发数据库管理系统时, 一个优秀的数据库服务器的选择和好的数据库结构设计起到举足轻重的地位。SQL Server属于微软公司研发的大型关系型数据库系统, 功能相对全面, 效率较高, 管理与操作比较简单、方便, 整个系统的安全及稳定也较高, 并且性能价格比最好, 节约企业资金, 降低研发成本, 是开发人员理想的选择, 能够作为中型企业或单位的数据库平台。数据库结构设计在数据库管理系统研发过程中同样占据非常关键的地位, 一个好的数据库结构是该数据库管理系统的基础, 数据结构设计的优劣将直接影响到该系统的效率以及所要达到的效果。
摘要：数据库服务器为企业应用提供数据增加、更新、删除、索引、高速缓存、事务管理、查询及优化、安全和多用户数据存储等服务。开发数据库管理系统时, 一个优秀的数据库服务器的选择和好的数据库结构设计起到举足轻重的地位。
关键词：数据库,关系数据库,面向对象,服务器
参考文献
[1]孙璐.Struts2+Spring+Hibernate在企业人事管理系统中的应用[J].软件导刊, 2010.
[2]程明.基于Struts2的数据传输系统的设计与实现[J].计算机应用与软件, 2009.
数据库管理系统 篇2
3.1 专门术语的定义
暂无
3.1.1 系统中常用的术语(或使用频率较高的术语)暂无
3.1.2 表格定义及规范 3.1.2.1数据约定
所有数据项都用英文、汉语拼音或缩写表示，数据库名称除外。
所有字段在设计时，除以下数据类型timestamp、image、datetime、smalldatetime、uniqueidentifier、binary、sql_variant、binary、varbinary外，必须有默认值。字符型的默认值为一个空字符值串；数值型的默认值为数值0；逻辑型的默认值为数值0；
其中：系统中所有逻辑型中数值0表示为“假”；数值1表示为“真”。datetime、smalldatetime类型的字段没有默认值，必须为NULL。当字段定义为字符串形时建议使用varchar而不用nvarchar。建议在大多数表中（如报销单，申请单），应都有以下字段： 字段名说明类型默认值 CreatorID创建者int CreatedTime创建时间DatetimeNULL 字符集采用 UTF-8，请注意字符的转换。
所有数据表第一个字段都是系统内部使用自动序列主键列，自增字段，不可空，名称为：id，确保不把此字段暴露给最终用户。
除特别说明外，所有字符串字段都采用varchar(50)类型，(无论汉字还是英文，都算一个字符）。
除特别说明外，所有小数的字段都采用 decimal(18,2)的形式表达。
除特别说明外，所有日期格式都采用 datetime 格式（根据需要提取时间格式）； 除特别说明外，所有整形都采用 bigint 格式。除特别说明外，所有字段默认都设置为 null。3.1.2.2表和表字段命名规范：
命名规则约束的范围包括：数据库的命名、表的命名及字段的命名。数据库相关的命名规则采用与通常的编程的变量命名规则原则一致，具体要求如下： 1）字段名及表名为典型的名词结构； 2）中文名称要求语言精练、文法严谨；
3）望文知意、易懂易用，禁止采用如：A002这种命名；
4）主体采用拼音字母的首写字母拼写构成，基于惯常法可适度采用无词义歧义性的英文命名；
5）长度不少于3个字母，不大于12个字母；
6）在对于拼音首字母类似的字段和表，为区别，添加下划线和数字如男性人数：NXRS，女性人数：NXRS_2。
3.2 数据设计
绘制数据流程图的目的是为了方便开发人员与用户的交流，以及为系统的设计提供依据。数据流程图的绘制过程通常采用自顶向下，逐层分解，直到功能细化为止，形成若干层次的数据流程图。3.2.1 数据流程图设计
0层数据流图
1层数据流图
3.2.2实体关系结构设计
图书实体关系
读者实体关系
图书借阅关系实体
用户实体关系
图书类别实体关系
3.3安全保密设计
3.3.1 逻辑上的安全保密
1、系统对非法使用者的安全保密处理措施
2、系统对正常使用者的安全保密处理措施
3、系统对管理员的安全保密 3.3.2 物理上的安全保密
1、数据库系统异常时的还原处理措施
2、设备遭异常毁坏时的安全防护措施
3、数据参数做到及时更新，保证系统正常运行
3.4 表格与功能模块相关性分析
3.5 表格定义
a.图书信息表
b.读者信息表
c.借阅表
d.管理员_书籍
应用性数据库管理系统的设 篇3
关键词：数据库管理系统；Access；数据库；实践应用
一、数据库管理系统的定义
数据库管理系统（database management system）是一种操纵和管理数据库的大型软件，是用于建立、使用和维护数据库，简称DBMS。它对数据库进行统一的管理和控制，以保证数据库的安全性和完整性。用户通过DBMS访问数据库中的数据，数据库管理员也通过DBMS进行数据库的维护工作。目前，常见的数据库管理系统产品有Oracle、Sybase、Informix、MicrosoftS QL Server、Microsoft Access、Visual FoxPro等，各以自己特有的功能，在数据库市场上占有一席之地。作为Microsoft Office组件之一的Microsoft Access是在Windows环境下非常流行的桌面型数据库管理系统。使用Microsoft Access无需编写任何代码，只需通过直观的可视化操作就可以完成大部分数据管理任务。在Microsoft Access数据库中，包括许多组成数据库的基本要素。这些要素是存储信息的表、显示人机交互界面的窗体、有效检索数据的查询、信息输出载体的报表、提高应用效率的宏、功能强大的模块工具等。它不仅可以通过ODBC与其它数据库相连，实现数据交换和共享，还可以与Word、Excel等办公软件进行数据交换和共享，并且通过对象链接与嵌入技术在数据库中嵌入和链接声音、图像等多媒体数据。本文以Access数据库为实例，分析数据库管理系统的设计与实现。
二、数据库管理系统（DBMS）的主要功能
数据库管理系统DBMS的主要目标是使数据作为一种可管理的资源来处理，其主要功能如下：数据定义：数据库管理系统（DBMS）提供数据定义语言；数据操作：数据库管理系统（DBMS）提供数据操作语言，供用户实现对数据的操作；数据库的运行管理：数据库管理系统（DBMS）的运行控制、管理功能，多用户环境下的并发控制、安全性检查和存取限制控制、完整性检查和执行、运行日志的组织管理、事务的管理和自动恢复。这些功能保证了数据库系统的正常运行；数据组织、存储与管理：数据库管理系统（DBMS）要分类组织、存储和管理各种数据，包括用户数据、存取路径等，需确定以何种文件结构和存取方式在存储级上组织这些数据，如何实现数据之间的联系。数据组织和存储的基本目标是提高存储空间利用率，选择合适的存取方法提高存取效率；数据库的保护：数据库中的数据是信息社会的战略资源，数据的保护至关重要。数据库管理系统（DBMS）对数据库的保护通过4个方面来实现：数据库的恢复、数据库的并发控制、数据库的完整性控制、数据库安全性控制。DBMS的其他保护功能还有系统缓冲区的管理以及数据存储的某些自适应调节机制等；数据库的维护：这一部分包括数据库的数据载入、转换、转储、数据库的重组合重构以及性能监控等功能，这些功能分别由各个使用程序来完成；通信：数据库管理系统（DBMS）具有与操作系统的联机处理、分时系统及远程作业输入的相关接口，负责处理数据的传送。对网络环境下的数据库系统，还应该包括DBMS与网络中其他软件系统的通信功能以及数据库之间的互操作功能。
三、数据库管理系统（DBMS）的需求分析与设计
1.创建主要的数据表及表间关系。在数据库的实际应用中，最常用的用途是两种：一种是信息资源处理，另一种是信息网络服务。数据库创建前，二维表的设计尤为重要，要对表的数量，名称，表结构等，有一个科学的分析设计。
如校园学生管理中，需要班级表，专业表，学生表，课程表，教师表，课程安排表，成绩表等等。表结构中，要定义不同字段的字段名称，数据类型，字段大小。
2.主要功能模块。功能模块用于实现信息的插入、删除、修改和查询。针对工作者所关心的数据信息设计查询功能，添加删除功能，显示功能等，要实现人机的互操作性
3.建立数据库中的查询、窗体、报表。数据库中的查询、窗体、报表要使用友好界面。数据库的工作是枯燥的，简易的操作界面可以减轻工作人员的疲劳程度。简单、快捷的报表设计，有利于工作成果的展现。数据库管理系统的质量评价指标有功能性、可靠性、易用性、效率、维护性、可移植性。要求数据库管理系统安全保密，成熟准确，易学易理解，适应性强。
四、结语
应用性数据库管理系统要满足不同层面应用人群的要求，具有科学性，可操作性，通过系统实现数据的集成管理。国内外的中小型数据库品种繁杂，数量巨大，不同的数据库可实现不同的应用性功能。不久的将来，人工智能，资源共享，互操作等技术都会集成到我们的数据库管理系统中，进一步实现我们对数据的有效管理。
参考文献：
[1]关雅莉.数据库技术-Access2003[M].电子工业出版社，2008.
[2]隋雪莉.《数据库管理系统VisualFoxPro6.0》的教学体会[J].福建电脑，2008，（5）.
[3]孟小峰，周龙骧，王珊.数据库技术发展趋势[J].软件学报，VoL15，No.12.
[4]张立.数据库管理系统及其实现问题的研究[J].电脑知识与技术，2010.
[5]李惠琴.标准信息数据库管理系统的创建与应用[J].航天标准化，2010，（1）.
[6]赵静.数据库管理系统的现状及发展方向[J].电脑编程技巧与维护，2009-02-30.
[7]周其乐.数据库管理系统的功能与组成[J].信息技术，2009.
[8]韩立毛，赵跃华，朱伟玲.安全嵌入式数据库管理系统的设计研究[J].通信技术，Vol.43，No.06，2010.
关系数据库管理系统数据字典研究 篇4
1 数据字典物理存储
1.1 数据字典的定义
数据字典的一个重要作用就是提供最终用户数据库所有的信息, 在物理存储上就采用跟其他用户表一样的实现, 提供统一的接口。而数据字典的主要作用还是提供给DBMS自身使用, 在实现上还跟整个数据库的结构功能相关。
1.2 数据字典的逻辑功能
具体来说, 关系数据库中的所有数据信息与关联都与数据字典有着十分紧密的联系。数据字典具有着对关系数据库中的所有对象进行定义的逻辑功能, 除此之外, 数据字典还可以对关系数据库中的序列值进行默认、对数据库中的各种信息进行约束、对数据库中的用户信息进行存储和统计、对数据库中的用户权限进行分辨, 并且还可以对数据库中的各种信息的定义以及它们之间的关联进行操作与辨别。
由于关系数据库之中的各个对象之间存在着较强的关联性, 当用户对某一对象进行删除操作时, 往往会由于该对象与其它对象之间的关联程度与类型不同而产生一定的影响。例如数据库用户在PRLMARY KEY上建立起一个unique index文件, 而这个unique index文件的主要功能就是帮助PRLMARY KEY实现其自身的功能任务。而由于PRLMARY KEY是依附在一个数据表中的, 当删除表或是表中的相关信息有所变动时, 依附于这个表存在的PRLMARY KEY中的unique index里的信息也会相应的被删除或有所变动。而数据字典负责的功能就是将关系数据库中发生的这些关联信息与操作完整的记录和保存下来。通常来说, 关系数据库中的所有这些关联对数据库的用户都是公开透明的, 而另一种情况就是数据库用户为了方便自己的操作或是其它因素, 在对数据库中的对象进行删除操作时需要加上由用户自己设定的关系语句才能实现删除操作, 当此删除操作实现时, 与该对象有着密切关联的其它信息也会一并被删除。
1.3 物理记录的存储格式
关系数据库中的数据字典与用户数据都是以表的形式被记录保存在关系数据库的物理文件中的, 并且关系数据库管理系统中有着多种物理存储格式, 每一种物理存储格式都有着各自不同的特点, 相互之间具有较大的差别, 而这都是由于关系数据库管理系统中并发模式类型的不同造成的。现阶段, 我国的数据库管理系统将加锁模型与多版本模型作为最为主要的两种并发模型。其中加锁式并发模型的特点是记录格式简单、无需版本信息就能实现, 如SQL Server并发模型。而多版本并发模型主要有Oracle数据块并发模型。该种并发模型不仅需要用到物理记录来对数据库中的版本信息进行记录, 而且还需要物理格式的帮助来实现对数据库系统的并发控制及相关的事务处理, 比较复杂。
2 数据字典内存表示
2.1 CACHE作用
关系数据库管理系统能够通过对数据字典中的信息数据进行读取来获得数据用户以及数据库中的对象与存储信息, 当数据库用户需要对某些数据进行查询和相关的操作时都需要利用其所发出的SQL语句来对数据字典中的信息进行查询, 查询频率非常高。现阶段, 我国的数据库管理系统主要由两部分组成, 即CACHE与RELCACHE。其中CACHE主要负责的是对数据库管理系统中的表进行存放。在该部分中, 一个系统表能够利用ID查询、NAME查询与主键查询中的任意一种方式进行查询, 除此之外, 用户也可以通过部分键对该系统表进行查询。当查询操作完成后, 关系数据库系统会根据数据字典的分析最终弹出用户需要寻找的表格。
而RELCACHE部分的每一项都是一个RELATION结构, 该结构对此结构中的所有数据信息与关联进行了记录与保存。并且此结构能够将关系数据库系统中的所有与需要查询事件相关联的描述信息进行联合构造, 以更好的满足数据库用户的需求, 提高关系数据库管理的质量与水平。
2.2 数据库的启动与CACHE的初始化
使关系数据库能够启动并发挥其应有的作用, 操作人员至少要做好以下三个步骤, 即将一个实例启动, 之后对数据库系统进行装配操作, 第三, 将数据库系统打开。使数据库的CACHE系统得以初始化的方式有两种:第一种, 在数据库系统建立时进行CACHE的初始化, 主要负责对数据库系统的内存进行分配;第二种, 数据库系统已经建立完成后在启动时进行初始化操作, 此时, 内存已经分配完毕, 用户只要正常进行启动操作就可以完成CACHE的初始化。
3 结束语
本文主要对关系数据库管理系统的数据字典程序进行了分析介绍与研究, 希望能够进一步推动我国关系数据库系统的管理质量, 促进关系数据库系统的进步。
参考文献
[1]程阳.关系数据库管理系统的一种简易的数据存储与查询模块的设计与实现[D].华中科技大学 (硕士学位论文) , 2012.
[2]冯玉才, 李东, 王元珍, 曹忠升.一种移动数据库管理系统的体系结构[J].计算机研究与发展, 2011, 38 (5) :620-625.
数据库管理系统 篇5
数据库管理系统综合应用
-------图书管理系统系统一、实验目的：
通过完成从用户需求分析、数据库设计到上机编程、调试和应用等全过程，进一步了解和掌握所讲解的内容。
二、实验简述：
一个简单的图书管理系统包括图书馆内书籍的信息、学校在校学生的信息以及学生的借阅信息。此系统功能分为面向学生和面向管理员两部分，其中学生可以进行借阅、续借、归还和查询书籍等操作，管理员可以完成书籍和学生的增加、删除和修改以及学生借阅、续借、归还的确认。
三、实验要求：
完成该系统的数据库设计；
用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、实验总结
通过这次实验，进一步了解什么情况下使用事务。
三种关系型数据库管理系统的比较 篇6
关键词：关系型数据库管理系统 Visual FoxPro；Access SQL Server
目前的商用数据库市场，近90%是采用关系数据模型。例如，小型数据库系统 Visual FoxPro, Access, MySQL等，大型数据库系统 DB2, Ingers, Oracle, Informix, Sybase, SQL Server 等．
目前，计算机数据库课接触比较多的有 Visual FoxPro, Access 和 SQL Server，前两种列为了全国计算机二级考试科目．下面对这三种关系型数据库管理系统进行比较．
1、数据库的区别及安全性
Access 的数据库文件格式是 MDB，一个数据库就是一个文件，所有的数据库对象都存储在这一个文件中．Visual FoxPro 的数据库文件格式是 DBC，一个数据库也是一个文件，但所有的数据库对象都分别以不同的格式存储，即是不同的文件．SQL_Server 的数据库物理上也是一个 MDF 数据文件，但 MDF 数据文件可以说是一个数据库的集合，里面包括了很多个数据库．
SQL_Server 提供相同的企业级安全性机制，可以完全控制用户访问数据库的情况，并提供完备的数据安全性方案．在 Visual FoxPro、Access 中也有一些安全方面的配置，但其性能根本没有 SQL Server 完善．
2、DBMS 和数据库的物理位置
Visual FoxPro, Access 的 DBMS 系统和数据库是不能分离的，必须物理上在同一台计算机．SQL Server的 DBMS 可以和数据库分离，即单独安装在物理上不同的计算机上．SQL Server 是支持客户机/服务器结构的数据库管理系统，数据库系统管理工具、前端开发工具和后台数据库是可以分离的，通常我们所说的网络数据库管理系统指的是管理工具和后台数据库的总和．
3、数据库规模和开发运行环境
Visual FoxPro 的规模属于一个中小型数据库开发软件，Access 也适用于中小型企业数据管理的需求．SQL Server 可以帮助各种规模的企业管理数据，是真正的中大型数据库．
Visual FoxPro和Access提供的是较弱的数据库管理和较强的前端开发工具，开发工具与数据库集成为一体，既是数据库管理工具，又是数据库应用开发的前端工具，在Visual FoxPro 6.0 里就集成了应用开发工具，直接使用VisualFoxPro 就可以进行数据库应用系统开发．在Access 2000 和 2003 里集成了脚本语言．
Visual FoxPro 可以编译成独立程序，脱离开发环境运行，可以生成独立的 EXE 文件作为商业软件产品；Access 应用只能在 Access 软件环境中运行，想要脱离 Access 只能用 VB 等来编程调用 Access数据库，现在小型 Web 开发中 ASP+Access 或JSP+Access 的方式比较常用．
SQL_Server 仅仅是一个数据库引擎，没有集成接口开发工具．任何前台应用程序的开发都需要开发程序来处理．
4、支持的操作系统
Visual FoxPro、Access 的计算机操作系统为桌面型操作系统，如 Windows 98/XP 系统等，不提供或仅仅提供有限的网络应用功能．SQL Server可以运行于 Windows NT/2000/XP 等多种操作系统之上．需要网络操作系统支持，包括 WindowsNT Server，Windows Server 2000，Windows Server2003，Linux Server，UNIX，Solaris 等．
5、学习和使用的难度
Access 被集成到 Office 中，具有 Office 系列软件的一般特点，如菜单、工具栏等．简单易学，一个普通的计算机用户，没有程序语言基础，也能快速地掌握和使用它．Visual FoxPro 除了掌握数据库的操作外，还涉及到程序设计，需要一定的程序语言基础，学习比 Access 稍难．
SQL Server 不但要掌握 SQL Server 的操作，而且还要能熟练掌握 Windows NT/2000 Server 的运行机制，以及 SQL 语言，所以对非专业人员的学习和使用有一定的难度．
总之，如果数据库系统并发的用户数较少，对安全性的要求也不高，那么 Visual FoxPro、Access 的性价比比较高．SQL Server 是基于服务器端的中大型的数据库，适合大容量数据的企业单位应用，在功能和管理上比 Access 和 Visual FoxPro 强得多．
参考文献：
[1]傅榮会.三种关系型数据库管理系统的比较研究[J].重庆三峡学院学报,No.3.2011.
[2]郑阿奇等.SQL Server 使用教程（第3版）[M].北京：电子工业出版社,2009.
多媒体数据库管理系统 篇7
随着现代信息技术的迅猛发展, 如今的信息已不仅仅包含数值和文本等简单的媒体类型, 而且有图像、图形、声音、视频及动画等多种媒体, 并且未来将会出现更多的媒体类型。多媒体由于其本身的综合性和结构的复杂性等, 对它的管理和操纵都十分困难。而现有的关系型数据库对多媒体数据的管理和操作能力十分有限, 尽管多媒体技术得到了很大的进步, 但开发集图像、声音、文字等多媒体信息于一体的数据库管理系统, 仍是近阶段数据库的一个发展方向[1]。
由于现有的关系型数据库对多媒体数据的管理和操作能力十分有限, 其对多媒体数据操纵的效果也差强人意。一些基于某一特定应用领域的多媒体数据库系统已取得了成功的经验, 比如各种各样的地理信息系统, 实现了对点、线、面等数据的管理;还有指纹数据库, 头像数据库等。但是, 到现在为止尚未建立一个通用的多媒体数据库管理系统。
1多媒体数据库管理系统
作为一个多媒体数据库管理系统, 本系统具备了管理文本、声音、图像和视频等多媒体数据的功能, 同时有效地将数据库中各种媒体记录与其对应的文件一一对应了起来。本系统具有以下主要功能:
(1) 多媒体数据的基本操作, 如查询、添加、删除和播放等。
(2) 多媒体数据类型定制, 可以添加新的数据类型。
2系统设计
本系统采用面向对象方法进行设计。在面对对象的多媒体数据库中, 首先要产生一系列的对象库, 再将几个相似的对象库抽取共同属性和方法, 形成类库[1], 因此系统定义了一个MultimediaFile基类, 并由这个基类派生出GraphicsFile、ImageFile、SoundFile和TextFile四个基类。此外还定义了一个User类和一个Types类。User类是用来管理用户的合法登录的, 而Type类则是为区分文件的种类而设计的。
本系统分BLL层、DAL层、Model层和UI层四层。
BLL层, 即业务逻辑层, 用于页面逻辑处理。根据UI层的操作, 在BLL层中进行处理。
Model层, 即模型层, 用于实体类的设计, 也就是在项目中的构建实体对象。本项目中包含七个实体类, 有MultimediaFile类、GraphicsFile类、ImageFile类、SoundFile类、TextFile类、Type类以及User类。其中MultimediaFile类是GraphicsFile类、ImageFile类、SoundFile类和TextFile类的基类。
DAL层, 即数据访问层, 用于对数据的处理。其中的ManageFile为整个项目的核心, 几乎包含了程序中所有的数据处理, BLL层调用的是这里的函数来传送数据或取得数据。
UI层, 即用户界面层, 也就是MultimediaMS项目的本身, 主要用于用户输入数据和处理事件。它是整个解决方案的入口。
2.1用户合法性的实现
当应用程序运行时, 在程序的主入口点调用“Application.Run (new Login () ) ;”即进入用户登录界面, 本系统的所有功能是从这里开始执行的。用户只有输入正确的用户名和密码才能进入系统, 否则无法进入系统。其代码如下:
private void btn-Login-Click (object sender, EventArgs e) {
if (this.txt-UserName.Text == ″″ || txt-Password.Text == ″″) {
MessageBox.Show (″用户名和密码必填″, ″警告″, MessageBoxButtons.OK, MessageBoxIcon.Warning) ;}
else {
string strsql = ″select * from users where user-name=′″+this.txt-UserName.Text+″′″;
SqlDataAdapter da = new SqlDataAdapter (strsql, conn ) ;
DataSet ds = new DataSet () ;
da.Fill (ds) ;
if (ds.Tables[0].Rows.Count <= 0) {
MessageBox.Show (″用户不存在″, ″警告″, MessageBoxButtons.OK, MessageBoxIcon.Warning) ; }
else{
if (ds.Tables[0].Rows[0][″user-password″].ToString () == this.txt-Password.Text.ToString () ) {
User user = new User () ;
user.UserID = int.Parse (ds.Tables[0].Rows[0][″user-ID″].ToString () ) ;
user.UserName = this.txt-UserName.Text;
MainForm filemanager = new MainForm (user) ;
this.Hide () ;
filemanager.Show (this) ;}
else {
MessageBox.Show (″密码错误″, ″警告″, MessageBoxButtons.OK, MessageBoxIcon.Warning) ;}}}}
2.2多媒体数据的管理
成功登录后, 用户将进入到多媒体数据库管理系统的主窗体, 点击主窗体中的文件管理项就会出现一个文件管理子窗体, 该窗体具有对多媒体数据管理的大多数功能, 如查询、添加、播放和删除等。此外, 用户还可以通过该窗体对文件类型进行添加或更改。
以下是点击查找时执行的代码:
private void btn-fsearch-Click (object sender, EventArgs e) {
switch (TypeName) {
case ″声音文件″:
this.dtg-FileView.DataSource = new
Multimediafiles () .GetSearchSoundFile (usr.UserID, TypeID, this.txt-fName.Text, Convert.ToDateTime (this.dtpBegin.Text) , Convert.ToDateTime (this.dtpEnd.Text) ) ;
break;
case ″图像文件″:
this.dtg-FileView.DataSource = new
Multimediafiles () .GetSearchImageFile (usr.UserID, TypeID, this.txt-fName.Text, Convert.ToDateTime (this.dtpBegin.Text) , Convert.ToDateTime (this.dtpEnd.Text) ) ;
break;
default:
this.dtg-FileView.DataSource = new
Multimediafiles () .GetSearchOtherFile (usr.UserID, TypeID, this.txt-fName.Text, Convert.ToDateTime (this.dtpBegin.Text) , Convert.ToDateTime (this.dtpEnd.Text) ) ;
break; }
dtgCheck () ;}
添加多媒体数据时执行的代码如下:
private void btn-finsert-Click (object sender, EventArgs e) {
if (TypeID != 1) {
FileAdd frm = new FileAdd (usr, Convert.ToInt32 (cmb-fileType.SelectedValue.ToString () .Trim () ) , this) ;
frm.ShowDialog () ;}
else{
MessageBox.Show (″请先选择文件的类型″, ″警告″, MessageBoxButtons.OK, MessageBoxIcon.Warning) ; }}
private void btn-addFile-Click (object sender, EventArgs e) {
try {
if (txt-filePath.Text != string.Empty) {
if (System.IO.File.Exists (txt_filePath.Text) ) {
openFileDialog1.InitialDirectory = txt-filePath.Text;}
else{
MessageBox.Show (″文件路径不存在, 请选择要添加的文件!″, ″警告″, MessageBoxButtons.OK, MessageBoxIcon.Warning) ; }}
else{
openFileDialog1.InitialDirectory = @txt-filePath.Text;}
switch (typeID) {
case 2:
TagPath = @″FilePathText″ ;
openFileDialog1.Filter = ″所有文件|*.*|文本格式|*.txt|Word格式|*.doc|Execl格式|*.xls″;
break;
case 3:
TagPath = @″FilePathSound″;
openFileDialog1.Filter = ″所有文件|*.*|mp3 格式|*.mp3|rm格式|*.rm|wma格式|*.wma|wmv格式|*.wmv|rmvb格式|*.rmvb″;
break;
default:
TagPath = @″FilePathOthers″;
openFileDialog1.Filter = ″所有文件|*.*|rmvb格式|*.rmvb″; break;} openFileDialog1.FilterIndex = 2;}
catch (SqlException ex) {
throw new Exception (ex.Message) ; }
openFileDialog1.ShowDialog () ;}
其它的代码如数据库的连接, 各种类的定义, 打开多媒体数据, 窗体间的调用就不详细介绍了。
3结论
多媒体数据库管理系统, 是一个能对文本、图形、声音和图像这些多媒体数据进行有效管理的数据库系统。本文只是在这方面做了一些尝试, 做成的系统也只能完成一些基本的功能, 但相信随着技术的不断发展, 多媒体数据库管理系统必将更加成熟, 而且还将会有更多的各种多媒体数据库应用于各行业与领域。
参考文献
[1]张英锋, 柏林.多媒体数据库管理系统的设计和开发[J].现代电子技术, 2001, 32 (1) :51-53.
遥感影像数据库管理系统研究 篇8
1 遥感影像数据库管理系统所具备的要求分析
遥感影像是记录电磁波的胶片, 与我们日常的影像数据存在很大的区别, 从遥感影像数据特征来进行分析, 遥感影像数据库管理系统需要具备以下几点要求:
1.1 在实际当中, 遥感影像的来源
有很多渠道, 如航空影像、卫星影像等等, 因此, 遥感影像数据库管理系统的兼容性要强。
1.2 遥感影像具有一个很明显的
特点就是能够表现立体空间, 支持空间表达对于应高影像来说是至关重要的, 所以遥感影像数据库管理系统对于空间数据索引和数据查询具有一定的能力。
1.3 由于遥感影像数据库来源于很
多的渠道, 影像数据也没有统一的标准, 所以对于遥感影像要满足多尺度的特性。
1.4 遥感影像数据库管理系统必
须具备“无缝性”, 主要表现在其一集合空间的无缝, 遥感影像的存储一般来说具有固定的存储模式, 而无缝性的要求就是要打破这种模式, 构建一个无缝的区域, 用户在使用的时候图幅是透明的。二是色彩空间的无缝性, 遥感影像数据库管理系统在一定区域和分辨率范围内, 影像色彩的变化应当是平滑的, 不能出现明显的差异。其三是尺度空间的无缝性, 在操作遥感影像数据缩放的时候, 应该保持不同尺寸之间的遥感影像能够平稳的过渡。其四是影像数据和元数据的无缝性, 该性质是遥感影像数据库管理系统建设当中需要着重强调的。
1.5 遥感影像应用较为广泛, 对于商业用途来说, 系统的通用性、扩展性以及维护性是非常重要的。
1.6 随着社会经济的发展, 遥感影
像数据量急剧增加, 遥感数据库管理系统的储存量也应该是海量的, 必须要达到TB级。
1.7 从数据可视化的角度上来说, 遥感影像数据库管理系统的建设应该以零延迟为目标。
2 遥感影像数据库系统管理模式研究
从大体上来说, 遥感数据库系统管理的主要方式可以分为三大类, 一个是基于文件的方式, 其次是基于数据库的方式, 最后就是文件和数据库混合的方式, 下面文章对三种方法进行简单的分析:
2.1 基于文件的方式
遥感影像数据库管理系统基于文件方式进行管理的主要优点就是结构不复杂, 并且维护的费用也不高, 技术相对来说较为成熟。同时也存在一定的缺点, 主要表现为安全性能不高, 不能支持多用户进行并发操作, 元数据管理效率较低等等。因此, 对于这种管理方式来说在多数据量的环境下性能表现力不从心, 大多数情况下只能适用于遥感影像数据量较小的环境下。
2.2 文件和数据库混合的方式
文件和数据库混合的方式的主要原理是将遥感影像数据以文件的形式保存在服务器上, 但是与之对应的元数据却分隔开来保存在了数据库当中, 这种管理方式的主要优点是遥感影像数据存储的效率高, 但是相对难度也会增大很多, 并且随着时间的推移, 遥感影像数据量会不断增多, 并且后期的维护难度也非常大。
2.3 基于数据库的方式
基于数据库的遥感影像管理模式主要以分布式对象对应关系数据库管理遥感影像数据, 该方式不仅可以给中央服务器减负, 还可以减少产生瓶颈的几率, 提高数据的传送率、查询以及更新效率, 可以大大缩短相应时间, 并且能够支持多用户的并发访问, 这些都是其他管理模式无法比拟的。除此之外目前的数据库都设置了安全访问控制机制, 这样的设置能够为开发人员省下了不少的麻烦, 提高效率。
3 遥感影像数据库管理系统建设对比分析
由于工作的需要, 遥感影像数据库管理系统的功能要求越来越高, 为了更好的进行分析研究, 文章对比了传统遥感影像数据库系统来论述。
3.1 传统遥感影像数据库管理系统分析
3.1.1 关系数据库系统
传统的关系数据库对于遥感影像数据的处理仅限于数值和字符串, 并没有丰富的数据类型, 这对于遥感影像的使用、研究来说是极其不方便的, 建立在对象层来挖掘面向对象应该是目前的主流, 对于对象数据库的存储和访问不能优化, 其效率不高, 而且技术上也存在严重的问题。
3.1.2 对象数据库系统
在上个世纪八十年代以来, 对了遥感影像数据的最好技术就是面对象技术, 这种技术的应用能够使得系统当中的数据模型表现的更加直观、并且性能更加的问题, 后期维护也较为方便, 同时这种系统也存在致命的缺陷, 对于SQL的支持很少, 实际的工作当中, 许多软件需要应用到SQL接口。
3.2 对象一关系数据库系统
对象一关系数据库管理系统具备最大的优势就是具有面向对象的建模能力, 对于复杂的遥感影像数据都能进行分析, 用户可以直接使用数据管理工具, 将遥感影像应用的具体范围与系统实现无缝结合, 极大的提高了工作效率。
在目前来说, 对象一关系数据库管理模式还处在研发阶段, 只能说是一种新兴的技术, 其应用的行业领域也较窄, 相比上文论述的遥关系数据库管理来说还尚不成熟, 关系数据库系统的所有操作只是按照既定的操作标准来执行, 相对来说非常简单, 但是其致命缺点有限的数据类型以及程序设计中数据结构是制约关系数据库系统发展的最大障碍。而遥感影像数据对象一关系数据库管理系统能够将面向对象的建模能力和关系数据库的功能实现了有机的结合, 理论上来说都优于上述两种遥感影像数据库管理系统, 还能将关系数据库系统缺点转换成优势, 具有高度的扩展性、管理复杂遥感影像数据的能力也大大提高, 用户通过自定义的功能和索引表达, 对于各种类型的遥感影像数据实现访问、存储以及恢复等功能。
遥感影像数据对象一关系数据库管理系统通过开放SQL平台, 可以最大限度的避免定义复杂对象的专有数据结构, 使得遥感影像数据库管理系统的应用更加广泛。
4 遥感影像数据库管理系统建设的技术分析
随着遥感技术的不断发展, 遥感影像数据量增长速度越来越快, 在这样的背景下, 必须要研发出一套高效的管理应用系统, 将遥感影像的分发以及处理能力提升到新的高度, 与此同时还需要很好的契合遥感影像数据制作影像海图等各方面应用需求。高效科学的遥感影像数据库管理系统建设成为了业内关注的焦点。鉴于此, 文章对遥感影像数据库管理系统建设的总体构架以及相关的技术问题提出了几点愚见。
4.1 遥感影像数据库管理系统建设的总体架构
针对日常生产生活对遥感影像数据库管理系统提出的功能和要求, 总的来说, 系统的总体框架可以分成四层:基础设施层、数据层、逻辑层和应用层。在这四个层次当中, 基础设施层是整个遥感影像数据库管理系统运行的基础, 主要包含了系统的软硬件运行环境以及网络运行环境的建设;第二层数据层对于整个遥感影像数据库管理系统来说, 是非常关键的组成部分, 也应该是建设的重中之重, 其主要的功能是对采集的原始遥感影像、影像元数据以及矢量数据等等进行储存;而对于逻辑层来说, 主要的工作就是对客户端访问遥感影像数据库所需的功能部件进行优化升级;最后的应用层主要就是对遥感影像数据库管理系统当中的集成影像进行日常的管理和维护, 同时提供查询、分析以及分发等等功能。
4.2 遥感影像数据库管理系统功的能设计
结合上文对遥感影像数据库管理系统总体架构分析, 所提出的四层主要架构需要实现的功能, 可以将遥感影像数据库管理系统分为五个子系统。
4.2.1 质检入库子系统
遥感影像采集后需录入到系统当中, 但是在此之前需要对遥感影像进行质检, 主要检查的内容包括了遥感影像的完整性、一致性等等, 并且通过工程化方式对遥感影像、元数据等等实现快速入库, 支持断点续传、后台任务同时进行。
4.2.2 组织管理子系统
该子系统是对遥感影像数据管理的核心部分, 主要对数据库当中遥感影像的参数进行配制、同时还包含了数据建模、数据备份以及数据共享等等应用, 方便遥感影像数据的共享和管理系统的集成。
4.2.3 分发服务子系统
需要在系统中引入电子商务模式的影像分发服务, 实现对数据库中遥感影像的查询、分发等功能, 同时在改子系统当中提供开放的数据接口。
4.2.4 技术支援子系统
对入库的遥感影像数据进行规范化处理, 包括了元数据的采集、快视图提取、镶嵌、配准等。
4.2.5 配置维护子系统
主要的工作是支持和维护遥感影像数据库管理系统的运行, 提供一系列的安全管理配套功能, 如用户管理、日志信息维护等。
结语
遥感技术随着社会经济的发展, 应用越来越广泛, 面对与日俱增的遥感影像数据, 必须要建立一个强大的遥感影像数据库管理, 这也是遥感影像发展的必然趋势。遥感影像信息系统核心技术设计的范围较广、难度较大, 目前有很多的学者在进行这方面的研究, 本文对遥感影像数据库管理系统的建设只是进行了粗浅的探讨, 相信随着研究的深入和科技的发展, 遥感影像数据库管理系统建设相关研究会更加的深入, 遥感影像也会更加方便的应用于我们的各项工作当中。
参考文献
[1]黄杰, 刘仁义, 刘南, 沈林芳, 王娜.海量遥感影像管理与可视化系统的研究与实现[J].浙江大学学报 (理学版) .2008 (06) .
[2]谭庆全, 毕建涛, 池天河.一种灵活高校的遥感影像金手塔构建算法[J].一计算机系统应用, 2008 (17) .
高校科研信息管理系统数据库设计 篇9
高校科研信息管理系统是指通过计算机完成对教师论文、项目、教材等科研信息的录入、整理以及统计工作的信息系统。实现录入信息的规范、 准确, 统计信息精确、高效是该系统的设计目标, 为了实现系统的设计目标, 数据库设计是关键, 将对科研信息的管理为例, 对高校科研信息管理系统的数据库设计进行探讨。
2 科研信息需求
需求分析是数据库设计的开始, 而好的开始是成功的一半, 因此一定要重视这一阶段的工作。根据我院科研管理部门的工作内容、流程以及科研管理的相关规定, 确定科研信息管理系统的需求如下:
2.1 处理数据
教师的论文、项目、教材、著 作、专利 、奖励等 内容 ,这里将其统称为成果。
2.2 数据录入要求
(1) 无论哪种成果在录 入数据时 必须录入 成果的名 称、作者、等级、出处、 发表或完成时间, 佐证图片等相关信息。以论文为例, 需要录入论文的题目、作者、出版单位、论文级别、 发表时间, 以及论文的封面、版权页、目录、正文等佐证图片;(2) 无论哪种成果数据, 均由第一完成人对数据进行录入, 其他参与人员由第一完成人按照相应等 级录入。以教材为例, 第一主编首先录入教材的名称、出版社、出版时间、以及教材的封面、 版权页、目录、前言 等佐证图 片 ,然后将副主编、参编作者录入系统。
2.3 数据统计分类
(1) 对所有教师的科研信息进行全部或分类 (如仅统计论文) 或时间段 (如2013年1月至2013年12月) 整理及统计;(2) 以部门为单位, 对该部门下的所有教师的科研信息进行全部或分类或时间段整理及统计;(3) 以教师为单位,对教师本人的科研信息进行全部或分类或时间段整理及统计。
2.4 基础数据管理
基础数据主要指两方面数据, 一方面是指教师隶属的部门信息, 这部分数据主要用以辅助实现科研信息的部门统计。另一方面是指系统数据字典即数据项及子项, 如职称是数据项,助教、讲师、副教授、教授等都是其子项, 这部分数据主要用以实现系统基础数据的可规划性, 方便系统的日后扩展与维护。
2.5 用户角色及权限
(1) 教师用户即一般用户 : 主要负责将本人的科研信息录入至系统, 并对已经审核完成的科研信息进行分类统计以及报表打印;(2) 审核员用户: 主要负责对教师用户录入的科研信息进行审核;(3) 管理员用户: 除具有以上二种用户的权限外, 还需负责基础数据的管理与维护、初始用户口令(即用户名及密码 )、分配用户权限等工作。
2.6 工作流程
首先由管理员对基础数据进行录入或导入, 初始用户口令, 授权用户权限; 其次由教师根据用户口令登录系统, 录入本人科研信息; 再次由审核员对教师录入的科研信息进行审核; 最后由管理员对所有科研信息进行整理与统计。
3 数据库
通过对科研信息管理系统进行需求分析, 以及数据完整性、一致性, 减少数据冗余的数据库设计原则, 确定本系统的数据库概要设计结构如图1所示。为了提高科研信息查询效率, 避免多表查询操作, 可将论文、项目、教材 、著作、专利、 奖励等数据统一存储在成果数据表中。
根据数据库概要设计结果, 实现系统功能共需8个数据表, 表1至表8所示, 其中数据项表及数据项子项表用于实现基础数据存储及管理。本系统共需性别 (如男、女)、学历(如本科、研究生等 )、学位 (如学士、硕士等 )、职称 (如助教、讲师等)、成果类别 (如论文、教材等)、成果等级 (如院级、省级、一般、核心等)、参与方式 (主编、副主编、第一作者、主持人等)、审核状态 (通过、未通过)、用户权限(如管理员、审核员、 教师 ) 共9个数据项 , 每项的子项参见其括号内容, 管理员用户可根据需要随时添加新的子项。
3.1 数据项表
用于存储该系统使用的数据字典的数据项, 属于基础数据的定义范畴, 如表1所示。
3.2 数据项子项表
用于存储数据字典的数据项的子项, 属于基础数据的定义范畴, 如表2所示。
3.3 部门表
用于存储部门信息, 属于基础数据的定义范畴, 如表3所示。
3.4 教师表
用于存储教师的基本信息, 属于基础 数据的定 义范畴 ,如表4所示, 其中性别、学历、学位、职称、 审核状态服从于数据项子项表。
3.5 成果表
用于存储各类成果信息, 如表5所示 , 其中成果 类别、成果等级、审核状态服从于数据项子项表。
3.6 成果人员表
用于存储参与成果完成的教师信息, 如表6所示, 其中参与方式、审核状态服从于数据项子项表。
3.7 成果图片表
用于存储成果图片信息, 如表7所示, 其中审核状态服从于数据项子项表。
3.8 用户表
用于存储系统用户信息, 属于基础数据的定义范畴, 如表8所示。其中用户权限服从于数据项子项表。 可根据教师表的教师编码字段即Id_tea对用户的用户名及密码进行初始化。
4 结语
基于数据库的影院管理系统设计 篇10
现代化的影院综合管理是集影院、影厅管理、影片放映管理、售票统计、分析管理等在内的一个综合性影院管理系统,对剧场、影院等娱乐场所的日常业务进行综合性管理。影院综合管理组织庞大,服务项目多,信息量大,要想提高劳动生产,降低成本,提高服务质量和管理水平,进而促进经济效益,必须借助计算机来进行现代化的信息管理。
现代影院综合计算机管理系统设计采取了Client/Server结构所具有的灵活、开放的强大特性,使之成为实现综合业务管理系统的综合性、开放性与易用性的优选方案。
2 需求分析
影院管理系统需要满足来自两方面的需求,这两方面分别是消费者和影院管理人员。消费者的需求是查询最新影片信息、放映计划;影院管理人员的功能最为复杂,包括对工作人员、影院、影厅、影片、预售票等进行管理和维护,以及系统状态的查看。
消费者可直接查看最新影片信息和放映计划情况,并且可以经过售票员购买影票。消费者还可以经过影院工作人员预定影票,并且可以及时退票。消费者也可以选择自己属意的座位。
影院管理人员功能的信息量大,数据安全性和保密性要求最高。本功能实现对影院信息、影厅信息、影片信息、最新放映计划信息、票房的管理和统计、工作人员和管理人员信息查看及维护。影院管理员可以浏览、查询、添加、删除、修改、统计影院管理的基本信息。
3 模块设计
本系统旨在开发一个集影院、影厅管理,影片放映管理,售票统计、分析管理等在内的一个综合性影院管理系统,对剧场、影院等娱乐场所的日常业务进行综合性管理。根据系统需求分析中总结的用户需求设计系统的体系结构。
系统的功能模块图如图1所示。
在本系统中,可以把功能模块分为5个功能集合来描述:
(1)系统设置模块
系统设置模块包括用户信息、系统注销和系统退出。系统在启动或重新登录的时候都会调用登录界面,它用于核实用户的合法性。用户类型分为管理员和普通用户两种,管理员可以进行用户信息管理和权限的控制,而普通用户则不能。权限控制虽然不是一个独立存在的模块,但是它却贯穿在整个系统的运行过程当中。
在本系统中,用户管理模块的功能比较简单。管理员可以创建用户、修改用户以及删除用户;普通用户则只能修改自己的用户名和密码。
(2)基础信息设置模块
基础信息设置模块主要包括影院、影厅的设置管理、影片的管理、放映计划管理。它是整个影院综合管理的设计与实现的基础和前提。其中影院和影厅的设置管理模块用于处理与影院、影厅相关的各种信息。影片的放映计划模块是在影片管理的基础上,对每个影厅所放映的影片进行编排。
(3)日常业务处理模块
日常业务处理模块是本系统的核心,主要用于影票的预订和销售以及退票处理。它主要包括预售票管理、退票处理等功能。
(4)信息查询和统计模块
信息查询和统计是在日常业务处理模块的基础上,主要用于对将要放映影片的查询,以及某影片售票情况等的查询,还有一周票房的统计。它主要包括售票查询、退票查询、影片查询、放映计划查询及票房统计、销售情况统计等。
(5)帮助
主要包括关于、帮助主题。
4 系统数据库
数据库结构设计是总体设计阶段非常重要的环节,好的数据库结构可以简化开发工程,使系统功能更加清晰明确。因为数据库结构的变化会造成编码的改动,所以必须认真设计数据库结构在进行编码,从而避免无谓的重复工作。
在需求分析阶段己完成该系统所有的数据分析。根据该阶段所建立的概念模型,已经得出满足第三范式的几个关系描述,该阶段的主要工作就是把前一阶段的成果转化为具体的数据库。
下面是该系统的主要数据表,加下划线的字段为主码。
(1)影院(影院编号,影院名称,联系电话,地址,级别,负责人)
(2)影厅(影厅编号,影厅名称,大小,负责人编号,所属影院编号)
(3)座位(座位编号,座位名称,状态,所属影厅编号)
(4)影片(影片编号,影片名称,类别编号,发行单位,发行时间,拷贝数,单价)
(5)影片类别(影片类别编号,类别名称)
(6)放映(放映编号,影厅编号,影片编号,开始时间,结束时间,放映日期,售票员,售票时间)
(7)部门(部门编号,部门名称,负责人,上级部门编号)
(8)管理人员(员工编号,员工姓名,性别,出生日期,职务,联系电话,联系地址,Email)
(9)影票(编号,影片编号,放映编号,座位编号)
(10)预定客户信息(编号,姓名,证件号码,座位编号,放映编号)
(11)票房统计信息(编号,影片编号,金额)(12)用户信息(姓名,密码)
5 系统实现
系统可以采用目前比较流行的ADO数据访问技术,并将每个数据库表的字段和操作封装到类中,从而成功地将面向对象的程序设计思想应用到数据库应用程序设计中。
模块及其内容描述如下:
Const用来管理工程中的常量。
DbFunc用来管理工程中与数据库操作相关的声明、变量和函数。
GeneralFunc用来管理工程中一些通用的自定义函数。
Variable用来管理工程中的全局变量。
5.1 Const模块
使用Public关键字可以定义一个全局变量,在工程中的任何地方都可以访问全局变量。
Const模块中通常的常量包括版本信息、工程生成日期和数据库连接信息等。
在Const中,数据库连接字符串的定义代码如下:
数据源信息常量和CONNECT_LOOP_MAX常量都与连接数据库的操作有关,它们将在DbFunc模块中使用。
5.2 DbFunc模块
使用DbFunc模块管理与数据库操作相关的声明、变量和函数。
DbFunc模块中包含了连接数据库、断开连接、执行SQL语句等几种数据库操作函数。
5.3 GeneralFunc模块
GeneralFunc模块模块用来管理通用的用户自定义函数。这些函数与数据库操作无关,可以应用在所有Visual Basic程序中。
如替换字符串中“’”字符的函数MakeStr()。
“’”字符在SQL语句中有着特殊的含义,它可以用来标识字符串的开始和结束。如果在字符串中包含了不必要的“’”的字符,就有可能产生错误。
5.4 Variable模块
Variable模块用来管理工程中的全局变量。
Variable模块的代码如下:
在Variable模块中,定义了一组类模块的实例。在声明类的实例时,一定要使用New关键字。它的作用是在第一次引用该变量时创建该对象的新实例。如果没有使用New关键字,则第一次引用变量时将报错。
6 结语
针对广泛需求的影院管理软件提出一种影院管理系统的设计与实现,此系统具有很好的扩展性,操作简单,可适用于中小影院进行科学规范有效的影院管理。
参考文献
[1]苏颖,张跃华.Visual Basic数据库开发应用技术.中国铁路出版社,2005.
[2]董国华,谢晗昕,陈艳华.信息系统开发实例精粹.电子工业出版社,2005.
数据库管理系统 篇11
关键词：“信息孤岛” 校务管理系统 数据共享 统一数据库
中图分类号：G203 文献标识码：A 文章编号：1673-8454（2007）12-0045-03
一、实施数据共享的背景和意义
中山大学信息管理系统自20世纪80年代开始建设，在各管理部门广泛使用。但随着时间的推移，原有的管理系统慢慢凸现许多弊端：
（1）多机型、多运行平台、多种数据库、多种运行方式、分散凌乱；
（2）面向部门、局部开发，没有共享的应用架构和技术架构，形成“信息孤岛”；
（3）各个部门的应用系统采用不同的信息编码规范和方式，系统之间数据交换困难，大都采用文本或者excel方式进行数据交换，这种数据交换方式效率低下、容易出错，而且对于需要实时获取数据的要求无法满足；
（4）各个应用系统之间同类信息重复设置，数据可信度差；
（5）难以实施综合流程和综合查询，决策支持能力弱。
随着学校规模的扩大和管理要求的提高，原有的管理系统已经远远不能满足学校发展的需要，系统的整合无论在建设理念、建设模式还是技术方面，都需要站在一个新的高度上来审视和全盘设计。中山大学提出了“五个统一”的实施原则，即统一数据库、统一标准、统一开发平台、统一用户管理、统一门户，并在五个统一的基础上，实施中山大学校务管理系统工程，校务管理系统的总体定位是：
（1）提高学校教育信息化的程度、管理水平以及整体综合实力；
（2）资源整合、优化、共享，消除数据重复管理、数据冗余以及数据不同步问题；
（3）规范、优化、重构业务流程；
（4）网络化、电子化、个性化办公环境，降低劳动强度，提升工作效率；
（5）综合分析、决策支持；
（6）公共信息服务、一站式服务。
从总体定位可以看出，实现数据共享是信息化资源共享的基础，是实施集成、综合、一体化解决方案的重要组成部分。
二、数据共享模式的探讨
在调研过程中，我们发现各个业务部门对信息化建设需求不同造成各部门使用的业务系统的完善程度各有不同。因此，选择何种数据共享模式，将对学校的校务管理系统工程建设产生巨大的影响，对学校的整体信息化建设也是至关重要的。从国内外实施数据共享的经验来看，目前数据共享模式主要有两种：一是采用数据交换平台的模式，另一种是采用统一数据库的方式。
1.“数据交换平台”的方案（见图1）
采用数据交换平台的方式，实施的关键点是“集成”，即原有建设的系统继续使用；新增的系统则按照新的规范建设。应用系统之间的交换数据可以集中存储、集中管理，形成一个统一的交换数据库（包含全校共用的基础数据和各业务系统的交换数据）。应用系统之间不再具有直接的数据关联，数据交换统一由业务数据库与交换数据库之间完成。因此，应用系统之间数据交换关系由原来的网状结构变成星型结构。[1]
2. “统一数据库”的方案
采用统一数据库方案，实施的关键点是“集中”，即需要重新规划设计业务系统，并逐步将原有的业务系统过渡到新的业务系统中；数据的存储和访问都采取新的模式进行，需要将原有业务系统的数据集中导入到统一数据库中。采用统一数据库方式具有更明显的优越性：
（1）如前所述，原有的信息管理系统的生命周期基本已经结束，不能满足学校整体应用的需要。原有的信息系统存在标准不统一、数据冗余、信息重复设置等弊端，已经没有继续沿用下去的意义，若继续使用原有的信息系统还会造成数据入口不统一，数据同步更新比较复杂等一系列的问题；
（2）在遗留数据库上实施软件开发或者数据交换平台都是令人备感挫折的软件开发现实，如果可能要尽量避免与它一起工作。[2] 特别是原有的业务系统基本都是在20世纪90年代开发的，采用的数据库模式各异，使得采用数据交换方式会更加困难甚至不可行；
（3）采用统一数据库方式能够保证数据的准确性、一致性和完整性问题，只有准确、完整的数据才能提高使用价值；
（4）采用统一数据库方式能够轻松解决综合信息服务问题、流程联动问题和辅助决策问题；
（5）在系统的安全稳定性方面，数据交换平台方式的安全问题分布在多个业务系统，根据木桶原理，整体安全性取决于业务系统中最薄弱的环节。而统一数据库采用集中控制方式，整体安全性大大提高；
（6）采用统一数据库的方式其后续的维护和管理更简单、成本更低，能实现信息化的可持续发展。
下面将对统一数据库在规划和实施过程中需要注意的问题进行探讨和研究。
三、统一数据库的规划与实施
1.保证全校信息编码的统一和一致
构建统一数据库，首先要关注的便是信息的标准化问题。整个高校的数据表示需要按照一定的标准编码，方便校内数据和各高校之间数据的流通。目前存在国家标准、行业标准、市级标准和高校内部标准，各个标准也不能完全一致。一般的实施做法是建立了一套以国家教育部信息标准为基础的数字化校园建议标准，在经过充分的实际调研工作之后，将根据学校的实际情况进行删减，并形成最终的某个高校的事实信息标准。[3]
在全校内统一信息标准是中山大学进一步做好信息化整合和共享、实现跨部门之间的业务整合的基础性工作，编码的标准化可以协调各部门的信息收集与信息处理工作，使之更符合系统的整体要求，减少信息的重复采集、加工和存储，保证信息的唯一性、及时性和可靠性。中山大学在建设校务管理系统的过程中形成了中山大学数字化校园校务管理系统信息分类与编码标准，并已经编写成书——《中山大学校务管理系统信息分类和编码标准》，该标准内容包括学校管理、人事、教学、办公、科研、财务、资产、其他等八类，共有267个代码标准，其中学校自编的代码有96种，相关的国家标准代码29种，相关的教育部标准代码142种。
2.数据的需求调研
采用统一数据库的方案，前期的数据调研就显得更为重要，需要结合各业务系统的需求分析对数据进行分类，从应用的角度可以将结构化数据分为以下三种，即：
（１）私有数据：业务部门产生的供自己系统使用的数据，如人事系统的进人过程信息；
（２）部门交换数据：部门之间需要交换的数据，这类型的数据通常存在于跨部门的流程中，如财务系统需要获取人事系统的人员工资信息；
（３）公共数据：为多数系统提供的共享数据，如人事系统的人员基本信息，教务系统、办公自动化系统、研究生管理系统等都需要用到。
在以上三种类型的数据中，对于交换数据和公共数据，除了定义数据结构外，还需要定义数据交换接口和数据权限。目前我们采用的数据交换接口主要是通过数据库视图和中间数据库两种方式。对于校务管理系统各业务系统之间的数据交换，我们采用数据库视图的方式，譬如教务系统需要用到学生收费系统中学生的交费情况，就可以直接调用学生收费情况视图查询；而对于有些不在校务管理系统中的数据交换需求，譬如一卡通系统、学生素质拓展系统，我们采用了中间数据库的方式提供数据，通过触发器将数据同步写入中间数据库中。除了这两种方式，在未来我们还需要提供基于xml的Web服务接口方式。
而数据权限定义则确保了数据库的设计遵循“谁产生、谁维护”的原则，明确了各业务系统之间的数据可视度。
3.统一数据库建设需要遵循轻重缓急的原则
中山大学校务管理系统一期工程涉及近20个行政机构和大部分的实体院系，首期MIS系统将以学校运作最重要的人、财、物的管理为主线，以人员（含教工、学生、校友）的管理为核心构建相应的业务系统。在规划统一数据库过程中，应当根据学校的整体需求和各业务系统的需求，分析哪些数据是需要首先整合进来的，哪些数据是以其他数据为基础而产生的；在此基础上，制定数据库建设的时间进度表。另外，还需要重视数据整理和导入工作，由于各部门原有的业务系统采用的数据存储模式都各不相同，因此在数据整理和导入工作上我们采用了由信息与网络中心牵头，各部处配合的模式，即各部处确保其提供的信息的准确性和完备性，信息与网络中心负责将各部处提供的数据导入统一数据库中。
4.借鉴高校建设共享数据库的经验
清华大学、北京大学、复旦大学等各高校在建设信息化的过程中积累了非常多的经验，对数据共享进行了深入的探讨和实践，譬如清华大学采用的是数据交换平台的模式，在各个应用系统业务数据库的基础上，建设交换数据库平台，并在数据交换的存储模式上进行了大量的研究和实践，这些都给我们建设统一数据库提供了宝贵的经验和思路。
5.坚持“统筹规划、统一标准、数据共享”的原则
无论是校务管理系统一期已经建设完成并投入使用的应用系统，还是正在建设或者新建的应用系统，在数据库设计上都必须坚持“统一标准、数据共享”的原则，只有这样，才能真正做到消除业务系统之间的冗余重复数据，消除“信息孤岛”，实现信息资源共享，提供可以反映整个学校全面情况的数据信息，从而为整个学校将来的决策支持系统积累分析数据。
四、结束语
实施统一数据库，是学校信息化建设的基石，在实施过程中，需要考虑各方面可能存在的问题。在技术上，需要解决信息标准、数据需求调研、数据库设计、各类型的数据整理、完善和导入等等；在非技术层面上，需要与各业务部门密切沟通，加强合作，共同为实现统一数据库这一目标而努力。本文分析了主要的数据共享模式，并对中山大学选择统一数据库方式进行了阐述，并探讨了在实践过程中需要注意的问题和应该遵循的原则。中山大学实施统一数据库将使整个学校的各业务系统能进行有机的集成，保持整体数据的统一和一致，并为整个学校的信息查询和决策分析提供可靠的、足够的、全面的数据保障，为数字化校园的进一步建设奠定基础。
参考文献：
[1]黄卫卫.基于交换的数据存储模式研究[J].教育信息化（增刊），２００４（７）：１６３－１６４
[2]Scott W. Ambler.Agile Database Techniques：Effective Strategies for the Agile Software Developer[M]. China machine press，November 2003
一卡通管理系统数据库设计分析 篇12
自从计算机应用到管理领域来, 世界发生了深刻的变化。建立起先进的信息管理系统成为企业高校发展的必然趋势, 而智能卡技术的推广和应用, 则是企业高校信息化的一个重要的标志。近年来, 高校经历了一系列的扩招调整, 各类事物越来越复杂, 信息量也越来越大, 涉及的部门也越来越多, 需要进行庞大的数据分析和存储, 如果沿用原来的手工操作方式, 无疑不能适应目前形势的需要。一卡通系统在这种背景下应运而生, 在当前高效企业信息化建设当中, 一卡通得到了高度重视, 成为今后高校企业信息化建设的必然趋势。在一卡通系统设计当中, 数据库系统占据了重要位置, 对于高校企业用户信息的管理起到至关重要的作用。
2 一卡通数据库系统功能
数据库是一种存储数据并对其进行操作的工作。数据库的作用是组织和表达想要的信息。简单的来说, 数据库就是信息的几何。计算机的数据库分为非关系数据库和关系数据库这两类。关系数据库当中包含了多个数据表的信息, 同时数据库当中含有不同部分的象记录、域等。
一卡通数据库设计应该包括人员信息的维护、信息注销、发卡时间登记以及有效期管理、挂失管理、补卡管理、门禁管理、消费管理、查询统计、系统管理等功能。人员信息的维护主要是用来记录个人的基本信息, 并能够修改这些信息。注销、有效期、挂失、补卡管理等功能主要是方便后期意外情况发生时能够方便进行有针对性的处理。系统管理主要是对用户的权限、部门的情况、消费状况等进行维护管理。
3 数据库的设计
设计数据库的时候需要全面的了解用户各方面的需求, 包括了现在有的以及将来可能会增加的需求。作为一卡通系统, 会随着硬件安装场所的变动而改动, 因此需要很大的可扩展性。用户的需求往往体现在各类信息的保存、更新和查询等等, 这就要求数据库的结构能够充分的满足各种输入输出信息的需求。收集基本的数据、数据结构以及处理数据的流程, 组成一份尽可能详尽的数据字典。有了数据库的结构、数据流程和数据项后, 就可以进行详细的数据库设计了。得到数据结构和数据项后, 根据此就能够设计用户需求的各种实体, 以及实体之间的关系, 为后面的逻辑结构的设计定下基础。实体之间通过相互作用形成数据的流动, 需要将现行的数据库概念结构化, 并且转化为SQL Server2000数据库系统所支持的实际的数据模型。在上述提到的实体之间的基础上, 形成数据库的表格以及各个表格之间的关系。经过了需求分析和结构设计后, 得到数据库的逻辑结构, 就可以通过SQL Server2000实现这个结构。
4 数据库的配置
一卡通系统涉及到众多的数据, 比如身份信息、消费信息等, 可以采用SQL Server2000作为数据库的开发平台。
4.1 客户端程序的实现
客户端是以高级的编程语言开发, 运行在局域网当中的各个客户机上面。提供给用户进行登录、维护数据、查询打印数据等功能。客户端软件通过TCP/IP协议可以访问服务器上的数据。每个用户只要有给定的权限就可以查询操作服务器上面的数据。当查询分析器执行SQL语言后, 就会自从产生需要的所有表格。有关的数据库结构各种后台工作已经完成。通过各个模块实现信息系统的相关的功能。
4.2 数据库的配置管理
采用流行的SQL Server和Windouws Server的数据库服务器的配置, 系统的数据和逻辑驻留在SQL Server数据库当中, , SQL Server以服务器的形式运行在Windows Server之上, 没有用户界面, 能够集中管理存储系统当中的数据。各个客户端可以使用win 7系统建立。SQL Server具有相当优异的安全性能, 可以设定访问的权限, 非常的方便导入导出数据库。除设置一个管理员来管理数据库, 管理员除了要检查数据库的配置和备份数据库当中的数据外, 还需要执行其他的很多任务, 同时必须保证服务器稳定和高效快捷的运行。、
SQL Server是一个很好的安全模型, 因此可以方面的定义各种安全措施, 包括从限制级数据库访问权限到限制对表中某一列的访问。在SQL Server中可以限制用户的访问权限, 也可以设置管理员使用的最高权限。在数据库定义当中, 每一个用户都有自己的使用权限, 用户的权限仅仅限于能够连接到数据库, 并不能修改数据库等其他的权限。在日常的数据库的运行当中, 需要按时的对数据库进行备份, 保证数据的安全以及完整。
数据库的分布策略采用混合式分布策略, 混合式的分布策略能够减少网络本地数据库服务器上的负载, 降低不同子系统之间的复杂性。此外, 系统当中的某个子系统出现故障, 系统仍然能够运行, 提高了系统的可靠性能。由于子系统数据库都在一卡通服务器上有备份, 因此当一个站点出现故障的时候, 通过SQL Server的复制能够快速的恢复数据。
4.3 数据库安全管理
一卡通系统当中包含了个人的很多信息, 为了保证一卡通的正常稳定方便的运行, 要在数据库当中建立一个加密系统来保证数据库的安全, 从而防止盗用窃取数据库的事情的发生。可以对一卡通进行特定范围内加密, 只有在这个范围内使用该卡才能够正常, 超过这个范围一卡通会自动锁死, 进入范围则自动解锁该卡。同时数据库的管理中心处理的信息服务器设置防护等级, 在数据服务器区设立绝密级数据服务器和机密级数据服务器, 提供数据库的安全性。
5 总结
随着数字化技术的广泛的应用, 一卡通的数据库得到不断的更新。对于每一个比如校园、小区、企业等局部封闭系统当中, 都有一个固定的资料中心, 所有的资料都可以在资料中心当中实现。一卡通加快了企业高校信息化程度, 提高了企业管理水平, 增强了对于用户的管理控制能力, 其高效便捷的管理功能使其必将成为社会信息管理的主流。
摘要：随着现代技术的发展, 计算机通信技术越来越多的被用到了生活当中。在过去的几年里, 越来越多的高校企业实施了一卡通系统。一卡通为高校企业的食堂管理、门禁、身份识别提供了极大的方便。本文研究了一卡通实用型的数据库设计, 概括了适合高校企业的“一卡通”数据库的设计。
关键词：一卡通,数据库,系统功能
参考文献
[1]王珊, 陈红.数据库系统原理教程[M].北京:清华大学出版社, 2006, 7.