关系型数据库范文

关系型数据库篇1

[关键词]UML 面向对象 关系型数据库

中图分类号：TaxB 文献标识码：A 文章编号：1009-914X（2014）17-0243-01

1、引言

在传统的数据库设计中，E-R图一直作为一门十分重要的工具来对数据进行建模，但是随着数据库规模的扩大，简单的E-R模型结构无法清晰地分析和描述问题，导致系统开发难度系数增大。为了更好的解决这一问题，近年来UML建模技术被广泛的应用于数据库设计领域。UML是最为广泛使用的面向对象系统的标准建模方法，采用UML的分析方法设计数据库，能够使数据库模型清晰易懂，能够更加清晰地反映系统结构，易于开发，缩短了系统开发周期。另一方面，现在的开发环境大多是面向对象的，而存储机制往往是基于功能分解的关系型数据库，支持的数据库模型中，关系型数据库是最普遍的。事实上，目前较为流行的对象关系数据库模型也是关系数据库模型的一个扩展，因此，在关系数据库设计中，UML可以完成标准ER模型的所有建模工作，而且可以描述ER模型所不能表示的关系。用UML进行数据库设计使商务和应用团队可以共享公共的语言，并与数据库团队进行有效沟通。

本文先简单介绍一些基本的概念，接着讨论将UML类图中的数及其对象映射成关系型数据库中的表的方法。最后结合一个实例来说明从UML模型关系数据库之间的转化。

2、属性、类以及类之间的关系

2.1 属性。对象属性对应于数据库表的字段，对象属性类型对应数据库表的域。

2.2 类。将问题域中的实体抽象为对象模型，在对象模型的基础上进一步抽象为类并将类映射为数据库的概念模型，是关系数据库设计的关键所在。将类名、属性以及对属性进行的相关操作组成一个完整的类模型。

3.2 属性类型映射为域。类的属性描述了其所有对象共有的特性。属性的类型可以是基本数据类型，如整数、实数、布尔型等，也要以是用户自定义类型。属性类型对应于数据库中的域，域的使用可使数据库设计更具一致性，优化了数据库应用的移植性。一般来说，实现简单域比较方便，只须定义相应的数据类型和空间大小。对于每个属性所联关系等原因，需要在表中增加一些新的列。

3.3 类映射为表。通常，一个类映射为一张类表，类的属性映射为表的各列，类的对象则映射为表中的各个记录。但是我们还要注意以下两种特殊情况：

（1）如果类的属性中某些属性只是暂时性使用，不需要在数据库中永久保存，则该类属性无须映射。

（2）如果类的属性如果是多值，则该属性映射为多个列。另外，由于附加对象标志符OID或附加关联系系等原因，会预收款致一些新的列增加。5、结束语

关系型数据库篇2

关键词：面向对象；关系数据库；对象关系数据库；映射

一、前言

随着数据库技术的发展，数据库应用领域已经从传统的商务数据处理扩展到许多新的应用领域，例如处理空间数据、时间数据、工程设计数据、超文本和多媒体数据等，原有的数据库系统很难适应这些新的应用领域中的复杂对象和这些对象的复杂行为的需求。新的应用需求推动了数据库技术的研究，其中最重要的研究方向之一就是使用一种与人们认识客观事物的过程一致的方法，这就是面向对象的方法，它是面向对象技术与数据库技术相结合的产物。在适应计算机应用的现实特性和发展趋势上，面向对象的方法表现出了多方面特有的优越性，它的兴起从整体上反映和概括了计算机发展的历史。

面向对象技术能够大大提高软件开发的效率及其可靠性、可维护性、可重用性，越来越多的软件开发机构和科研人员开始使用面向对象技术进行系统分析、设计、编制程序。然而在数据库领域，面向对象数据库产品却未真正成熟，关系数据库产品依然是开发MIS的必然选择。占主导地位的关系数据库成为了面向对象系统架构中对象与关系数据库转换的“瓶颈”。将oo（object oriented）技术的优越性与成熟的关系数据库技术有机地结合起来，是一个很有应用价值的研究课题。本文提出一个对象关系数据库系统模型：在业务逻辑层和关系数据库的物理存储结构中间增加一个OR层，层为用户应用程序提供统一接口，并结合RDBMS透明地完成对象和关系数据库之间的转换，解决对象数据的存储查询等操作。

二、面向对象数据库发展

（一）面向对象数据特点

Peter Coad和Edward Yourdon这样描述面向对象：面向对象=对象+分类+继承+消息。其中对象指一组属性及这组属性上专用操作的封装体。类是一组具有相同属性和操作的对象描述。继承是类之间一种基本关系，指某个类的层次关联中不同类共享属性和操作的机制。消息是对象间通信的手段，一个对象通过向另一个对象发送消息来请求其服务。此外，面向对象数据特点还有封装、信息隐蔽、消息传递、多态性等。综上所述，面向对象数据与现实世界实体对象一一对应，具有传统数据库数据不具有的两大特性，即内容海量性和结构复杂性，它们是构建新型数据库的基础。

（二）传统数据库局限性

1、不能表示客观世界复杂对象。采用二维表表示数据及其关系，语义表示能力差，无法表示客观世界复杂对象，不能揭示数据之间深层含义和内在联系，缺乏数据抽象。

2、缺少对复杂数据类型支持。只能理解、存储和处理简单数据类型，不能根据客户需要动态扩大数据集。碰到复杂问题常利用高级程序设计语言构造相应数据类型和操作，既加重用户负担，又不能保证数据一致性。

3、数据结构不能与行为相关联。对象有两方面内容，即结构和行为。传统DB把前者映射到数据库模式中，对后者没有很好实现。

4、阻抗失配和语义断层，不能与高级程序设计语言无缝集成。传统DB开发需同时使用数据库语言（SQL）和高级程序设计语言，涉及模式和结构转换问题，既容易丢失原数据结构语义，又妨碍其他工具和用户在原有语义层次上共享数据。

5、缺乏管理知识和对象的能力。传统DB处理对象是确定的、现存的，不能很好地处理和管理实际应用中的二义性、未知对象。此外，它们没有演绎和推理功能，不能很好地管理知识，无法满足MIS，DSS，OA和AI等领域进行高层管理和决策的要求。

6、不能满足巨型数据库应用需要。随着多媒体技术、空间信息科学和数据挖掘技术等学科的蓬勃兴起，处理的海量数据已非一般二维表可存储和管理，而且数据结构越来越复杂，有的还有语义动作，使传统数据库显得力不从心。

另外，传统数据库还不能主动检查和处理事件，缺乏对长事务和多重嵌套事务的响应和处理能力。

综上所述，传统数据库已不能满足复杂的实际应用需要，随着面向对象研究的深入，把面向对象设计方法和数据库技术结合形成新一代数据库系统――面向对象数据库系统，不仅是数据库学科发展需要，也是推进计算机其他分支健康发展的必然结果。

（三）面向对象数据库概念

面向对象数据库系统（OODBS）支持定义和操作OODB，应满足两个标准：首先它是数据库系统，其次它也是面向对象系统。第一个标准即作为数据库系统应具备的能力(持久性、事务管理、并发控制、恢复、查询、版本管理、完整性、安全性)。第二个标准就是要求面向对象数据库充分支持完整的面向对象（OO）概念和控制机制。

综上所述，我们将面向对象数据库简写为：面向对象数据库=面向对象系统+数据库能力。

三、面向对象数据库技术――对象关系数据库

（一）系统模型

系统模型（如图1所示），包括3个层次：业务逻辑层、OR层和物理存储层。

1、业务逻辑层。业务逻辑层是程序开发人员或者用户所接触的接口层，在这个层次上是完全的面向对象内容。业务逻辑层由很多接口组成，例如应用程序接口是专门为特定的应用程序开发的面向对象接口；领域接口针对具体的应用领域，它与领域有关（或垂直定向），例如有些领域接口用于健康保健上的应用程序，它们仅适用于这个领域；其他一些接口适用于金融、制造业、通信等领域。业务逻辑层还可以包括其他类型的接口，例如多领域接口表明它们适用于多个领域。

2、OR层。OR层是系统的关键层和核心层。它是与领域无关的（或水平定向的）层，用于完成OO和RDB的相互映射和转换。它由4个模块组成：预处理/后续处理模块；OSQL/SQL转换器；OO/RDB映射转换器；RDBMS是成熟的关系数据库管理系统。

3、物理存储层。系统的最底层是物理存储层。在数据存储的结构上，仍然采用关系数据库的形式。可见，该系统模型是对传统关系数据库的扩展，是把面向对象技术与关系数据库相结合而建立的一个对象关系数据库管理系统（ORDBMS）。其具有以下优点：（1）与纯粹的面向对象数据库管理系统（OOD2BMS）相比，系统充分考虑结合了现有RDBMS的优点，并且在当前的数据库理论和技术现状下，具有更好的可实现性；（2）与当前普遍使用的两层构架模型相比，该系统的逻辑更加清晰。同时，由于OR映射层对业务逻辑层提供了统一的面向对象接口，用户和程序员编码时可以将更多的精力放在具体领域的业务实现上而不是关系数据库与类实例的转换上。

（二）映射规则

OR映射是系统的关键功能，而OO/RDB映射转换器是实现该功能的主要模块。因此，根据面向对象理论和关系数据库的特点，重点讨论和制定映射规则。总体映射思路如表1所示：

1、没有继承关系的类映射规则：对于没有继承关系的一个类映射为一个表，其中表名取类名，对象标识符对应表的一个主键，表的对象属性对应表列且以属性名作为列名。另外，因为表中的列除了来自该对象的属性外，可能会因为关联、概括等关系而有所扩充，因此表列个数应大于或等于属性个数。同样原因，表的主码可能包括除对象标识符对应主键以外的其他键。

2、类层次映射。对于存在继承关系的3个类OA、OB和OC，不妨设OA是OB和OC的共同父类，则该类层次映射到数据表，可以根据具体情况的不同采用以下三个规则：（1）将整个类层次映射为单个数据表，表中包括所有类（基类、子类）的属性。该规则的优点是实现简单，且支持多态，而且因为表中包含了所有信息，报表操作简单。缺点是增加了类层次中的耦合，类层次中任何类属性的更改会导致表结构的更改，即会影响到整个层次结构而不仅仅是该类的子类；浪费了大量的数据库存储空间。（2）将处于继承层次最底层的各个具体类分别映射到一个数据表，每一个表包含OID、具体类本身的属性和它继承的属性，而抽象的基类则不参与映射。该规则的优点是报表操作实现简单，表中包含了具体子类的所有信息.缺点是类的修改会导致其所有子类对应表的更改；角色的更改会造成ID的重新赋值（因为不同子类的ID可能重复）；难以在支持多重角色时保持数据的完整性。（3）每个类均映射为一个数据库表，表中包含特定于该类的属性和OID，其父类的OID也作为外键存在与表中，作为指针指向该类从父类所继承属性的属性值。该规则与面向对象概念的一致性及对多态的支持最好，易于修改基类和增加新的类。缺点是映射后的数据库中存在大量的表，系统访问对象属性时要涉及多个表，需要较长的时间，对报表的支持较差。

3、类方法和类事件映射规则：方法和事件是其值不能静态存储在数据库中而只能动态执行相关程序计算得到的一种特殊的属性。在标准RDB模型中并没有支持用户自定义函数和过程的机制。可幸的是多年来一些商业化RDBMS产品已提供了这些功能，SQL标准也开始考虑包含这一功能，成为PSM子程序（包括了用户自定义函数和过程），这样就能够建立方法和事件定义到PSM子程序定义的映射中。另外，方法调用的一个显著特性就是多态，即动态捆绑。因此，仅把方法和事件调用映射为相应的PSM子程序调用是不够的，需要在方法调用被映射后的目标代码中包含PSM子程序以及该子程序调用的动态解决方案。一般的方法是将方法调用映射为case语句，在case语句中列出所有捆绑的条件和各种情况下相关PSM子程序的调用。类方法和事件的映射是与语言相关的程序翻译问题，与具体的RDBMS相关，因此需要人工来完成。

4、类间关系映射。类间关系有很多种，例如继承、组装、聚合等等。规则2处理了继承关系，对于其他的所有关系可以归结为三种类型：一对一、一对多和多对多关系。类间关系映射为一个关系表，规则如下：如果两个对象之间存在一对一关联，则在两个对象映射表中任选一个加入另一个对象映射表的主键作为自己的外键；如果两个对象之间存在一对多关联，则在“多”方对象映射表中加入“一”方对象映射表的主键作为外键；如果两个对象之间存在多对多关联，则产生对应该关联的表，它由两个对象对应表的所有主键组成，并以它们作为自己的主键。

四、结束语

对象关系数据库系统模型为OR映射提供了明确的思路和有章可循的方法，能够有效降低实际开发难度和工作量、规范映射模型、使业务逻辑部分和数据存储部分达到了松耦合。

面向对象数据库和关系数据库之间的运算转换，在多重数据库互操作研究中是一个重要的环节。本文中，讨论了对象关系数据库的体系结构及其映射规则。这些工作对于对象关系数据库的实际应用具有一定的现实意义。

参考文献：

1、王意洁.面向对象的数据库技术[M].北京:电子工业出版社，2003.

2、Ian Graham著，袁兆山译.面向对象方法原理与实践[M].北京:机械工业出版社，2003(3).

3、Scott.W.Ambler著，车皓阳、刘锐译.面向对象软件开发教程[M].北京:机械工业出版社，2003(3).

关系型数据库篇3

孙皓

（成都理工大学，四川 成都 610059）

摘要：关系型数据库是各类网络服务进行数据存储和查询的重要支撑，但由于其有限的可扩展性，在数据量和访问量爆炸式增长的现在已经越来越难以满足大型网站的需求。非关系型数据库抛弃了关系数据库复杂的关系模型，以高可扩展的架构优势成为了大型网站的支柱。文章探讨了NoSQL的应用模式，并基于Erlang语言设计并实现了易于扩展的NoSQL数据库。在测试中此数据库表现出了优异的可扩展性，可以轻松的搭建以其为基础的集群，支撑大量的数据存储请求。

关键词: 数据库；NoSQL；Erlang；分布式系统；非关系型数据库

中图分类号：TP392 文献标识码：A 文章编号：1009-3044(2011)14-3237-02

随着互联网的爆发式增长，用户的数量、网站的规模和访问频度也急剧增加，于此同时关系型数据库的不足也开始显现，其中最关键的一点即是性能问题，带来这一问题的原因有[1]：

首先，对于单一的关系型数据库来说，支持schema和SQL语句导致了存储引擎和数据物理结构的复杂度较高，这些复杂度不可避免的增加了大量IO，影响了整体性能的提升。

其次，关系模型导致数据库难以扩展。复杂的关系模型造成通常使用服务的分布化来解决单一服务器的性能瓶颈的方法难以使用，开发者切分数据的难度较大，效果不甚明显。

因此为了获得更好的扩展性，从而达到更高的性能，摆脱关系模型对数据的控制是关键的一环，高可扩展、高性能的数据库需要更为简单，耦合度更低的数据模型。以键值模型为主的NoSQL数据库较好的解决了这一问题。NoSQL数据库一般不支持复杂的SQL语句查询，仅仅以通过键查找值（key-Value）的形式提供数据的存储和查询服务，解放了对于数据库架构设计的限制。

1 NoSQL模型的研究

NoSQL一词最早出现于1998年，是Carlo Strozzi开发的一个轻量、开源、不提供SQL功能的关系数据库，但是并未引起重视。到了2009年，Last.fm的开发人员发起了一次关于分布式开源数据库的讨论，讨论中再次提出了NoSQL的概念，这时的NoSQL主要指非关系型、分布式的数据库设计模式，强调键值对存储模型和文档数据库的优点，并不是单纯的反对RDBMS，因此很多场合中NoSQL被解释为“Not Only SQL”[2]。

简单的说，NoSQL的思路即是使用松散耦合、可扩展的数据模式来进行逻辑侧的建模，代替以往的关系模型，从而获得天生的良好可扩展性。

2 NoSQL数据库使用的技术

系统主要由Erlang语言编写。Erlang是一种通用的并行编程语言，它由瑞典电信设备制造商爱立信开发1987年开始开发，成功应用于爱立信的一些高端电信设备，表现出了极高的可靠性。Erlang于1998年发表了开放源码版本。Erlang是基于虚拟机的解释性语言，但是由于其用途广泛，乌普萨拉大学为之开发了高性能的Erlang编译器版本，称为HiPE，大大提升了Erlang的运行效率。

Erlang 是一个为并行和分布式系统设计的语言[5-6]：

在Erlang语言中变量是单一赋值的，也就是说一个变量的值只能一次性给定，一旦给一个变量赋了值，就不能改变他它。Erlang的这个特性巧妙的抛弃了并行程序的副作用。在很多使用线程的语言中，例如C、Java，不同的线程间往往共享内存，而这部分内存是各个线程都可以修改的，因此会产生冲突、竞争条件等副作用，在线程的实际使用中就需要对访问这些共享内存的行为进行加锁。这不仅降低了多核系统上的程序运行速度，也使得此种编程模型下的开发容易出错，且出现问题后难以调试。

而Erlang从根本上避免了这个问题，由于变量不可修改，也就不存在冲突或竞争条件之类的经典问题，大大简化了并行程序的书写。另一方面，当调试中发现某个变量值出错时，也很容易定位问题：因为变量只能绑定一次，错误一定在那个绑定此变量的的语句处。

Erlang没有共享内存的线程模型，每一个Erlang进程都在自己的内存空间中执行，拥有自己的堆和栈。进程之间交互的唯一方法是消息传递，消息传递是异步的，典型的消息发送如下：Pid ! Message。这就将一个消息发送给了标识符为Pid的进程。事实上，Erlang进程不仅可以存在同一台物理机器上，甚至可以是远程的任意节点，只要之间可以互相访问，都可以简单的使用Pid ! Message 来发送消息，Erlang是面向分布式系统的语言。

3 NoSQL数据库的设计

为了获得高可扩展性和高可靠性，NoSQL数据库实际是一个分布式的数据库集群，分为四个主要部分：

1)存储服务。负责对键值对进行存储，并提供查询功能，此部分的每个服务就是一个进程，多个进程可以运行于不同的服务器上，也可以运行于同一台服务器的不同端口上。每一个进程按照接收到的消息进行工作，这个消息可能是从客户端来的（实际由路由服务进行了解释和转发）查询、删除或更改命令，也可能是管理服务发送的各种指令。所有的键值对根据key的高一个或二个字节分成若干组，每一组存于同一个存储服务进程中，这样所有的数据按组分布于整个集群。

2)路由服务。负责直接同客户端交互，接收客户端的请求，并更具key将请求定位到具体的存储服务进程，连接该进程进行查询等操作，最后向浏览器返回请求结果。路由服务可以由多台机器担任，此时每台路由提供的服务都是等同的，客户可以连接任一台，需要的话还可以在路由前增加缓存设备。

3)监控服务。监控服务同所有的路由服务进程和存储服务进程相连接，当路由服务或者存储服务崩溃的时候将会通知监控服务，监控服务可以根据用户设置的策略重启崩溃的服务并发出报警。监控服务的另一项重要职责是保存key的分组情况，并在表有改动的时候通知相应进程。

4)管理服务。管理服务是直接面向管理员的接口，提供了一系列管理接口，可以通过此接口启动/停止各类服务，查询集群服务的状态，查询各类统计值，查看日志等。一般来说管理服务和集群的正常运行关系不大，对于集群来说它是没有状态的，在完成管理操作后可以随时关闭。

5)客户端接口。客户端接口用以连接集群进行查询等操作，可以是随集群一起的C/C++链接库，也可以是Java类库，或者Perl/Python模块等等。在我们的设计中使用了纯HTTP RESTful服务，因此可以使用各种语言/框架的原有HTTP模块即可完成同路由服务的交互，使用RESTful风格的服务可以大大增加集群的使用场景。

一个请求的完成路径如下：用户连接到路由服务，发出请求，路由服务查询该请求所对应的存储服务进程及其所在机器和端口，随后路由服务将请求翻译为内部格式并向存储服务进程发出请求，存储服务进行相应操作，操作完成后将结果返回给路由服务，路由服务将结果使用RESTful风格重新打包后返回给客户。

例如，针对某学校的学生信息，在部署汇总使用下面的URI来定位（学号为223）：

/student/info/223

当需要获取学生的信息时，可以使用标准HTTP协议发出请求：

GET /student/info/223 HTTP/1.1

Host:

Accept: text/plain

集群也以HTTP协议标准格式返回结果：

HTTP/1.1 200 OK

Content-Length: 3059

Server: KV1.0

Date: May, 1 Jan 2011 02:44:04 GMT

Content-Type: text/plain

Cache-control: private

This is data...

当集群需要扩展时，可以简单的将一部分数据组迁移到新的机器上，并更新监控服务中的数据分组表使路由将这部分请求转发至新的机器。

由于每台存储服务独立提供查询和添加服务，因此集群的相应能力是机器相应能力的简单相加，这一特性很适合数据量庞大和业务快速增长的企业，可以随时对集群简单的扩容来满足需求。

4 结论

作为关系型数据库在遇到扩展性和性能瓶颈时的辅助，论文中设计并实现的NoSQL数据库拥有良好的可扩展性，在集群机器数量增加时，数据库的响应能力几乎可以以线性的规模进行增长，较好的满足了大型网站对于容量和访问量的要求。

参考文献:

[1] Michael Stonebraker．SQL databases v. NoSQL databases [J]．Communications of the ACM,2010,53(4):10-11．

[2] Wikipedia. NoSQL词条 [EB/OL]. /wiki/NoSQL.

[3] Abraham Silberschatz, Henry F Korth, Sudarshan S. 数据库系统概念[M].北京:机械工业出版社,2006.

[4] Sam Lightstone, Toby Teorey, Tom Nadeau.物理数据库设计[M].北京:清华大学出版社,2007.

[5] Francesco Cesarini, Simon Thompson.Erlang 编程指南[M].北京:机械工业出版社,2011.

[6] Joe Armstrong.Erlang 程序设计[M].北京:人民邮电出版社,2008.

[7] Andrew Tanenbaum,Maarten Van Steen.分布式系统原理与泛型[M].北京:清华大学出版社,2008.

[8] Francisco Maia, José Enrique Armendáriz-I?kigo．Scalable Transactions in the Cloud: Partitioning Revisited [J]．Lecture Notes in Computer Science，2010，6427(2010):785-797．

关系型数据库篇4

【关键词】面向对象数据库 信息化 关系数据库

随着计算机技术的不断发展，数据库技术已经成为计算机领域中不可缺少的一部分。关系模型以其自身的优势逐渐占据了主导地位，成为目前最重要也是应用最广泛的一种数据模型。但是，在计算机技术日新月异的发展过程中，数据库系统处理的已不仅仅是一些简单的数据类型，它还必须能够处理一些复杂的数据类型。在这种情况下，一种新型的数据模型—面向对象的数据模型问世了。本文就关系数据库和面向对象的数据库的性能和结合进行一些探讨。

一、关系数据库的特点分析

（一）数据模型

关系模型是建立在集合代数基础上的，具有坚实的理论基础。而关系模型包含的概念是关系、属性、记录等。关系模型用关系描述实体；它的基本特征是用二维数组表示所有实体，实体之间的联系也用关系来表示；

（二）数据库系统

（1）基本结构。关系数据库的基本结构是记录，一个记录包含若干条属性。

（2）支持的数据类型。关系数据库的基本数据类型包括整型、实型、字符串型、布尔型等，不允许用户增加新的数据类型。

（3）模式修改。关系数据库系统中，主要的模式修改有：创建或删除一个关系；在关系模式中增加或删除一个属性；在关系模式中修改完整性的约束条件。

二、面向对象数据库的特点分析

（一）数据模型

面向对象的数据模型是建立在面向对象的程序设计方法的基础上的。面向对象的数据模型使用了许多面向对象的概念。面向对象的数据模型不对每个实体一一定义，它只定义对象的类，根据类定义属性和方法。

（二）数据库系统

（1）基本结构。面向对象的数据库的基本结构是对象。对象与记录的概念类似，但内容要比记录复杂得多，每个对象由唯一的标识符把状态和行为封装起来。

（2）支持的数据类型。在面向对象的数据库中，它不仅包含关系数据库中的基本的数据类型，而且也可以包含用户自己定义的新类型。

（3）模式修改。面向对象的数据库系统中，主要的模式修改有：类集的改变；已有类的成分的改变；子类/超类成分的改变；查询操作：关系数据库的查询操作支持嵌套子查询、集合（交、并、差）查询等，查询是非导航式的。面向对象的数据库中，查询操作是在类上进行的，查询是导航式的。

三、关系数据库（RDB）向面向对象数据库（OODB）的转换

（一）RDB向OODB转换的可行性

关系数据库在简单大量数据的检索查询上占有优势，而面向对象数据库的优势在于对复杂数据对象的导航式访问。经过大量的研究和实践证明下面的两种方法是可行的：建立基于关系的面向对象数据模型；将关系数据模型与面向对象数据模型统一起来。

（二）RDB向OODB转换的思想

传统关系模型=（Sr，Ar） 其中Sr是关系的集合，Ar是关系代数；面向对象模型=（So，Ao） 其中So是对象的集合，Ao是对象集合的代数运算两者之间的不同之处在于Sr中的每个元素是关系，只有结构部分，而So中的每个元素是对象，不仅具有结构部分，还具有操作部分，而且对象具有封装性。具体完成从关系数据库向面向对象数据库转换思想如下：在关系模型基础上增加抽象数据结构，过程类型以及类型模式的继承性等。面向对象的方法是从抽象数据类型发展起来的，它主要是为了解决软件的复杂性和软件的结构问题。在两者的结合，这里强调数据完整性的问题。保证数据完整性的一个重要方法就是引入数据约束。

（三）RDB和OODB的前景分析

关系模型的数据结构简单，容易理解和掌握。对实体和实体之间的联系的描述简明、精确，给用户使用数据库提供了很大的方便。但是，它不能表示复杂的对象，也不具备定义复杂操作的能力。所以，根据目前数据库技术的发展趋势，关系模型还应扩充，与面向对象模型相结合，从而具有更强的功能和更广泛的应用领域。因此，关系数据模型仍然具有良好的发展前景。面向对象的数据模型由于可以表示复杂的数据类型，它能适用于一些关系模型不能适用的复杂应用领域，而且它对实体的描述比关系模型更加现实、自然、更加直观。因此，面向对象的数据模型比关系模型更具优势，更有发展潜力。

四、结语

RDB和OODB都有其各自的优势及应用领域，由于OODB模型的特点，还可以设计出更多的转换算法和集成更好的模型。对于将RDB与OODB更紧密的结合成真正的面向对象数据模型还需要更深入的探讨。

参考文献：

[1]萨师煊，王珊.数据库系统概论[M].北京：高等教育出版社，2000.

[2]钱雪忠，罗海驰，陈国俊.数据库理论及技术课程设计[M].北京：清华大学出版社，2009.

[3]范剑波.数据库理论与技术实现[J].西安电子科技大学出版社，2012.

[4]温雅丽.面向对象技术在多媒体数据库的应用[J].科技情报开发与经济，2002，（4）.

关系型数据库篇5

关键词：土壤肥力；数据库；盘锦

中图分类号： S158 文献标识码： A 文章编号： 1674-0432（2013）-20-44-1

1 数据库资料准备

1.1 图件资料收集与处理

①地形图：收集盘锦市1∶5万用地形图，同时对水利、公路、规划、国土等部门联系收集有关最新图件资料，对地形图进行修正；②土地利用现状图：盘锦市电子图（ArcGIS等格式），比例尺分别为1∶5万和1∶1万；③土壤图：第二次土壤普查成果资料及土壤图（1∶5万）。在进行调查和采样点为确定时，可通过土壤图了解土壤类型等信息，同时土壤图也是各类评价成果展示的基础图件；④农田水利图：盘锦市农田水利分区图（1∶5万），以及当地耕地的灌溉条件、灌溉保证率、灌溉模数、排涝模数、抗旱能力、排涝能力等指标；⑤采样点点位图：根据制定地块采样计划，编制采样点点位图，进行土壤采样。

1.2 数据及文本资料收集与处理

①县、乡、村名编码表：参照《耕地资源管理信息系统数据字典》中编码规则，建立最新、最准、最全的市域内行政区划代码表，提供的所有资料中均采用本代码，已经有编码的资料应编写代码对照表；②土壤类型代码表：建立土壤类型代码表，保持土壤志中分类系统表、土壤图图例、典型剖面理化性状统计表、农化样数据表等资料的一致；③土壤肥力普查土壤采样点基本情况及化验结果数据。

2 数据库管理系统建立

2.1 数据库功能设计

2.1.1 数据管理 包括空间和属性数据管理两个部分，空间数据管理主要对盘锦市耕地土壤肥力评估所用到的相关矢量图层数据文件进行导入、导出及更新、修正；属性数据管理主要是对本数据库内部的土壤类型、耕地中各元素指标数据等进行管理。

2.1.2 数据处理 对空间数据和属性数据进行相关的数据操作处理。如对矢量图层进行空间查询、空间叠加分析、差值分析等，属性数据进行查询、统计等。

2.1.3 评价模型 根据相关评价中选用的各类数学模型（层次分析模型、隶属函数模型），对评价指标数据进行耕地的肥力质量评价等。

2.1.4 数据输出 对各指标数据及评价成果生成不同的专题地图、数据统计表、评价成果文本等进行输出和打印。

2.2 空间图形数据库的建立

数据内容主要包括基础地理信息数据和耕地资源专题数据。基础地理信息数据包括土地利用现状、道路、河流、等高线、行政区划等；耕地资源专题数据包括土壤类型图、耕地各指标元素含量数据等。空间数据库采用分层进行管理和组织。一个数据文件可划分不同的数据图层，分层原则完全独立于具体的应用模型，不同图件上的要素均按点、线、面进行归类，各层信息按数据库信息分类编码体系规范化分类进行编码。

2.3 指标属性空间数据库的建立

属性数据包括基础地理信息数据，土地利用数据，土壤类型数据，采样点数据，耕地各元素指标数据。本系统采用关系型数据库二维关系表的形式设计系统属性数据库结构，应用Access建立属性数据库。Access通过收集、处理、编辑数据，增加一个字段制作成表单的形式完成入库，依靠识别该字段来完成链接，同时也可以通过Code字段关联项来实现与空间数据库的连接[1]。其中：采样点调查数据包括采样点地理位置、自然条件、土壤情况、种植作物品种等；耕地各元素指标数据包括全氮、全钾、pH等，同时还有系统模型库所需要的参数及相关文献资料等。

2.4 评估模型数据库的建立

耕地土壤肥力评估采用的数学模型在数据库中一般表示形式是方程式，具体反映模型中变量之间的关系、约束条件及其目标。本数据库的评估模型的方程式形式不适合计算机求解，在计算机中一般是将求解方程的算法编为程序形式，包括源程序和目标程序[2]。因此通过建立本评价系统的模型数据库，用来存储所有模型以及模型与数据的匹配关系。

评估模型由模型字典库和模型文件库组成。模型字典是模型文件的索引，模型字典库的内容包括模型的编号、名称与模型文件等的说明；模型文件库是模型的主体，一个模型至少有2～4个模型文件。本系统的模型数据库是针对系统中耕地土壤肥力评价而建立的，也是由Access数据库管理系统来存储数据，模型库中主要包括评价所涉及的各因子的详细信息及各种数学模型。

3 结论

基于ArcGIS平台，实现了耕地土壤肥力评估的空间、属性数据及评价模型数据库三者无缝结合，从而能够很好的表达盘锦市耕地土壤肥力的空间与属性数据的关系，使盘锦市耕地土壤肥力评估的结果准确可靠，同时能够表达其空间分布和各肥力等级之间的规律。

参考文献

[1] 方秉望.ArcGIS 在土地利用规划数据库建设中的应用[J].现代农业科技，2013（2）：333-334.

[2] 唐秀娟.耕地质量评价系统的开发及应用研究[D].云南昆明：昆明理工大学（2008）.

关系型数据库篇6

【关键词】 文史数据库 设计 要点分析

1 前言

随着文史资料研究的逐步深入，构建文史数据库成为了提高文史资料研究质量的重要手段。通过对数据库的设计过程进行了解后发现，数据库的设计与实现步骤主要为需求分析阶段、概念结构设计阶段、逻辑结构设计阶段和物理实施阶段。要想保证文史数据库设计取得积极效果，就要明确设计思路，同时在数据模型的建立上下功夫。在确定设计思路过程中，应合理确定数据模型、概念模型和现实需求。在数据模型建立过程中，应严格规范化要求，提高数据模型建立质量。

2 文史数据库的设计与实现的步骤分析

通过了解发现，文史数据库的设计与实现主要分为以下几大步骤：

2.1 需求分析阶段

在文史数据库设计之前，需要明确文史数据库需要具备哪些功能，需要研究文史数据库的特点及文史数据库与其他数据库的区别，保证文史数据库的设计能够满足实际需要，提高文史数据库的设计效果。

2.2 概念结构设计阶段

在明确了文史数据库的需求以后，需要进行数据库结构的简单构建，其中重要的一环是划分数据库的基本结构，并建立数据库的基本的概念，保证结构层次能够满足实际需要。

2.3 逻辑结构设计阶段

逻辑结构设计是文史数据库设计的重要阶段，是保证文史数据库功能实现的关键阶段，在这一过程中，需要构建适合数据库需要的数学模型，并提高数据模型的运算效果，保证数据库的功能得以实现。

2.4 物理实施阶段

所谓物理实施阶段主要是利用数据库设计原理，将物理元件连接和组装在一起，实现数据库的功能，在文史数据库设计与实现过程中，物理实施需要连接硬件系统，并将数学模型落实到系统中。

3 文史数据库的设计与实现的思路分析

数据库系统：需要机器中的某种数据库管理系统支持，物理存储逻辑结构；数据模型：逻辑结构设计关系模型；概念模型：（e-r模型）现实需求。

e-r模型中的术语：实体、属性、实体型、实体集、键、联系。实体名（属性1，属性2，……，属性n） 图形描述规则：（1）“矩形”框用于表示实体集；（2）“椭圆形”框用于表示实体集中实体的公共属性；（3）“菱形”框用于表示实体集之间的联系。实体之间的联系有三种类型：（1：1）、（1：n）、（n：m）。

数据模型：关系、属性、关键字（候选关键字，主关键字，外部键）、关系模式 关系名（属性1，属性2，属性3，……属性n）。关系完整性约束：用户自定义完整性、实体完整性、参照完整性。

e-r模型和数据模型的对应关系：实体名（属性1，属性2，……，属性n）关系模型：关系名（属性1，属性2，……，属性n）。

4 文史数据库的设计与实现的数据模型建立分析

数据模型构成： 数据结构：数据库的框架。二维表格（关系模型） 数据完整性：用约束保证数据正确。 数据操作：插入，删除、修改。

关系数据模型的规范化要求：（1）一个关系是一个二维表格。每个关系只包含一个实体的信息。（2）关系中每一分量不可再分，是最基本的数据单位。（3）每一列是一个属性，有唯一的属性名。属性在表中的顺序无关紧要。每一列的数据分量是同属性的。（4）二维表格中每一行（除属性名行）是一个元组，表中不能有重复的元组（元组是唯一的），用关键字（主关键字和候选关键字）来保证元组的唯一性。每一行由一个实体的诸多属性构成，且各行的顺序可以是任意的。

基于文史数据库的特点，在文史数据库设计过程中，应对数据模型建立引起足够的重视，应从数据模型建立入手，全面提高文史数据库的构建效果。

5 结语

通过本文的分析可知，在文史数据库的设计与实现过程中，要想保证数据库的设计与实现取得积极效果，就要对数据库的设计

骤、数据库的思路确定和数据库模型建立等方面有足够的了解。同时，还要认真分析文史数据库的特点，明确文史数据库与其他数据库的区别，保证文史数据库在构建过程中能够满足实效性要求，达到提高文史数据库构建质量的目的。由此可见，在文史数据库设计与实现过程中，我们要明确设计步骤，把握设计原则，提高设计质量，满足实际要求，使文史数据库的设计能够取得积极效果。

参考文献：

[1]季伟，刘永辉，刘剑，崔卫.实现三网融合的ftth工程设计[j].光通信技术，2010年05期.

[2]刘亚荣，杨春，李新，蒋存波.基于gpon的高校ftth设计方案[j].光通信技术，2011年02期.

[3]张杰，郑振鹏，乐孜纯，付明磊.一种融合型光网络单元的设计与实现[j].光通信技术，2012年01期.

[4]刘豫，李兆会.基于ftth的三网融合解决方案[j].硅谷，2012年13期.

[5]袁恩野.pon技术在宽带网络中的应用[j].硅谷，2013年11期.

关系型数据库篇7

关键词：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）.

作者简介：国明，女，河北石家庄人，硕士研究生，曾参与目录服务项目建设与运维，目前负责系统运行监控。

关系型数据库篇8

数据库管理数据，具有数据结构化，共享性高，冗余度低，易扩充，数据独立性高等优点。对于文章拟采用的文件与数据库结合管理文物保护工程中数据的方法，更具有以下优点:(1)数据文件采用文件管理模式管理。对数据存储路径和数据命名进行规范化，制定命名规则和存储方案，便于理解数据之间的层次关系，为数据查询及数据库设计提供条件，而且此种存储方法不破坏数据的数据结构，仍可采用先进的三维点云数据处理软件对数据进行处理。(2)数据库管理数据文件间的关系并补充完善其属性数据，利用数据库和数据编程语言，编写合适的查询界面，实现数据的属性查询，存储位置查询等，提高数据查询使用效率。

2数据文件管理

由于文物保护工程中文物范围很大，为了数据采集方便，需根据工程特点及实际操作便利程度将文物进行分区，对文物信息进行分区域数据采集，另外需要将文物中具有代表性特点的对象进行单独的数据采集和存储。据此可以将文物三维数字化工程在文件管理中按照整体、区域、对象进行分类，若对象较多且复杂，可再根据工程需要分为若干子对象。以大足石刻千手观音虚拟修复工程为例，根据千手观音的整体结构特征，将其划分为9行11列，共99个区域，各区域以“行号－列号”命名(如图2);将具有代表性的对象进行分类，分为主尊、肋侍、手、法器，并以此命名文件夹。根据各对象特点，各肋侍命名为肋侍1、肋侍2、肋侍3、肋侍4，手以“所属区域行号－所属区域列号－手编号”的方式命名，法器以其类别名称命名。根据划分区域、对象的提取及各文件夹命名，千手观音虚拟修复工程数据的文件管理结构如图3所示。该工程中涉及的数据类型有纹理数据、点云数据、模型数据、真三维模型数据、正射影像图、数字线划图、剖面图，在整理好的文件管理结构各个子文件中存储该对象或区域的各类数据。

3数据库管理

数据库主要存储上述文件管理结构，对于工程中涉及的各类空间数据，需存储各类数据间的关系及数据属性信息。3.1文件结构在数据库中的实现该工程中的文件管理结构在数据库中主要通过编码的方法实现，即按目录层次编码，每层2位编码，则每个目录最多有99个子目录，由于千手观音有近1000只手，所以在手数据目录层编码设置3位，可以存储999个子目录，可满足工程需要。上述文件结构编码如图4所示:在数据库中，该文件结构可由表1实现，记录各文件目录Id及名称，父目录名称，所属层级及编码号，在查询文件结构时，可根据父目录名称查询该文件夹下的文件夹名称和数目，也可以根据编码查询文件结构。3.2数据类型管理利用三维激光扫描仪器获取文物的三维信息，根据点云数据的基本处理流程，工程中的四类基本数据类型为:点云数据、纹理数据、模型数据、真三维模型数据。根据这四类基本数据，还可以得到一些其他类型的数据，为了满足日后数据管理的需要，在数据库中设计数据类型管理表，用来管理工程中涉及的各类数据，表2列出了该工程中的4种数据类型，由于各工程中的数据类型不止这4种，所以可以根据需要，向数据类型管理表中继续添加数据类型。数据类型管理实体与各类数据类型实体之间是分类管理的关系，四类基本数据类型来源及关系总结如下:点云数据通过三维激光扫描仪获取;纹理数据利用高分辨率数码相机获取;模型数据是由点云数据经配准、去噪、融合、建模等处理得到的数据，所以点云数据与模型数据是多对一的关系;模型数据经纹理贴图后得到真三维模型数据，所以真三维模型数据与模型数据是一对一的关系，与纹理数据是一对多的关系。数据类型管理实体与各类数据的关系及各类数据之间的关系可表示为图5所示。在千手观音虚拟修复工程中，利用这四类基本数据生成了正射影像图、数字线划图、剖面图三类数据。该工程中涉及的这三类数据来源为:正射影像图由多张纹理图数据经软件纠正所得，所以正射影像图与纹理数据是一对多的关系;数字线划图是正射影像图经软件描绘提取得到的，所以数字线划图与正射影像图是一对一的关系;剖面图是利用三维模型，经软件剖切获得的，由于剖面可以有不同的方位，所以剖面图与模型数据是多对一的关系。在实体关系中，有一对一和多对一的关系。对于关系中，一对一的关系，在其中一个实体表中设置外键，如纹理数据和图像数据关系中，可在纹理数据表格中设置图像数据编号外键，实现两者一对一的关系;多对一的关系，在前者表中设置外键，如纹理数据与真三维模型数据是多对一的关系，在纹理数据表格中设置真三维模式数据编号外键，以此实现两者多对一的关系。数据类型实体属性及关系设置如图6(E－R图)所示:3.3数据库实现根据上述数据库关系模型图，设计各数据表格和数据模式，将表的字段表示为数据库支持的数据类型。利用Oracle数据库管理系统，在User表空间下，创建Spatial用户，并创建各表数据，建立各表之间的关系。数据加载方式有多种，本次实验中，已有表格数据利用SQLdeveloper导入Excel数据，部分实验数据采用手工录入方式，其他数据采用程序开发的方式导入。数据库查询:利用创建的数据库，可以根据工程需要，查询文物信息采集状况、成果数据完成情况等，如某区域数据是否进行数据采集，是否符合工程标准;还可利用线划图数据名称查找相关正射影像图数据等。

4数据管理系统设计及实现

为了方便日常数据管理，便于无数据库相关基础知识人员对数据进行相关查询，设计如下数据库管理系统，对数据进行简单查询调用。本系统以Microsoftvisualstudio2010为开发平台，利用c#开发语言，ADO．NET连接Oracle数据库。Ora-cle数据连提供程序是．NETFramework的一个插件，提供了访问Oracle数据的功能［6］。为了方便数据录入，编写数据入库界面实现点云数据、模型数据等空间数据的导入操作。各项数据存入数据库后，可根据需要进行各项数据查询，方便数据管理，提高管理效率。另外，为方便无数据库知识背景人员对数据进行查询，设计了数据查询界面(如图7所示)，可实现特定数据类型的通过数据对象名称进行的查询。

5结语

本文分析总结了文物三维数字化工程中涉及的各类数据关系，以大足石刻千手观音虚拟修复工程为例，实现了数据的高效管理和查询，主要成果如下:(1)根据该工程特点及文物三维数字化工程采集处理数据的共性，对该工程涉及的各类数据进行了整理，在文件管理模式下，规范了存储路径和命名规则，使数据在文件管理模式下更加规范，节省了存储空间；(2)对工程中涉及的多源数据关系及属性数据进行整理，设计数据库实体与实体关系，利用oracle数据库及数据库工具，通过程序开发的方式将各类数据导入数据库，提高了数据查询效率和安全性;(3)设计并开发了简单的数据库操作系统，方便无数据库知识背景的工作人员对数据进行查询，提高了工程中数据的查询使用效率。