数据库索引范文

时间:2023-03-08 11:17:56

数据库索引

数据库索引范文第1篇

[关键词]数据库 SQL2008 索引 创建 碎片 重建

中图分类号:P628+.4文献标识码:A

随着现代信息技术的发展,数据处理技术得到大力发展,而数据管理不只是存储数据和管理数据,还包括用户所需要的不同的数据管理的方式。数据库技术从存储有各种数据的原始表格到能够进行大量数据存储的大型数据库系统都在各个方面得到了广泛的应用,形成了多种类型的数据库处理技术。其中,关系数据库是一种典型的数据管理方式,而且相对比较稳定。但关系数据库也存在一些不足:存取路径对用户透明导致查询效率往往不如非关系数据模型。为提高性能,必须对用户的查询请求进行优化,增加了开发数据库管理系统的难度。而索引是进行大量数据的查询必要简化手段,也是实现查询请求优化的重要方法,本文就对关系数据库(以SQL server2008为例)的索引进行详细的探究。

一、数据库文件底层物理结构

数据库系统是一个搭在操作系统平台上的数据管理软件,所管理的数据最终是以文件形式存在。数据库中的每个文件都有一个唯一的文件 ID 号。数据存储是以页为基本单位,若要唯一标识数据库中的页,需要同时使用文件 ID 和页码。

SQL Server 中数据存储的基本单位是页,每页大小为8K,当系统为数据库文件.mdf 或 .ndf分配磁盘空间时,从逻辑上划分成从0到n连续编号的页,数据都存储页上操作。在数据页上,每页的开头是 96 字节的标头,用于存储有关页的系统信息。此信息包括页码、页类型、页的可用空间以及拥有该页的对象的分配单元 ID。数据行是真正存储数据的,它紧接着标头按顺序放置,页的末尾是行偏移表,对于页中的每一行,每个行偏移表都包含一个条目。每个条目记录对应行的第一个字节与页首的距离。行偏移表中条目的顺序与页中数据行的顺序相反。

SQL Server中管理数据存储空间的基本单位是区。一个区通常是八个物理上连续的页。为了更有效地利用分配的磁盘空间,根据区内含有对象个数分为统一区和混合区。统一区由单个对象所有,区中8页只能由所属对象使用。混合区最多可由八个对象共享,区中八页的每页可由不同的对象所有。通常从混合区向新表或索引分配页,当表或索引增长到 8 页时,将变成使用统一区进行后续分配。如果对现有表创建索引,并且该表包含的行足以在索引中生成 8 页,则对该索引的所有分配都使用统一区进行。

从上面知识,我们可以知道表组织关系为:表分布在一个或多个分区中,每个分区在一个堆或一个聚簇索引结构包含数据行。堆页或聚簇索引页在一个或多个分配单元中进行管理,具体的分配单元数取决于数据行中的列类型。

二、数据库中的索引

索引是一种在表上建立的用来提高数据查询速度的B-tree类型的数据结构。当我们在某列上建立索引后,数据库会在表中建立索引数据,这些数据以页级为基本单位进行存储,每一个页中都包含指向数据的指针,使用查询时就会根据这些索引信息进行查询,以提高查询速度。但索引是一种独立于数据库表的数据结构,存储它需要额外的空间,而且在后面对数据库表进行的插入、删除等操作都要对索引进行操作,都会影响数据库系统的性能。

数据库系统支持的索引类型按存储结构可以分为聚簇索引和非聚簇索引。

1、聚簇索引(也称聚类索引、聚集索引)

索引是按B-tree结构进行组织的。索引B-tree中的每一页称为一个索引节点。B-tree的顶端节点称为根节点。索引中的底层节点称为叶节点。根节点与叶节点之间的任何索引级别统称为中间级。聚簇索引的数据页是按照表中数据的物理存储顺序来有序存储。聚簇索引叶节点包含基础表的数据页。根节点和中间级节点包含存有索引行的索引页。每个索引行包含一个键值和一个指针,该指针指向B-tree上的某一中间级页或叶级索引中的某个数据行。每级索引中的页通过双向链接的形式连接起来。当使用查询时,可以通过对B-tree的查找到对应的索引值,再去查找该索引对应的具体数据页所在的叶子节点获取数据。使用索引查询可以避免全表扫描,而且在查询B-tree的过程中,可以使用二分查找法、折半查找法等查找方式对索引的查询进行优化,这样就更加提高了查询的速度。由于聚簇索引规定数据在表中的物理存储顺序,因此一个表只能包含一个聚簇索引。

2、非聚簇索引(也称非聚类索引、非聚集索引)

非聚簇索引与聚簇索引具有相同的 B 树结构,但是基础表的数据行的物理存储顺序与非聚簇键的顺序没有关系。非聚簇索引的叶层是由指向具体数据的指针或索引页组成,而不是由数据页组成。既可以使用聚簇索引来为表或视图定义非聚簇索引,也可以根据堆来定义非聚簇索引。非聚簇索引中的每个索引行都包含非聚簇键值和行定位符。此定位符指向聚簇索引或堆中包含该键值的数据行。如果是堆表(没有聚簇索引)上的非聚簇索引,则行定位器是指向行的指针。如果表有聚簇索引或索引视图上有聚簇索引,则行定位器是行的聚簇索引键。SQL Server 通过使用存储在非聚簇索引的叶行内的聚簇索引键搜索聚簇索引来检索数据行。由于每次查询数据指针的跳转都会需要系统开销,因此非聚簇索引更适于处理从表中只返回少数行的查询。聚簇索引更适于处理需要一系列行的查询。

三、正确使用索引分析

通过遍历索引结构的节点来提高查询效率,但索引是需要额外的存储空间,同时再进行数据的插入删除等操作可能会重建索引,会大大增加系统开销,必须正确使用索引。使用索引还需要考虑到:建立索引和维护索引都要耗费时间,且耗费时间随着数据量的增加而增加;当对表中的数据进行增加、删除和修改的时候,索引也要动态的维护,这样就降低了数据的维护速度;索引需要额外的存储空间。

选择在使用最频繁、需要排序的字段上建立索引。在常用来连接表的列上建立索引,可以加快基表连接的速度;在常需要根据范围进行搜索的列上创建索引,因为索引已经排序,其指定的范围是连续的;在经常需要搜索的列上,可以加快搜索的速度。特别是建立聚簇索引时基表中与聚簇索引相关联的数据行必须按照与索引搜索键相同的顺序排序和存储,且基表会被复制并且按照选择索引字段排序,原来的基表会被删除,这就要求必须有足够的空间来存放数据基本的副本和索引本身。

在使用索引时,可能由于一些原因造成索引失效,我们应当尽量避免这些问题的发生。造成索引失效的一些原因:

(1)、使用了不兼容数据类型导致失效。通常在一些隐式类型转换中易出现,也容易让人忽略。

(2)、查询语句中包含有数学运算与逻辑非操作等导致失效。

(3)、对索引所在列进行运算或包含NULL关键字导致索引失效。

(4)、使用不能确定范围的运算符与子句(或子查询)导致失效。

(5)、其它不正确使用符号导致失效,例如双引号。

四、索引碎片与索引重建

索引自动创建后,数据的插入、更新、删除等操作都会对索引运行动态的维护,每次维护都有可能产生新的无效的索引,由于维护次数以及数据量的增大,这些无效的索引会越来越多,这些就是索引碎片。出现大量的索引碎片时,如果要在几千万条数据中查找出数据,则会有很大的时延。这时须要对索引碎片进行处理,通常有以下四个方法:

1、删除并重建索引

先删除索引,再重建索引。但是在删除与重建过程中,该索引不可用,如果在删除与重建过程中有请求,将造成阻塞。特别注意的是,如果重建的是聚簇索引,那么非聚簇索引会重建两次;再删除聚簇索引时,非聚簇索引的数据行指针会指向堆数据,重建聚簇索引时,非聚簇索引的数据行指针又回指回聚簇索引的数据页行的位置。

2、使用DROP_EXISTING子句重建索引

采用这种方法重建索引时,会保留聚簇索引键值,这样就防止了非聚簇索引重建两次。但是在重建过程中如果有请求,还是有可能会造成阻塞和索引失效的问题。由于重建过程中会保留聚簇索引键值,要强迫用户去分别发现和修复表上的每一个索引。

3、执行DBCC DBREINDEX 存储过程

允许SQL Server给索引分配新页来减少内部和外部碎片,直接在索引的物理存储列表中重组索引。DBCC DBREINDEX也能动态的重建带约束的索引。执行这处存储过程是以一个事务来运行的,如果在完成这个事务之前中断了,那么会丢失所有已经执行过的碎片。同样在执行过程中,如果还有要使用索引,也有可能会阻塞。

4、执行DBCC INDEXDEFRAG存储过程(SQL Server 2000中运行)

执行DBCC INDEXDEFRAG存储过程就是要按照索引键的逻辑顺序,通过重新整理索引里存在的叶页来减少外部碎片,通过压缩索引页里的行然后删除那些由此产生的不需要的页来减少内部碎片。执行它得到结果没有前面几个方法彻底,但它不会遇到阻塞问题。

五、结束语

索引是提高数据库系统进行数据检索效率的重要手段,但索引并不是越多越好,需要我们从底层认索引数据结构,以加深我们对正确使用索引的理解。同样当索引使用出现失效以及大量索引碎片时,我们要能及时的采取对应的办法来解决这些问题。

参考文献

[1] 数据库索引与优化刘华清、陈振东、涂刚现代计算机2012.06(下)

[2] 索引在查询优化中的作用王磊 长春理工大学学报 (高教版)2009.2[3]

[3] 浅谈如何在SQL Server 中使用索引谷峥征 李春玲 教研论坛2009.8

[4] SQL Server 查询优化技术的研究向猛信息与电脑 2012.2

[5] 浅谈数据库中索引的应用王琳 科教纵横 2011.7

数据库索引范文第2篇

【关键词】数据库索引;聚集索引;非聚集索引;查询优化

由于计算机网络技术的迅猛发展,企业间数据交流的各种数据量的急剧增长,不但要求处理的结果要准确,而且也要求处理速度及时,这对数据库的处理能力能力方面提出了更高的要求,如何设置有效的数据库索引达到数据库优化是本文要讨论的重点。

应用索引的过程其实类似于查新华字典,比照数据库的概念,新华字典里的拼音检字法和部首检字法就是新华字典的两种不同的索引,而新华字典的正文则相当于表同时创建索引并不会改变表中的数据的物理位置,它只是创建了一个新的数据结构指向数据表。比起逐一查阅字典正文查找某一个具体的汉字,显然不管使用哪种检字法都可以很快地在字典正文中找到这个汉字,这就是使用索引的给我们带来的好处。如何准确高效地从海量的信息中查询到想要的数据,已成为数据库设计人员的首要任务。

所以我们可以从逻辑上简单地认为,索引是一个单独的、物理的数据结构,它主要包含两列内容,第一列是从表或视图中的列或列的组合所生成的键值的集合,且根据键值以升序或降序排列。这一列类似于新华字典的音序,它以字母升序排列,即A在最前,而Z在最后。索引的另外一列则是指向表中这些值的数据页的逻辑指针的集合。这一列则类似于对应音序的页码。索引依赖于表,作为表的组成部分,由数据库系统自动维护,是对数据库表中一个或多个列的值进行排序的数据结构,不同的索引对应不同的排序方法。一个表的存储是由两部分组成的,一部分是用来存放数据的数据页面,另一部分是用来存放索引的索引索引页面,通常索引页面比数据页面小得多。

假设表中的数据在磁盘上存储是有序的,那么当在数据库在进行插入数据、删除数据和更新数据时,则一定会导致数据的顺序会发生变化,为了保证数据的连续性和有序性,就需要重新移动数据,改变它们的物理位置,而种移动将会导致增大磁盘的I/O操作,使得整个数据库运行非常缓慢;使用索引的主要目的是使数据逻辑有序。为了实现数据逻辑有序,实际上索引的物理结构是一个双向链表,使用双向链表来保证数据的逻辑顺序,如果要对表中的一个已有结点进行更新则仅需修改该节点的前驱和后继,而且无需修改该节点的物理位置;如果要在两个节点中插入一个新的节点只需修改节点的前驱和后继,而且无需修改新节点的物理位置;如果要删除一个已有结点,则仅需修改其前驱结点的后继为该被删除结点的后继。总的来说,索引保存着具体数据的物理地址值。

索引从大的方面分为聚集索引和非聚集索引。所谓聚集索引是指表中数据的物理顺序是和索引的顺序是一至的,数据页是聚集索引的叶节点,数据页之间通过双向链表的形式连接起来,而且实际的数据都存储在数据页中。查询时,数据库首先根据索引查找,找到索引值后,接着查找该索引的数据页(叶节点)获取具体数据。如果没有索引,则查询时会进行全表的遍历。第二类索引则称为非聚集索引,非聚集索引是物理存储不按照索引排序,非聚集索引的叶节点(IndexLeafPages)包含着指向具体数据行的指针或聚集索引,数据页之间没有连接是相对独立的页。具体地来说,非聚集索引又分为:①堆表非聚集索引在没有聚集索引的情况下,表中的数据页是通过堆(Heap)形式进行存储,堆是不含聚集索引的表;SQLServer中的堆存储是把新的数据行存储到最后一个页中。非聚集索引通过双向链表连接,而叶节点包含指具体数据行的指针。堆表中查询信息时,首先遍历索引,获取到指针信息,再根据指针信息获取相应数据页中的数据。②聚集表非聚集索引当表上存在聚集索引时,任何非聚集索引的叶节点就不是指针值,而是包含聚集索引的索引值。非聚集索引依然通过双向链表连接,但叶节点包含的是索引表的索引值。在聚集表中查询信息时,首先遍历索引,获取索引值,然后根据索引值获取相应数据页中的数据。

数据库查询表主要通过以下五种方式:

①TableScan:扫描整个表,这个操作将会逐行检查整个表,直到找到所匹配的记录行或者扫描完整个表。可以看出,这种查找记录的方式效率是最差的。

②IndexScan:根据索引,按照一定的算法从表中过滤出来一部分记录,在过滤出来的这一部分记录中进行查找所匹配的记录行,显然这种方式比第一种方式的查找范围要小,因此比TableScan的查找效率高。

③IndexSeek:根据索引,直接定位(获取)记录的存放位置,然后根据获取的记录的存放位置,直接取得记录,因此,比TableScan、IndexScan快。

④ClusteredIndexScan:与TableScan相似,这种方式也是要遍历整个表,但是它与TableScan不同的是数据表中的记录已经按照聚集索引来排列了,即记录实际就是按聚集索引的来顺序存放的。而TableScan扫描的表只是没有建立聚集索引,表中的记录没有按照一定的顺序存放,因此这两个操作本质上是一样的。

⑤ClusteredIndexSeek:这种方式是直接根据聚集索引获取记录,因为表中的记录已经按照聚集索引排列了,所以是最快的查询方法。

一个表是不是索引越多越好呢,当然不是。因为增加索引后,会增加维护该索引的时空开销,修改数据表时,必须要更新相应字段的索引。当一个表中的索引过多时,也严重会影响性能。一般会考虑在经常查询的列上建立相关索引并及时删除不需要的索引。

总之,索引使数据库引的查询操作执行的速度更快,它可以有针对性的数据检索,而不是简单地整个表扫描(FullTableScan)。在数据库中,为表添加必要的索引会提高查询的执行效率,但是过多的索引必然需要更新和维护索引表,这将会导致系统性能下降,所以必须控制索引的数量及时删除不必要的索引。

参考文献

[1]曹素丽,杨延广.ORACLE数据库索引的设计与维护研究[J].微型电脑应用,2012(11):29-31.

[2]马守东.关系数据库索引的研究和探索[J].信息与电脑(理论版),2011(10):159-160.

[3]张效尉,姜静.内存数据库技术研究[J].软件导刊,2011 (10):147-148

[4]涂刚,刘华清,傅伟.数据表结构的研究[J].天水师范学院学报,2009(5):86-88.

[5]岳国华.提高ORACLE8i数据库响应速度的若干技术对策[J].计算机应用与软件,2004(5):110-112.

数据库索引范文第3篇

关键词 银行业务;DB2;数据库索引;大型主机;数据库

中图分类号TP392 文献标识码A 文章编号 1674-6708(2011)50-0219-02

0 引言

数据库对于银行的业务来说无疑有着至关重要的作用,核心数据全部保存于数据库中。每天银行都有着成千上万笔交易,其中查询功能占据着业务的很大一部分比例。如何在现有的数据基础上大幅提升性能,如何提升效率从而降低企业成本,是每个银行需要面对的问题。本文从数据库索引的特征方面入手简单介绍一下在IBM大型机平台上的大型关系数据库db2索引的特征和简单用法。

1 大型关系数据库DB2简介

1970年IBM公司的研究员E.F.Codd 发表了业界第一篇关于关系数据库理论的论文"A Relational Model of Data for Large Shared Data Banks",首次提出了关系模型的概念。这篇论文是计算机科学史上最重要的论文之一,奠定了Codd博士"关系数据库之父"的地位,同时也为DB2数据库打下了坚实的理论基础。1983年,IBM推出了这款大型数据库软件, DATABASE 2(DB2)for MVS(内部代号为"Eagle")。

经历25年的发展,DB2现在除了应用于IBM的OS/390、z/OS大型机平台之外,还可以应用于中型机AS/400以及OS/2、windows2000等pc机上,平台具有非常好的伸缩性。DB2为用户提供数据可用性,完整性、安全性、可恢复性以及高效的执行能力,满足了各个层次用户的需要。本文接着就DB2的索引方面进行一下简单介绍。

2 DB2索引

DB2索引也是一种 DB2 对象(一个单独的 VSAM 数据集),它由一组排好序的键组成,这些键是从相应表中的一个列或多个列抽取出来的。

2.1 DB2索引类型

2.1.1非唯一索引

实际应用当中大部分的索引是非唯一索引。一般性的数据都具有可重复性特性,所以他们不能被定义为唯一索引。

2.1.2唯一索引

唯一索引用来保证数据的唯一性,唯一索引一般性能要高于非唯一索引,这与索引的稠密度有关。唯一索引的稠密度永远等于数据总条数的倒数。

2.1.3纯索引

纯索引的概念是相对与一般索引。如下方式表中有俩个字段,其中字段1是唯一主键,字段2为数据,实际的查询中经常是select * from 表 where col1=?这样的查询条件可以使用纯索引来避免表查询,具体创建命令为:CREATE UNIQUE INDEXON(COL1_NAME)INCLUDE(COL2_NAME)。上述的语句的意思就是在col1上创建唯一索引,选择包含col2的数据,这些附加的数据将与键存储到一起,但是不作为索引的一部分,所以不被排序。纯索引访问是用来减少对数据页的访问,因为所需要的数据已经显示在索引中了。

2.1.4群集索引

群集索引允许对数据页采用更线性的访问模式,允许更有效的预取,并且避免排序。群集索引是要求数据在插入时,做更多的操作,将相临的数据条目放入相同的页,使得查询速度更快,因为每次访问索引页要将所有的索引条目都访问完毕才移到下一页,保证了缓存池中任何一个时刻都只有一个索引页存在。

群集索引的特点:

1)高查询速度,数据页以键的顺序排列;

2)以键的顺序扫描整张表。

插入和更新需要做更多的事情,不建议经常插入和更新的表上做群集索引。

2.2 DB2索引结构

在DB2中,索引的物理结构是一个独立的VSAM数据集,逻辑结构是一颗B+树。B+树把它的存储块组织成一棵树。这棵树是平衡的,即从树根到树叶的所有路径都一样长。通常B+树有3层:根、中间层和叶,但也可以是任意多层。

典型的B+树结构:

根结点中至少有两个指针被使用。所有指针指向位于B+树下一层的存储块;

叶结点中,最后一个指针指向它右边的下一个叶结点存储块,即指向下一个键值大于它的块。在叶块的其他n个指针当中,至少有个指针被使用且指向数据记录;未使用的指针可看作空指针且不指向任何地方。如果第i个指数被使用,则指向具有第i个键值的记录;

在内层结点中,所有的n+1个指针都可以用来指向B+树中下一层的块。其中至少2个指针被实际使用(如果是根结点,则不管n多大都只要求至少两个指针被使用)。如果j个指针被使用,那该块中将有j-1个键,设为K1,K2……,Kj-1。第一个指针指向B+树的一部分,一些键值小于K1的记录可在这一部分找到。第二个指针指向B+树的另一部分,所有键值大小等于K1且小于K2的记录可在这一部分中。依此类推。最后,第j个指针指向B+树的又一部分,一些键值大于等于Kj-1的记录可以在这一部分中找到。注意:某些键值远小于K1或远大于Kj-1的记录可能根本无法通过该块到达,但可通过同一层的其他块到达。

假若我们以常规的画树方式来画B+树,任一给定结点的子结点按从左(第一个子结点)到右(最后一个子结点)的顺序排列。那么,我们在任何一个层次上从左到右来看B+树的结点,结点的键值将按非减的顺序出现。下图为B+树的一个简单实例。(图1)

2.3 DB2索引访问机制

快速索引式访问

一般来将DB2最快的数据访问方式就是使用索引。索引是为了快速找着数据块的数据结构。

在DB2使用索引来查询数据前,必须满足以下要求:

1)至少有一个SQL谓词必须是可索引的;

2)其中一列必须作为可用索引中的列而存在。

2.4 DB2索引创建原则

DB2索引的数据结构实现是一个B+树,通过索引可以实现快速查询,避免全表扫描以此来减少IO操作。

索引是对表数据的一种抽象,通过抽取有限数据,对数据的分布进行计算,以此来完成对数据的快速检索。

索引创建基本语句:

“CREATEINDEXON ()”。

创建索引需要注意的地方:

索引应该用来提高查询速度,但是会对更新和删除操作带来负面影响,因为要同步更新索引。所以索引应该创建到更新、删除相对比读取少的表上。

索引需要独立的空间进行存储和管理。索引是需要磁盘空间来存储。所以避免重复创建冗余索引。

索引用来避免表扫描。通过索引对大量数据抽取有限部分,形成一个相对少量的有序数据结构,通过对有序数据结构的查找可以快速想要查找的数据。所以索引适合建立在数据量比较大的表上,而且该表上的查询经常是根据条件查询部分数据。比如一些系统基础表,如SYSTEM表,这些表数据量小,而且经常是查询全部数据,所以这些表上建立索引对性能的影响不是很大,完全可以避免,以免对管理造成影响。

创建索引的目的还有一个就是保证数据唯一性。

主键会隐式创建索引,所以请不要在主键上创建索引浪费空间。

尽量减少索引的创建。DB2路径访问优化器会根据表中所提供的索引来完成尽可能多的访问路径的成本估计。创建过多的索引意味着DB2优化器生成更多的访问路径,完成更多的访问计划成本估算,这会增加SQL语句编译时间。

创建唯一索引可以避免排序。因为索引是有序数据结构,在进行扫描时,DB2会默认按照顺序输出结果,而不是按照插入先后。通过创建唯一索引可以避免排序,提高查询性能。

具有大量重复数据的列上不要创建索引。在大量重复的列上创建索引没有任何意义。

2.5 DB2索引优化

谓词类型 可索引 注释

Col∝con Y ∝代表>,>=,=,

但是是可能不可索引的。

Col between con1 and con2 Y 在匹配系列中必须是最后的。

Col in list Y 仅对一个匹配列

Col is null Y

Col like ‘xyz%’ Y 模糊匹配%在后面。

Col like ‘%xyz’ N 模糊匹配%在前面。

Col1∝Col2 N Col1和col2来自同一个表

Col∝Expression N 例如:c1(c1+1)/2

Pred1 and Pred2 Y Pred1和Pred2都是可索引的,

指相同索引的列

Pred1 or Pred2 N 除了(c1=a or c1=b)外,

他可以被认为是c1 in(a,b)

Not Pred1 N 或者任何的等价形式:

Not between,Not in,Not like等等。

参考文献

[1]牛新庄.DB2数据库性能调整和优化[M].清华大学出版社,2009.

[2]牛新庄.循序渐进DB2―DBA系统管理、运维与应用案例[M].清华大学出版社,2009.

[3]温涛,戴慰,等.DB2深度解析――高级DBA和开发者篇[M].东软电子出版社,2009.

数据库索引范文第4篇

关键词:B树结构;外存储原理;MySQL索引

中图分类号:TP311 文献标识码:A 文章编号:1009-3044(2014)34-8079-02

本文的内容结构如下所示:

第一部分主要从数据结构及算法理论层面讨论B-Tree。

第二部分结合外存储器的存储原理,讨论使用BTree作为索引的原因。

第三部分讨论MySQL数据库中InnoDB数据存储引擎中的索引――改进的B+Tree的结构,及其优点。

1 索引的数据结构及算法基础

数据库查询是数据库的最主要功能之一,提高数据查询速度是数据库索引的主要目标,通常,研究者通过优化检索算法来提高查询速度。查找算法有几类,一种是顺序查找,算法的复杂度为O(n),另外有二分查找、二叉树查找等。一般来说,一种查找算法对应一种数据结构,例如顺序查找对应连续的数据,二分查找对应排好序的数据,二叉树搜索对应二叉查找树。但是,这类数据结构还完全不能满足各种查找需求。比如,二分查找的条件要求将数据排序,但是数据库中不可能同时将两列都按顺序存储。所以,数据库系统必须维护满足特定查找算法的数据结构――索引,以实现更高级的查找算法。

当前,大部分数据库系统都采用BTree作为索引结构,其原因在于BTree的数据结构和主流外存储器的存储原理。下面先介绍B-树的基本结构。

B-树的基本属性:

1) 定义任意非叶子结点最多只有M个儿子;且M>2;

2) 根结点的儿子数为[2, M];

3) 除根结点以外的非叶子结点的儿子数为[M/2, M];

4) 每个结点存放至少M/2-1(取上整)和至多M-1个关键词;(至少2个关键词);

5) 非叶子结点的关键词个数=指向儿子的指针个数-1;

6) 非叶子结点的关键词:K[1], K[2], …, K[M-1];且K[i] < K[i+1];

7) 非叶子结点的指针:P[1], P[2], …, P[M];其中P[1]指向关键词小于K[1]的子树,P[M]指向关键词大于K[M-1]的子树,其它P[i]指向关键词属于(K[i-1], K[i])的子树;

8) 所有叶子结点位于同一层;

如图1所示,是B-树的基本结构。关于如何在一棵B-树中按照key的值去检索数据,描述如下:

1) 以根节点作为入口,对key集合作二分查找,如果找到目标key,则可以直接返回data数据。否则进入第二步。

2) 找到相应区间,根据区间的指针指向的point,得到对应的节点,执行1中过程。如此递归,直到找到目标节点,或者最终返回null point。

加速一个B-树的度为d,有N个key,现在为其建立索引,那么这棵B-树的高h最大为logd((N+1)/2),查找目标key,查找过程中需要遍历节点个数的复杂度为O(logdN),与二叉查找和顺序查找相比,B-树是一个效率很高的索引数据结构。

图1 B-Tree的结构

通常,数据库中数据都很多,导致建立的索引也很大,很难全部存储在内存中,因此,通常将索引保存在磁盘中。这样,在索引中查找时,就需要进行磁盘I/O,而与内存存取速度比较,磁盘I/O的速度要慢几个数量级。所以,通常我们将在查找过程中磁盘的操作次数作为我们评价一种数据结构是否适合作为索引的关键信息。那么,建立好的索引就是要尽量减少查找过程中磁盘I/O的次数。

了解磁盘的存取原理,对应理解使用B-树作为索引结构必不可少。

2 磁盘的存储原理

磁盘的内部结构如图2所示。

操作系统在读取磁盘数据时,将数据逻辑地址传给磁盘,磁盘会将操作系统传来的逻辑地址转换为物理地址以确定需要读取的数据的具置,即数据所在的磁道和扇区,那么,为了读取目标数据,磁盘需要将磁头移动到对应的那个扇区上,磁盘是通过横向移动磁头做到这点的。移动磁头的过程叫做寻道,而这个过程所耗费时间叫做寻道时间。然后磁盘需要通过旋转将目标扇区旋转到磁头下,这个过程所花费的时间叫做旋转时间。

图2 磁盘的内部构造图

磁盘的存储结构和寻址方式,导致了磁盘的存取速度比通常的主存储器慢几个数量级。磁盘在寻址过程中的需要的机械运动的时间,是导致磁盘在查找存储数据速度缓慢的主要原因。所以,如果想要提高数据库存储速度,减少磁盘IO次数是主要途径。其中一个可行的操作方案就是:每次寻址之后,预读一定的磁盘空间的内容。这样在读取相同大小空间的数据内容时,减少了机械寻址的时间,可以大大减少磁盘的存储速度。实际上,磁盘也正是这样做的。通常,磁盘在读取数据的时候,都会预取出一定长度的数据块,称为页。通常,页是4k大小。由前面对B树的介绍我们可以知道,进行一次检索需要访问h(B树的高度)个节点。那么,h的大小即是衡量一个索引好坏的标准。假设一个数据库表中需要保存N条信息,B树中每个节点保存d个key,那么由前文可知:h=logdN;d越大,h就越小。利用磁盘的预读机制,我们可以将一棵B的节点大小设定为一个页的大小,那么,在磁盘在预读的时候,取出的一个页都是有用key信息,这样大大提高了数据的存储效率,加快了检索的过程。

由以上内容可以判断,B-树非常适合作为索引结构,其查找效率是非常高的。

3 MySQL中的索引结构分析

B-树有多重改进版本,MySQL使用的B+树就是其中一种。

B+树的改进有以下两点:

1) 节点的指针数量可key数量一一对应。

2) 内节点不保存data,只保存key和指针;叶子节点只保存key和data,不存储指针。

MySQL中索引的结构如图3所示:

B+树的性能分析:

从B+树的性质我们可以知道,B+树的内节点不保存data值,只保存key和指针。那么,假设一个页的大小空间用于保存一个节点,这样在同一个节点中能够保存的key值比B-树结构会更多,即d更大。由h=logdN可知,h更小。所以B+树比B-树更适合作为索引结构。

由图3中可以看到,MySQL索引的结构,是一种改进的B+树,其每个叶子节点中都包含一个指向相邻叶子节点的指针。添加这个指针的目的是为了提高区间访问的性能。如图3所示,查询key为从18到49的所有数据记录,当找到18后,只需顺着节点和指针顺序遍历就可以一次性访问到所有数据节点,极大提到了区间查询效率。

4 总结

使用数据库索引是提高数据库查询速度的关键因素,合理利用索引,对于提高数据库性能有很大帮助。数据库的性能优化需要对数据库的索引内部结构及其原理有深入的了解。该文阐述了BTree索引的基本原理,并说明了MySQL数据库的索引实现,为索引调优和数据库性能优化提供了有效的帮助。

参考文献:

[1] D Comer.Ubiquitous B-tree; ACM Computing Surveys (CSUR), 1979.

[2] Codd E F.A relational model of data for large shared data banks L[M].Communications of the ACM, 1970,13(6):377-387.

[3] Baron Scbwartz.高性能MySQL[M].王小东,译.北京:电子工业出版社,2010.

数据库索引范文第5篇

关键词:移动对象;移动对象索引;无限制空间;网络空间;R树

中图分类号: TP311.132

文献标志码:A

Access methods in moving objects databases

XIAO Hui1,2, LI Qing-quan1

(

1. Transportation Research Center, Wuhan University, Wuhan Hubei 430079, China;

2. School of Remote Sensing and Information Engineering, Wuhan University, Wuhan Hubei 430079, China

)

Abstract:

In the paper, the access methods of moving objects are summarized. Firstly, we classify moving objects indexing based on their underlying structure: moving objects indexing in unconstrained space and moving objects indexing in network space. And then, the analysis of indexing for the past, now and the future location is presented. Finally, we discuss the future research direction of moving objects indexing.

In the paper, the access methods of moving objects were summarized. Firstly, the moving objects indexing was classified according to the underlying structure: moving objects indexing in unconstrained space and moving objects indexing in network space. And then, the analysis of indexing for the past, now and the future location was presented. Finally,the future research direction of moving objects indexing was discussed.

Key words:

moving object; moving objects index; unconstrained space; network space; R-tree

0 引言

近年来,移动对象的管理逐渐成为研究的热点。越来越多的与位置相关的应用需要处理位置随时间变化的空间对象,例如出租车、飞机、油罐车、犯罪分子和野生动物等。这些应用服务的主要目的是有效地存储并查询连续运动的移动对象,这就需要一个良好的索引结构。

根据移动对象的特点,移动对象m是一个空间位置随着时间不断变化的对象,可表示为一系列的三元组m(id,siti), id是移动对象的标识符,si表示移动对象的位置,ti是表示时间戳。因此,一个随着时间变化位置的点对象可以表示为三维时空中的线段集。由于移动对象时空数据的特性,移动对象索引应该考虑当前时空数据以及历史轨迹数据的处理,具体说来,就是在索引树结构中插入及分裂操作,压缩及删除操作。移动对象索引是一个动态树,需要不断地插入移动对象当前的时空信息,插入与分裂操作算法的优劣直接影响着索引的性能。同时随着时间的进步,会产生大量过时的数据,并占用大量的空间,这些数据需要采用压缩与删除操作,以减少数据存储空间的占用,这也是索引结构所需要考虑的操作。

时空数据库中,数据具有时间与空间双重变化的属性,数据结构相当复杂,并具有海量的时空数据,位置服务应用也要求能实时响应,所以时空数据的索引结构更为重要。根据移动对象的运动空间,可将移动对象分为无限制空间的移动对象和网络空间的移动对象两类。据此,本文分别讨论了两种空间下移动对象索引发展情况。移动对象索引不仅要考虑索引空间还要考虑索引时间,为了支持对移动对象的查询,必须对移动对象的不同时态进行索引,包括移动对象的完整历史轨迹索引、移动对象的当前及未来位置的索引。

1 无限制空间内移动对象索引

1.1 当前及未来位置索引

为了预测移动对象未来位置,需要存储运动附加信息(例如,速度和目标位置)。在D 维空间中,通过一个参考位置,一个移动对象的运动可以建模为x┆ref=(x1,x2,…,xd),其中参照时间是t┆ref=0,速度向量是v=(v1,v2,…,vd)。那么,在t>t┆ref的任意时刻,移动对象预测位置xt=x┆ref+v(t-t┆ref)。简而言之,可以假设对象在一维空间中运动。对象运动可以用线性方程表示xt=at+b,a和b是常量。这里a是移动对象常量速度,b是移动对象起始位置。另外,可以把时刻t┆ref=0位置作为参考位置。当前及未来位置索引方法主要可以分为三类,原时空索引方法、空间转换索引方法、参数化时空索引方法;其中参数化时空索引方法是对当前及未来位置索引比较有效的方法。

1.1.1 原时空存取方法

索引移动对象的PMR-quadtree[1]方法利用了PMR-quadtree作为底层结构来索引移动对象未来轨迹。主要问题是当对象更新时,整个索引就被破坏掉,然后需要根据给定新位置信息重新构建索引。为了避免过量更新操作,索引在每ИΔt时间后重构。在抽象层次上,有限的时间维被分割为等大小的时间片,每个时间片对应一个Δt。对于每个时间片Δt,Ц据运动方程建立一个PMR-quadtree。然而,由于存储有限,只存储了当前的PMR-quadtree。这种方法的缺点是:1)因为通过MBR表示轨迹,所以产生了大量的死空间;2)由于所有轨迹有相同的时间值,所以数据是分散的。

1.1.2 空间转换方法

为了克服这些缺点,提出了将时间空间域转换到另一个空间的方法。主要思想是在新的空间中,容易表示和查询数据。

文献[2]中采用对偶变换(Duality Transformation,DT)将时空域中的线段(移动对象轨迹)变换为二维空间中的一个点来进行索引,即把原始空间时态域中的线性运动方程x=at+b表示为二维变换空间中的一个点(a,b),其中速度大小a表示水平轴方向,参考位置b表示垂直轴方向。由于二元变换空间中数据分布的不均匀性,二元变换空间点使用kd树来进行索引。相应地,原始空间时态域中的窗口查询则被映射为二元空间的多边形区域查询。

动态数据结构对偶变换[3]是对偶变换的另一种形式。二维空间(x,y)中的移动对象加入时间维表示为(x,y,t),轨迹分别可以投影到(x,t), (y,t)平面。对偶转换分别在这两个平面上进行。范围查询的结果是这两个平面上范围查询结果的综合。这个方法没有使用类kd树的结构,而是使用了运动数据结构索引对偶空间。

┑4期 ┬り偷:移动对象数据库索引研究综述

┆扑慊应用 ┑30卷

SV模型[4]采用了更激进的方法,它将移动对象建模为四元组(s,e,ts,v0),而不是轨迹。4个参数分别表示起始位置s,目的地e,开始时间ts和初始速度v0,在二元空间中使用起始时间t和移动对象目的位置e分别作为水平轴和垂直轴。同样原始空间时态域中窗口查询则被转换为二元空间中多边形查询,并使用SS树来进行索引。由于SV模型限定速度为常量,在公路交通控制系统、飞机调度中有较好的应用。

PSI[5]称为参数空间索引技术。利用R树索引2d+1维空间,d维对应于参考位置x┆ref,并且d维对应速度,而1维对应时间维v。对象运动被建模为一个在2d+1维中被MBR包含的轨迹。主要的思想是时间范围[ts,te],在这个范围内,对象运动时有效的,被存储在索引中。同时,没有全局时间参照的概念。

对偶转换方法的缺点是:1)二维空间不能捕捉原始空间中的所有信息;2)不能保证在原始空间中彼此接近的对象在二维空间中仍然彼此接近;3)在原始空间的矩形范围查询总是被转化为二维空间多边形范围查询,导致算法非常复杂。

1.1.3 参数化时空存取方法

鉴于对偶转换的缺点,利用参数矩形索引原始时空数据的索引方法逐渐为大家认可。主要思想是构造时间的边界矩形框函数,并将覆盖的移动对象保存在相同的矩形框内。在这种情况下,可以查询任何时刻的对象。

TPR树[6]是建立在R树上的一种结构,定义了时参范围框形,能在时间上持续地跟随其包围的移动对象移动。在构建时刻,TPR树建立一个保守的时参范围矩形框,来覆盖一个移动对象集合。时参范围矩形框的下界根据所覆盖对象的最小速度设置,而上界根据所覆盖对象的最大速度设置。因此,保守矩形框的边界不会收缩,只会扩大,这样可以保证总是覆盖移动对象。为了避免边界矩形框变得很大的情况,当更新对象位置时,所在路径的边界框都要重新计算。移动对象的运动利用线性函数表示,当线性函数参数变化时,则更新索引。

PR树[7]与TPR树类似,但PR树考虑了移动对象的运动空间范围,利用参数矩形表示移动对象运动的空间范围。每个参数矩形有一个时间间隔特征,时间间隔表示移动的开始时间与结束时间。TPR树中,移动对象被认为是不停运动的,PR树考虑了移动对象的结束时间。因此,移动对象是被表示为多边形而不是一条轨迹。在移动结束时刻,移动对象的边界矩形可以通过移动对象的凸包计算得到。

VCIR树[8]的主要思想是为R树中的节点增加一个v┆max的属性,v┆max存储这个节点包括的所有对象的最大允许速度。对于时间t上的查询,所有的边界矩形是利用v┆maxЮ沟摹N南[8]认为用散列的方法管理移动对象,随着时间的推移必会带来过多的溢出页面,因此建议使用查询索引(Query Indexing,QI)和速度约束索引(Velocity-Constrained Indexing,VCI)来管理移动数据。与TPR树类似,它们都随着时间变化扩展边界矩形从而尽可能地包含移动对象,但其基础模型是不同的。VCI索引中,并不需要知道每一个移动对象的精确速度,它仅仅限定了一个最大的速度,所有移动对象速度不能超过这个速度值。TPR树中,必须知道每一个移动对象的速度。VCI索引是特别针对连续查询的共享执行处理提出的。

REXP树[9]是TPR树的扩展,它给移动对象赋予了失效时间的概念,主要想法是避免对移动对象长期的不更新。为了利用失效时间信息,REXP树使用了一种新的边界区域。在边界区域被重新计算之前,REXP树从索引中移除失效的节点。

TPR*树[10]利用了与TPR树相同的结构和假设。TPR树利用了与R*树相同的插入和删除函数,而TPR*树提出了一种新的插入和删除算法,并满足最小代价函数。

1.2 历史轨迹索引

历史轨迹随着时间的增长而增加,移动对象持续地发送位置信息,若要保存移动对象每个时刻的位置几乎是不可能的。把对移动对象轨迹的索引方法分为三类,第一类方法是扩展现有的空间索引方法,将时间维简单地视为空间维的扩展;第二类方法是区别空间与时间数据,并考虑时间维单调递增的特性,而不是简单地将时间维视为空间的另一维;第三类方法是首先索引轨迹数据的时间维,然后索引空间维,这是从结构上解决轨迹索引的有效方法。

下面介绍各种索引方法。

1.2.1 空间索引扩展方法

这类索引主要关注空间域的处理,时态域作为辅助对象处理。

RT树[11]是结合空间索引方法R树[12]和时态索引方法TSB树[13]而产生的。RT树是在R树中加入了一个新的数据项来表示当前对象的开始时间和结束时间。一个RT树记录的形式为(id,MBR,ts,te),其中id是对象的标识,MBR是对象的最小外接矩形,ts,te是对象有效的时间间隔。在空间查询方面,RT树的效率与R树相同,但是,在进行时间片查询或者时间段查询时,通常要遍历整棵树。

3D R树 [14]是2D R树在时空中的自然扩展,它把时间维看作时空对象另一个空间维度,主要思想是避免区分空间查询和时间查询。3D R树适于位置与范围随时间变化较小的时空对象,它的优点是实现简单,支持时间和空间查询。缺点是对于生命期较长或者位置变化较大的对象,三维MBR也过大,导致大量重叠,降低索引效率;另外,时间片查询不再依赖于查询时间上的单元,而是依赖于历史数据中的所有单元。

STR树[15]是R树的扩展。它以最小包围盒(Minimum Bounding Box,MBB)组织移动轨迹中的每一个线段,叶节点的形式为(id,tid,MBR,o),其中id是轨迹标识,o是轨迹在MBR中的方向。STR树的主要思想是保证空间的紧凑以及保留轨迹信息,同一轨迹的线段在R树中尽量保持邻近。参数p表示保存轨迹所需的层次数目,用来平衡空间相邻属性与轨迹保存之间的关系。当插入一条新线段时,在R树中要尽量让这条线段在层次p内保持与它的前一条线段的相邻。pг叫蛟嚼于保持轨迹线段的相邻性,但越不利于轨迹的保存。STR树采用了不同于R树的插入/分裂算法,传统R树在插入时遵循的是空间上的最小扩张原则,而STR树不仅要考虑空间上的邻近关系,而且要考虑部分轨迹保持,也就是说尽量使插入的线段与同一轨迹在一起。其分裂算法也是从部分轨迹保持目的出发,使得操作后的索引结构仍然保持较高的效率。

1.2.2 重叠及多版本结构

这类索引把时间维与空间维独立表示,每个时刻的空间数据对应一个索引结构(例如R树),整个轨迹将是由若干个时刻对应的独立索引结构(例如R树)组成。这种方法的缺点是存储空间的开销非常大。

MR树[11]在R树中利用了重叠B树的思想。主要思想是避免R树在每个时间戳分开存储带来的巨大存储量,通过在连续的R树中消除对象的冗余存储来节省存储空间,不同的父节点指向在不同时间戳下保持不变的同一个节点。在时间片查询中,这种方法堪称完美,查找总是直接指向对应时间片的根节点,然后在对应的R树上进行空间查询即可。然而,对于时间窗口查询,这种方法是低效的。

HR树[16]称作历史R树,非常类似于MR树。HR树有具体的算法并给出了在R树上重叠B树的执行细节。在四叉树利用了重叠树的思想,产生了重叠四叉树。

HR+树[17]是为了避免HR树中中间节点的重复问题。HR树中存在中间节点的重复问题是由于任意节点容纳属于同一根节点的唯一记录,同一根节点的R树属于同一时间戳。HR+树放松了这个条件,它允许不同时间戳的中间节点指向同一叶节点。然而,每棵R树中这个叶节点的父节点具有唯一的权限存取与它同一时间戳的叶节点数据部分。换句话说,叶节点可以有多个父节点,但每个父节点只有权存取它对应的部分。

MV3R树[18]主要是基于多版本B树的思想。主要方法是建立两棵树,一个MVR树用来处理时间戳查询,一个3D R树用来处理长时间间隔查询。短时间间隔查询根据阈值来判断由哪棵树进行处理。它结合了多版本R树对时刻查询的有效性和三维R树对长时段查询的有效性,同时又克服了两者的缺点。

PPR树中的贪婪算法[19]扩展了PPR树,以便支持时空应用,PPR树是主要用于双时态数据库的索引结构。将PPR树直接用于时空引用,这将导致产生大量死空间,为了解决这个问题,使用了人工目标更新的方法。最优贪婪算法用于为线性移动对象的人工更新找到最优位置。在文献[20]中利用了多项式函数来支持目标的移动。

1.2.3 面向轨迹存取方法

这类索引主要考虑面向轨迹查询,但也支持空间查询以及空间聚集查询。

TB树[15]称作轨迹束索引,它保存了轨迹,是类R树的结构,每个叶节点仅包含属于同一轨迹的线段,它是第一个支持轨迹查询的索引结构。它与其他R树变体的区别在于TB树的插入算法不依赖移动对象的时空关系而是依赖移动对象标识ID。这种方法的缺点是空间上邻近的不同轨迹的线段被存储在不同的节点中。TB树的增长是自左向右的。最左边的叶节点是最早插入的节点,最右的叶节点是最后插入的。TB树是仅处理轨迹的STR树 的扩展。

SETI[21]索引方法将静态的空间区域进行非重叠的分区,这种想法主要是考虑到相对于时间维的持续连续变化可以认为空间维是几乎静态的,另外,它使用六边形替代传统的矩形作为索引目标的外接框,并对空间进行分区。在每一个分区内,使用R树索引轨迹段。分区函数尽量将同一轨迹的线段存储在同一分区内,轨迹的存储主要考虑最小化R树中空间维度的影响。穿过两个空间分区的轨迹段将被截断,并且在两个分区都存储轨迹段的信息,但缺点是导致查询结果的重复。

SEB树[22]即起止时间戳B树(The Start/End timestamp B-tree),与SETI的思想类似。空间分区为若干可重叠的区域,这些区域利用SEB树索引,SEB树只考虑移动对象在区域内的开始与结束时刻,移动对象散列在区域中。与SETI的区别在于,SEB树中并不直接索引轨迹,而是索引二维点。在空间分区过程中,具有相似轨迹的点尽量保持在一起。

PA树[23]中作者认为最小外接矩形不能表示轨迹的平滑,应该将轨迹近似地表达为一系列连续地多项式运动函数,并提出了PA树。PA树是一个参数式索引,它索引表达轨迹的多项式。PA树与R树类似,它们的区别在于R树结构中的最小外接矩形在PA树中用多项式系数表示。

2 网络空间内移动对象索引

在现实世界中,大多数的移动对象其实都不是无限制的,它们往往是被限制在网络中,例如汽车总是在道路网络中运行。网络空间中移动对象的表达也更为简洁,不需用二维地理坐标,可以利用网络中的线性参考位置表示移动对象的位置。这种简洁的表达方式也有助于提高了移动对象索引的效率。下面介绍几种重要的网络空间内移动对象索引方法。

FNR树[24]是道路网络中移动对象索引方法。FNR树是移动对象历史轨迹的索引,它是一个混合树结构,由一个二维R树与一维R树组成。二维R树索引道路网络的每一个路段,每一个叶节点中包含指向一维R树的指针。一维R树索引在某个时间间隔内与路段对应的动态移动对象。这种方法的缺点在于选用了道路每个交叉点之间的路段作为索引基本元素,这样R树中就产生了庞大的叶节点以及对应的巨大更新。这种方法的主要缺点是使用的以道路路段为索引元素的道路网络模型,这种模型导致了索引树结构中大量节点的产生,以及移动对象在路段变更时产生的大量更新。

文献[25]把道路网络与轨迹从复杂的三维空间转换为两个低维子空间,在低维子空间索引移动对象轨迹,移动对象与道路网络分别用两棵二维R树索引,道路网络索引的基本元素也是路段。与FNR树相比,它们的移动对象索引方式不同。利用Hilbert曲线将二维移动空间映射到一维线性空间,道路网络的路段,以及移动对象的位置都映射到一维线性空间中。由于移动对象的索引也采用了二维R树,所以在查询处理时,相比FNR树对移动对象的索引更复杂些。但这种方法对移动对象的运动表达较为合理,移动对象在路段中的表达可以任意改变运动方向与速度,而FNR树不能做到这点。

MON树[26]存储了道路网络中移动对象的整个历史轨迹,并可对过去时态进行查询。使用路径作为索引的基本元素,路径由同名道路构成,将道路网络的道路表示为多段线,由于道路表达上的区别,MON树对移动对象轨迹的表达比FNR树更为简洁,同时索引效率有所提高,但由于路径过长,容易产生较大的死空间,影响查询效率。MON树支持窗口查询以及范围查询,但不能对与网络拓扑有关的查询提供支持,例如最近邻查询。

AU[27]方法是一种动态数据结构在分组网络中具有相似运动特征的移动对象,道路网络利用R树进行索引并构建在AU之上,从而形成道路网络上移动对象的索引结构。主要目的在于通过AU分组提高单个移动对象更新的效率。它是针对移动对象当前及未来位置的索引方法。

3 结语

综上所述,移动对象数据库系统往往具有海量数据以及复杂的时空运行特征,对于移动对象索引缺乏公认有效的,且能满足各种实际查询需求的方法。目前人们对移动对象索引研究取得了一定的成果,但尚有很多问题亟待解决,移动对象索引的发展方向如下所示。

1)网络空间内的移动对象索引方法将三维时空索引的问题转换为两个低维空间索引的问题,即分别索引网络数据及移动对象。通过从高维到低维的转换,可以将移动对象索引的问题转换两个简单的低维空间索引问题,低维空间索引结构也远没有三维时空的索引结构复杂,这是解决移动对象索引的一个有效思路,但如何有效地将移动对象索引从高维空间分解到低维空间,这是目前亟待解决的问题。

2)索引的目标主要是为了高效的查询处理,而在时空应用中,时空查询种类繁多,则索引支持的查询越多,这样的索引应用就越广泛。选择性查询、最近邻查询、持续查询和连接查询等是时空查询中常见的查询要求,但现在大多数的索引结构仅支持选择性查询,对于最近邻查询,索引通常需要考虑道路网络的拓扑性,现今的绝大多数索引结构都没有考虑道路的拓扑连接特征,索引结构中如何高效地索引道路以及道路网络的拓扑连接性,以便支持最近邻查询,也是目前的研究方向之一。持续查询是比较复杂且实时的查询要求,如何在海量的移动数据中保持持续查询结果的实时性以及准确性,这对索引结构也提出了较高的要求。

3)移动对象的位置是连续变化的,也导致了索引的更新是一个巨大的难题。若显式地对移动对象的位置变化进行更新,则造成系统效率低下,若存储移动对象过期的位置,则不能满足位置服务的需要。为了保持索引的实时性与正确性,通常利用时态函数表示移动对象的变化,当参数(例如速度、方向等)变化时,才进行必要的更新。当前的方法对移动对象的位置变化主要是线性近似,现实世界中,车辆的运行轨迹往往是非线性的,如果高效、正确地索引这种非线性的位置变化,是可能的研究方向。移动对象未来位置的预测精准性也极大地影响更新的效率,结合交通具体情况,提出更精确的预测模型以及索引结构,也是目前的研究方向。

4)MBR(最小外接矩形)作为对近似索引目标的技术,在空间及时空索引中被广泛的应用,例如R树、TRP树,具有计算简单,容易理解的优点,但对索引目标的近似比较粗糙,容易产生死空间。移动对象索引中,为了缓解这个问题,发展了六边形、八角形、多项式表达等技术来近似索引目标,以便更平滑地表示移动对象轨迹,提高索引的命中率。但这些方法也存在结构复杂、函数组成较多等问题,提出一个计算简单,近似精确的方法,仍然有待研究。

参考文献:

[1]TAYEB J, ULUSOY O, WOLFSON O. A quadtree-based dynamic attribute indexing method[J]. The Computer Journal, 1998,41(3): 185-200.

[2]KOLLIOS G, GUNOPULOS D, TSOTRAS V J. On indexing mobile objects[C]// Proceedings of the ighteenth ACM SIGMOD-SIGACT-SIGART Symposium on Principles of Database Systems. Philadelphia, Pennsylvania: ACM Press, 1999: 261-272.

[3]AGARWAL P K, ARGE L, ERICKSON J. Indexing moving points [J]. Journal of Computer and System Sciences, 2003, 66(1): 207-243.

[4]CHON H D, AGRAWAL D, ABBADI A E. Storage and retrieval of moving objects[C]// Proceedings of the Second International Conference on Mobile Data Management, LNCS 1987. London:Springer-Verlag , 2001:173-184.

[5]PORKAEW K, LAZARIDIS I, MEHROTRA S. Querying mobile objects in spatio-temporal databases[C]// The 7th International Symposium on Advances in Spatial and Temporal Databases. Redondo Beach: Springer Berlin, 2001: 59-78.

[6]SALTENIS S. Indexing the positions of continuously moving objects[C]// International Conference on Management of Data Proceedings of the 2000 ACM SIGMOD International Conference on Management of Data. Dallas: ACM Press, 2000: 331-342.

[7]CAI M. REVESZ P. Parametric R-tree: An index structure for moving objects [C]// The 10th International Conference on Management of Data. Pune: ACM Press, 2000: 234-243.

[8]PRABHAKAR S. Query indexing and velocity constrained indexing: Scalable techniques for continuous queries on moving objects [J]. IEEE Transactions on Computers, 2002, 51(10): 1124-1140.

[9]SALTENIS S, JENSEN C S. Indexing of moving objects for location-based services [C]// Proceedings of the 18th International Conference on Data Engineering. San Jose: IEEE Computer Society, 2002:463-472.

[10]TAO Y, PAPADIAS D, SUN J. The TPR*-tree: An optimized spatio-temporal access method for predictive queries [C]// Proceedings of 29th International Conference on Very Large Data Bases. Berlin: Morgan Kaufmann, 2003: 790-801.

[11]XU X, HAN J, LU W. RT-tree: An improved R-tree index structure for spatiotemporal databases [C]// Proceedings of the 4th International Symposium on Spatial Data Handling. Zurich: Springer, 1990: 1040-1049

[12]GUTTMAN A. R-trees: A dynamic index structure for spatial searching[C]// Proceedings of the 1985 ACM SIGMOD International Conference on Management of Data. Boston: ACM Press, 1984: 47-57.

[13]LOMET D, SALZBERG B. Access methods for multiversion data [C]// Proceedings of the 1989 ACM SIGMOD International Conference on Management of Data. Portland: ACM Press, 1989: 315-324.

[14]THEODERIDIS Y, VAZIRGIANNIS M, SELLIS T. Spatio-temporal indexing for large multimedia applications [C]// Proceedings of the 1996 IEEE International Conference on Multimedia Computing and Systems. Hiroshima: IEEE CS, 1996: 441-448.

[15]PFOSER D, JENSEN C S, THEODORIDIS Y. Novel approaches in query processing for moving object trajectories [C]// Proceedings of 26th International Conference on Very Large Data Bases. Cairo: Morgan Kaufmann, 2000: 395-406.

[16]

NASCIMENTO M A, SILVA J R O. Towards historical R-trees [C]// Proceedings of the 1998 ACM symposium on Applied Computing. Atlanta: ACM Press, 1998: 235-240.

[17]TAO Y, PAPADIAS D. Efficient historical R-trees [C]// Proceedings of the 13th International Conference on Scientific and Statistical Database Management. Fairfax: IEEE Computer Society, 2001: 223-232.

[18]TAO Y, PAPADIAS D. MV3R-tree: A spatio-temporal access method for timestamp and interval queries [C] // Proceedings of 26th International Conference on Very Large Data Bases. Roma: Morgan Kaufmann, 2001: 431-440.

[19]KOLLIOS G. Indexing animated objects using spatiotemporal access methods[J]. IEEE Transactions on Knowledge and Data Engineering, 2001,13(5): 758-777.

[20]HADJIELEFTHERIOU M. Efficient indexing of spatiotemporal objects [C]// Proceedings of the 8th International Conference on Extending Database Technology. Prague: Springer, 2002:251-268.

[21]CHAKKA V P, EVERSPAUGH A C, PATEL J M. Indexing large trajectory data sets with SETI [C]// First Biennial Conference on Innovative Data Systems Research. Asilomar: Online Proceedings, 2003:450-460.

[22]SONG Z, ROUSSOPOULOS N. SEB-tree: An approach to index continuously moving objects [C]// The 4th International Conference on Mobile Data Management. Melbourne: Springer,2003:340-344.

[23]NI J, RAVISHANKAR C. Indexing spatio-temporal trajectories with efficient polynomial approximations [J]. IEEE Transactions on Knowledge and Data Engineering, 2007,19(5):1-16.

[24]FRENTZOS E. Indexing objects moving on fixed networks [C]// Proceedings of the 8th International Symposium on Advances in Spatial and Temporal Databases. Santorini Island:Springer,2003:289-305.

[25]PFOSER D, JENSEN C S. Indexing of network constrained moving objects [C]// Proceedings of the 11th ACM International Symposium on Advances in Geographic Information Systems. New Orleans: ACM Press,2003:25-32.

[26]de ALMEIDA V T, GüTING R H. Indexing the trajectories of moving objects in networks[J]. GeoInformatica, 2005,9(1):33-60.

数据库索引范文第6篇

【关键词】空间数据库;索引技术;Web技术;高维空间

随着空间数据应用的增加,存储空间开销的加大以及索引空间重叠的剧增,空间数据库的索引性能下降。为提高空间查询的效率,空间数据库索引技术应运而生。下面我们将从四个方面来对空间数据库索引技术进行探讨。

1.高维空间索引技术

随着三维地理信息系统、多媒体数据库及时空数据库的研究和发展,对多维空间目标的搜索及更新功能的要求越来越迫切。而目前常用的空间索引技术,主要是针对一维或二维空间中的空间数据。将这些索引技术运用于三维或更高维空间数据时,其查询效率将大大降低,有时索引机制甚至不起到作用。因此,如何索引这些高维数据是一个很大的挑战,有必要研究新的可扩展的高维索引技术,使之不但能有效地检索一维或二维空间数据,而且能有效地检索高维的空间数据。

高维空间数据索引的一种实现方法是降维,然后再降维后的子空间里运用一维或多维空间索引技术。其降维的方法包括空间填充曲线、奇异值分解、距离映射算法等。由于高维空间数据索引结构的复杂性,高维空间数据索引技术的研究仍然存在很多问题有待于进一步探讨。

2.基于空间关系的索引技术

基于空间关系的数据索引技术在空间数据库中占有十分重要的地位。这是因为,空间数据库涉及对现实世界大量具有不规则几何形状空间目标的处理,这些目标之间存在着复杂的空间关系。很多查询和分析操作都是基于目标间空间关系的。只有在相应的空间数据结构基础上,依据目标间的空间关系建立良好的索引机制,才有可能有效地提高对空间数据的处理效率,尤其是空间查询的效率。否则,查询某个空间目标时,必须将该目标的特征值与空间数据库中存储的所有目标进行一一比较,以最终确定要查找的目标,这显然是令人难以容忍的。由此可见,基于空间关系的空间索引技术研究具有十分重要的意义。

目前的空间索引技术都有其固定的优势和不足,其共同特点是基于空间目标的空间位置来建立相应的索引结构,其主要目的是提高空间数据库系统中区域查询效率。然而目前的空间索引技术难以根据目标之间的空间关系来建立有效的检索机制,从而极大地影响了系统的功能和效率。若能根据空间目标之间的某些空间关系来动态地相应的索引机制,使之能够依据目标间的空间关系,快捷地查找到相关的目标,这必将极大地提高空间查询和空间分析的效率,从而有效地扩充空间数据库系统的数据组织、数据分析和数据维护功能。

3.基于Web技术的空间索引技术

与传统的空间数据库相比,基于Web的空间数据库在体系结构上有了根本的转变,它主要包括以下几部分:(1)基于Internet/Ineranet环境,采用了TCP/IP通信协议,大大扩展了空间信息共享范围。(2)在应用层采用了HTTP协议,客户端只需要有通用的浏览器即可,不需要有特殊的软件,大大增强了系统的性能。(3)应用的分布性。可以根据网络带宽、计算机性能等一系列资源状况,将应用按照功能分布到不同的结点上,如分布到多台服务器上或是将一部分简单应用分布到客户机上,复杂的应用仍交给服务器执行,这样可以大大提高系统的性能。(4)空间数据的分布性。空间数据可以根据其本身具备的空间特征存储在最适宜的位置上,从而大大简化了对空间数据的管理。

基于Web的空间数据库为信息的高度共享提供了可能,它改变了以往数据信息传输、、共享及应用的过程和方式,是空间信息系统发展的必然趋势。基于Web的空间数据库目前还处在发展阶段,还存在着许多关键问题尚未突破,空间数据的存储、检索及相关索引技术结构的建立即为其中等待解决的难题之一。

4.基于空间数据仓库的索引技术

随着信息技术的飞速发展和空间数据库业界对海量空间数据存储、管理、分析和交换的需求,以面向事务处理为主的空间数据库系统已不能满足需要,空间信息系统开始从管理转向决策处理,空间数据仓库就是为满足这种新的需求而提出的空间信息集成方案,它与传统空间数据库的主要差别为面向主题的数据组织和管理、数据的集成、数据的维护与管理及空间数据的时空序列变化这四个方面。

空间数据仓库是对空间数据进行管理的数据仓库,它将各种空间数据集成在一起提供给用户。由于空间数据本身具有的特点,空间数据仓库具有许多更加复杂的特性与关键技术,如空间数据仓库内数据的组织与显示,空间数据变换,客户端数据分析等,空间数据的高效存储和数据索引技术也是空间数据仓库的关键技术之一。空间数据库为了支持高层次的决策分析需要大量的数据。这些数据可能分布在不同的已有应用中,存储在不同的平台和数据库中。空间数据仓库则根据主题通过专业模型对不同源数据库中的原始业务数据进行抽取和聚集,形成一个多维视角,从而为用户提供一个综合的、面向分析的决策支持环境。这一过程的完成需要一套高效存储和数据索引技术作为保证才能完成。随着空间数据仓库研究的不断发展,基于数据仓库的空间数据索引技术也将得到不断的完善和发展。

5.结束语

空间数据索引是提高空间数据查询最有效的方法,也最难全面掌握的技术,因为正确的索引机制可能使查询效率提高一万倍,而无效的索引可能会浪费了数据库空间,甚至大大降低查询性能。采用不依赖于商用数据库空间扩展技术的空间数据引擎,具有良好的空间存储和访问效率,移植性好,灵活性高,更易于提高和完善,对于应用模型的设计也更为有利。缺点是实现难度大,且不支持扩展SQL查询,数据维护复杂。商用空间数据库的空间扩展最大的优点在于对象级的数据存储机制和支持扩展SQL的查询。采用数据库厂商提供的抽象数据类型存储空间数据,使得数据共享和互操作更有潜力。目前的各种商用空间数据库引擎或空间扩展技术有待于进一步研究。

参考文献:

[1]谈国新.一体化空间数据结构及其索引机制研究.测绘学报,1998,27(4):293299

[2]孙小燕,谭勇桂.空间索引技术―回顾与展望.计算机工程与应用.2002,24:197200

作者简介:

数据库索引范文第7篇

关键词 Native XML数据库 KeyX索引 ISP原理

中图分类号:TP311.131 文献标识码:A

Optimization of the XML Database Based on Index

TU Haiyan, ZOU Yunsong, LAI Xiang

(Military and Economics College, Wuhan, Hubei 430035)

Abstract Based on the characteristics of Native XML Database, an adaptive optimal indexing methods, the method according to the characteristics of XML data files, combined with the the ISP principle of automatic optimization KeyX index. The experimental results show that it can effectively real-time optimization of the index, to ensure that the XML database continued efficient operation.

Key words Native XML database; KeyX index; ISP principle

0 引言

Native XML数据库(Native Xml Database)是为XML数据量身定做的数据库,能在XML数据爆炸式增长时,对数据有效存储、查询和管理。Native XML数据库充分考虑到XML数据的特点,以一种自然的方式来处理XML数据,能够从各个方面很好的支持XML的存储和查询。它是现在唯一的纯XML数据库,应用十分广泛。

当XML数据比较庞大时,查询变得相当耗时,因此使用索引来加速查询十分必要。一般的Native XML数据库主要使用值索引、节点名索引、边或路径索引,其中值索引应用最为广泛。本文使用的KeyX索引是最新提出的值索引类型,它能提供通配符、多路径、范围查找等其它值索引类型所不具备的功能,该索引已开始逐步引入实际应用,并在不断地完善之中。通常情况下,数据库的索引是在开发阶段设计完成的,不能满足此后数据库的扩展需求,在XML数据库中尤为突出,所以对索引进行优化是非常有必要的。本文使用ISP(Index Selection Problem)原理对索引进行实时自动优化,保证XML数据库持续高效运行。

1 Native Xml数据库索引KeyX

KeyX是一种为Native XML 数据库量身订做的XML索引结构,KeyX还能够提供通配符、多路径、范围查找等其它值索引结构所不具备的功能。对一组频繁使用的查询表达式,从其查询的原XML数据中提取相关关键词,并将其存储在一个经过优化的搜索结构中,以便于以后能对关键词进行高效的检索,这些搜索结构包括哈希表、Tries、B+Tree等。

创建索引的过程如下。XPath表达式: = // [ = ],将所有author的内容与对比,并将所有在路径///中的author元素作为关键词从XML数据中提取出来。每一个关键词都和XML数据中的一个或多个节点(元素或属性)有关。实验结果表明,KeyX将XML数据查询速度提高了105~106倍,并且随着XML数据量的增大,加速能力将更强。

2 利用ISP原理优化Native Xml数据库索引

定义合适的索引对优化数据库非常必要。为使索引能满足日后数据库扩展的需要,本文使用了ISP原理进行优化。所有的数据库操作都将以包的形式记录下来,即工作量workload,记为,每次对XML数据库的操作(operation, = )所使用的路径表达式,被查询优化器定义为一组“备选索引”,这些“备选索引”能够有效地加速对数据库的操作。

与一般索引结构不同的是,“备选索引”不是由编码而来的,它是由查询优化器提取出来。表达式具有三种类型:第一种由关键词和路径组成,记为,如//,这种类型使用最多;第二种是带通配符的路径,记为,如//*;第三种由纯路径组成,记为,如//。在使用中根据实际需要选取提取方法。

由于工作量是由索引决定的,所以我们在考察时,只需分析所有的索引即可,记(Total Index Candidate) = ,由所有和工作量相关的索引组成。

当对数据库进行操作时,中的特定索引被激活,称此动作为索引配置(index configuration),记为,记所有可能的索引配置集合为。每次激活索引,累积组合将导致新的索引配置,根据ISP复杂度定义可得,|| = 2||。

由ISP原理:

(1)(下转第139页)(上接第122页)

其中为经ISP优化的索引配置,为每次进行操作所需的时间,为进行操作所需的存储空间(包括内存)。

并非所有索引配置都直接在数据库管理系统中创建,查询优化器需要根据XML数据中的相关关键词来预估时间和空间的需求,再由ISP在数据库管理系统中创建索引。

3 Native XML数据库索引优化实验结果及分析

本文建立的操作模型如图1所示。其中XDBMS使用Native XDBMS Infoyte DB V3,用来存储XML数据,Infoyte DB 内嵌了一个XPath查询引擎,通过查询优化器调用。当一个操作需求到来后,查询优化器对此操作进行处理,预估查询表达式并在KeyX索引存储器中检查是否有合适的索引,如果存在,就根据索引来加速查询;如果不存在,则转到XPath引擎处理。在实验中我们使用B+树作为KeyX索引存储器里的搜索树。索引选择工具(Index Selection Tool, ISP Tool)在数据库操作期间会被周期性的触发,然后根据操作需求找到一个尽可能好的索引配置。计算此操作的工作量并交由ISP Tool和查询优化器建立通信,由两者共同决定查询表达式以及假设的索引配置。经过此计算和优化过程后,查询优化器将此索引存储到KeyX索引存储器中。

图1 Native XML数据库索引优化实验模型

实验中,我们使用的XML文档大小为26M,包含58万个节点,实验用计算机配置:CPU C4 2.4G/内存512M/硬盘80G。软件平台:Visual C#, Native XDBMS Infoyte DB V3。建立了27个不同的基于XPath的数据库操作,为每一个表达式提供了一个备选索引,在初始化阶段,我们随机选择其中25个数据库操作。通常情况下,有些操作可能会被多次选中,有的则可能一次都未被选中。另外,每一个操作可能会通过预先定义的优化比进行修改。为进一步测试该系统的自适应优化特性,在程序持续运行当中,我们通过一个delta算法创建一个XPath查询,并将其与原27个操作的其中一个进行替换,保持27个操作总数不变。delta算法进行的操作能保证整个工作量较小地、随机地变化,这个算法能对现实数据库操作进行模拟。由于每次工作量变化微小,我们每进行30次数据库操作后调用一次ISP Tool。在实际应用中可根据需要将参数ispFrequency进行调整。

实验结果证明本文提出的方法能有效地自适应优化XML数据查询,不再需要人工定义和维护索引,在设计XML文档时也不需要使用DTD或XML Schema定义格式,而是通过系统的自适应、自优化功能完成索引的维护。应用于Native XML数据库索引类型较多,尽管本文仅对提出的KeyX索引进行了优化研究,但本文的方法也可推广到其它类型索引的优化之中。

参考文献

[1] B. C. Hammerschmidt, M. Kempa, and V. Linnermann. A selective key-oriented xml index for the index selection problem in xdbms. Proceedings of the 15th International Conference on Database and Expert Systems Applications - DEXA ’04. 2005

[2] IBM Corporation. IBM DB2 XML Extender. URL: www-3.省略/software/data/db2/extenders/xmlext/.

[3] Infonyte GmbH. InfoNyte DB.省略.

[4] 万常选.XML数据库技术.北京:清华大学出版社,2005.

[5] 向科峰,郑晓莉.基于TPR树的索引技术研究.电脑知识与技术,2005(36).

[6] 陈婕.基于XML的数据库统一的研究.硅谷,2008(11).

数据库索引范文第8篇

关键词:企业内网;搜索引擎;信息;数据库

中图分类号:TP393 文献标识码:A 文章编号:1009-3044(2014)01-0008-03

1 概述

目前网络服务,特别是局域网搜索引擎在企业网络内得到广泛应用,但是企业内网搜索引擎,搜索到的信息单一,只有标题,没有与标题(关键词)相关的信息,不方便使用者了解是否已经获得自己需要的信息,所以类似百度、谷歌等的局域网搜索引擎在企业网中将有着广泛的应用前景。

因此实现对企业内网中文件的搜索的快速性和准确性,优化搜索结果,返回用户需要的信息,以及对整个搜索引擎的实现。使得企业资源更好的共享、信息的实时性,避免了旧的复杂、层层传递的麻烦,大大提高了资源的有效利用率。然而,要做到高效,准确的搜索到用户所需要的相关信息,就必须从数据库设计开始,因为在现在的应用系统中,衡量应用系统成败的标准之一就是对数据查询及处理的速度。

2 关键词及信息管理

企业内网搜索引擎是对内网中的信息资源进行搜集整理,然后高效率的为内网用户提供查询的系统。企业内网搜索引擎它包括网站信息添加、网站信息修改和网站信息删除几部分。目前企业内网搜索引擎的工作模式是基于关键词的检索,应用这种搜索方式,用户可以用逻辑组合方式在企业内网搜索引擎导航上输入与自己搜索相关的关键词,企业内网搜索引擎则根据用户输入的关键词寻找用户所需内网中资源的地址,然后使用相关的技术将在导航上输入的关键词的所有相关网址及指向相关网址的链接按照一定的顺序返回给用户。例如,百度。

用户输入的关键词经过处理后,企业内网搜索引擎程序便开始工作,从索引数据库中找出所有包含关键词的网页信息,并且根据排名算法计算出哪些网页应该排在前面,然后按照一定格式返回到页面。

3 数据结构及数据库设计

企业内网搜索引擎的数据结构为倒排索引(也称倒排文件),倒排索引是指用相关记录的非主属性值(也叫外键)来查找记录而组织形成的文件叫倒排文件。所有外键值都存在于倒排文件中,并列出了与之相关的所有主键值的记录,主要用于比较复杂的查询。与传统的数据库查询不同,在企业内网搜索引擎收集完数据及关键词的预处理阶段,需要一种高效快速的数据结构来对用户提供检索服务。然而目前最有效高速的数据结构就是“倒排文件”。倒排文件可以被简单的定义为“用文档中的关键词作为索引,内网中的文档作为索引目标”的结构。

在现在的应用系统中,衡量应用系统成败的标准之一就是对数据查询及处理的速度。需要设计一个搜索引擎数据库用于存放相关信息,一旦有文章更新则更新文章中的信息及关键词段,企业内网搜索引擎在内存中完成所有的文章关键词段搜索,并且在此期间不允许有其他的操作,比如说文章的更新等等。在对企业内网搜索引擎的功能模块进行分析以后,建立了数据库。

3.1 数据流图

3.2 数据库设计步骤

1) 数据库需求分析:对企业内网搜索引擎的实施与应用的必要性和可行性进行论证,罗列出相关对象及其属性,形成数据字典。

2) 数据库系统分析:在需求分析的结果上进行总体分析,了解数据库整体结构。

3) 数据库功能和对象分析:对总体分析进行细化从对象和功能方面进行详细描述。

4) 数据库设计:选用SQL Server对功能和对象建立表。

3.3 各表之间关系

3.4 数据对象

3.4.1 Web对象

用途:为Web页面提供存储,提取,URL操作,方便对Web页面的增加,删除与修改。

约束:数据系统中包含多个实例

持久性:持久对象

属性描述

属性:url 类型:String 描述:本网页的URL。

属性:title 类型:String 描述:记录网页的标题

属性:time 类型:time 描述:记录网页添加时间

属性:content 类型:String 描述:记录与网页相关的内容,并显示出搜索到的网页的相关信息。

3.4.2 Admin对象

用途:为系统提供后台管理,设置管理员登录,并且登录密码采用MD5加密。

约束:数据系统中包含多个实例

属性描述

属性:username 类型:String 描述:记录管理员登录名

属性:password 类型:String 描述:记录管理员登录密码

属性:login_ip 类型:String 描述:记录登录的IP地址

3.4.3 Keyword对象

用途:当用户在导航栏上输入关键词后,为系统提供对关键词的管理。

约束:数据系统中包含多个实例

属性描述

属性:keyword 类型:String 描述:记录用户在内网中导航上输入的关键词。

4 完整性约束

完整性约束条件也称为完整性规则,关系完整性约束是为确保数据库中数据的相容性和正确性,对关系模型提出的某种约束条件或规则,是数据库中数据必须满足的语义约束条件。

4.1 数据库约束

数据库顾名思义就是指一个用户或者管理员定义的表的集合;然而数据库约束是指所建立的数据库必须满足某个特定的条件(本数据库中各表之间的相互联系)。

4.2 表约束

表约束就是指该表的每条记录必须满足某个特定的条件(只涉及该表本身而不涉及数据库中的其他表和其他域)。SQL允许把约束定义在字段和表上,允许对数据施予任意的控制,若用户想在字段里存储违反约束的数据,那么就会出现错误。这种情况同时也适用于数值来自缺省值的情况。表约束有以下几种类型:

1) 检查约束:是最常见的约束类型。允许在某个字段里声明的数值使一个结果为真的布尔表达式。

2) 非空约束:只是简单地声明一个字段必须不能是 NULL ,非空约束在功能上等效于创建一个检查约束。

3) 唯一约束:保证在一个字段或者一组字段里的数据与表中其它行的数据相比是唯一的。

4) 主键:只是唯一约束和非空约束的组合。

5) 外键:声明一个字段的数值必须匹配另外一个表中出现的数值。

以上约束类型的语法参考SQL数据库,例如要强制一个产品的价格的检查约束,可以使用下面语法:

CREATE TABLE products (

pdn integer,

name text,

price numeric CHECK (price > 0)

);

5 数据备份与数据安全

数据备份分为完全备份和差异备份。完全备份就是将整个数据都做备份;差异备份是从上一次完全备份后所做的数据进行备份。数据安全是一种主动的包含措施,数据本身的安全必须基于可靠的加密算法与安全体系,其中在企业内网搜索引擎的数据库建立中就采用了MD5加密算法,保证内网中的数据库信息的数据安全性。

参考文献:

[1] 袁津生,李群,蔡岳.搜索引擎原理与实践[M].北京邮电大学出版社.

[2] 吴洁明,软件工程应用实践教程[M].清华大学出版社.

[3] 王珊,萨师煊.数据库系统概[M].论高等教育出版社.

数据库索引范文第9篇

关键词: 移动对象数据库;索引;查询;无限制空间;网络空间

中图分类号:TP311文献标识码:A文章编号:1009-3044(2011)27-6592-02

Indexing and Querying in Moving Objects Database

ZHANG Xia

(Computer and Information Technology Institute of Nanjing College of Information Technology, Nanjing 210046, China)

Abstract: Firstly, the paper introduced the features of Moving Objects Database (MOD). Then, the moving objects indexing was classified according to the different index space: moving objects indexing in unconstrained space and moving objects indexing in network space. Several technologies of moving objects indexing were presented. And then, the paper introduced several querying techniques, and proposed that query evaluation should be multi-faceted, multi-perspective. Finally, the development of Indexing and querying in moving objects database were briefly presented.

Key words: moving objects database; index; query; unconstrained space; network space

1 绪言

随着无线通信、卫星定位等技术的飞速发展及其广泛应用,如何存储、查询和管理一些随空间改变和时间推移的数据成为现代数据库研究的一个重要方向。移动对象数据库(Moving Objects Databases,MOD)旨在常规的时空数据库基础上建立移动对象运动轨迹模型[1],增强数据更新和索引技术,扩展数据查询语言,并增加移动对象位置不确定性管理方法[2]。其研究重点集中于几个核心问题:1)移动对象建模和数据模型;2)索引方法和查询处理;3)精确性和不确定性管理;4)实现原型。而如何高效表示和查询移动对象的连续变化信息是移动对象数据库首先要解决的问题。本文对移动对象数据库的索引方法和查询处理作简单的综述。

2 MOD的主要特点

文献[2]中指出了MOD(移动对象数据库)不同于传统数据库的4个特点:

1)存储历史数据:MOD通过记录和处理对象位置或形状要素随时间的变化情况,保存了对象的现势信息、历史信息和过程信息,MOD的语义更丰富,更完整地表达和模拟移动对象的真实状态,更准确地反映移动对象的时序变化与发展的过程和规律。

2)支持动态属性:MOD提出了动态属性的概念,即属性值随时间持续改变而不需显式更新。

3)表达丰富的时空语义:MOD可以表达对象空间结构和空间拓扑关系等空间语义,还可以表达事件序列和时间相关性等时间语义。

4)管理位置不确定性:位置不确定性是移动对象的固有特性,这是因为受主客观因素的限制,移动对象不能(或不必)把每次定位的结果都上传到指挥监控中心的数据库,而是采用一定的折衷策略,在位置精度和通信开销之间取得平衡,从而使数据库中所保存的对象位置并不总与其实际位置一致。移动对象的位置不确定性对数据库的位置数据建模、索引和查询等方面都产生了深远的影响。

3 MOD的索引方法

MOD中的数据具有时间与空间双重变化的特点,其海量的时空数据经常要求能实时响应,所以,MOD的索引结构相当重要。MOD的索引不仅要考虑索引空间还要考虑索引时间,为了支持对移动对象的查询,必须对移动对象的不同时态进行索引,包括移动对象的完整历史轨迹索引、移动对象的当前及未来位置的索引[3]。根据移动对象的运动空间,可将移动对象分为无限制空间的移动对象和网络空间的移动对象两类。

3.1 无限制空间内移动对象索引

无限制空间内移动索引的研究围绕当前及未来位置的索引和历史轨迹索引展开。对当前及未来位置的索引主要有原时空存取,空间转换,参数化时空存取等方法;对历史轨迹的索引主要有空间索引扩展,重叠及多版本结构,面向轨迹存取等方法。例如,PA树[4]是一个参数式索引,它索引表达轨迹的多项式。该方法的作者认为最小外接矩形不能表示轨迹的平滑,应该将轨迹近似地表达为一系列连续的多项式运动函数。相比于R树[5]来说,PA树中用多项式系数代替R树结构中的最小外接矩形。

3.2 网络空间内移动对象索引

事实上,大多数的移动对象其实都不是无限制的,它们往往是被限制在网络中,例如汽车总是在道路网络中运行。网络空间中移动对象的表示可以利用网络中的线性参考位置,而不是用二维地理坐标。FNR[6]树是一种在道路网络中对移动对象历史轨迹的索引方法,由一个二维R树与一维R树组成。这种方法的主要缺点索引树结构中的大量节点,以及移动对象在路段变更时产生的大量更新。针对基于受限网络的移动对象管理研究中道路网模型简单,以及以空间平面坐标表达移动对象位置的方法不适合于道路网应用的问题,桂智明等人设计了一种针对道路网络的移动对象索引模型[7]。与FNR及相关改进的索引方法相比,该方法在移动对象位置更新及添加上有更高的效率,在相关查询上结果更加合理。在针对移动对象当前及未来位置的索引方法上,Au[8]方法通过AU分组提高单个移动对象更新的效率。

4 MOD的查询处理

索引的主要目标是高效的查询处理,移动对象数据库中查询种类繁多,选择性查询、最近邻查询、持续查询和连接查询等都是常见的查询要求;相同的索引方法对于不同的查询技术有不同的查询效率;不同的索引方法对相同的查询技术也是有不同的查询效率;相同的索引方法和查询方法,对于不同的查询要求也是有不同的查询效率,因此,MOD的查询效率依赖于查询种类、索引技术和查询算法等多个方面,不能单一地来评判某个查询方法的好与坏,对查询策略的评价应多方面,多角度考虑。

移动对象数据库中早期的K最近邻查询算法主要是查询某个指定时刻距离查询点最近的K个对象。接着,人们开始关注于连续性查询系统并将其应用于位置服务中,被查询的对象和查询点都可以处于运动的状态。现有方法中SEA-CNN[9]较具代表性,通过建立查询索引机制等手段降低了系统I/O开销,但没有深入讨论对中间结果的利用和动态查询的优化问题。为此,文献[10]提出了对象和结果的双缓存机制,减少静态查询重新初始化次数,进一步缩小动态查询搜索区域,实现了对象访问和查询结果的双重共享。概率方法也曾被应用到移动对象数据的查询中来,如文献[11]将概率查询方法运用到受限网络移动对象的不确定区域中,提出了对受限网络移动对象轨迹的不确定性点查询和概率范围查询。此外,还有一些其他的查询类型。文献[12]定义了一种基于事件的位置相关查询ELDQ(Event-based Location Dependent Query),提出了相应的网络内优化方法来降低处理ELDQ的代价,包括自适应传感器选择算法、网络内的查询传播方法和网络内的位置相关数据聚集算法。同时,该文设计了一种两级多查询优化策略来降低处理并发ELDQ查询的总体开销。

5 结束语

移动对象数据库系统往往具有海量数据以及复杂的时空运行特征,对于移动对象索引缺乏公认有效的,且能满足各种实际查询需求的方法。目前人们对移动对象索引研究取得了一定的成果,但尚有很多问题等待解决,文献[3]中指出移动对象数据库中索引的发展方向:1)分别索引网络数据及移动对象;2)增加索引支持的查询种类;3)索引的更新;4)MBR(最小外接矩形)作为对近似索引目标的技术,对索引目标的近似比较粗糙,容易产生死空间。

移动对象数据库中的查询不是孤立存在的,它与索引方法密切相关。某查询方法适用于一种索引方法,但不一定适用于另外一种索引方法,需要依据实际解决的问题而定。

参考文献:

[1] 何云斌,樊守德,郝忠孝.基于MOST模型的移动对象全轨迹建模[J].计算机工程,2008,34(16):41-43.

[2] 曾军,张跃鹏,张德.移动对象数据库及其应用[J].测绘科学与工程.2010,30(2):65-69.

[3] 肖晖,李清泉.移动对象数据库索引研究综述[J].计算机应用,2010,30(4):1064-1071.

[4] NI J,RAVISHANKAR C.Indexing spatio-temporal trajectories with efficient polynomial approximations[J].IEEE Transactions on Knowledge and Data Engineering, 2007,19(5):1-16.

[5] GUTYMAN A.R-trees:A dynamic index structure for spatial searching[C].Proceedings of the 1985 ACM SIGMOD International Conference on Management of Data. Boston:ACM Press,1984:47-57.

[6] FRENTZOS E.Indexing objects moving on fixed networks[C].Proceedings of the 8th International Symposium on Advances in Spatial and Temporal Databases. Santorini Island:Springer,2003:289-305.

[7] 桂智明,廖湖声.基于LRS与GDF的移动对象轨迹建模及索引[J].计算机应用研究,2008,25(9):2684-2686.

[8] CHEN J,MENG X.Update-efficient indexing of moving objects in road networks[J].Geolnformatica,2009,13(4):397-424.

[9] Xiaopeng Xiong,Mohamed F,Mokbel,et,al.SEA-CNN:Scalable Processing of Continuous K-Nearest Neighbor Queries in Spatio-temporal Databases[C].Proceedings of the 21st International Conference on Data Engineering.2005:643-654.

[10] 潘鹏.时空数据库的索引机制及查询策略研究[D].武汉:华中科技大学,2007.

[11] 宋广军,郝忠效,王丽杰.受限网络移动对象不确定性轨迹的查询[J].计算机工程,2010,36(6):276-277,280.

数据库索引范文第10篇

方志中的人物传记是方志重要的组成部分。在人物传记中记载了一个地区的知名人士,而这些人士大多数在正史中是不予以记载的。因此,在方志人物传记中能够查到不少正史中所没有的人物,这对于历史研究来说是非常有帮助的。但是,由于方志中的人物众多,在使用时颇感不便,因此,人们开始编制方志传记资料索引。

我国最早的方志人物传记索引是1939年江苏省立图书馆曹允源编制的《吴县列传人名索引》,此后,陆续编制了《宋元方志传记索引》、《山西通志人物传记索引》、《东北方志人物传记资料索引》、《北京天津地方志人物传记索引》、《广西方志传记人名索引》等,台湾地区也编制了《中日现藏三百种明代地方志传记索引》等,这些索引的编制对于人们查找方志中的人物起到了积极作用。但是,限于印刷型载体的篇幅,这些索引也存在着明显的不足。一是索引的著录内容少,一般为姓名、别名、出处等几项;二是检索点单一,仅在索引正文中按人物的姓名排序,另外在书后再附一种与正文对应的检索方式,仅此而已;三是编制时投入的人力、物力多,编制周期长,一部索引的编制要经过多道工序,诸如写卡片、校对,再到写清样、排版、校对直至印刷等多个环节,投入的人力多,工作量大。正是由于这些不足,限制了人们大规模编制方志人物传记索引的工作,从而也限制了人们便捷地查阅方志中人物的需求。

随着现代高新技术的发展,为索引的编制带来了新的发展天地。计算机数据库技术的出现,为索引的编制提供了一个高效、简便的工具。采用计算机数据库技术编制索引不仅可以使索引的编制达到事倍功半的效果,而且还极大地丰富了读者的检索途径,从而实现以往传统的印刷型索引所达不到的效果。

北京图书馆收藏的新旧方志居海内外各图书馆之首。如何充分发挥这些方志的作用,使其更好地为社会主义精神文明和物质文明服务是图书馆工作者的职责;在人们开始进入信息时代,如何使方志中的大量信息为人们所了解并便于查询,也是图书馆工作者的义务;从全球信息化进程发展来看,将方志中的大量信息进行数字化处理、使海内外广大读者通过网络来进行检索,也是图书馆工作者的工作。

据此,北京图书馆地方志和家谱文献中心决定率先着手建立方志人物传记资料索引数据库。

方志人物传记资料索引数据库的目标是:要能够适应新旧方志中的人物传记情况,要准确和较为全面地揭示人物的基本属性,发挥计算机检索的优势,满足读者多途径检索人物的需求,为读者提供一个快速、便利的查询工具,使之为广大读者所使用。

在这个目标的指导下工作人员进行了大量的调研工作,以最终确定数据库项目的内容。而数据库内容的确立是数据库检索的基础,也是直接影响数据库建设质量的关键因素。如前所述,现有的印刷型方志人物传记资料索引,主要是通过人物的姓名来进行检索,检索途径单一。所记载的内容基本是姓名和主要的字、号,个别的有生卒年。对于出处基本是书名的简称或代号。有关人物的其他内容则不予反映。

在掌握现有方志人物传记资料索引情况的基础上,根据读者检索的需求和图书馆工作人员以往的工作经验以及计算机所提供的功能,最后确定该数据库的项目内容为:姓名、别名、性别,民族、籍贯、朝代、生卒年、参考年,肖像、身份类别主题词、方志省份和出处,总计12项。

这12个项目大大超过了现有印刷型方志人物传记资料索引所收录的内容。

1.标识人物身份主题词的使用

在方志的人物传记中,由于所收录的人物较多,因此大多数的方志都将所收人物按其身份进行集中编排,并给予相应的门类名称。在旧方志中,一般将人物分为名宦、儒林、忠义、宦绩、文苑、武功、隐逸、孝友、义行、方伎、仙释等门类。在新方志中则分为英烈、劳模、能工巧匠和专家学者等。显然,这样的分类与集中便于读者使用。

但是,在印刷型方志人物传记资料索引中是难于做到按上述门类进行编辑检索的。假如这样做,那索引的工作量就要成倍的增长,如果要编制一个数千人物的索引,那就是一个浩瀚的工程。在现有的方志人物传记资料索引中,读者只能在掌握了一个人物的姓名或其主要的别名之后,方可进行检索,而要查寻某一门类的人物是无法办到的。假若读者想了解某一地区历史上在农业种植方面有特殊技艺的人物,就只能将该地区现存的所有方志一部一部进行翻检,才能得到所需要的人物。

为实现读者可以按门类进行检索的要求,参照图书馆对书刊文献进行主题标引的工作,在该数据库中设置了标识人物身份的主题词项目。目前主题标引多用于书目、篇名等数据库中,用于人物标引尚未见到。因此,对人物进行主题标引是该数据库的一个特点,也是计算机检索有别于印刷型检索的重要标志。

为使计算机的检索达到应有的效果,数据库对于主题词的使用考虑了以下三个问题:

第一、用词的规范性。在新旧方志中,虽然有大量的志书对于人物传记按门类进行了集中编排,但是,这些门类名词的使用由于编纂者的理解不同和所处的历史环境的不同往往存在着差异,因而造成对同一门类的用词不统一;另外,各地在编纂方志时对于同一人物的传记在撰写时侧重点不同,所反映的内容不同,所安置的门类也就不尽相同。如果仅仅按各方志中人物所处的门类来进行主题标引,就会出现对同一人物的用词不一致,从而在进行主题检索时达不到应有的效果。为规范主题标引的用词,在标引时遵循了以下四条原则:

首先,选用的词要具有检索意义和组配意义,并能够表达相应的概念;

其次,选用的词必须词义明确,一词一义;

再次,选用的词要具有一定的使用频率;

第四,参照《中国图书分类主题词表》中的词汇。

按照上述原则编制了一个人物主题词表,并在工作中逐步完善。

第二、用词的准确性。在标引用词的准确性方面、由于对人物的主题标引主要是根据该人物传记中所反映的这个人物的生平事迹、主要贡献和主要活动内容,给予一个或数个主题词。因此,大致从以下几方面来确定主题词:

人物的专业、专长或所从事的行业。如政治、军事、医学等;

人物在社会生活中所产生较为突出的影响。如义行、劣行等;

人物的某些特定身份。如英烈、君主、宗教徒等;

人物传记中所记载该人物经历的主要甚至是唯一的重大历史事件。如辛亥革命、历次农民起义等;人物传记中所记载该人物对于某一地区做出重大贡献的情况。如郑成功,台湾就可以选做主题词;

人物参加的党派、社团、帮会等。

如兴中会、日知会等。第三、用词的适度性。由于方志所收录人物的多样性和复杂性,使得在对人物进行主题标引时要恰如其份。标引太少,就不能全面、准确地揭示人物的基本情况,在检索时难于达到预期的效果;反之,标引过多,会造成对于人物界定过细,同样会造成在检索时命中结果的分散,降低检索效率。因此,恰当地标引是保证检索效果的基础。为此,数据库规定对于人物的主题词标引控制在八个之内。如:

顾炎武,明末清初杰出的思想家、爱国学者。他的主题词是“政治”、“哲学”、“文学”、“文献学”等;

孙叔平,他的主要经历是从事于教育工作和哲学研究。因此,他的主题词为“教育”和“哲学”;

胡也频,此人主要从事文学创作,并从事出版发行工作,参加左联,任执行委员, 1931年2月7日被杀害。他的主题词为“文学”、“出版发行”、“英烈”和“左联”。

2.对于别名较为全面的收录

在方志的人物传记资料中,一个人物除了有一个正式的或较为通用的名字外,绝大多数人物还会有别名。别名的情况较为复杂。对于古代帝王等封建统治者,多有年号、庙号、谥号。而这些年号、庙号或谥号又多为后世通用的名称,其本名反不为一般人所熟知。如:秦始皇、乾隆等;对于文人墨客,则有字、号、室名、笔名等,如:倪儹,元朝人,工诗文,善绘画,以山水见长。他初名珽,字元镇,又字玄瑛,号云林,别号幻霞子、荆蛮民、净名居士、如幻居士、朱阳馆主、萧闲仙卿、海岳居士、无住庵主、沧浪漫士、曲全叟,变姓名曰奚元朗;

对于近现代的革命者,则有化名、曾用名等,如:董必武,曾经化名“碧吾”;陈潭秋,曾化名“徐杰”;

对于出家者,则有法名、法号、俗号等,如:马道一,是佛教禅宗的第八代大师,“马道一”是其俗名,世称“马祖”,谥号“大寂禅师”;

对于能工巧匠,则有绰号等。如:余德新,是个在当地饮食业有较为突出技能的人物,由于其技艺出众,人们戏称其为“一大堆”;

还有一些其他的称谓。

3.对于人物生卒年不确定性的处理

人物的生卒年是断定一个人物的重要依据,也是进行历史研究所不可缺少的。在方志人物传记资料中,对于人物生卒年的描述也不完全相同,归纳起来大体有三种情况。为便于检索,数据库设计了相应的著录要求。

一是有明确的生卒年,特别是在新方志中,对于近现代人物基本上都有明确的生卒年。对于这种情况,就在“生卒年”项目中填入具体的年份,并在“朝代”一栏中填入相应的时代。生于1840年以后的,或主要活动在1840年以后的,则填入“近现代”。这主要是便于检索。

如:余德新,生于1913年,卒于1978年,在“朝代”一栏中填入“近现代”;

二是没有明确的生卒年,但是有人物活动的具体朝代。这样就将此人活动的朝代填入“朝代”一栏中即可,“生卒年”予以空置。

如:朱子才,金代进士,生卒年不详,在朝代一栏填入“金”;

三是没有明确的生卒年,但是有此人活动的朝代,以及此人任职时间或此人经历一个重要事件的时间。对于这种情况,著录时要求在“朝代”一栏中填入相应的朝代,在“参考年代”一栏中填入任职时间或经历事件的具体时间,给读者一个较为具体的参考时间,帮助读者进行判断。

如:田瑜,北宋庆历年间进士,生卒年不详。但在他的传记中记载了庆历四年(1044)欧希范叛乱,田瑜率兵讨伐,予以平灭。这样,在“朝代”一栏中填入“北宋”,在“参考年代”一栏中填入“1044”。

4.其他项目的设置

籍贯。在方志的人物传记资料中常常会有同名同姓者,要予以区分,籍贯是一个重要条件。因此,数据库中设置了籍贯的项目。它要根据方志人物传记所记载的情况而定,对于不确定的要经过相应的考证,予以判断,最终获得一个较为正确的籍贯地名。

肖像。在有些新方志的人物传记资料中刊登了人物的照片或肖像绘画,这是旧方志所不具备的。这对于进行一些专题研究和爱国主义教育是十分有利的。

方志省份。这是一部方志所属的省、市、自治区,它可以帮助读者了解该方志所属的具体省别。

出处。在出处一项中,要著录五个内容,即书名、出版地、出版者、出版时间和页码。众所周知,方志的编纂出版具有一定的连续性,旧方志如此,新方志也要如此。按照中国地方志领导小组的有关规走,新方志要20年左右一编修。因此,在出处项中设置出版地、出版者和出版时间就是为了区分同一个地区不同时代编纂出版的方志。

方志人物传记索引数据库所收录的内容是人物的有关数据,基本上是属于专题性的题录数据库,其主要功能要求是提供读者进行检索。数据的收录范围明确,数据内容较为规范,数据结构也基本稳定,由此也决定了数据库开发的软硬件条件和性能要求。在硬件方面,要求是486/100以上的PC机,内存16兆,最少8兆,200兆的硬盘,这要根据数据量的多少而定。VGA显示器。外接针式打印机或激光打印机。目前为单机版,以后将升级到网络版。在软件方面,操作系统是中文Windows95,应用系统则在VisuaI FoxPro 3.0上进行二次开发。Visual FoxPro 3.0是Mi crosoft公司推出的一种开发工具,它吸收了以往FoxPro的优点,并在此基础上进行了改进,包括从面向字符式数据库转向面向对象的风格,完全支持Windows事件模式以及数据字典的创建等功能,使其达到更快捷的速度、更完善的功能和更简便的操作。

该数据库提供了检索、编辑、显示、统计、打印、系统维护和帮助的功能。

检索功能。系统提供了姓名、别名、性别、民族、籍贯、朝代、生卒年、参考年、肖像、标识人物身份的主题词、方志省份和出处12个检索点。这些检索点既可以进行单项检索,也可以进行组配检索;对于姓名、别名等还可以进行前方一致的截断检索;对于主题词可以同时进行多个组配检索。

编辑功能。这是提供工作人员录入数据时使用。系统提供了方便的数据录入功能。由于在录入同一部方志时,其出处、方志省份内容完全相同,为减轻工作人员的劳动强度,工作人员在录入同一部方志的不同人物数据时,可以在前一条数据的基础上保持无需修改的内容,仅对不同的内容进行修改,以此追加新的记录。

显示功能。系统提供了简要显示、文本显示和卡片显示,使读者和工作人员可根据需要来选择。简要显示仅对命中的数据显示人物的姓名、出处中的方志名称和页码;文本显示则显示人物的姓名、朝代、生卒年、别名、性别(男性不显示)、民族(汉族不显示)、籍贯。肖像(有则显示“照片”或“肖像”,没有则不显示任何信息)、出处;卡片显示则按一个卡片格式将人物的12项内容全部予以显示。

统计功能。系统可以进行以下操作:一是统计数据库中所有数据记录的情况;二是统计数据库中有关某一部方志的数据记录情况,三是统计数据库中所有方志的部数;四是统计数据库中所收各省方志的部数。

打印功能。

系统可以打印输出校对单、别名索引、方志一览表、主题词表和按人物姓名为序的表格,提供使用。系统维护功能。提供了数据备份、数据安装、数据链接、重新索引和库整理的功能。

综上所述可以看出,该数据库提供的多途径检索、方便的数据录入、多种统计和打印等功能,不仅方便了读者使用,也便于工作人员进行数据库建设,是一个较为理想的方志人物传记资料索引数据库的编制工具。

利用该数据库,北京图书馆地方志和家谱文献中心已经完成了485部新方志中的近3万条人物数据的制作工作,取得了良好的效果,达到了预期的目的,并为今后继续制作方志人物传记资料索引数据库积累了丰富的经验。这批数据即将上网,读者通过访问我馆的主页(http://www. nlc. )就能检索。

上一篇:数据清洗范文 下一篇:关系型数据库范文

友情链接