数据库（Database）是按照数据结构来组织、存储和管理数据的仓库，它产生于距今五十年前，随着信息技术和市场的发展，特别是二十世纪九十年代以后，数据管理不再仅仅是存储和管理数据，而转变成用户所需要的各种数据管理的方式。数据库有很多种类型，从最简单的存储有各种数据的表格到能够进行海量数据存储的大型数据库系统都在各个方面得到了广泛的应用。

简介(定义1 定义2 定义3 定义4)

数据库中数据的性质(数据整体性 数据共享性)

发展简史(数据管理的诞生 关系数据库的由来 结构化查询语言(SQL) 数据库巨人的诞生 面向对象数据库 数据管理的变革 非关系型（无模式文档型）数据库)

发展阶段(人工管理阶段 文件系统阶段 数据库系统阶段 未来发展趋势)

基本属性(基本结构 主要特点 种类)

常用数据库(麦杰的实时数据库 IBM 的DB2 Oracle Informix Sybase SQL Server PostgreSQL mySQL Access数据库 SQLite FoxPro数据库 INFOBANK数据库 SOSHOO网)

数据库病毒检查方法

数据库查询优化原则

简介

定义1

严格地说，数据库是“按照数据结构来组织、存储和管理数据的仓库”。在经济管理的日常工作中，常常需要把某些相关的数据放进这样的“仓库”，并根据管理的需要进行相应的处理。例如，企业或事业单位的人事部门常常要把本单位职工的基本情况(职工号、姓名、年龄、性别、籍贯、工资、简历等)存放在表中，这张表就可以看成是一个数据库。有了这个"数据仓库"我们就可以根据需要随时查询某职工的基本情况，也可以查询工资在某个范围内的职工人数等等。这些工作如果都能在计算机上自动进行，那我们的人事管理就可以达到极高的水平。此外，在财务管理、仓库管理、生产管理中也需要建立众多的这种"数据库"，使其可以利用计算机实现财务、仓库、生产的自动化管理。

J.Martin给数据库下了一个比较完整的定义：数据库是存储在一起的相关数据的集合，这些数据是结构化的，无有害的或不必要的冗余，并为多种应用服务；数据的存储独立于使用它的程序；对数据库插入新数据，修改和检索原有数据均能按一种公用的和可控制的方式进行。当某个系统中存在结构上完全分开的若干个数据库时，则该系统包含一个“数据库集合”。

定义2

数据库是依照某种数据模型组织起来并存放二级存储器中的数据集合。这种数据集合具有如下特点：尽可能不重复，以最优方式为某个特定组织的多种应用服务，其数据结构独立于使用它的应用程序，对数据的增、删、改和检索由统一软件进行管理和控制。从发展的历史看，数据库是数据管理的高级阶段，它是由文件管理系统发展起来的。

定义3

(伯尔尼公约议定书专家委员会的观点)

所有的信息(数据事实等)的编纂物，不论其是以印刷形式，计算机存储单元形式，还是其它形式存在，都应视为“数据库”。

数字化内容选择的原因有很多，概括起来主要有：

(1)存储空间的原因。数字化的产品是通过网络被广大用户存取利用，而大家都知道数字化产品是存放在磁盘阵列上的，磁盘阵列由服务器来管理，磁盘空间是有限的，服务器的能力也是有限的，不可能无限量地存入数字资源，这就需要我们对文献资源数字化内容进行选择。

(2)解决数字化生产高成本和图书馆经费有限性之间矛盾的需要。几乎没有图书馆有充足的资源来对整个馆藏进行数字化，内容选择不可避免。

(3)数字资源管理的需要。技术的快速发展使数字化项目所生成的数字资源的生命周期越来越短，投入巨资进行数字迁移是延长数字资源生命的1个重要途径，昂贵的维护成本就必须考虑数字化的内容选择。

数据库发展史数据库技术从诞生到现在，在不到半个世纪的时间里，形成了坚实的理论基础、成熟的商业产品和广泛的应用领域，吸引越来越多的研究者加入。数据库的诞生和发展给计算机信息管理带来了一场巨大的革命。三十多年来，国内外已经开发建设了成千上万个数据库，它已成为企业、部门乃至个人日常工作、生产和生活的基础设施。同时，随着应用的扩展与深入，数据库的数量和规模越来越大，数据库的研究领域也已经大大地拓广和深化了。30年间数据库领域获得了三次计算机图灵奖（C.W. Bachman,E.F.Codd, J.Gray），更加充分地说明了数据库是一个充满活力和创新精神的领域。就让我们沿着历史的轨迹，追溯一下数据库的发展历程。

传统上，为了确保企业持续扩大的IT系统稳定运行，一般用户信息中心往往不仅要不断更新更大容量的IT运维软硬件设备，极大浪费企业资源；更要长期维持一支由数据库维护、服务器维护、机房值班等各种维护人员组成的运维大军，维护成本也随之节节高升。为此，企业IT决策者开始思考：能不能像拧水龙头一样按需调节的使用IT运维服务？而不是不断增加已经价格不菲的运维成本。

定义4

数据库（DataBase，DB）是一个长期存储在计算机内的、有组织的、有共享的、统一管理的数据集合。它是一个按数据结构来存储和管理数据的计算机软件系统。数据库的概念实际包括两层意思：

（1）数据库是一个实体，它是能够合理保管数据的“仓库”，用户在该“仓库”中存放要管理的事务数据，“数据”和“库”两个概念结合成为数据库。

（2）数据库是数据管理的新方法和技术，它能更合适的组织数据、更方便的维护数据、更严密的控制数据和更有效的利用数据。

数据库中数据的性质

数据整体性

数据库是一个单位或是一个应用领域的通用数据处理系统，他存储的是属于企业和事业部门、团体和个人的有关数据的集合。数据库中的数据是从全局观点出发建立的，他按一定的数据模型进行组织、描述和存储。其结构基于数据间的自然联系，从而可提供一切必要的存取路径，且数据不再针对某一应用，而是面向全组织，具有整体的结构化特征。

数据共享性

数据库中的数据是为众多用户所共享其信息而建立的，已经摆脱了具体程序的限制和制约。不同的用户可以按各自的用法使用数据库中的数据；多个用户可以同时共享数据库中的数据资源，即不同的用户可以同时存取数据库中的同一个数据。数据共享性不仅满足了各用户对信息内容的要求，同时也满足了各用户之间信息通信的要求。

发展简史

数据管理的诞生

数据库的历史可以追溯到五十年前，那时的数据管理非常简单。通过大量的分类、比较和表格绘制的机器运行数百万穿孔卡片来进行数据的处理，其运行结果在纸上打印出来或者制成新的穿孔卡片。而数据管理就是对所有这些穿孔卡片进行物理的储存和处理。然而，1 9 5 1 年雷明顿兰德公司（Remington Rand Inc）的一种叫做Univac I 的计算机推出了一种一秒钟可以输入数百条记录的磁带驱动器，从而引发了数据管理的革命。1956 年IBM生产出第一个磁盘驱动器—— the Model 305 RAMAC。此驱动器有50 个盘片，每个盘片直径是2 英尺，可以储存5MB的数据。使用磁盘最大的好处是可以随机地存取数据，而穿孔卡片和磁带只能顺序存取数据。

1951： Univac系统使用磁带和穿孔卡片作为数据存储。

数据库系统的萌芽出现于60 年代。当时计算机开始广泛地应用于数据管理，对数据的共享提出了越来越高的要求。传统的文件系统已经不能满足人们的需要。能够统一管理和共享数据的数据库管理系统（DBMS）应运而生。数据模型是数据库系统的核心和基础，各种DBMS 软件都是基于某种数据模型的。所以通常也按照数据模型的特点将传统数据库系统分成网状数据库、层次数据库和关系数据库三类。

最早出现的是网状 DBMS，是美国通用电气公司Bachman等人在1961年开发成功的IDS（Integrated DataStore）。1961年通用电气公司（General ElectricCo.）的Charles Bachman 成功地开发出世界上第一个网状DBMS也是第一个数据库管理系统—— 集成数据存储（Integrated DataStore IDS），奠定了网状数据库的基础，并在当时得到了广泛的发行和应用。IDS 具有数据模式和日志的特征。但它只能在GE主机上运行，并且数据库只有一个文件，数据库所有的表必须通过手工编码来生成。之后，通用电气公司一个客户——BF Goodrich Chemical 公司最终不得不重写了整个系统。并将重写后的系统命名为集成数据管理系统（IDMS）。

网状数据库模型对于层次和非层次结构的事物都能比较自然的模拟，在关系数据库出现之前网状DBMS要比层次DBMS用得普遍。在数据库发展史上，网状数据库占有重要地位。

层次型DBMS是紧随网络型数据库而出现的。最著名最典型的层次数据库系统是IBM 公司在1968 年开发的IMS

（Information Management System），一种适合其主机的层次数据库。这是IBM公司研制的最早的大型数据库系统程序产品。从60 年代末产生起，如今已经发展到IMSV6，提供群集、N路数据共享、消息队列共享等先进特性的支持。这个具有3 0 年历史的数据库产品在如今的WWW应用连接、商务智能应用中扮演着新的角色。

1973 年Cullinane 公司（也就是后来的Cullinet软件公司），开始出售Goodrich 公司的IDMS 改进版本，并且逐渐成为当时世界上最大的软件公司。

关系数据库的由来

网状数据库和层次数据库已经很好地解决了数据的集中和共享问题，但是在数据独立性和抽象级别上仍有很大欠缺。用户在对这两种数据库进行存取时，仍然需要明确数据的存储结构，指出存取路径。而后来出现的关系数据库较好地解决了这些问题。

1970年，IBM的研究员E.F.Codd博士在刊物《Communication of the ACM》上发表了一篇名为“A Relational Model of Data for Large Shared Data Banks”的论文，提出了关系模型的概念，奠定了关系模型的理论基础。尽管之前在1968年Childs已经提出了面向集合的模型，然而这篇论文被普遍认为是数据库系统历史上具有划时代意义的里程碑。Codd的心愿是为数据库建立一个优美的数据模型。后来Codd又陆续发表多篇文章，论述了范式理论和衡量关系系统的12条标准，用数学理论奠定了关系数据库的基础。关系模型有严格的数学基础，抽象级别比较高，而且简单清晰，便于理解和使用。但是当时也有人认为关系模型是理想化的数据模型，用来实现 DBMS是不现实的，尤其担心关系数据库的性能难以接受，更有人视其为当时正在进行中的网状数据库规范化工作的严重威胁。为了促进对问题的理解，1974 年ACM牵头组织了一次研讨会，会上开展了一场分别以Codd和Bachman为首的支持和反对关系数据库两派之间的辩论。这次著名的辩论推动了关系数据库的发展，使其最终成为现代数据库产品的主流。

1969： Edgar F。“Ted” Codd发明了关系数据库。

1970年关系模型建立之后，IBM公司在San Jose实验室增加了更多的研究人员研究这个项目，这个项目就是著名的System R。其目标是论证一个全功能关系DBMS的可行性。该项目结束于1979年，完成了第一个实现SQL的 DBMS。然而IBM对IMS的承诺阻止了System R的投产，一直到1980年System R才作为一个产品正式推向市场。IBM产品化步伐缓慢的三个原因：IBM重视信誉，重视质量，尽量减少故障；IBM是个大公司，官僚体系庞大；IBM内部已经有层次数据库产品，相关人员不积极，甚至反对。

然而同时，1973年加州大学伯克利分校的Michael Stonebraker和Eugene Wong利用System R已发布的信息开始开发自己的关系数据库系统Ingres。他们开发的Ingres项目最后由Oracle公司、Ingres公司以及硅谷的其他厂商所商品化。后来，System R和Ingres系统双双获得ACM的1988年“软件系统奖”。

1976年霍尼韦尔公司(Honeywell)开发了第一个商用关系数据库系统——Multics Relational Data Store。关系型数据库系统以关系代数为坚实的理论基础，经过几十年的发展和实际应用，技术越来越成熟和完善。其代表产品有Oracle、IBM公司的 DB2、微软公司的MS SQL Server以及Informix、ADABASD等等。

结构化查询语言(SQL)

1974 年，IBM的Ray Boyce和Don Chamberlin将Codd关系数据库的12条准则的数学定义以简单的关键字语法表现出来，里程碑式地提出了SQL(Structured Query Language)语言。SQL语言的功能包括查询、操纵、定义和控制，是一个综合的、通用的关系数据库语言，同时又是一种高度非过程化的语言，只要求用户指出做什么而不需要指出怎么做。SQL集成实现了数据库生命周期中的全部操作。SQL提供了与关系数据库进行交互的方法，它可以与标准的编程语言一起工作。自产生之日起，SQL语言便成了检验关系数据库的试金石，而SQL语言标准的每一次变更都指导着关系数据库产品的发展方向。然而，直到二十世纪七十年代中期，关系理论才通过SQL在商业数据库Oracle和DB2中使用。

1986年，ANSI把SQL作为关系数据库语言的美国标准，同年公布了标准SQL文本。目前SQL标准有3个版本。基本SQL定义是ANSIX3135-89，“Database Language - SQL with Integrity Enhancement”[ANS89]，一般叫做SQL-89。SQL-89定义了模式定义、数据操作和事务处理。SQL- 89和随后的ANSIX3168-1989，“Database Language-Embedded SQL”构成了第一代SQL标准。ANSIX3135-1992[ANS92]描述了一种增强功能的SQL，现在叫做SQL-92标准。SQL-92包括模式操作，动态创建和SQL语句动态执行、网络环境支持等增强特性。在完成SQL-92标准后，ANSI和ISO即开始合作开发SQL3标准。SQL3的主要特点在于抽象数据类型的支持，为新一代对象关系数据库提供了标准。

数据库巨人的诞生

——甲骨文公司（Oracle）

1976 年IBM E.F.Codd发表了一篇里程碑的论文“R系统:数据库关系理论”，介绍了关系数据库理论和

查询语言SQL。Oracle的创始人Ellison非常仔细地阅读了这篇文章，被其内容震惊，这是第一次有人用全面一致的方案管理数据信息。作者E.F.Codd十年前就发表了关系数据库理论，并在IBM 研究机构开发原型，这个项目就是R系统，存取数据表的语言就是SQL。Ellison看完后，敏锐意识到在这个研究基础上可以开发商用软件系统。而当时大多数人认为关系数据库不会有商业价值。Ellison认为这是他们的机会:他们决定开发通用商用数据库系统Oracle，这个名字来源于他们曾给中央情报局做过的项目名。几个月后，他们就开发了Oracle 1.0 。但这只不过是个玩具，除了完成简单关系查询不能做任何事情，他们花相当长的时间才使Oracle变得可用，维持公司运转主要靠承接一些数据库管理项目和做顾问咨询工作。而IBM却没有计划开发，为什么蓝色巨人放弃了这个价值上百亿的产品，原因有很多：IBM的研究人员大多是学术出身，他们最感兴趣的是理论，而非推向市场的产品，从学术上看，研究成果应公开，发表论文和演讲能使他们成名，为什么不呢？还有一个很主要的原因就是IBM 当时有一个销售得还不错的层次数据库产品IMS。直到1985年I B M 才发布了关系数据库D B 2 ,Ellision那时已经成了千万富翁。Ellison曾将IBM 选择Microsoft 的MS-DOS作为IBM-PC机的操作系统比为：“世界企业经营历史上最严重的错误，价值超过了上千亿美元。”IBM 发表R系统论文，而且没有很快推出关系数据库产品的错误可能仅仅次之。Oracle 的市值在1996年就达到了280亿美元。

面向对象数据库

随着信息技术和市场的发展，人们发现关系型数据库系统虽然技术很成熟，但其局限性也是显而易见的：它能很好地处理所谓的“表格型数据”，却对技术界出现的越来越多的复杂类型的数据无能为力。九十年代以后，技术界一直在研究和寻求新型数据库系统。但在什么是新型数据库系统的发展方向的问题上，产业界一度是相当困惑的。受当时技术风潮的影响，在相当一段时间内，人们把大量的精力花在研究“面向对象的数据库系统(object oriented database)”或简称“OO数据库系统”。值得一提的是，美国Stonebraker教授提出的面向对象的关系型数据库理论曾一度受到产业界的青睐。而Stonebraker本人也在当时被Informix花大价钱聘为技术总负责人。

然而，数年的发展表明，面向对象的关系型数据库系统产品的市场发展的情况并不理想。理论上的完美性并没有带来市场的热烈反应。其不成功的主要原因在于，这种数据库产品的主要设计思想是企图用新型数据库系统来取代现有的数据库系统。这对许多已经运用数据库系统多年并积累了大量工作数据的客户，尤其是大客户来说，是无法承受新旧数据间的转换而带来的巨大工作量及巨额开支的。另外，面向对象的关系型数据库系统使查询语言变得极其复杂，从而使得无论是数据库的开发商家还是应用客户都视其复杂的应用技术为畏途。

数据管理的变革

二十世纪六十年代后期出现了一种新型数据库软件：决定支持系统(DSS)，其目的是让管理者在决策过程中更有效地利用数据信息。于是在1970年， 第一个联机分析处理工具——Express诞生了。其他决策支持系统紧随其后，许多是由公司的IT部门开发出来的。

1985年，第一个商务智能系统(business intelligence)由Metaphor计算机系统有限公司为Procter & Gamble公司开发出来，主要是用来连接销售信息和零售的扫描仪数据。同年， Pilot 软件公司开始出售第一个商用客户/服务器执行信息系统——Command Center。同样在这年，加州大学伯克利分校Ingres项目演变成Postgres，其目标是开发出一个面向对象的数据库。此后一年， Graphael公司开发了第一个商用的对象数据库系统—Gbase。

1988年，IBM公司的研究者Barry Devlin和Paul Murphy发明了一个新的术语—信息仓库，之后，IT的厂商开始构建实验性的数据仓库。1991年，W.H. "Bill" Inmon出版了一本“如何构建数据仓库”的书，使得数据仓库真正开始应用。

1991： W.H.“Bill” Inmon发表了”构建数据仓库”

二十世纪九十年代，随着基于PC的客户/服务器计算模式和企业软件包的广泛采用，数据管理的变革基本完成。数据管理不再仅仅是存储和管理数据，而转变成用户所需要的各种数据管理的方式。Internet的异军突起以及XML语言的出现，给数据库系统的发展开辟了一片新的天地。

非关系型（无模式文档型）数据库

随着互联网web2.0网站的兴起，非关系型的数据库现在成了一个极其热门的新领域，非关系数据库产品的发展非常迅速。而传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，例如：

1、High performance – 对数据库高并发读写的需求

web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘IO就已经无法承受了。其实对于普通的BBS网站，往往也存在对高并发写请求的需求，例如像JavaEye网站的实时统计在线用户状态，记录热门帖子的点击次数，投票计数等，因此这是一个相当普遍的需求。

2、Huge Storage – 对海量数据的高效率存储和访问的需求

类似Facebook，twitter，Friendfeed这样的SNS网站，每天用户产生海量的用户动态，以Friendfeed为例，一个月就达到了2.5亿条用户动态，对于关系数据库来说，在一张2.5亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的。再例如大型web网站的用户登录系统，例如腾讯，盛大，动辄数以亿计的帐号，关系数据库也很难应付。

3、High Scalability && High Availability- 对数据库的高可扩展性和高可用性的需求

在基于web的架构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，你的数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移，为什么数据库不能通过不断的添加服务器节点来实现扩展呢？

在上面提到的“三高”需求面前，关系数据库遇到了难以克服的障碍，而对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地，例如：

1、数据库事务一致性需求

很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求也不高。因此数据库事务管理成了数据库高负载下一个沉重的负担。

2、数据库的写实时性和读实时性需求

对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应用来说，并不要求这么高的实时性，比方说我（JavaEye的robbin）发一条消息之后，过几秒乃至十几秒之后，我的订阅者才看到这条动态是完全可以接受的。

3、对复杂的SQL查询，特别是多表关联查询的需求

任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询，特别是SNS类型的网站，从需求以及产品设计角度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。

因此，关系数据库在这些越来越多的应用场景下显得不那么合适了，为了解决这类问题的非关系数据库应运而生，各种各样非关系数据库，特别是键值数据库(Key-Value Store DB)风起云涌，多得让人眼花缭乱。

发展阶段

数据库发展阶段大致划分为如下几个阶段：人工管理阶段、文件系统阶段、数据库系统阶段、高级数据库阶段。

人工管理阶段

50年代中期之前，计算机的软硬件均不完善。硬件存储设备只有磁带、卡片和纸带，软件方面还没有操作系统，当时的计算机主要用于科学计算。这个阶段由于还没有软件系统对数据进行管理，程序员在程序中不仅要规定数据的逻辑结构，还要设计其物理结构，包括存储结构、存取方法、输入输出方式等。当数据的物理组织或存储设备改变时，用户程序就必须重新编制。由于数据的组织面向应用，不同的计算程序之间不能共享数据，使得不同的应用之间存在大量的重复数据，很难维护应用程序之间数据的一致性。

这一阶段的主要特征可归纳为如下几点：

*计算机中没有支持数据管理的软件。

*数据组织面向应用，数据不能共享，数据重复。

*在程序中要规定数据的逻辑结构和物理结构，数据与程序不独立。

*数据处理方式——批处理。

文件系统阶段

这一阶段的主要标志是计算机中有了专门管理数据库的软件——操作系统（文件管理）。

上世纪50年代中期到60年代中期，由于计算机大容量存储设备（如硬盘）的出现，推动了软件技术的发展，而操作系统的出现标志着数据管理步入一个新的阶段。在文件系统阶段，数据以文件为单位存储在外存，且由操作系统统一管理。操作系统为用户使用文件提供了友好界面。文件的逻辑结构与物理结构脱钩，程序和数据分离，使数据与程序有了一定的独立性。用户的程序与数据可分别存放在外存储器上，各个应用程序可以共享一组数据，实现了以文件为单位的数据共享。

但由于数据的组织仍然是面向程序，所以存在大量的数据冗余。而且数据的逻辑结构不能方便地修改和扩充，数据逻辑结构的每一点微小改变都会影响到应用程序。由于文件之间互相独立，因而它们不能反映现实世界中事物之间的联系，操作系统不负责维护文件之间的联系信息。如果文件之间有内容上的联系，那也只能由应用程序去处理。

数据库系统阶段

60年代后，随着计算机在数据管理领域的普遍应用，人们对数据管理技术提出了更高的要求：希望面向企业或部门，以数据为中心组织数据，减少数据的冗余，提供更高的数据共享能力，同时要求程序和数据具有较高的独立性，当数据的逻辑结构改变时，不涉及数据的物理结构，也不影响应用程序，以降低应用程序研制与维护的费用。数据库技术正是在这样一个应用需求的基础上发展起来的。

数据库技术有如下特点：

* 面向企业或部门，以数据为中心组织数据，形成综合性的数据库，为各应用共享。

* 采用一定的数据模型。数据模型不仅要描述数据本身的特点，而且要描述数据之间的联系。

* 数据冗余小，易修改、易扩充。不同的应用程序根据处理要求，从数据库中获取需要的数据，这样就减少了数据的重复存储，也便于增加新的数据结构，便于维护数据的一致性。

* 程序和数据有较高的独立性。

* 具有良好的用户接口，用户可方便地开发和使用数据库。

* 对数据进行统一管理和控制，提供了数据的安全性、完整性、以及并发控制。

从文件系统发展到数据库系统，这在信息领域中具有里程碑的意义。在文件系统阶段，人们在信息处理中关注的中心问题是系统功能的设计，因此程序设计占主导地位；而在数据库方式下，数据开始占据了中心位置，数据的结构设计成为信息系统首先关心的问题，而应用程序则以既定的书结构为基础进行设计。大事记

1951：Univac系统使用磁带和穿孔卡片作为数据存储。

1956：IBM公司在其Model 305 RAMAC中第一次引入了磁盘驱动器

1961：通用电气(GE)公司的Charles Bachman开发了第一个数据库管理系统——IDS

1969：E.F. Codd发明了关系数据库。

1973： 由John J.Cullinane领导Cullinane公司开发了 IDMS——一个针对IBM主机的基于网络模型的数据库。

1976： Honeywell公司推出了Multics Relational Data Store——第一个商用关系数据库产品。

1979： Oracle公司引入了第一个商用SQL关系数据库管理系统。

1983： IBM 推出了DB2数据库产品。

1985： 为Procter & Gamble系统设计的第一个商务智能系统产生。

1991： W.H.“Bill” Inmon发表了”构建数据仓库”。

未来发展趋势

随着信息管理内容的不断扩展，出现了丰富多样的数据模型（层次模型，网状模型，关系模型，面向对象模型，半结构化模型等），新技术也层出不穷（数据流，Web数据管理，数据挖掘等）。目前每隔几年，国际上一些资深的数据库专家就会聚集一堂，探讨数据库研究现状，存在的问题和未来需要关注的新技术焦点。过去已有的几个类似报告包括：1989 年Future Directions inDBMS Research-The Laguna BeachParticipants ，1990 年DatabaseSystems : Achievements and Opportunities ，1995 年的Database 1991：W.H. Inmon 发表了《构建数据仓库》

基本属性

基本结构

数据库的基本结构分三个层次，反映了观察数据库的三种不同角度。

(1)物理数据层。

它是数据库的最内层，是物理存贮设备上实际存储的数据的集合。这些数据是原始数据，是用户加工的对象，由内部模式描述的指令操作处理的位串、字符和字组成。

(2)概念数据层。

它是数据库的中间一层，是数据库的整体逻辑表示。指出了每个数据的逻辑定义及数据间的逻辑联系，是存贮记录的集合。它所涉及的是数据库所有对象的逻辑关系，而不是它们的物理情况，是数据库管理员概念下的数据库。

(3)逻辑数据层。

它是用户所看到和使用的数据库，表示了一个或一些特定用户使用的数据集合，即逻辑记录的集合。

数据库不同层次之间的联系是通过映射进行转换的。

主要特点

(1)实现数据共享。

数据共享包含所有用户可同时存取数据库中的数据，也包括用户可以用各种方式通过接口使用数据库，并提供数据共享。

(2)减少数据的冗余度。

同文件系统相比，由于数据库实现了数据共享，从而避免了用户各自建立应用文件。减少了大量重复数据，减少了数据冗余，维护了数据的一致性。

(3)数据的独立性。

数据的独立性包括数据库中数据库的逻辑结构和应用程序相互独立，也包括数据物理结构的变化不影响数据的逻辑结构。

(4)数据实现集中控制。

文件管理方式中，数据处于一种分散的状态，不同的用户或同一用户在不同处理中其文件之间毫无关系。利用数据库可对数据进行集中控制和管理，并通过数据模型表示各种数据的组织以及数据间的联系。

(5)数据一致性和可维护性，以确保数据的安全性和可靠性。

主要包括：①安全性控制：以防止数据丢失、错误更新和越权使用；②完整性控制：保证数据的正确性、有效性和相容性；③并发控制：使在同一时间周期内，允许对数据实现多路存取，又能防止用户之间的不正常交互作用；④故障的发现和恢复：由数据库管理系统提供一套方法，可及时发现故障和修复故障，从而防止数据被破坏

(6)故障恢复。

由数据库管理系统提供一套方法，可及时发现故障和修复故障，从而防止数据被破坏。数据库系统能尽快恢复数据库系统运行时出现的故障，可能是物理上或是逻辑上的错误。比如对系统的误操作造成的数据错误等。

种类

数据库通常分为层次式数据库、网络式数据库和关系式数据库三种。而不同的数据库是按不同的数据结构来联系和组织的。

1.数据结构模型

(1)数据结构

所谓数据结构是指数据的组织形式或数据之间的联系。如果用D表示数据，用R表示数据对象之间存在的关系集合，则将DS=(D，R)称为数据结构。例如，设有一个电话号码簿，它记录了n个人的名字和相应的电话号码。为了方便地查找某人的电话号码，将人名和号码按字典顺序排列，并在名字的后面跟随着对应的电话号码。这样，若要查找某人的电话号码(假定他的名字的第一个字母是Y)，那么只须查找以Y开头的那些名字就可以了。该例中，数据的集合D就是人名和电话号码，它们之间的联系R就是按字典顺序的排列，其相应的数据结构就是DS=(D，R)，即一个数组。

(2)数据结构种类

数据结构又分为数据的逻辑结构和数据的物理结构。数据的逻辑结构是从逻辑的角度(即数据间的联系和组织方式)来观察数据，分析数据，与数据的存储位置无关。数据的物理结构是指数据在计算机中存放的结构，即数据的逻辑结构在计算机中的实现形式，所以物理结构也被称为存储结构。这里只研究数据的逻辑结构，并将反映和实现数据联系的方法称为数据模型。

目前，比较流行的数据模型有三种，即按图论理论建立的层次结构模型和网状结构模型以及按关系理论建立的关系结构模型。

2.层次、网状和关系数据库系统

(1)层次结构模型

层次结构模型实质上是一种有根结点的定向有序树(在数学中"树"被定义为一个无回的连通图)。下图是一个高等学校的组织结构图。这个组织结构图像一棵树，校部就是树根(称为根结点)，各系、专业、教师、学生等为枝点(称为结点)，树根与枝点之间的联系称为边，树根与边之比为1:N，即树根只有一个，树枝有N个。

按照层次模型建立的数据库系统称为层次模型数据库系统。IMS(Information Manage-mentSystem)是其典型代表。

(2)网状结构模型

按照网状数据结构建立的数据库系统称为网状数据库系统，其典型代表是DBTG(Data Base Task Group)。用数学方法可将网状数据结构转化为层次数据结构。

(3)关系结构模型

关系式数据结构把一些复杂的数据结构归结为简单的二元关系(即二维表格形式)。例如某单位的职工关系就是一个二元关系。

由关系数据结构组成的数据库系统被称为关系数据库系统。

在关系数据库中，对数据的操作几乎全部建立在一个或多个关系表格上，通过对这些关系表格的分类、合并、连接或选取等运算来实现数据的管理。dBASEII就是这类数据库管理系统的典型代表。对于一个实际的应用问题(如人事管理问题)，有时需要多个关系才能实现。用dBASEII建立起来的一个关系称为一个数据库(或称数据库文件)，而把对应多个关系建立起来的多个数据库称为数据库系统。dBASEII的另一个重要功能是通过建立命令文件来实现对数据库的使用和管理，对于一个数据库系统相应的命令序列文件，称为该数据库的应用系统。因此，可以概括地说，一个关系称为一个数据库，若干个数据库可以构成一个数据库系统。数据库系统可以派生出各种不同类型的辅助文件和建立它的应用系统。

常用数据库

麦杰的实时数据库

实时数据库系统介绍

实时数据库系统是数据库理论在新领域的扩展，在电力、化工、钢铁、冶金、造纸、交通控制和证券金融等领域有着非常广阔的应用前景。它可以为企业提供高速、及时的实时数据服务，能够对快速变化的实时数据进行长期高效的历史存储，是工厂控制层（现场总线、DCS、PLC等）与生产管理系统之间连接的桥梁，同时也是流程模拟、先进控制、在线优化、故障诊断等系统的数据平台。

openPlant实时数据库系统采用当今先进的技术和架构，可安全、稳定地实现与现场各控制系统的接口，并能对采集来的数据进行高效的数据压缩和长期的历史存储，同时提供方便易用的客户端应用和通用的数据接口（API/DDE/ODBC/JDBC/OPC等），使企业的管理和决策人员能及时、全面的了解当前的生产情况，也可回顾过去的生产情况，及时发现生产中所存在的问题，提高设备利用率，降低生产成本，增强企业的核心竞争力。

实时数据库系统特点

企业级的生产实时数据平台

分布式数据库架构，满足集团级需求

实时访问全厂生产数据

高效的数据压缩和长期历史存储

支持在线计算和统计

专业的图形仿真技术，监视画面与控制系统完全一致

丰富的客户端应用工具

优异的跨平台性能，支持Unix/Linux/Windows等操作系统

开放的数据接口，如API/DDE/ODBC/JDBC/OPC

200,000点上万小时现场稳定运行考验

支持远程访问，随时随地享用生产信息

个性化定制服务，让您从容应对不断变化的用户需求

IBM 的DB2

作为关系数据库领域的开拓者和领航人，IBM在1977年完成了System R系统的原型，1980年开始提供集成的数据库服务器—— System/38，随后是SQL/DSforVSE和VM，其初始版本与SystemR研究原型密切相关。DB2 forMVSV1 在1983年推出。该版本的目标是提供这一新方案所承诺的简单性，数据不相关性和用户生产率。1988年DB2 for MVS 提供了强大的在线事务处理（OLTP）支持，1989 年和1993 年分别以远程工作单元和分布式工作单元实现了分布式数据库支持。最近推出的DB2 Universal Database 6.1则是通用数据库的典范，是第一个具备网上功能的多媒体关系数据库管理系统，支持包括Linux在内的一系列平台。

Oracle

Oracle前身叫SDL，由Larry Ellison 和另两个编程人员在1977创办，他们开发了自己的拳头产品，在市场上大量销售，1979 年，Oracle公司引入了第一个商用SQL 关系数据库管理系统。Oracle公司是最早开发关系数据库的厂商之一，其产品支持最广泛的操作系统平台。目前Oracle关系数据库产品的市场占有率名列前茅。现在Oracle数据库包含三种：大型数据库（主流是10g/11g）、My Sql数据库、内存数据库。

Informix

Informix在1980年成立，目的是为Unix等开放操作系统提供专业的关系型数据库产品。公司的名称Informix便是取自Information 和Unix的结合。Informix第一个真正支持SQL语言的关系数据库产品是Informix SE（StandardEngine）。InformixSE是在当时的微机Unix环境下主要的数据库产品。它也是第一个被移植到Linux上的商业数据库产品。

Sybase

Sybase公司成立于1984年，公司名称“Sybase”取自“system”和“database” 相结合的含义。Sybase公司的创始人之一Bob Epstein 是Ingres 大学版（与System/R同时期的关系数据库模型产品）的主要设计人员。公司的第一个关系数据库产品是1987年5月推出的Sybase SQLServer1.0。Sybase首先提出Client/Server数据库体系结构的思想，并率先在Sybase SQLServer 中实现。

SQL Server

1987 年，微软和IBM合作开发完成OS/2，IBM 在其销售的OS/2 ExtendedEdition 系统中绑定了OS/2Database Manager，而微软产品线中尚缺少数据库产品。为此，微软将目光投向Sybase，同Sybase 签订了合作协议，使用Sybase的技术开发基于OS/2平台的关系型数据库。1989年，微软发布了SQL Server 1.0 版。

PostgreSQL

PostgreSQL 是一种特性非常齐全的自由软件的对象——关系性数据库管理系统（ORDBMS），它的很多特性是当今许多商业数据库的前身。PostgreSQL最早开始于BSD的Ingres项目。PostgreSQL 的特性覆盖了SQL-2/SQL-92和SQL-3。首先，它包括了可以说是目前世界上最丰富的数据类型的支持；其次，目前PostgreSQL 是唯一支持事务、子查询、多版本并行控制系统、数据完整性检查等特性的唯一的一种自由软件的数据库管理系统.

mySQL

MySQL是一个小型关系型数据库管理系统，开发者为瑞典MySQL AB公司。在2008年1月16号被Sun公司收购。而2009年，SUN又被Oracle收购。对于Mysql的前途，没有任何人抱乐观的态度。目前MySQL被广泛地应用在Internet上的中小型网站中。由于其体积小、速度快、总体拥有成本低，尤其是开放源码这一特点，许多中小型网站为了降低网站总体拥有成本而选择了MySQL作为网站数据库。

Access数据库

美国Microsoft公司于1994年推出的微机数据库管理系统。它具有界面友好、易学易用、开发简单、接口灵活等特点，是典型的新一代桌面数据库管理系统。其主要特点如下：

(1)完善地管理各种数据库对象，具有强大的数据组织、用户管理、安全检查等功能。

(2)强大的数据处理功能，在一个工作组级别的网络环境中，使用Access开发的多用户数据库管理系统具有传统的XBASE(DBASE、FoxBASE的统称)数据库系统所无法实现的客户服务器(Cient/Server)结构和相应的数据库安全机制，Access具备了许多先进的大型数据库管理系统所具备的特征，如事务处理/出错回滚能力等。

(3)可以方便地生成各种数据对象，利用存储的数据建立窗体和报表，可视性好。

(4)作为Office套件的一部分，可以与Office集成，实现无缝连接。

(5)能够利用Web检索和发布数据，实现与Internet的连接。 Access主要适用于中小型应用系统，或作为客户机/服务器系统中的客户端数据库。

SQLite

SQLite是遵守ACID的关联式资料库管理系统，它包含在一个相对小的C库中。它是D.RichardHipp建立的公有领域项目。不像常见的客户端/服务器结构范例，SQLite引擎不是个程序与之通信的独立进程，而是连接到程序中成为它的一个主要部分。所以主要的通信协议是在编程语言内的直接API调用。这在消耗总量、延迟时间和整体简单性上有积极的作用。整个数据库（定义、表、索引和数据本身）都在宿主主机上存储在一个单一的文件中。它的简单的设计是通过在开始一个事务的时候锁定整个数据文件而完成的。

FoxPro数据库

最初由美国Fox公司1988年推出，1992年Fox公司被Microsoft公司收购后，相继推出了FoxPro2.5、2.6和VisualFoxPro等版本，其功能和性能有了较大的提高。 FoxPro2.5、2.6分为DOS和Windows两种版本，分别运行于DOS和Windows环境下。FoxPro比FoxBASE在功能和性能上又有了很大的改进，主要是引入了窗口、按纽、列表框和文本框等控件，进一步提高了系统的开发能力。

INFOBANK数据库

INFOBANK数据库，中国资讯行1995年推出，经历17年的发展，已成为全球最大的中文商业信息数据库之一。

INFOBANK采集来自国内1200多家媒体、国外100家媒体的公开信息，同时与国内百余家官方和行业权威机构合作，为广大用户提供丰富的中文商业信息。

INFOBANK由14个子数据库组成，100亿的汉字储量，累计包含专业文献超过600万篇，资讯内容涉及19个大类，197个行业，日增新250万汉字。同时还设有特点栏目，满足用户撰写论文、了解行业信息等多样化需求。

SOSHOO网

搜数网，中国资讯行于2006年推出，是以统计数据为核心的数据垂直搜索网站，商业数据逾200,000,000条，囊括4000多本年鉴，涵盖760,000张统计表格。时间跨度自1949年至今，覆盖全国31个省级行政区域并深入254个地级、市级、县级行政区域，同时包括部分台港澳以及国际部分地区统计资料。数据内容涉及54个行业大类。

网站数据库的安全隐患

（一）、导致安全问题存在的原因

目前导致电子商务网站数据库存在安全隐患的原因主要表现在以下几个方面：（1）用户对数据库的不正确访问，引起数据库数据的错误；（2）为了某种目的，故意破坏数据库，使其不能恢复；（3）非法访问不该访问的数据库信息，但又不留痕迹；（4）用户通过网络进行数据库访问时，有可能受到各种技术（如搭线窃听等）的攻击；（5）非法用户绕过安全内核，窃取信息资源等现象；（6）未经授权非法修改数据库数据，使其数据失去真实性等等。

（二）ASP带来的安全问题

1.ASP程序源代码的隐患

由于ASP程序采用的是非编译性语言，这大大降低了程序源代码的安全性。任何人只要进入站点，就可以获得源代码，从而造成ASP应用程序源代码的泄露。 2.程序设计中的安全隐患

ASP代码利用表单（form）实现与用户交互的功能，而相应的内容会反映在浏览器的地址栏中，如果不采用适当的安全措施，只要记下这些内容，就可以绕过验证直接进入某一页面。例如在浏览器中敲入“page.asp?x=1”，即可不经过表单页面直接进入满足“x=1”条件的页面。因此，在设计验证或注册页面时，必须采取特殊措施来避免此类问题的发生。

二、保护电子商务网站数据库安全的方法

（一）非常规命名法

修改数据库的主文件名。防止数据库被找到的简便方法是为Access数据库文件起一个复杂的非常规名字，并把它存放在多层目录下。例如，对于网上花店的数据库文件，不要简单地命名为“flower.mdb”或“bloom.mdb”，而是要起个非常规的名字，例如：halower123.mdb，再把它放在如/wh123/wd123d/hoo9/dh123/abc之类的深层目录下。这样攻击者想简单地猜测数据库的位置就很困难了。另外，把mdb扩展名修改为ASP或ASA等不影响数据查询的名字

但是有时候修改为ASP或者ASA以后仍然可以被下载，如将mdb修改为ASP以后，直接在IE的地址栏里输入企业提供安全高效的信息服务。

（二）使用ODBC数据源

在ASP程序设计中，应尽量使用ODBC数据源，不要把数据库名直接写在程序中。　如果，ASP源代码失密后，数据库也很容易被下载下来。如果使用ODBC数据源，就不会存在这样的问题了。

（三）加密ASP页面

可以使用微软公司的免费软件Script Encoder对ASP页面进行加密。它可以对当前目录中的所有的ASP文件进行加密，并把加密后的文件统一输出到相应的目录中。由于Script Encoder只加密在HTML页面中嵌入的ASP代码，其他部分仍保持不变，这就使得我们仍然可以使用FrontPage等常用网页编辑工具对HTML部分进行修改、完善，操作起来简单方便、效果良好。

（四）利用Session对象进行注册验证

为防止未经注册的用户绕过注册界面直接进入应用系统，可以采用Session对象进行注册验证。Session对象最大的优点是可以把某用户的信息保留下来，让后续的网页读取。一般情况，在设计网站时都要求用户注册成功后才可登录。但如果不采用Session对象进行注册验证，则用户在浏览器中敲入“URL/hrmis.asp?page=1”即可绕过注册界面，直接进入系统。利用Session对象可以有效阻止这一情况的发生。

三、保障电子商务网站数据库安全的措施

（一）、存在漏洞的保护措施

1、数据库文件名应复杂

下载Access数据库文件，首先必须知道该数据库文件的存储路径和文件名。如果你将原本非常简单的数据库文件名修改得更加复杂，这样那些“不怀好意”者就要花费更多的时间去猜测数据库文件名，无形中增强了Access数据库的安全性。很多ASP程序为方便用户使用，它的数据库文件通常都被命名为“data.mdb”，这大大方便了有经验的攻击者。如果我们将数据库文件名修改得复杂一些，他人就不易猜到，如将“data.mdb”修改为“1rtj0ma27xi.mdb”,然后修改数据库连接文件中的相应信息。这样Access数据库就相对安全一些。此方法适合于那些租用Web空间的用户使用。

但其不足之处是，一旦查看到数据库连接文件中的内容，再复杂的文件名也无济于事。

2、利用ODBC数据源

很多网站Web程序，将Access数据库文件的存储路径和文件名存放在数据库连接文件中。一旦这些连接文件中的内容外泄，那么不管数据库文件名多么复杂，都会暴露出踪迹。

这时就可以使用ODBC数据源方法，即使连接文件的内容外泄，他人也只能知道网站程序所使用的ODBC数据源名称，而数据库文件的存储路径和文件名却无法找到。接着在IIS服务器中新建名为“rtjmaxi”的ODBC数据源，并在其中指定“1rtj0ma27xi.mdb”数据库文件的位置即可，最后点击“确定”按钮完成配置。

但其不足之处是，此方法不适合于租用Web空间的用户使用，要想使用ODBC数据源方法，必须要有管理和维护IIS服务器的权限。

3、改变存储位置

一般情况下，Access数据库文件存放在相应的Web目录中，很多黑客就是利用这种规律来查找并下载数据库文件。因此可以采用改变数据库文件存储位置的方法，将数据库文件存放在Web目录以外的某个文件夹中，让黑客难以猜测存储位置。接着修改好数据库连接文件中的数据库文件相应信息，这样Access数据库文件就安全多了。即使攻击者通过连接文件找到数据库文件的存储路径，由于数据库文件存放在Web目录以外的地方，攻击者就无法通过HTTP方式下载数据库文件。但其不足之处是，此方法不适合于租用Web空间的用户使用，因为将Access数据库文件移至Web目录之外，一般需要很大的权限。

以上方法，在不同程度上增强了数据库文件的安全性，但我们不能将它们当成“仙丹妙药”，毕竟网络环境是复杂的，黑客的破坏手段也在不断增强，我们可以根据自己的需要，选择其中的多种方法配合使用，效果才会更理想，网站数据库后台文件才会更加安全。

（二）、网站数据库管理安全的措施

服务器管理员还应在IIS中为每个网站设置好执行权限，可千万别给人家静态网站以"脚本和可执行"权限。一般情况下给个"纯脚本"权限就够了，对于那些通过网站后台管理中心上传的文件存放的目录，就更吝啬一点吧，执行权限设为"无"好了，这样做是为了防止人家上传ASP木马，执行权限设为"无"，人家上传ASP木马也运行不了。一般情况下，SQL注入漏洞仅是涉及一个网站安全的事，如果人家通过这个漏洞上传了ASP木马并运行起来，那整个服务器都失陷了。所以有远见的、有责任心的服务器管理员应该十分吝啬的配置IIS的执行权限。

程序员主要要做两件事，最重要的一件事，当然是对客户端提交的变量参数进行仔细地检测。对客户端提交的变量进行检查以防止SQL注入。二是给用户密码加密。比如用MD5加密。MD5是没有反向算法,不能解密的。人家即使知道经加密后存在数据库里的像乱码一样的密码，他也没办法知道原始密码了。

数据库病毒检查方法

1:使用恶意软件扫描器

有的数据库服务器因为怕性能下降或者系统崩溃而不采取，或者采取有限的恶意软件防范措施。所以如果没有安装反病毒软件，就尽快安装一个杀毒软件。如果需要实时保护的资源太多了，那么就要将数据库和其它高活动性的目录排除在实时扫描的外面吧。否则，最低限度，也要安装反病毒软件，然后每隔几天，找个非高峰的时间来扫描本地磁盘。

如果已经运行了反病毒软件，那么确保它是最新的（那些基于客户端的自动更新和网络管理签名并不是百分百的可靠），并且执行一次全面的系统扫描。

2: 查看内存

可以使用Windows任务管理器来搜索那些看起来就属于恶意软件，或者使用了太多内存或者占用了大量CPU时间的应用程序。建议使用Sysinternals公司的Process Explorer（下面高亮显示的NetBus Trojan），因为它提供了运行进程的较多信息，并且以更可靠的方式来杀掉那些不应该的进程。

在网络中的所有系统中，确实需要彻底地了解数据库——其中包括记录哪些进程应该运行，哪些不应该。所以，如果在第一次安装之后拥有了良好的基线——甚至是现在，假设所有事物都运行得很好——当发生特洛伊类型的问题的时候，就可以用它作为比较的基础。

3: 查看开放的端口

可以使用Windows内置的netstat工具来查看哪些端口开放的，并且连接到服务器上。在命令行中，输入netstat –an　more，可以一页挨着一页地查看开放的和监听的TCP和UDP端口。还有一种更好的方法就是使用Foundstone的 Vision工具或者Sysinternals公司的TCPView工具来完成。

4: 查看网络流量

也许判断SQL Server中是否发生了恶意行为的最简单办法就是看看它是否进行了网络通信。如果有一个非常顺手的网络分析器，那么就可以在1、2分钟之内发现情况。可以使用SQL Server自身携带的分析器，或者从别处连接到以太网交换器的交换或者镜像端口上。

EtherPeek可以轻松抓取网络流量，并且高亮显示特洛伊的动作——在本次网络流量抓取过程中可以真正地创建网络分析触发器和过滤器，如果知道要寻找什么的话。这里的列表列出了常见的特洛伊和相关端口的细腻向。这种发现恶意流量的方法并不是十分安全，因为端口号是可以经常更换的，但是它的服务器是个不错的目标。

可以在“监控”模式下运行Ether Peek，让它对网络上发生的事情有个从上到下的整体视角，——而不需要抓取包。可以查看正在使用哪个协议，寻找巨大的流量，奇怪的通信，以及其它网络进出SQL Server系统的倾向。

5:对付恶意软件的方法

特洛伊木马是计算机上的一个令人厌恶的创造——它创建远程访问隧道，截获按键，删除数据等更多事情——特别是在最重要的服务器上。很明显，最好的办法就是不用SQL Server进行Internet访问，Web浏览，电子邮件等行为。——但是，这不现实。（或者其他人）可能会需要它最终不仅仅作为一个数据库服务器。一旦这样的事情出现了，就需要确保是被保护的。不要把责任推卸给其他人，或者其他任何东西，特洛伊不是运行在他们的系统上。不论以何种方式，永远不要假设反病毒软件可以保证万无一失。

分析并解决恶意软件的方法：如果想要攻击，或者安装一个可以在网络上给帮助的欺诈软件，那么没有什么地方比直接在SQL Server上更好了。服务器上可能还没有特洛伊，但是如果感觉到有问题，那么凶手就可以很容易发现。

数据库查询优化原则

1.对数据库查询进行优化，应尽量避免全表扫描，首先应考虑在where 及order by 涉及的列上建立索引。

2.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：

select id from t where num is null

可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：

select id from t where num=0

3.应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。

4.应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：

select id from t where num=10 or num=20

可以这样查询：

select id from t where num=10

union all

select id from t where num=20

5. in 和 not in 也要慎用，否则会导致全表扫描，如：

select id from t where num in(1，2，3)

对于连续的数值，能用 between 就不要用 in 了：

select id from t where num between 1 and 3

6.下面的查询也将导致全表扫描：

select id from t where name like '%abc%'

若要提高效率，可以考虑全文检索。

7.如果在 where 子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时;它必须在编译时进行选择。然而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描：

select id from t wherenum=@num

可以改为强制查询使用索引：

select id from t with(index(索引名)) wherenum=@num

8.应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：

select id from t where num/2=100

应改为：

select id from t where num=100*2

9.应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如：

select id from t where substring(name，1，3)='abc'--name以abc开头的id

select id from t where datediff(day，createdate，'2005-11-30')=0--‘2005-11-30’生成的id