时间：2022-10-04 17:03:28
绪论：在寻找写作灵感吗？爱发表网为您精选了8篇关系数据库，愿这些内容能够启迪您的思维，激发您的创作热情，欢迎您的阅读与分享！
（白城师范学院计算机科学学院，吉林白城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.
【关键词】关系数据库；数据仓库；数据挖掘；关系
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 关系数据库、数据仓库与数据挖掘的融合
日常事务处理需要关系数据库，构建分析处理环境需要数据仓库，帮助决策者寻找数据之间的潜在的关联需要数据挖掘。他们之间是相互联系又有区别的，不能互相取代的，又需要相互融合。数据仓库中的数据并不是最新的，专有的，而是来源于其他关系数据库，它是建立在一个更全面和完善的信息应用的基础上，用于支持高层决策分析的数据基地。数据仓库是数据库新技术，到目前为止，数据仓库仍用关系数据库管理系统管理数据。数据挖掘是从大量存储在数据库、数据仓库或其他信息库中发现有趣知识的过程。只有这三个数据库技术互相融合，取长补短，各尽其责，才能更好的为广大用户所使用，为社会各个领域所应用。
【参考文献】
[1]华冠萍.数据仓库、数据挖掘及OLAP之两两关系[J].福建电脑，2007，8.
摘要：XML可以用于实现异构数据库，同时也是一种中间件和数据承
>> XML文档与关系数据库数据转换的研究 基于DOM的XML文档到关系数据库的数据转换方法 基于关系数据库的XML存储技术 浅谈数据库记录与XML数据的转换 论XML文档数据库数据之间的转换原理及转换对象 基于．NET平台的关系数据库转换 WebService在LDAP与关系数据库之间数据同步的研究 基于XSD模式的XML文档与关系数据库的转换 一种模仿XML的灵活的关系数据库设计 基于关系数据库的时态XML存取研究 运用XML实现异构数据库的数据转换 浅析Notes数据库与关系数据库的关系 关系数据库的设计与测试 基于架构的关系数据库与云端数据库比较分析 XML文档与数据库表信息互相转换的方法研究与实践 关系数据库与非关系数据库 浅析关系数据库、数据仓库与数据挖掘的关系 浅谈关系数据库的数据保护策略 关系数据库查询优化策略与研究 关系数据库二进制存储图像数据的研究与应用 常见问题解答 当前所在位置：，1994.
[2]陈志炜.一种基于语义的将关系数据转换为XML数据的方法[D].南京：东南大学硕士学位论文，2004.
[3]萨师煊，王珊.数据库系统概论[M].第三版.北京：高等教育出版社，2005.
收稿日期：2016-11-25
目前世界上许多跨国信息技术行业的公司都在开发基于SaaS的产品和服务，为未来互联网的发展提供技术平台，而电子商务是近年来互联网应用最受瞩目的领域。因此SaaS模式的普及必将对电子商务的发展产生深刻的影响。
正如10Gen工程副总裁Geir Magnusson所指出那样，在未来我们将很难找到关系数据库的影子，这是因为关系数据库不适用于分布式环境。SaaS的普及要求我们必须重新审视我们做事的方式。
时下的许多新型数据库，包括Google的Bigtable，Amazon的SimpleDB，10Gen的Mongo，AppJet的AppJet数据库以及甲骨文开源BerkelyDB。这些数据库没有一个是关系型的。而这些数据库具有一些共同特征，就是都特别适用于服务云计算式的应用。它们中的大多数可以在分布式环境中运行，这意味着他们可以分布在多个地点的多台服务器上。它们本质上都不是事务性的，并且都牺牲了一些高级查询能力以换取更好的性能。在很多情况下，这些数据库可以通过对象调用来检索，而不用SQL。
尽管大型关系数据库已经被应用在很多数据处理中心，但SaaS需要一种不同的设置来充分发挥其潜力。试想，在跨越地理空间距离之间执行复杂查询以便减少响应时间、设计和维护支持不同位置的相关数据备份、在一个点瘫痪时能保证该数据同步、维护和运行这样的体系并非易事。因此，数据库组成部分在不同位置的分散对SaaS很必要，这也是SaaS产生的原因。更重要的是SaaS体系结构具有不同于目前使用的关系型结构的属性，在SaaS体系结构里，关系不复存在，人们以群集形式看待数据。
关键词:关系数据库;云端数据库;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:
关键字：优化查询；SQL查询；关系数据库
数据库查询操作是数据库操作的核心操作，对数据的查询效率及处理速度已成为衡量数据库性能的一个重要指标。数据库查询技术也是学生对《数据库原理与应用》这门课程所必须掌握的知识和技能，数据库查询技术的精通也为以后课程的学习（如：C#.NET程序设计）中的数据库应用程序的设计打下良好的基础。
为了优化数据库的性能，简单、有效的方法就是优化查询。
1优化原理和实质
数据查询处理的代价通常取决于对磁盘的访问，因为磁盘比内存的访问速度要慢。对于一个给定的查询，有许多可能的处理策略，复杂查询更是如此[1]。查询优化的实质是在结果正确的前提下，找出与已有表达式等价，但查询效率更高的表达式。
2在教学中要注重的几种典型的优化方法
2.1建立视图
视图可简化用户操作数据的方式，使用户能着重于所感兴趣的特定数据和所负责的特定任务。如果该视图数据规模小于定义的基本表，则基于视图的查询比原查询的速度会快得多。
例：要查询每门课程成绩最高的学生的学号
SELECT 学号，课程号，成绩
FROM 成绩表 A
WHERE 成绩=（SELECT MAX（成绩）
FROM 成绩表B
WHERE A..课程号=B.课程号）
语句缺点：这属嵌套查询，子查询的结果集将作为外层查询的条件，查询效率不高。
解决方案：可先建立视图，求得每门课程的最高分，再与成绩表中比较，获取与视图中最高分数据相等的记录，这就减少了内层连接的数据量，从而提高了检索速度。
用SQL语句优化的步骤为：
首先，创建视图
GREATE VIEW V_max_cnoscore AS
SELECT 课程号，Max(成绩) AS 最高分数
FROM 成绩表 GROUP BY 课程号
其次，利用视图检索数据
SELECT 学号，A.课程号，A.成绩
FROM 成绩表A，V_max_cnoscore B
WHERE A.成绩=B.最高分数 AND A.课程号=B.课程号
2.2查询条件Where子句的优化
2.2.1合理设置WHERE条件的先后顺序。多数数据库都是按从左到右的顺序处理条件，把能过滤更多数据的条件放在前面，过滤少的放后面，便可提高检索速度。
例：SELECT * FROM student
WHERE ssex=’女’ --条件1过滤的数据较少
AND sdept=’计算机系’ --条件2过滤数据比条件1多
上面的SQL就不符合上述原则，可改为：
SELECT * FROM student
WHERE sdept=’计算机系’
AND ssex=’女’
对同一表格进行多个选择运算，选择条件的排序对性能有较大影响，不仅影响索引的选取，而且关系到临时表的大小[2]。因此，要提高查询速度，可将较严格的条件写在前面，较弱的放在后面。
2.2.2避免使用“< >”或“NOT”操作符。“< >”或“NOT”均属于排斥性操作符，不是包括性操作符，这会使系统在搜索数据时无法使用索引，只能直接搜索表中的数据，例：
（1）SELECT 学号 FROM 成绩表 WHERE 成绩< >80
（2)SELECT 学号 FROM 成绩表 WHERE NOT(成绩80)
（3)SELECT 学号 FROM 成绩表 WHERE成绩< 80 OR 成绩>80
比较以上三条语句，可知第3条可使用索引查询，它的查询速度最快。
2.2.3恰当运用“OR扩展”技术。该技术是把在Where子句中带有OR的查询转换成包含多个UNION ALL的查询。
例：查询计算机系县年龄不大于20岁的学生。
常规的SQL语句：
SELECT 学号，姓名 FROM 学生表 WHERE 系名=’计算机系’ OR 年龄
假定表中“系名”和“年龄”两个字段上创建了索引，以上的查询可能不会使查询优化器使用索引，从而查询效率降低，可改进为：
SELECT 学号，姓名 FROM 学生表 WHERE 系名='计算机系'
UNION ALL SELECT 学号，姓名 FROM 学生表 WHERE 年龄
2.2.4合理减少LIKE条件的使用。在SQL查询中，LIKE条件使用的神奇之处在于其与通配符匹配所提供的模糊查询功能。但在字符串的比较中，有时大量字符的逐个比较，也会大大降低查找效率。
例：图书按26个英文字母分为26类，查找所有属于‘A’类图书的销售金额。
SELECT 图书类号, SUM (数量*单价) FROM 销售
WHERE 图书类号LIKE′A%′GROUP BY图书类号
优化为精确查询：
SELECT 图书类号，SUM(数量*单价) FROM销售
WHERE 图书类号>=′A′AND图书类号
GROUP BY图书类号
2.3正确使用子查询“展平”技术子查询“展平”技术就是指将子查询转变为半连接，连接或者反连接，从而将查询优化。
例：找出成绩大于等于90分的学生的姓名。
SELECT 姓名 FROM 学生表 WHERE 学号IN
(SELECT 学号FROM 成绩表WHERE 成绩>=90)
语句缺点：需要搜索学生表的每一行，来查找所有满足子查询条件的记录。
解决方案：将学生表作为连接的内表，查询将作为通常的连接来执行。
优化后的SQL语句：
SELECT 姓名FROM (SELECT 学号 FROM 成绩表
WHERE成绩>=90) A，学生表 B WHERE A.学号=B.学号
2.4善于使用存储过程
存储过程是SQL语句和可选控制流语句的预编译集合，一个名称存储并作为一个单元处理。善于使用存储过程，将使SQL变得更加灵活和高效。
例：查询某个学生某门课程的考试成绩，列出学生的姓名、课程名及成绩
CREATE PROC pro_student_degree
@stu_name char(12)，@course_name char(18) AS
SELECT sname，cname，degree
FROM student A INNER JOIN sc B ON A.sno=B.省略o=o
WHERE sname=@stu_name AND cname=@course_name
以上是一个带有两个输入参数的简单存储过程，只需执行一个简单的SQL语句――“EXEC pro_student_degree‘刘娜’,’数据库原理’”就可完成查询。
编写性能优化的SQL语句是提高数据库系统的重要因素，随着数据库管理系统中数据量的增大，如何提高查询速度与效率也是计算机软件开发的一个时代要求。实现优化查询的方法很多，在使用中，要根据具体情况权衡利弊，使数据库查询性能最优。在学生的教学中要注重培养学生的动手能力，使学生养成编写优化的SQL语句的习惯。
参考文献：
[1]王振辉,吴广茂.SQL查询语句优化研究[J].计算机应用，2005，（12）:208.
[2]SQL查询优化注意where条件的顺序.. 2009-06-18.
关键词：对象关系数据库；面向对象；AMOS II
中图分类号：TP311文献标识码：A文章编号：1009-3044(2008)34-2016-02
A New Generation of Object-Relational Database: AMOSII
LIU Yan-hong1,2
(1.Nanjing Institute of Industry Technology Information Engineering, Nanjing 210046, China; 2.Nanjing University of Aeronautics and AstronauticsCollege of Information Science and Technology，Nanjing210016，China)
Abstract: Object-relational database can be combined with a single relational database system and a single object-oriented database system. It overcomes their limitations and is a new direction for research and discussion. AMOS II is the latest generation of object-relational database and has powerful object-oriented features. It provides the features and functions that a large number of next-generation database should have. The case of AMOS II fully reflects the advanced nature of the relational database.
Key words: object-relational database; object oriented; AMOS II
1 引言
随着数据库技术的发展,原有的数据库系统很难适应新的应用领域中的复杂对象和这些对象的复杂行为的需求。新的应用需求推动了数据库技术的研究, 其中最重要的研究方向之一就是使用一种与人们认识客观事物的过程一致的方法, 这就是面向对象的方法。这种方法大大提高软件开发的效率。对象关系数据库是面向对象技术与数据库技术相结合的产物。
2 对象－关系数据库
对象关系数据库兼有关系数据库和面向对象的数据库两方面的特征。即它除了具有原来关系数据库的种种特点外，还应该提供以下特点：
1) 允许用户扩充基本数据类型。即允许用户根据应用需求自己定义数据类型、函数和操作符，而且一经定义，这些新的数据类型、函数和操作符将存放在数据库管理系统核心中，可供所有用户公用。
2) 能够在SQL中支持复杂对象。由多种基本类型或用户定义的类型构成的对象。能够支持子类对超类的各种特性的继承，支持数据继承和函数继承，支持多重继承，支持函数重载。能够提供功能强大的通用规则系统，而且规则系统与其他的对象－关系能力是集成为一体的。
3 新一代对象关系数据库的优势
3.1 传统的关系数据库的缺陷
传统的关系数据库局限性为：
1) 面向机器的语法数据结构，数据模型单一，数据类型简单、固定。
2) 不能依据某一类型的数据类型来扩展数据类型。
3) 结构与行为完全分离。
4) 存储管理的对象有限，事物处理能力较差。
3.2 新一代对象关系数据库的特征和功能
1) 数据库应支持复杂的数据类型，并能存储和处理复杂对象。还要具备支持用户自定类型和可扩展能力。
2) 数据库必须对其它系统开放。
3) 系统必须具有可移植性，可连接性，可扩展性和可互操作性。实现程序设计语言和数据库语言的无缝的集成。
4 AMOS II应用案例分析
AMOS II是最新一代的对象关系数据库，它充分体现了对象关系数据库的强大功能。
4.1 学生课程成绩查询案例
有若干学生，学生信息包括学号，姓名，班级。有若干选修课程，课程信息包括课程号，课程名，成绩。实现功能：1、通过查询语句，可以查看所有的学生信息和课程信息。2、输入学生信息如姓名，可以查看到他所选课程的相关内容。3、输入课程名称可以查看到选这门课的学生姓名。4、输入学生姓名，可以统计出该生选的所有课程名称和课程数。
4.2 案例设计与分析
1) AMOS II具有面向对象数据库的特点。
在OODB中, 用类来描述对象的结构特征和行为特征。它有下面的定义形式：
class < 类名> [ (参数表) ]properties
{类的特征}
在本案例中课程和学生类设计如下：
create type kecheng properties(
sid charstring,//课程号//
sname charstring,//课程名//
scoreinteger //期末成绩//
);
create type student properties(
tidcharstring,//学生号//
tname charstring,//学生姓名//
banjicharstring //班级//
);
创建kecheng的对象并且赋值用以下命令：
create kecheng(sid, sname,score) instances
:s1("01","Chinese",91),:s2("02","English",90),
…;
创建student的对象并且赋值用以下命令：
create student (tid, tname, banji) instances
:t1("08001","zhangsan","3ban"),
:t2("08002","lisi", "4ban"),
…;
函数设计举例如下：
create function o_derect(student nonkey)-> as stored;
//输入参数student类，返回该学生所选课程的元组//
create function sname(kecheng nonkey)->charstring as stored;
create function tname(student nonkey)->charstring as stored;
create function tid(student nonkey)->charstring as stored;
…;
以上定义的源代码保存在文件lyh.amosql中。AMOSQL类似于SQL语言。例如用下面命令对学生信息进行查询：
select tin (x), tname(x), from student (x);
在AMOS II中运行并得出结果，如图1。
这些类、对象、属性和函数的设计，充分体现了面向对象技术的特点。
2) AMOS II具有强大的可扩充功能。
AMOS II提供的Java函数的接口。在AMOS II中可以调用用户自定义的Java函数。
本案例用Java语言定义函数tongji()并保存在名为lyh.java的文件中。该函数的功能是接受输入参数为学生名，输出该学生所选择的课程名并统计出课程个数。
为了能在AMOS II调用该函数，需要在javademo.osql文件中添加下面的语句：
create function tongji(charstring)->charstring as foreign "JAVA:lyh/tongji";
运行后如图2所示。
这充分体现了AMOS II允许用户根据应用需求自己定义数据类型、函数，具有强大的可扩展功能。
5 总结和展望
综上，对象―关系数据库是面向对象技术与数据库技术相结合的产物。AMOS II是最新的一代对象关系数据库，具有强大的面向对象的功能。从学生课程成绩查询案例，可以看到AMOS II具有面向对象数据库的特点，允许用户根据应用需求自己定义数据类型、函数和操作符，具有强大的可扩展功能，体现了对象关系数据库的先进性。本文用具体案例介绍了在AMOS II中如何定义类，对象和函数，和如何调用Java自定义函数，实现统计函数的功能。
对象―关系数据库技术还处于研究发展阶段,在很多方面它还面临很多的挑战，例如对象―关系数据库还可以从面向对象数据库那里吸收养分和研究成果，如路径索引、对象聚集等。相信对象―关系数据库有着美好的发展前景。
参考文献：
[1] 赵志升,许素文,杨小姝.对象――关系数据库管理系统及其特性与实现[J].电脑开发与应用,2002,15(8):47-48.
[2] 王治.对象―关系数据库技术及其发展[J].九江师专学报:自然科学版,2003,22(5):86-88.
>> 基于关系数据库的本体构建方法研究 面向关系数据库的装备领域本体构建研究 基于对象关系数据库的移动对象数据库管理系统的研究 基于UML模型的关系数据库设计 基于关系数据库的XML存储技术 基于．NET平台的关系数据库转换 基于架构的关系数据库与云端数据库比较分析 基于关系数据库的关键词查询研究 基于关系数据库的时态XML存取研究 基于关系数据库的动态工资管理系统研究 基于关系数据库的文件树存储策略研究 基于关系数据库的可适性系统研究 基于DOM的XML文档到关系数据库的数据转换方法 基于关系数据库的实时XML数据查询处理 浅谈关系数据库的数据保护策略 一种基于依赖关系的关系数据库语义模式提取方法 关系数据库查询优化策略研究 关系数据库查询优化策略与研究 XML文档与关系数据库数据转换的研究 WebService在LDAP与关系数据库之间数据同步的研究 常见问题解答 当前所在位置：），但该工具只能创建轻量级本体，映射简单，不能完全地对关系数据库中存在的概念进行建模。
2）德克萨斯大学的Sunitha Ramanujam提出了“Bi-directional Translation of Relational Data into Virtual RDF Stores”[5]，即关系数据和RDF间的双向转换，并在D2R的基础上开发了工具D2RQ++。
3）中科院国家科学图书馆成都分馆的Shihan Yang等人提出“半自动化地从关系数据库中构建本体”，文中提出了利用中间件来实现关系数据库到本体转化的方法，并且提出了W-graph的中间件语言，W-graph映射语义使用与关系数据库和本体都无关的双向模拟等价图表示。中间件模式是动态的，当数据库模式或本体频繁变化时，该方法因此有很好的适应性。此方法不仅可以处理数据库模式而且也可以处理数据库中存储的实例。图形语义编辑工具的开发，提高了方法的可用性。
4）许卓明提出 “一种从关系数据库学习OWL本体的方法”，开发出了关系数据库模式到OWL本体转换原型工具DB2WO，并给出了实例验证。该研究首先给出了关系数据库模式和OWL本体的定义，其次定义了关系数据库模式到OWL本体的一组映射规则，然后开发了转换工具DB2WO。关系数据库模式信息通过读取关系数据库字典来提取。
5）陈和平等人提出“基于关系数据库的本体生成器的设计与实现”[6] 。该研究中首先指出需要解决的2个关键问题：（1）如何提取关系数据库的ER模式（2）如何定义由ER模式到OWL本体的映射规则。然后给出ER模式的提取一般可以通过查询该关系数据库的数据字典或应用数据库的逆向工程工具，接着给出了ER模式到OWL本体的10多条转化规则。最后，给出了本体生成器OWLFROMDB的功能模块结构图，并给出了实例验证。
6）中国人民理工大学的Peng Liu等人在2010第九届国际网格和云计算会议提出“基于关系数据库的本体自动构建”[7]。其思想跟前述许卓明、陈和平等一致：通过分析关系数据库模式，建立一系列的从关系数据模式到OWL的转换规则，然后给出了算法和流程图，最后给出了生成的本体的层次图。
7）W3C成立了 RDB2RDF研究组，致力于提供一个从关系数据库RDB到本体描述语言RDF的规范性的映射标准，到目前为止，该研究小组提出了几个关于RDB到RDF映射语言的内部草稿，还未成为标准。
3 研究瓶颈及建议
现在，基于关系数据库生成本体的研究已经引起越来越多研究者的兴趣。基本思路无非是从关系数据库中提取出数据模式，然后设定数据模式转化为本体的规则，然后编程实现。每个研究人员都提出了自己的转化规则，而并没有人对规则的可行性给出评价结果。至今，尚未有研究者或机构给出权威的转换规则。转换规则的可行性和合理性应该是未来研究的重点。
4 结束语
利用关系数据库中结构化的数据作为数据源来构建本体的方法，已经引起了众多研究人员的重视，而随着W3C的介入， 必将使这种转换规范化。
参考文献：
[1] /RDF[EB/OL].
[2] /TR/owl-features[EB/OL].
[3] Du Xiaoyong, Li Man, Wang Shan. A Survey on Ontology Learning Research[J] .Journal of Software, 2006,17(9): 1837-1847.
[4] Sunitha Ramanujam ,VaibhavKhadilkar.Bi-directional Translation of Relational Data into Virtual RDF Stores[C].2010 IEEE Fourth International Conference on Semantic Computing,2010,61:268-276.
[5] Shihan Yang,Ying Zheng.Semi-Automatically Building Ontologies from Relational Databases[J].IEEE,2010:150-154.
购物车(0)
