（白城师范学院计算机科学学院，吉林白城137000）
【摘要】关系数据库、数据仓库和数据挖掘是作为三种独立的信息技术出现的，是数据库研究、开发和应用最活跃的分支之一，通过对三种技术的内在联系性和互补性分析，从而更好的使用数据库技术处理各种信息需求，建立更加完善的数据库应用系统或新的决策系统。
关键词 关系数据库；数据仓库；数据挖掘；关
0引言
关系数据库是20世纪70年代初提出来，经过数据库专家几十年的努力，理论和实践都取得了显著成果，标志着数据库技术的日益成熟。但它仍然难以实现对关系数据库中数据的分析，不能很好地支持决策，因此在80年代，产生了数据仓库的思想，90年代，数据仓库的基本原理、架构形式和使用原则都已确定。主要技术包括对数据库中数据访问、网络、C/S结构和图形界面，一些大公司已经开始构建数据仓库。针对数据仓库中迅速增长的海量数据的收集、存放，用人力已经不能解决，那么数据仓库中有用的知识的提取就需要数据挖掘来实现。数据挖掘与统计学子领域“试探性数据分析”及人工智能子领域“知识发现”和机器学有关，是一门综合性的技术学科。了解关系数据库、数据仓库与数据挖掘三者之间的区别与联系，使之更好的使用这3种技术，处理各种信息需求是非常必要和重要的。
1关系数据库、数据仓库和数据挖掘之间的关系
1.1关系数据库和数据仓库之间的联系与区别
关系数据库是面向事务的设计，数据仓库是一个面向主题的设计；关系数据库存储在线事务数据，数据仓库通常存储历史数据，关系数据库的设计将尽量避免冗余，但数据仓库是倾向于引入冗余；关系数据库设计用于捕获数据，数据仓库设计用于分析数据。传统的关系数据库面向以事务处理为主的系统应用，所以它无法满足决策支持系统的分析要求。事务处理和分析处理有非常不同的性质，他们有不同的需求数据。
1.2数据仓库与数据挖掘之间的联系与区别
数据挖掘是基于数据仓库和多维数据库中的数据，找到数据的潜在模式进行预测，它可以对数据进行复杂处理。大多数情况下，数据挖掘是让数据从数据仓库到数据挖掘数据库中。从数据仓库中直接得到进行数据挖掘的数据有许多优点，因为数据仓库中数据的清理和数据挖掘中几乎是相同的，如果数据在数据仓库中已被清除，数据挖掘中不再被清除，并且数据不一致也得到了解决。数据仓库是数据挖掘的先期步骤，通过数据仓库的构建，提高了数据挖掘的效率和能力，保证了数据挖掘中的数据的宽广性和完整性。
1.3关系数据库与数据挖掘之间的联系与区别
数据挖掘的数据源不一定是数据仓库。也可以是一个关系数据库中的数据，但要事先进行数据预处理，才能用于数据挖掘。数据预处理是数据挖掘的关键步骤，并且是数据挖掘过程中的主要工作部分。因此，数据仓库和数据挖掘没有必然的联系，有些人简单地认为，数据仓库是数据挖掘的准备，这种理解是不全面的，也可以使用关系数据库中的数据作为数据挖掘的数据源。
2三种技术的应用
2.1应用价值
2.1.1关系数据库
关系数据库的主要价值体现在事务处理。关系数据库已经渗透到各行各业的日常事务，该事务管理离不开关系数据库的应用系统，这是对传统事务管理的一个重大突破，是社会甚至家庭不可或缺的工具，它对社会的应用价值是100%。
2.1.2数据仓库
数据仓库的主要价值体现在为决策分析提供数据源。一方面，在一个事务中，用户要求高效的访问系统和数据库，操作时间应该短。在一个决策分析中，决策问题的一些请求可能会导致系统的操作，解决这一问题的决策分析需要遍历大多数数据库中的数据，这对一般日常事务处理系统是困难的，所以操作数据和决策分析数据应该分开。另一方面，决策数据需求问题。在决策分析时，由于不同的应用系统中，实体、字段存在数据类型、名称和格式的不符，需要在集成时进行转换，这个转换必须在决策之前完成；一些决策数据需要动态更新，需要经常进行汇总和总结，这些需求用事务处理系统解决比较繁琐。三是数据的操作模式问题。决策分析人员要以专业用户身份，使用各种工具以各种形式来操作数据，对数据操作的结果以商业智能的方式表达出来。事务处理系统不能满足这一要求，只有数据仓库系统能够满足数据挖掘技术对数据环境的要求，所以使用数据仓库中的数据省去了对数据预处理的步骤。
2.1.3数据挖掘
面对日益激烈的市场竞争，客户对迅速应答各种业务问题的能力要求越来越高，对过量数据的及时处理要求越来越高，带来的挑战一方面大规模、复杂数据系统让用户感觉漫无头绪，无法开始；另一方面，这些大量数据背后隐藏很多有意义的有价值的决策信息。如计算机界都熟知的“啤酒与尿布”的故事，就是零售业巨头“沃尔玛”从大量销售数据中分析出来的规律：美国的男士在下班要去超市买婴儿尿布，同时他们还会买啤酒。“沃尔玛”就把这两种“毫不相干”的商品摆放在靠近的货架上，并且还摆放一些下洒小菜，使这些商品销量大增。所以应用数据挖掘从大量数据中发现规律，具有具体的指导意义。
2.2应用领域
2.2.1关系数据库
关系数据库应用领域非常广泛，如：证券行业、医院、银行、销售部门、公司或企业，以及政府、国防工业，科学和技术发展领域等等，这些领域都需要使用数据库来存储数据。例如:人事管理系统、工资管理系统，xxx部门信息管理系统，手机话费管理系统等，都需要关系数据库作为后台提供数据源。
2.2.2数据仓库
数据仓库应用领域主要有两个方面：一是全局应用。因为数据仓库获得来自多方面的数据，所以在把数据向数据仓库输入时，要进行转换、计算和综合等集成处理。通过处理把来自不同地方的数据源转换成统一的格式，以促进全局应用。二是复杂系统。信息处理的要求越来越复杂，除了数据处理操作，如添加、删除、修改、和统计汇总，高级管理层也希望对历史的和现在的数据进行各种复杂性分析，以支持决策。数据仓库中就是存储了旧的历史数据，方便复杂分析、应用，为高层决策服务。
2.2.3数据挖掘
数据挖掘的应用领域主要表现在特定应用问题和应用背景。数据挖掘技术已经应用于各行各业，如电信，保险，交通，学校、银行、超级市场等。例如：数据挖掘技术应用在大学。高校扩招，学生增加到几万人，但是学生的学习积极性不高，成绩不好，因此引入数据挖掘技术找出影响学生学习积极性和学习成绩的原因，制定措施，提高教育和教学质量。分析的数据源是考试成绩和成绩之外的影响因素，分析的方法是采用关联规则、模型库、去“噪”处理、粗糙集等进行数据挖掘，得出的结论是：传统的学习方法不能完全满足需要，改进教学方法和教学模式，从而调动学生学习的积极性，提高教学质量。
3关系数据库、数据仓库与数据挖掘的融合
日常事务处理需要关系数据库，构建分析处理（下转第318页）（上接第59页）环境需要数据仓库，帮助决策者寻找数据之间的潜在的关联需要数据挖掘。他们之间是相互联系又有区别的，不能互相取代的，又需要相互融合。数据仓库中的数据并不是最新的，专有的，而是来源于其他关系数据库，它是建立在一个更全面和完善的信息应用的基础上，用于支持高层决策分析的数据基地。数据仓库是数据库新技术，到目前为止，数据仓库仍用关系数据库管理系统管理数据。数据挖掘是从大量存储在数据库、数据仓库或其他信息库中发现有趣知识的过程。只有这三个数据库技术互相融合，取长补短，各尽其责，才能更好的为广大用户所使用，为社会各个领域所应用。
参考文献
［1］华冠萍.数据仓库、数据挖掘及OLAP之两两关系[J].福建电脑,2007,8.
［2］牛承珍.马季兰.浅谈数据挖掘应用[J].山西科,2008.5.20.
关键词：NoSQL数据库；关系型数据库；CAP理论
中图分类号：TP311文献标识码：A文章编号：1009-3044(2011)20-4802-03
Relational Database and NoSQL Database
ZHANG Hua-qiang
(Anhui Nari Jiyuan Software CO.,LTD., Hefei 230088,China)
Abstract: This paper introduces a database called NoSQL,thoughout the descriptions of the traditional relational database and its present problems, meanwhile,points out the characteristics of NoSQL datebase and the current application situations; finally, summarizes how to usein combination with NoSQL database and the traditional relational database in some scenes and illustrates with some examples.
Key words: relational database; NoSQL database; CAP theory
回顾数据库的发展历程，数据库技术从60年代末开始，经历了层次数据库、网状数据库和关系数据库而进入数据库管理系统( DBMS)阶段至今, 数据库技术的研究也不断取得进展。最近几十年, 关系型数据库成为发展的主流, 几乎所有新推出的DBMS产品都是关系型的。关系型数据库在计算机数据管理的发展史上是一个重要的里程碑。但最近NoSQL数据库却风声鹊起，引起了人们的极大关注。NoSQL数据库并不是最近才出现的，很多NoSQL数据库实现都已经存在了十多年了，有很多成功案例，是什么原因让它们比以前更受欢迎了呢？NoSQL数据库会不会替代现有的关系型数据库呢？本文将一一为你做出解答。
1 关系型数据库
1.1 关系型数据库概述
关系型数据库是支持关系模型的数据库系统，他是目前各类数据库中最重要，也是使用最广泛的数据库系统。关系型数据库从诞生到现在经过几十年的发展，已经变的比较成熟，目前市场上主流的数据库都为关系型数据库，比较知名的如Sybase，Oracle，Informix，SQL Server，DB2等。
1.2 关系型数据库的优势
关系型数据库相比其他模型的数据库而言，有着以下优点：
容易理解：关系模型中的二维表结构非常贴近逻辑世界，相对于网状、层次等其他模型来说更容易理解。
使用方便：通用的SQL语言使得操作关系型数据库非常方便，只需使用SQL语言在逻辑层面操作数据库，而完全不必理解其底层实现。
易于维护：丰富的完整性（实体完整性、参照完整性和用户定义的完整性）大大降低了数据冗余和数据不一致的概率。
1.3 关系型数据库存在的问题
传统的关系型数据库具有不错的性能，高稳定型，久经历史考验，而且使用简单，功能强大，同时也积累了大量的成功案例。在90年代的互联网领域，一个网站的访问量一般都不大，用单个数据库完全可以轻松应付。在那个时候，更多的都是静态网页，动态交互类型的网站不多。可是最近几年，互联网Web2.0网站开始快速发展。火爆的论坛、博客、微博逐渐引领web领域的潮流。传统的关系型数据库在应付这些超大规模和高并发的纯动态网站显得力不从心，暴露了很多难以克服的问题。
数据库高并发读写：高并发的纯动态网站一般都是根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘IO就已经无法承受了。
海量数据的高效率存储和访问：上述提到的Web2.0网站，每天用户会产生海量的动态信息，对于关系数据库来说，在一张数以亿计条记录的表里面进行SQL查询，效率是极其低下，难以忍受的。
数据库的高可扩展性和高可用性：基于web的架构当中，数据库无法通过添加更多的硬件和服务节点来扩展性能和负载能力，对于很多需要提供24小时不间断服务的网站来说，数据库系统升级和扩展却只能通过停机来实现，这无疑是一个艰难的决定。
2 NoSQL数据库
2.1 NoSQL数据库概述
NoSQL数据库是非关系型数据存储的广义定义，它打破了长久以来关系型数据库与ACID理论大一统的局面。NoSQL 数据存储不需要固定的表结构，通常也不存在连接操作。NoSQL数据库不使用传统的关系数据库模型，而是使用如key-value存储、文档型的、列存储、图型数据库、xml等方式存储数据模型。 其中用的最多的是： key-value存储。
2.2 NoSQL数据库优势
易扩展：NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系型数据库的关系型特性。数据之间无关系，这样就非常容易扩展。也无形之间，在架构的层面上带来了可扩展的能力。
大数据量，高性能: 同样由于数据之间无关系，数据库的结构简单，在大数据量下，NoSQL数据库表现出非常高的读写性能。
灵活的数据模型：NoSQL数据库无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系型数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直难以想象。
2.3 NoSQL数据库应用现状
NoSQL数据库并不是最近才出现的，很多NoSQL数据库实现都已经存在了十多年了，有很多成功案例，是什么原因让它们比以前更受欢迎了呢？首先是由于社会化网络和云计算的发展，一些原先只有很高端的组织才会面临的问题，如今已经成为普遍问题了。其次，已有的方法已经被发现无法跟随需求一起扩展了。并且成本的压力让很多组织需要去寻找更高性价比的方案，并且研究证实基于普通廉价硬件的分布式存储解决方案甚至比现在的高端数据库更加可靠。所有这些导致了对NoSQL数据库的需求。
Web2.0技术在网络中的广泛应用为NoSQL数据库发展提供了充足的动力，市场上先后出现了十多种比较流行的NoSQL产品，例如：Redis，Tokyo Cabinet，Cassandra，Voldemort，MongoDB，Dynomite，HBase，CouchDB，Hypertable， Riak，Tin， Flare， Lightcloud， KiokuDB，Scalaris， Kai， ThruDB，...... 这些NoSQL数据库都有自己的独到之处。有满足极高读写性能需求的Kye-Value数据库：Redis，Tokyo Cabinet， Flare；还有满足海量存储需求和访问的面向文档的数据库：MongoDB，CouchDB；以及满足高可扩展性和可用性的面向分布式计算的数据库：Cassandra，Voldemort；在此就不详细介绍每款NoSQL数据库了。
3 关系型数据库与NoSQL数据库结合
伴随着越来越多的NoSQL产品涌现出来， NoSQL数据库会不会替代现有的关系数据库？在说明之前，我们先简单了解下CAP理论，以及ACID、BASE。
3.1 CAP理论
CAP:
C: Consistency 一致性
A: Availability 可用性 (指的是快速获取数据)
P: Tolerance of network Partition 分区容忍性 (分布式)
ACID：
ACID事务提供以下几种保证：
Atomicity（原子性），事务中的所有操作，要么全部成功，要么全部不做。
Consistency（一致性），在事务开始与结束时，数据库处于一致状态。
Isolation（隔离性），事务如同只有这一个操作在被数据库所执行一样。
Durability（持久性），在事务结束时，此操作将不可逆转。
BASE：
Basically Available（基本可用）
Soft-state（软状态/柔性事务）
Eventual Consistency（最终一致性）
BASE模型是传统ACID模型的反面，不同与ACID，BASE强调牺牲高一致性，从而获得可用性，数据允许在一段时间内的不一致，只要保证最终一致就可以了。
互联网Web2.0网站由于数据库存在高并发读写、高可扩展性、高可用性，所以要求设计成分布式存储，而在设计一个分布式存储系统时，根据CAP理论，一致性(C)，可用性(A)，分区容错性(P)，三者不可兼得，最多只能同时满足其中的两个。而关系型数据库保证了强一致性(ACID模型)和高可用性，所以要想实现一个分布式数据库集群非常困难，这也解释了为什么关系型数据库的扩展能力十分有限。而NoSQL数据库则是通过牺牲强一致性，采用BASE模型，用最终一致性的思想来设计分布式系统，从而使得系统可以达到很高的可用性和扩展性。
对Web2.0网站来说，可用性与分区容忍性优先级要高于数据一致性，一般会尽量朝着 A 、P 的方向设计，但事实上，数据库系统最大的优势就对一致性的保证，单纯为了P(分布式)而放弃C（一致性）也是不可取的，所以需要通过其它手段来保证对于一致性的商务需求。
3.2NoSQL数据库实际应用缺陷
缺乏强有力的商业支持：大部分的NoSQL数据库都是开源项目，没有世界级的数据库厂商提供完善的服务，如果出现故障，只能自己解决，风险较大。
成熟度不高： NoSQL数据库的实际应用不多，大部分NoSQL产品都在小范围应用。成熟度不高，目前还很难在企业中广泛应用。
NoSQL数据库在设计时难以体现实际：关系型数据库中的关系模型对于数据库设计是很有帮助的，而NoSQL数据库缺乏这种关系，难以体现业务的实际情况，对于数据库的设计与维护都增加了很大难度。
3.3 关系型数据库与NoSQL数据库结合
从上面的CAP理论来看，分布式存储系统更适合用NoSQL数据库，现有的Web2.0网站遇到的性能以及扩展性瓶颈也会迎刃而解，但是目前NoSQL数据库的实际应用缺陷又让我们难以放心。这时我们考虑是否可以将NoSQL数据库与关系型数据库结合使用，在强一致性(C)，高可用性场景我们采用ACID模型，在高可用性和扩展性场景，我们就采用BASE模型，答案是肯定的，目前的NoSQL数据库还难以与关系型数据库一争高下，但它却可以对关系数据库在性能和扩展性上进行弥补，所以我们可以把NoSQL和关系数据库进行结合使用，各取所长，需要使用关系特性的时候我们使用关系数据库，需要使用NoSQL特性的时候我们使用NoSQL数据库，各得其所。
下面举个典型的例子加以说明：
在Web2.0网站中比较典型就是用户评论的存储，评论表大致可分为评论表主键ID、被评论用户ID、评论用户ID、评论时间、评论内容等字段。结合关系型数据库与NoSQL数据库的特点，我们可将需要查询的字段，比如评论表主键ID、被评论用户ID、评论用户ID、评论时间等数据、时间类型的小字段存储于关系型数据库中，根据查询建立相应的索引，而评论内容是个大文本字段，我们肯定不会通过文本内容进行查询，所以我们把评论内容存储在NoSQL数据库中。这种让关系型数据库专门负责处理擅长的关系存储，NoSQL数据库作为数据的存储的结合使用方式，首先节省了关系型数据库的IO开销，提高了数据库的数据备份与恢复速度；其次由于NoSQL数据库的Cache往往都是行级别的，所以对评论内容字段也更容易做Cache，最后由于NoSQL数据库天生就容易扩展，经过这种结合优化，关系型数据库的性能也能得到提高。这种结合方式实现起来比较容易，却能取得不错的效果。关系型数据库与NoSQL数据库结合并不局限于这种方式，应该根据具体的应用场景灵活组合使用。
4 结束语
关系数据库已经流行了几十年了，NoSQL数据库想在短期内取而代之显然是不可能的，但是NoSQL数据库的发展势头也不容小觑。在当前阶段的某些场景下，可以将NoSQL数据库与关系型数据库结合使用，相互弥补各自的缺陷，这种数据库组合对解决目前Web2.0网站所遇到的性能、扩展性等问题具有指导意义。
参考文献：
[1] 李莉莎.关于NOSQL的思考[J].中国传媒科技,2010(4):40-41.
全球多家研究机构统计数据显示，大数据产业将迎来发展黄金期，IDC预计，大数据和分析市场将从2016年的1300亿美元增长到2020年的2030亿美元以上，中国报告大厅的大数据行业报告数据也说明，自2017年起，未来2-3年的市场规模增长率将保持在35%左右。大数据像空气一样，随处可见，日积月累的海量数据不得不让人们重新考虑大数据的存储和管理。
2传统关系数据库面临的挑战
基于二维关系模型的数据库在数据管理的发展历程中是一个标志性的时期，数据结构化存储，冗余较低、程序和数据具有一定的独立性、易扩充等特点。随着Internet技术的发展，涌现出半结构化、非结构化数据，对这些结构复杂的大数据的高效实时多维分析的需求越来越多。传统的关系数据库从70年展至今，虽然应用范围较广技术较成熟，但在处理海量数据方面还存在许多不足。（1）关系模型结构制约了快速访问大数据的能力。在二维关系表中，依据属性的值来检索相应的元组，受这种方式的束缚，在检索数据过程中，将耗费一定的时间，从而使访问数据的时间较慢。在存储对象设计上虽然可以使用分区的方法，提高数据访问冲突，但在大量数据的前提下，分区技术改善的性能较微弱。（2）处理大数据的灵活性不足。在应用系统中，用户的各种查询需求经常发生变化，不受时间和操作对象的约束，用户希望随时随地都能快速得到反馈结果。关系型数据库需要专门的数据库维护人员对用户的查询要求进行优化处理，不能及时的反馈给用户查询结果，这使得使用关系数据库存储数据的企业不具备对大数据的快速响应能力。（3）处理复杂结构数据能力较弱。关系型数据库对现实数据的处理常见类型为字符、数值等，对于半结构化和非结构化数据的处理只限于二进制代码文件的存储，而现今用户对复杂结构数据的要求上升为识别、检索和多维分析，如何处理占总数据量85%的非结构化数据，是许多关系数据库产品需要解决的问题。（4）存储维护管理PB级数据导致成本不断增加。数据量递增使得企业在硬件存储上投资不断增加，虽然存储设备的投入成本在逐步降低，但总成本却在逐步提高。此外，大量复杂结构的数据维护工作也给数据库管理员增加了很多负担。
3大数据库技术
随着大数据技术的日趋完善，各大公司及开源社区都陆续了一系列新型数据库来解决海量数据的组织、存储及管理问题。目前，工业界主流的处理海量数据的数据库有四种，分别是列式数据库、内存数据库、键值数据库及流式数据库。
3.1列式数据库
采用列族存储数据，将经常被使用的数据放到一个列族中，例如，经常会查询学生的学号和姓名，而不是专业，这样把学号和姓名放到一个列族中，专业放到另一个列族中，该数据库通常用来存储分布式大数据，HBase是列式数据库的典型代表。
3.2内存数据库
对数据库中所有数据的操作都在内存中完成，一般数据库也有一定的缓存机制，对大部分数据的操作都包含从外存到内存的读取，这一过程在很大程度上降低了系统的性能。由于在内存中的读/写是以纳秒为单位的，所以内存数据库的性能极高，Spark是内存数据库的典型代表。
3.3键值数据库
该数据库主要借助哈希表的结构，使用一个特定的键和一个指向特定数据的指针，利用键来完成对数据库中数据的添加、删除和查询操作，这种结构具有很好的扩展性，使系统具有较高的性能，Memcached、Redis、MemcacheDB都是键值数据库的典型代表。
3.4流式数据库
基本理念是数据的价值会随着时间的流逝而不断减少，因此，需要使式数据库来实现流式计算。流式计算处理模式是将源源不断的数据视为数据流，它总是尽可能快速地分析最新的数据，并给出分析结果，也就是尽可能实现实时计算。典型流式数据库：SparkStreaming、Storm。
4大数据SQL
大数据查询分析是基于互联网的相关服务的增加、使用和交互模式中的核心问题。由ApacheLucene的创始人DoungCutting使用GFS、Map-Reduce技术支持创建的ApacheHadoop，是一个能够对大量数据进行分布式处理的软件框架。Hadoop技术无处不在，其发展得益于Google发表的关于GFS和MapReduce的论文。在开源世界，ApacheHadoop的分布式文件系统HDFS和HadoopMapReduce完全是谷歌文件系统GFS和MapReduce的开源实现。Hadoop项目已经发展成为一个生态圈，触及了大数据领域的各个方面。由Google的BigTable和Amazon的Dynamo使用的NoSQL数据库，提倡使用非关系型的数据存储，这一全新的思维的注入，打破了关系型数据库管理系统在商用数据库领域几十年的统治性地位。
关键词:SQL Server ;数据库;完整性;安全性;保护
中图分类号:TP311文献标识码:A文章编号:1009-3044(2010)03-526-02
On the Relational Database Protection Strategy
CHEN Yu
(Anhui Institute of Economics and Management, Hefei 230001, China)
Abstract: With the rapid development of computer technology, database applications are very extensive, has been deep into all areas of society, but the attendant had a data security protection, the database stored in a large number of information resources, information security is an important aspects. Papers exist in the database and a number of security issues, summed up in the SQL Server database integrity in the necessary controls and security settings, including authentication and access management.
Key words: SQL Server; Database; Integrity; Security; Protection
关系数据库的特点之一就是DBMS能提供统一的数据保护功能来保证数据的安全可靠和正确有效,数据库的数据保护主要包括数据的安全性和数据的完整性。数据库的完整性是指数据的正确性和相容性,是为了防止数据库中存在不符合语义的数据,也就是防止数据库中存在不正确的数据;数据库的安全性是指保护数据库以防止不合法的使用所造成的数据泄露、更改或破坏。数据库中的数据是从外界输入的,而数据的输入由于种种原因,会发生输入无效或错误信息,保证输入的数据符合规定,成为数据库系统,尤其是多用户的关系数据库系统首要关注的问题,数据完整性因此而提出。另外数据库中大量数据的集中存放和管理,日渐成为非法入侵者攻击的焦点,数据库的安全越来越多地受到网络安全、操作系统安全、用户等多方面因素的影响,已经成为了信息安全的主要研究课题之一。论文将以目前主流的关系数据库系统软件SQL Server为例来讨论数据库系统的数据保护策略。
1 关系数据库的完整性控制
1.1 概述
为了保证数据库的完整性,DBMS一般都提供了对数据库完整性进行定义、检查及违约处理机制,并把用户定义的数据库完整性约束条件作为模式的一部分存入数据字典中。DBMS中检查数据是否满足完整性约束条件的机制称为完整性检查,一般在对数据库中数据进行增、删、改操作后开始检查,也可以在事务提交时检查,检查这些操作执行后数据库中的数据是否违背了完整性约束条件。当DBMS发现用户的操作违背了完整性约束条件,就采取一定的动作,如拒绝(NO ACTION)执行该操作或级连(CASCADE)执行其他操作,进行违约处理以保证数据的完整性。
关系数据库的完整性控制主要包括三类:实体完整性、参照完整性与用户自定义完整性。实体完整性规定关系中的主码取值唯一且非空;参照完整性规定关系的外码取值为被参照关系主码的值或取空值;除此两类必须满足的完整性约束以外,关系在不同的应用环境当中,往往还需要一些特殊的约束条件,用户自定义的完整性就是针对某一具体关系数据库的约束条件,它反映某一具体应用所涉及的数据必须满足的语义要求。
1.2 SQL Server中的完整性设置
在SQL Server中,可以通过“约束”、“规则”、“默认”、“触发器”、“存储过程”等来达到保证数据完整性的目的。
1.2.1 通过“约束”实施数据的完整性控制
约束是强制实行的应用规则,它通过限制列中数据、行中数据来保证数据的完整性,包括CHECK约束、PRIMARY KEY约束、FOREIGN KEY约束、UNIQUE约束。
举例1:create table xs_cj
(学号char(8) not null
constraint pk-cj primary key clustered, /*定义主键约束*/
课程号char(3) not null,
成绩 tinyint null)
1.2.2 通过“规则”实施数据的完整性控制
“规则”的作用类似于“检查约束”,若将一个“规则”绑定到指定列上,则可以检查该列的数据是否符合“规则”的要求。“规则”与“检查约束”的主要区别在于一列只能绑定一个“规则”,但却可以设置多个“检查约束”。“规则”的优点是仅创建一次就可以绑定到数据库的多个表的列上,使同一个数据库中所有表的不同列共享。“规则”还可以绑定到同一数据库中一个以上的用户定义的数据类型上。使用“规则”的过程依次为:创建规则――绑定规则――解除绑定――删除规则。
举例2:use xs_cj
create rule rule_cjas@成绩>=0 and @成绩
go
sp_bindrule rule_cj,'学生成绩表.成绩'
/*将"规则rule_cj"绑定到的“成绩”字段*/
sp_bindrule rule_cj,'学生成绩表.补考成绩'
/*将"规则rule_cj"绑定到的“补考成绩”字段*/
1.2.3 通过“默认”实施数据的完整性控制
与“规则”类似,“默认值”对象(简称为“默认”)也是仅创建一次就可以绑定到数据库的多个表的列或用户定义的数据类型中,使它们共享“默认”。作用与DEFAULT约束相似,在插入数据行时,为没有指定数据的列提供事先定义的默认值。
举例3:use xs_cj
go
create default xscj_mr as '男'/*创建默认对象*/
use xsda
go
exec sp_bindefault 'xscj_mr',' xsda.性别' /*将默认对象绑定到表xsda的性别列上*/
2 关系数据库的安全性控制
2.1 概述
数据库必须具有坚固的安全系统,才能控制可以执行的活动以及可以查看和修改的信息。无论用户如何获得对数据库的访问权限,坚固的安全系统都可以确保对数据进行保护。安全系统的构架建立在用户组的基础上。
2.2 SQL Server中的安全设置
在SQL Server中,用户要经过两个安全性阶段:身份验证和授权。身份验证能决定用户能否连接到服务器,授权阶段验证已登陆服务器的用户能否连接SQL Server实例的权力。
2.2.1 SQL Server 的身份验证模式
SQL Server 服务器身份验证有以下两种模式:Windows 认证模式和Windows 与SQL Server混合认证模式。Windows 认证更为安全, 因为Windows 操作系统具有较高的安全性(C2 级安全标准) 。SQL Server 认证管理较为简单, 当SQL Server 在Windows NT 或Windows2000 上运行时, 系统管理员必须制定系统使用的认证模式。当采用混合认证模式时,SQL Server 既允许使用Windows 认证模式又允许使用SQL Server 认证模式。在完成SQL Server 安装以后, SQL Server 就建立了一个特殊帐户sa。sa 帐户拥有最高的管理权限, 可以执行服务器范围内的所有操作, 既不能更改sa 用户名称, 也不能删除sa, 但可以更改其密码。在刚刚完成SQL Server 的安装时候, sa 帐户没有任何密码, 所以要尽快为其设置密码。
2.2.2 授权阶段
只有授权的用户和系统才能访问被保护了的数据,保密性是防止非授权访问,这是信息安全最重要的要求。用户在实现安全登录之后,检验用户的下一个安全等级是数据库访问权限。在身份验证阶段利用登陆账号连接到服务器后,只表明该账户通过了Windows NT认证或SQL Server认证,并不代表用户就能访问数据库,而登陆者要操作数据库中的数据时,必须要有用户账号才能够存取数据库。就如同在自助银行门口刷卡进门(登录服务器),然后再凭银行卡和密码支取金额(进入数据库)一样。数据库用户是指在数据库内唯一标识用户身份的ID。SQL Server通过授权和角色管理来给用户指定可以访问的数据库对象的权限。如果一组用户具有相同的权限,那么我们可以先创建一个角色,对这个角色赋予权限,然后将这些用户添加到该角色中使它们成为这个角色的成员。这样就可以对这些相同权限的用户进行统一的管理,在用户较多的情况下减轻了管理负担。在SQL Server中,系统的每个数据库都定义了许多不同的固定角色,但这些角色的范围只限于它所在的数据库。每个用户可以属于多个不同的角色,从而拥有不同的权限。
3 结束语
数据库安全保护是管理信息系统中的重要课题,涉及的范围很广,可以采用的安全策略也很多。因此,必须根据具体的应用环境的安全需要分析安全薄弱环节,并制定统一的安全管理策略加以实施。良好的数据库的安全性设计,可以有效地保护数据库,防止不合法的访问和破坏。SQL Server 数据库本身具备一定的安全防范能力,然而最关键的还需要加强对数据库安全的认识和相关培训。数据库安全性问题的探讨仍需继续,还有更多的数据库安全维护工作等着完善。
参考文献:
[1] 王珊,萨师煊.数据库系统概论[M].高等教育出版社,2006.
[2] 李德有,彭德林. SQL Server 数据库应用与开发[M].中国水利水电出版社,2007:180.
[3] 张鑫燕,吴小松. SQL Server 2000程序设计[M].科学出版社,2003.
[4] 王玉,粘新育. SQL Server 数据库应用技术[M].中国铁道出版社,2008:183-201.
[5] 饶琛,赵晓静. 浅谈SQL Server 数据库的安全设计与应用[J] . 电脑知识与技术,2008,5 :1-2.
[6] 王曦. 关于SQL Server 数据库安全设置的探讨[J].福建电脑,2008,10:1-2.
关键词:关系数据库;云端数据库;Bigtable;时间戳
中图分类号:TP399文献标识码:A文章编号:1009-3044(2009)25-7090-03
Comparison and Analysis for Relational Database and Cloud Database Based on Architecture
ZHANG Zhen-yong, WEN Jing-hua
(Guizhou College of Finance and Economics, Guiyang 550004,China)
Abstract: Aiming at the shortcoming that relational database processes a large number of video,audio,images and complex data types, this thesis compared and analyzed relational database and Bigtable representing cloud database and based on architecture. The results showed that cloud database was more advantageous than relational database in precessing a great mass of data and complex data types. With the development of the cloud database technology,cloud database will be superseding the relational database as the mainstream of the database.
Key words: ralational database; cloud database; bigtable; timestamp
关系数据库从1970年发展至今,虽功能日趋完善,但对数据类型的处理大多采用数字、字符等基本数据类型,对多媒体信息的处理只是停留在简单的二进制代码文件的存储。随着信息技术的发展,互联网上数据量高速增长,非结构化数据的应用日趋扩大,再加上用户应用需求的提高、硬件技术的发展和Web2.0提供的多彩的多媒体交流方式,用户对多媒体处理的要求从简单的存储上升为识别、检索和深入加工等高级应用。关系数据库在处理这类数据时,逐渐暴露出了一些缺陷。
如何来高效处理占数据总量70%的声音、图像和视频等复杂数据类型是目前互联网界亟待解决的问题。正是在这种状态下,云端数据库便应运而生并开始发展起来。目前云端数据库技术在云计算中的应用有Google的Bigtable系统[1]、Amazon公司的Dynamo系统、Hadoop的一个子项目Hbase、微软的Live Mesh系统等等。无论是Bigtable还是Hbase都是采用通用的云端数据库架构,只是核心技术不同。所以本文就以Google的Bigtable架构为代表与传统的关系数据库架构进行比较和分析。
1关系数据库
1.1关系数据库概念及特点
关系数据库在一个给定的应用领域中,所有实体及实体之间联系的关系的集合。它是建立在集合代数基础上,应用数学方法来处理数据库中的数据,现实世界中的各种实体以及实体之间的各种联系均用关系模型来表示,也就是说关系数据库是建立在关系模型基础上的数据库[2]。
关系数据库具有数据结构化、最低冗余度、较高的程序与数据独立性、易于扩充、易于编制应用程序等优点,目前较大的应用软件系统都是建立在结构化数据库设计之上的。
1.2关系数据库系统的架构
关系数据库的架构包括六个部分[3]:
1) 查询语言接口
查询语言接口通过使用SQL语言对数据库进行特设查询数据。
2)交互式查询工具
交互式查询工具是用于访问,修改以及更新一个或多个关联的数据表,并以视图的方式返回给用户。
3) 核心软件
该核心软件用于控制查询处理,存取数据路径,用户访问管理,存储管理,索引,交易处理和读取/更新信息。
4) 公用机制
公用机制主要用于输入/输出/备份调整工具及参数/报告撰写。
5) 存储机制
存储机制主要进行数据库写入,归档,用户管理器,服务器管理,重做日志文件。
6) 数据库
数据库的特点是以数据文件的方式对数据对象进行物理存储,包含了系统目录即数据目录,一个或多个数据文件以结构化形式存储组成集合即二维表,并将不同数据集通过主键和外键进行关联。
关系数据库的架构如图1所示。
1.3关系数据库的缺陷
通过对关系数据库架构的分析,可以发现关系数据库的一些不足,概括如下四点:
1) 数据类型表达能力差
因为关系数据库所处理的是结构化的数据,所以关系数据库缺乏直接构造与现代软件应用有关的信息的类型表达能力。随着信息技术的飞速发展,图像、视频、音频以及文档等非结构化的数据已被应用到人们的日常生活当中,利用关系数据库来处理这些非结构化的数据已经显得有点力不从心了。因此目前大多数RDBMS产品所采用的简单类型在重构复杂数据的过程中将会出现性能问题;数据库设计过程中的额外复杂性;RDBMS产品和编程语言在数据类型方面的不协调,需要通过较复杂的程序化进行数据类型之间的转换来达到数据类型的一致性。
对于工程应用来说,关系数据库不能支持复杂数据类型的典型结果就是需要额外地分解数据结构工作,这些被分解的结构不能直接表示应用数据,且从基本成分重构时也非常繁琐和费时间。
2) 复杂查询功能比较差
在关系数据库中,利用SQL语言进行查询数据。虽然SQL语言为数据查询提供了很好的定义方法,但是当用于复杂信息的查询时可能会非常繁琐。这是由于在工程应用时规范化的过程通常会产生大量的简单表,从而降低数据的冗余度。那么在这种环境下由存取信息产生的查询必须处理大量的表和复杂主键和外键之间的联系以及连接运算,会影响系统的查询效率。
3) 支持长事务能力差
由于RDBMS记录锁机制的颗粒度限制,对于支持多种记录类型的大段数据的登记和检查来说,简单的记录级的锁机制是不够的,但基于键值关系的较复杂的锁机制来说却很难推广也难以实现。
4) 环境应变能力差
在要求系统改变的环境下,关系数据库从一种系统移植到另一个系统上的成本高且修改困难。再加上,关系数据库和编程语言所提供的数据类型的不一致,使得从一个环境转换到另一个环境时需要多至30%的附加代码。
正是由于关系数据库的这些缺陷,才推动了数据库技术的发展,产生了云端数据库技术,进而弥补了关系数据库的不足。
2 云端数据库
2.1 Bigtable的介绍
Google在 2004 年初就开始研发了BigTable,到了2005年大概有100个左右的服务使用BigTable。BigTable 让Google在提供新服务时的运行成本降低,最大限度地利用了计算能力。
Bigtable是一个大型,容错,自我管理的分布式存储系统,并用于管理分布在成千上万台服务器上的结构化数据[4]。它是建立在GFS分布式文件系统[5]、Scheduler分布式集群调度、Lock Service分布式的锁服务[6]和 MapReduce编程模式[7]基础之上的系统。
2.2 Bigtable的架构
1) Bigtable的数据模型
一个Bigtable(大表)是一个稀疏的,分布的,持续的以及多维的排序的数据映射。这个映射由行主键,列主键和时间戳进行索引[4]。每一项值在映射中是一系列不被解释的字节元组即(row:string,column:string,timestamp:int64)string。
在Bigtable的数据模型中,所有的数据都存放在表格单元中,每一行表示一个事物的数据内容,其所在列表示这个事物的唯一标志,其所对应的时间戳表示这个事物在某个时间上的状态即具体的数据内容。关系数据库只能反映当前时间上事物所处的状态,而Bigtable不仅能显示事物当前所处的状态,而且还可以记录某个事物的过去某个时间所处状态。Bigtable的数据模型如图2所示。
2) Bigtable的架构
与目前的关系数据库类似,BigTable也是客户端和服务器端的联合设计,使得性能能够最大程度地符合应用的需求。
BigTable系统依赖于集群系统的底层结构,一个是 Google的分布式文件系统(GFS),一个是分布式的集群任务调度(scheduler),还有一个分布式的锁服务(Lock Service)。BigTable使用Lock Service来保存根数据表格的指针,即客户端用户可以首先从Lock Service锁服务器中获得根表的位置,进而对数据进行访问。BigTable使用一台服务器作为主服务器,用来保存和操作元数据。主服务器除了管理元数据之外,还负责对tablet服务器(即一般意义上的数据服务器)进行远程管理与负载调配。客户端通过编程接口与主服务器进行元数据通信,与tablet服务器进行数据通信[8]。
Bigtable的架构由Bigtable master、Bigtable tablet servers和Bigtable client library三部分组成,如图3所示。
Bigtable master存储了许多由大量的tablets组成的表。主要负责指派tablet到tablet的各个服务器上,并检测tablet服务器的增减和服务程序装载满与否,进行实时的分配任务,使tablet服务器负载均衡并回收GFS文件系统中的垃圾文件。此外,它还处理模式更改,如表和列簇的创建。
每一个tablet服务器用于管理一部分tablets,通常有10-1000个tablet和处理客户端用户的读/写请求。tablet是由大表以行为单位分隔而成的。每个tablet保存了连续的行,然后别分配到各个tablet服务器上。
Bigtable client library是客户端用户和Bigtable服务器通信的接口。用户通过Bigtable client library接口来读数据和写数据等操作。
3 关系数据库与云端数据库的比较
3.1 两者架构的区别
关系数据库架构与云端数据库中的Bigtable架构主要区别如表1所示。
3.2 基于架构的比较分析
通过对关系数据库架构和云端数据库中的Bigtable架构的分析,可以从以下几个方面对两者进行比较:
1) 数据模型
在关系数据库中创建的表是一张二维表包括行和列,使用简单的数据类型对结构化的数据进行存储。但对于非结构化的数据的存储,因为关系数据库要保持数据冗余度低这一优点,所以关系数据库的设计会比较复杂且困难。而Bigtable创建的类似于二维表,但事实上不是二维表,它是由行主键、列主键、时间戳三个域组成的多维map。虽然Bigtable存储数据的冗余度比较高,但是Bigtable比关系数据库的二维表多了一个域――时间戳域,时间戳域可以记录事物的不同时间时的状态。另外Bigtable是以一条记录为原子对数据进行操作的,所以Bigtable不仅可以对事物的当前状态进行更新,还可以对事物的过去状态进行查询。在这一点上,关系数据库是不支持历史查询的。
2) 数据的存取方式
在关系数据库中用户对数据进行查询、添加、修改及删除等的操作是使用SQL语言。对于处理海量及复杂数据时,使用SQL语言对多个关联表进行操作就可能会显得非常繁琐。Bigtable并非支持SQL语言的数据库,而是以map 函数方式的,以列导向的数据库。Bigtable对数据的存取是以一行记录为原子进行的,不必关联其他的表,那么数据存取的速率要比关系数据库要高。
3) 数据迁移能力
关系数据库提供了一些简单的数据类型,在环境发生变化比如应用平台或者是编程语言所提供的数据类型与关系数据库所提供的不一致时,那么数据之间的转化过程将会相当复杂而且还会增加成本。而Bigtable所提供的数据类型只有字符串类型,所有数据都是以字符串的形式进行处理,因此Bigtable在进行数据迁移时相比关系数据库要容易并且成本也要比关系数据库要低得多。
4) 支持事务
关系数据库为了保持数据的完整性和一致性,提供了事务处理功能。关系数据库在处理简单事务方面,显现出了关系数据库的优势。但是在处理繁琐的事务方面,比如执行了n条SQL语句来对多个关联的数据表进行处理,执行效率就会显得比较低。目前,Bigtable还不支持事务处理功能,但是Google已经考虑到了该功能,一旦Bigtable支持了多行数据的事务支持,执行效率将会大大提高。
总之,云端数据库在处理非结构化数据时要比关系数据库的效率高,更适宜在多节点的服务器集群上工作,比关系数据库更适应环境的变化,最大的优点是使用成本比关系数据库要低得多。
4 结束语
本文通过对关系数据库架构和云端数据库架构的比较分析,可以得出云端数据库在许多方面要比关系数据库占优势,也就是说云端数据库技术具有很大的发展前景。虽然云端数据库技术还不够成熟,再加上各大关系数据库供应商对关系数据库技术的不断改进以及对查询算法进行优化,但是随着云端数据库技术的不断成熟,将会得到广泛的应用,进而逐步会取代关系数据库成为数据库中的主流。
参考文献:
[1] Chang F,Dean J,Ghemawat S,Hsieh WC,Wallach DA,Burrows M,Chandra T,Fikes A,Gruber RE.Bigtable:A distributed storage system for structured data.In:Proc.of the 7th USENIX Symp.on Operating Systems Design and Implementation.Berkeley:USENIX Association,2006:205-218.
[2] 瞿裕忠 胡伟 郑东栋 仲新宇. 关系数据库模式和本体间映射的研究综述[J].计算机研究与发展,2008,45(2):300-309.
[3] Fay Chang,Jeffrey Dean,Sanjay Ghemawat,Wilson C.Hsieh,Deborah A.Wallach Mike Burrows, Tushar Chandra, Andrew Fikes,Robert E.Gruber.Bigtable: A Distributed Storage System for Structured Data,OSDI,2006:1-5.
[4] Ghemawat S,Gobioff H,Leung ST.The Google file system.In:Proc.of the 19th ACM Symp.on Operating Systems Principles.New York:ACM Press,2003.29-43.
[5] Dean J,Ghemawat S.MapReduce:Simplified data processing on large clusters.In:
关键词：关系数据库 会计账务数据库 结构分析
数据库是以某种数据模型所确定的数据结构方式来组织和存储某个组织（或部门）相互关联的数据集。数据库管理系统是一种帮助用户建立、使用、管理和维护数据库的计算机系统软件。
一、数据模型及其建立
数据模型是对现实世界数据特征进行抽象的工具，用来描述和处理现实世界中的数据和信息。数据模型要能较真实地模拟现实世界，既要便于人们理解，又要便于在计算机上实现。数据模型主要由数据结构、数据操作、数据完整性规则三个部分组成。数据结构描述了组成数据库的基本成分；数据操作描述了对数据结构允许执行的操作集合；完整性规则描述了对数据结构所具有的约束和存储规则。
二、关系数据模型结构及数据库中的数据文件之间的对应关系
下面我们通过会计科目代码表来介绍关系数据模型的基本概念及其与数据库中的数据文件之间的对应关系：
（一）关系、二维表、数据文件。关系数据模型中用关系来表述现实世界中能够相互区别的要管理的数据对象集。每一个关系都有一个关系名和一组表述其特征的属性集，人们就是通过这些属性集区别不同的关系。如记账凭证、会计科目、总账都可以称之为关系，它们都是要管理的数据对象集，都有各自的属性集。一个关系用一张二维表表示，表名对应关系名。二维表由有限个不重复的行组成，表中的每一列不可再分。一张二维表在关系数据库中用一个数据文件存储。
（二）记录。二维表中的每一行称为一个记录，描述了关系中一个具体的个体，在数据文件中是一个记录值。如表中第一行为现金账户的记录，描述了现金账户在会计科目代码文件中所有属性的取值（特征）。
（三）属性、列、字段。二维表中的每一列是一个属性，描述了关系的一个特征。一个二维表的所有列构成了一个关系的属性集，通过它可以区别不同的二维表（关系）。二维表中的每一列的数据属于同一类型。每一列的列名对应关系的属性名，同时对应数据文件中的字段名。如表中用6个列表示会计科目代码的属性，其中第三列表示属性“科目性质”，当某条记录取值为1时，表示是资产类科目。
（四）主码、主关键字。指二维表中的某个列（属性）或某几个列（或属性组），它们的值能够唯一确定表中或数据文件中的一个记录。如表中的“科目代码”属性可以作为主码（或主关键字），用来唯一识别表中的每一个会计科目。
（五）域。描述二维表中每一列属性或数据文件的某一字段的取值类型和范围。表中每一列的列名下面的括号中的内容表示该列的取值类型和范围，其中第四列“底层明细标志”表示某个科目是不是最底层明细科目（不再有下层科目），只有两种取值T（真）和F（假）。
（六）关系模式。一个关系模式由一个关系名及它所有的属性构成，它对应一个二维表的表名和表头栏目行（列的集合），构成了一个二维表的框架，同时也是设计该二维表的数据文件结构的依据。
三、关系数据模型的数据操作（二维表）
从数学的角度看，关系数据模型的数据操作是基于集合的操作，操作对象和操作结果都是集合。从数据处理的角度看，数据操作的对象和结果都是二维表。对二维表的操作主要有：
（一）对表中的行（记录）进行操作。指对一张表中指定范围的记录进行有条件的操作，操作的结果组成一张新表。例如，从“会计科目代码表”中筛选出资产类科目组成新的“资产类科目代码表”，操作的范围是整个“会计科目代码表”，条件是“科目性质等于1”。对表中的行进行操作后的结果表的结构与原表相同，记录数小于或等于原表。
（二）对表中的列（属性）进行操作。指对一张表中指定的列进行有条件的操作，操作的结果组成一张新表。例如，从“会计科目代码表”中选出“科目代码”、“科目名称”两列，组成新的科目代码对应表，新表只有“科目代码”和“科目名称”两列。显然，列操作后的结果表的结构与原表不同，结果表小于或等于原表。
（三）连接。对两张表或多张表进行有条件的连接操作，生成一张新表。连接操作后的结果表大于等于操作前的表。
从应用的角度看，对二维表中的数据操作功能主要包括更新（增加、修改、删除）数据和检索（查询）数据，即对二维表填入和修改数据，并从表中检索出数据进行加工应用。
四、关系数据模型的数据完整性规则
数据完整性是指数据库中存储的数据是有意义的或正确的。关系数据模型中的数据完整性规则是指对二维表的定义和操作过程中要遵循的某些约束条件。主要包括：
（一）实体完整性。指每张表都必须有主码，而且表中不允许存在无主码值的记录和主码值相同的记录。每一个记录都必须有科目代码，并且不能有相同科目代码的记录和无科目代码的记录。
（二）参照完整性。指一张表的某列的取值受另一张表的某列的取值范围约束，描述了多张表之间的关联关系。例如，记账凭证表中的“科目代码”列的取值受到会计科目代码表的“科目代码”取值范围的限定。
（三）用户定义完整性。指针对某一具体应用定义的数据库约束条件，反映某一具体应用所涉及的数据必须满足应用语义的要求。即限制属性的取值类型及范围，防止属性的值与应用语义矛盾。
五、关系数据模型得到的启示
（一）数据的二维表及二维表之间的关联设计。基于关系数据模型的会计账务数据库是以二维表为基本部件构建的，数据库中的每一个数据文件对应一张二维表，数据文件之间的关联也可以用二维表之间的关联来表示，对二维表的定义和数据操作必须满足数据完整性约束条件。构建一个会计账务数据库首先要将会计账务管理的对象，如会计科目、记账凭证、日记账、明细账、总账及它们之间的关系抽象成二维表的形式，弄清了它们的二维表结构也就弄清了它们的数据文件结构，即电子账结构。因此，会计账务数据库结构设计可以转变成会计账务数据的二维表及二维表之间的关联设计，而一张二维表的表头栏目（属性集）反映了表的结构特征，是设计数据文件结构的依据。
（二）关系数据库管理系统软件版本。依据关系数据模型研发的关系数据库管理系统是开发和管理会计数据库系统的工具软件，也是支持所开发的会计数据库系统运行的平台，任何一个会计账务数据库都必须在某一个关系数据库管理系统的在线管理下运行。由于不同的数据库软件公司提供的关系数据库管理系统软件的各个版本的功能强弱、所适应的计算机系统的运行环境（单机、网络等）、所提供的对表的操作命令等都有所不同。
参考文献：
[1]王新明、郑春玲.基于关系数据库策略驱动的网络安全评估系统[J].计算机工程与应用，2004，40（2）：15.
关键词：WebService；LDAP；关系型数据库；数据交互
中图分类号：TP311.52
LDAP目录服务主要实现对各业务系统用户账号的统一管理，而各业务系统大都建立在关系型数据库的基础上，因此要实现用户账号的统一管理，必须首要解决LDAP目录服务与关系型数据库之间用户数据的同步问题。本文要研究的即是一种利用webservice接口实现数据同步的技术。
1 LDAP与关系数据库
1.1 LDAP目录结构
LDAP目录服务与UNIX文件系统类似，按照树型结构来组织，称为目录信息树（Directory Information Tree，DIT）。LDAP协议本身和信息模型都是可扩展的，LDAP协议规定了信息的形式及特性、信息存放的索引和对象组织方式、分布式的操作模型。LDAP目录中可以存放文本、图片、URL、二进制数据等不同类型的数据。
LDAP树状信息中的基本数据单元称为对象，对象可以理解为关系数据库中表的记录。对象是具有标识名（Distinguished Name，DN）的属性集合，DN可以理解为关系数据库表中的关键字。属性可以由类型和多个值组成，LDAP中的属性可以理解为关系数据库中的域。域由域名和数据类型组成，在LDAP中为了便于检索类型，一个类型可以同时拥有多个值。
1.2 关系数据库的数据结构
关系数据库最早是E.F.Codd于70年代初提出的，其理论建立在集合代数理论基础上。关系数据库的结构是二维表，由关系和元组组成。目前，主流的关系数据库有ORACLE、SQL、access、SQL Server、sybase等。
1.3 LDAP与关系数据库的比较
与众多关系数据库一样，LDAP目录服务也可以进行查询与数据更新操作，但LDAP目录不具备关系数据库完备的关系运算处理能力，也不具备很强的数值计算能力。LDAP目录服务对数据对象建立索引，优化了对数据对象读取和搜索等操作，与普通关系数据库相比具有较高的检索效率。LDAP目录中的对象一般按照地理位置或组织关系进行组织，应用中非常直观。
1.4 XML简介
可扩展标记语言（Extensible Markup Language，XML）是一种允许用户对自己的标记语言进行定义的源语言，是标准通用标记语言的子集，提供了统一的方法来描述和交换独立于应用程序或供应商的结构化数据。
与Access、Oracle和SQL Server等数据库不同，XML数据库提供了更强有力的数据存储和分析能力，且表现形式极其简单，这就使得它易于在任何应用程序中读写数据，成为数据交换唯一的公共语言。本文研究的数据同步技术就是以XML作为介质实现的。
2 数据同步技术
如何实现LDAP与关系数据库之间的数据同步？以典型的关系数据库ORACLE数据库为例，关系数据库之间的数据同步操作可通过数据库本身的触发器实现，数据源一旦触发数据更新操作，触发器会将更新的记录数据自动同步到目的数据库中。但是，LDAP目录服务是面向查询的，为了追求较高的查询效率，LDAP采用基于索引文件的平面存储方式， 并且LDAP协议不支持触发器机制，LDAP协议对数据更新不是原子操作。因此，要实现LDAP与关系数据库的数据同步，需解决以下两个问题：一是，实现LDAP目录与关系数据库之间的数据格式转换；二是实现LDAP目录服务向关系数据库的更新触发机制。
2.1 数据格式转换的实现方法
LDAP目录的数据文件为.ldif格式的文本文件。关系数据库无法直接与此类文件进行交互。为解决以上问题，可采用XML作为中间文件。当LDAP目录对象的数据发生变化后，将增量数据转化为XML格式文件，之后再将XML文件导入关系数据库实现LDAP目录服务到关系数据库的数据更新。
2.2 LDAP更新触发的实现方法
3 结束语
通过Tomcat监听和webservice接口调用，可以实现将LDAP目录中更新的对象传输到关系数据库ORACLE表记录中，此方法是使用解决了异构数据源的数据交互问题，实现了LDAP到各业务系统用户账号的统一管理。
参考文献：
[1]宗士强，林剑柠，朱双华.LDAP目录服务同步[J].计算机与现代化，2010（10）.
[2]逯文晖，郑晓薇，顾慧.目录于关系数据库的分层映射数据集成模型[J].计算机工程与设计，2010（21）.
[3]武静.身份管理技术现状与对策[J].电信网技术，2009（03）.
[4]封明玉，赵政，张钢.分布式环境下数据冲突及其解决方案[J].计算机应用研究，2002（02）.
中图分类号： G250.74 文献标识码： A 文章编号：
第一章绪论
当今社会，传统的GIS将属性数据与空间数据分离的数据组织形式已经不能满足现有的GIS数据管理的需要，将属性数据和空间数据统一起来存放在关系数据库并进行有效的管理的技术，已经显得越来越重要了。
地理信息系统（GIS）不仅具备一般计算机系统所具有的功能，如采集、管理、分析和表达数据等功能。 还拥有分析和表达地理空间数据的能力。由此，可以简单地定义地理信息系统是一种用来采集、模拟、处理、检索、分析和表达地理空间数据的计算机信息系统。是有关空间数据管理和空间信息分析的计算机系统。
当前，分离的数据组织形式以不能满足现今的GIS数据管理的需要，所以空间和属性数据要求进行一体化的管理，本文将对此作出分析研究。
第二章地理信息系统数据库
2.1GIS数据库中的地理数据
2.1.1 空间数据
空间数据（Spatial Data）：描述地理数据中空间特征部分的数据。
点
线
面
复杂空间数据类型
复杂空间数据类型是由点、线或面等空间数据类型组合而成，但不能简单地归为点、线、面类型的一种特殊数据类型，一般结构比较复杂。
图2-1 河流A
如图:河流A就不能用线类型数据简单地归类，而应该属于复杂空间数据类型。
2.1.2 属性数据
属性数据（Attribute Data）：又指非空间数据。描述地理数据中属性特征部分的数据。
2.2GIS数据库系统模型
在过去的10年中，GIS数据管理方法的发展主要有以下4种类型
1 对不同的应用模型开发独立的数据管理服务，是一种基于文件管理的处理方法。
2 在商业化的DBMS基础上开发附加系统。开发一个附加软件用于存储和管理空间数据和空间分析，使用DBMS管理属性数据。
3 使用现有的DBMS，通常是以DBMS为核心，对系统的功能进行必要扩充，空间数据和属性数据在同一个DBMS管理之下。需要增加足够数量的软件和功能来提供空间功能和图形显示功能。
4 重新设计一个具有空间数据和属性数据管理和分析功能的数据库系统。如图：
图2-2GIS数据库系统模型
通过数据库系统几种模型的比较我们可以看出，用标准的DBMS来存储空间数据，不如用扩展的RDBMS存储表格数据那样好。主要是因为，GIS需要一些复杂的图形功能，一般的RDBMS不能支持；再就是DBMS难以实现对空间数据的关联、连通、包含和叠加等基本操作。所以说，关系型数据库是当前管理空间地理数据最行之有效的管理模式（我们使用C应用模型）。
第三章 Oracle数据库中的数据管理
3.1基于ArcSDE的空间数据的一体化管理
数据进入数据库的的方式是通过管理系统(Oracle)管理工具以及第三方软件（ArcSDE for Oracle）转换和加载的。
ArcSDE存储和组织空间数据的方式是通过将空间数据类型加入到关系数据库（Oracle）来组织、存储和管理地理数据的。ArcSDE并不改变和影响现有的数据库或应用，它仅仅只是在现有的（属性）数据表中加入图形数据项（Shape Column），以方便软件管理、访问与其关联的空间数据。空间图形数据和空间图形索引放在另外的数据表中，通过关键项空间可用表、空间图形表、图形索引表实现关联。通过将层从逻辑上分成一个个小块来对数据库中各层的所有要素建立索引，层中的要素则分解到各单元中描述，最后将此描述信息写到索引表中。落到多个单元上的要素，将在每个单元对应的索引记录中加以描述，没有数据的单元不包括在索引表中。
简单说来， ArcSDE就是将底层的空间几何数据和空间属性数据关联起来，使空间数据在客户端表现为是一个连续地、无缝地地理实体，达到一体化的效果。
ArcSDE for Oracle是一个基于Oracle数据库基础上的地理数据库服务器，是对Oracle关系型数据库的一个扩展。采用ArcSDE管理地理信息数据，大大提高了空间数据的安全性、易用性和可维护性。
一体化空间数据管理的优势
借助数据库系统的逻辑检查功能，保证数据的录入和编辑质量。
支持大型数据库。arcSDE利用统一的数据模型，维护关系数据库中的空间和属性数据，管理近乎无限的空间特征，如:全国范围的土地利用现状和历史数据。
提供了网络环境下的数据操作。对复杂的空间查询来说，使用互操作处理的客户机/服务器模式在网络上得以实现，客户机与服务器共同完成这一工作。客户机主要是响应空间分析操作，服务器则进行数据搜索和检索。这种互操作处理方法使得动态空间叠加成为可能，当大量增加客户机的时候，利用对称多处理结构或调整计算机缓冲区大小，可以把客户机带来的性能下降到最小。
客户端工具的广泛性。用空间数据库所提供的API接口，客户端可采用任何GIS工具调用API服务，开发应用程序。
特征组是连续的，借助于底层的关系数据库强大的数据管理功能，实体—关系数据模型能容纳连片的数据区域，实现连续地理实体的物理级无缝存储。
支持多用户并发操作。许多用户能同时编辑地理数据。地理数据库数据模型支持多用户并发操作。
第四章 结论
4.1主要内容
运用ArcSDE8.2 for Oracle 将客户端程序和数据库关联起来,使Oracle数据库能够对空间数据进行一体化管理,完成客户端空间数据和属性数据的相关数据查询、空间分析等。
4.2 优点
使用ArcSDE数据模型将空间几何数据和空间属性数据关联起来，从而使空间数据在逻辑上形成一体化，简化了从数据底层到WEBGIS的过程,使结构更加紧凑。
4.3 存在的问题
SDE数据模型没有显式地存储空间拓扑关系，从而使空间分析过分依赖于客户程序(ArcMap)，对客户程序造成一定负担。
参考文献：
[1] Goodchild M. Future directions for geographic information science. Geographic Information Science, 1995 (1):1~7
[2] TAMAS ABRAHAM and JOHN F RODDICK. Survey of spatio-temporal databases. GeoInformatica, 1999,3(1):61~99
[3] ESRI.Spatial Database Engine. .1999.
[4] J.E.McCORMACK and J.HOGG.. Virtual-memory tiling for spatial data handling in GIS. COMPUTER & GEOSCIENCE, 1997, Vol.23(4): 659~669
[5] 边馥苓. 地理信息系统原理和方法. 北京:测绘出版社，1996，5
[6] 龚健雅. 当代GIS的若干理论与技术. 武汉:武汉测绘科技大学出版社，1999，44-46
购物车(0)
