数据库常见面试题
1. 主键 超键 候选键 外键
表中对储存数据对象予以唯一和完整标识的数据列或属性的组合。一个数据列只能有一个主键，且主键的取值不能缺失，即不能为空值（Null）。
在关系中能唯一标识元组的属性集称为关系模式的超键。一个属性可以为作为一个超键，多个属性组合在一起也可以作为一个超键。超键包含候选键和主键。
是最小超键，即没有冗余元素的超键。
在一个表中存在的另一个表的主键称此表的外键。
2.数据库事务的四个特性及含义
数据库事务transanction正确执行的四个基本要素。ACID,原子性(Atomicity)、一致性(Correspondence)、隔离性(Isolation)、持久性(Durability)。
原子性:整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
一致性:在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。
隔离性:隔离状态执行事务，使它们好像是在给定时间内执行的唯一操作。如果有两个事务，运行在相同的时间内，执行 相同的功能，事务的隔离性将确保每一事务在系统中认为只有该事务在使用系统。这种属性有时称为串行化，为了防止事务操作间的混淆，必须串行化或序列化请 求，使得在同一时间仅有一个请求用于同一数据。
持久性:在事务完成以后，该事务所对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。
3.视图的作用，视图可以更改么？
视图是虚拟的表，与包含数据的表不一样，视图只包含使用时动态检索数据的查询；不包含任何列或数据。使用视图可以简化复杂的sql操作，隐藏具体的细节，保护数据；视图创建后，可以使用与表相同的方式利用它们。
视图不能被索引，也不能有关联的触发器或默认值，如果视图本身内有order by 则对视图再次order by将被覆盖。
创建视图：create view XXX as XXXXXXXXXXXXXX;
对于某些视图比如未使用联结子查询分组聚集函数Distinct Union等，是可以对其更新的，对视图的更新将对基表进行更新；但是视图主要用于简化检索，保护数据，并不用于更新，而且大部分视图都不可以更新。
4.drop,delete与truncate的区别
drop直接删掉表 truncate删除表中数据，再插入时自增长id又从1开始 delete删除表中数据，可以加where字句。
（1） DELETE语句执行删除的过程是每次从表中删除一行，并且同时将该行的删除操作作为事务记录在日志中保存以便进行进行回滚操作。TRUNCATE TABLE 则一次性地从表中删除所有的数据并不把单独的删除操作记录记入日志保存，删除行是不能恢复的。并且在删除的过程中不会激活与表有关的删除触发器。执行速度快。
（2） 表和索引所占空间。当表被TRUNCATE 后，这个表和索引所占用的空间会恢复到初始大小，而DELETE操作不会减少表或索引所占用的空间。drop语句将表所占用的空间全释放掉。
（3） 一般而言，drop & truncate & delete
（4） 应用范围。TRUNCATE 只能对TABLE；DELETE可以是table和view
（5） TRUNCATE 和DELETE只删除数据，而DROP则删除整个表（结构和数据）。
（6） truncate与不带where的delete ：只删除数据，而不删除表的结构（定义）drop语句将删除表的结构被依赖的约束（constrain),触发器（trigger)索引（index);依赖于该表的存储过程/函数将被保留，但其状态会变为：invalid。
（7） delete语句为DML（data maintain Language),这个操作会被放到 rollback segment中,事务提交后才生效。如果有相应的 tigger,执行的时候将被触发。
（8） truncate、drop是DLL（data define language),操作立即生效，原数据不放到 rollback segment中，不能回滚
（9） 在没有备份情况下，谨慎使用 drop 与 truncate。要删除部分数据行采用delete且注意结合where来约束影响范围。回滚段要足够大。要删除表用若想保留表而将表中数据删除，如果于事务无关，用truncate即可实现。如果和事务有关，或老师想触发trigger,还是用delete。
（10） Truncate table 表名 速度快,而且效率高,因为:
truncate table 在功能上与不带 WHERE 子句的 DELETE 语句相同：二者均删除表中的全部行。但 TRUNCATE TABLE 比 DELETE 速度快，且使用的系统和事务日志资源少。DELETE 语句每次删除一行，并在事务日志中为所删除的每行记录一项。TRUNCATE TABLE 通过释放存储表数据所用的数据页来删除数据，并且只在事务日志中记录页的释放。
（11） TRUNCATE TABLE 删除表中的所有行，但表结构及其列、约束、索引等保持不变。新行标识所用的计数值重置为该列的种子。如果想保留标识计数值，请改用 DELETE。如果要删除表定义及其数据，请使用 DROP TABLE 语句。
（12） 对于由 FOREIGN KEY 约束引用的表，不能使用 TRUNCATE TABLE，而应使用不带 WHERE 子句的 DELETE 语句。由于 TRUNCATE TABLE 不记录在日志中，所以它不能激活触发器。
5.索引的工作原理及其种类
数据库索引，是数据库管理系统中一个排序的数据结构，以协助快速查询、更新数据库表中数据。索引的实现通常使用B树及其变种B+树。
在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式引用（指向）数据，这样就可以在这些数据结构上实现高级查找算法。这种数据结构，就是索引。
为表设置索引要付出代价的：一是增加了数据库的存储空间，二是在插入和修改数据时要花费较多的时间(因为索引也要随之变动)。
上图展示了一种可能的索引方式。左边是数据表，一共有两列七条记录，最左边的是数据记录的物理地址（注意逻辑上相邻的记录在磁盘上也并不是一定物理相邻的）。为了加快Col2的查找，可以维护一个右边所示的二叉查找树，每个节点分别包含索引键值和一个指向对应数据记录物理地址的指针，这样就可以运用二叉查找在O(log2n)的复杂度内获取到相应数据。
创建索引可以大大提高系统的性能。
第一，通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性。
第二，可以大大加快数据的检索速度，这也是创建索引的最主要的原因。
第三，可以加速表和表之间的连接，特别是在实现数据的参考完整性方面特别有意义。
第四，在使用分组和排序子句进行数据检索时，同样可以显著减少查询中分组和排序的时间。
第五，通过使用索引，可以在查询的过程中，使用优化隐藏器，提高系统的性能。
也许会有人要问：增加索引有如此多的优点，为什么不对表中的每一个列创建一个索引呢？因为，增加索引也有许多不利的方面。
第一，创建索引和维护索引要耗费时间，这种时间随着数据量的增加而增加。
第二，索引需要占物理空间，除了数据表占数据空间之外，每一个索引还要占一定的物理空间，如果要建立聚簇索引，那么需要的空间就会更大。
第三，当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，这样就降低了数据的维护速度。
索引是建立在数据库表中的某些列的上面。在创建索引的时候，应该考虑在哪些列上可以创建索引，在哪些列上不能创建索引。一般来说，应该在这些列上创建索引：在经常需要搜索的列上，可以加快搜索的速度；在作为主键的列上，强制该列的唯一性和组织表中数据的排列结构；在经常用在连接的列上，这些列主要是一些外键，可以加快连接的速度；在经常需要根据范围进行搜索的列上创建索引，因为索引已经排序，其指定的范围是连续的；在经常需要排序的列上创建索引，因为索引已经排序，这样查询可以利用索引的排序，加快排序查询时间；在经常使用在WHERE子句中的列上面创建索引，加快条件的判断速度。
同样，对于有些列不应该创建索引。一般来说，不应该创建索引的的这些列具有下列特点：
第一，对于那些在查询中很少使用或者参考的列不应该创建索引。这是因为，既然这些列很少使用到，因此有索引或者无索引，并不能提高查询速度。相反，由于增加了索引，反而降低了系统的维护速度和增大了空间需求。
第二，对于那些只有很少数据值的列也不应该增加索引。这是因为，由于这些列的取值很少，例如人事表的性别列，在查询的结果中，结果集的数据行占了表中数据行的很大比例，即需要在表中搜索的数据行的比例很大。增加索引，并不能明显加快检索速度。
第三，对于那些定义为text, image和bit数据类型的列不应该增加索引。这是因为，这些列的数据量要么相当大，要么取值很少。
第四，当修改性能远远大于检索性能时，不应该创建索引。这是因为，修改性能和检索性能是互相矛盾的。当增加索引时，会提高检索性能，但是会降低修改性能。当减少索引时，会提高修改性能，降低检索性能。因此，当修改性能远远大于检索性能时，不应该创建索引。
根据数据库的功能，可以在器中创建三种索引：唯一索引、主键索引和聚集索引。
唯一索引是不允许其中任何两行具有相同索引值的索引。
当现有数据中存在重复的键值时，大多数数据库不允许将新创建的唯一索引与表一起保存。数据库还可能防止添加将在表中创建重复键值的新数据。例如，如果在employee表中职员的姓(lname)上创建了唯一索引，则任何两个员工都不能同姓。 主键索引 数据库表经常有一列或列组合，其值唯一标识表中的每一行。该列称为表的主键。 在数据库关系图中为表定义主键将自动创建主键索引，主键索引是唯一索引的特定类型。该索引要求主键中的每个值都唯一。当在查询中使用主键索引时，它还允许对数据的快速访问。 聚集索引 在聚集索引中，表中行的物理顺序与键值的逻辑（索引）顺序相同。一个表只能包含一个聚集索引。
如果某索引不是聚集索引，则表中行的物理顺序与键值的逻辑顺序不匹配。与非聚集索引相比，聚集索引通常提供更快的数据访问速度。
局部性原理与磁盘预读
由于存储介质的特性，磁盘本身存取就比主存慢很多，再加上机械运动耗费，磁盘的存取速度往往是主存的几百分分之一，因此为了提高效率，要尽量减少磁盘I/O。为了达到这个目的，磁盘往往不是严格按需读取，而是每次都会预读，即使只需要一个字节，磁盘也会从这个位置开始，顺序向后读取一定长度的数据放入内存。这样做的理论依据是计算机科学中著名的局部性原理：当一个数据被用到时，其附近的数据也通常会马上被使用。程序运行期间所需要的数据通常比较集中。
由于磁盘顺序读取的效率很高（不需要寻道时间，只需很少的旋转时间），因此对于具有局部性的程序来说，预读可以提高I/O效率。
预读的长度一般为页（page）的整倍数。页是计算机管理存储器的逻辑块，硬件及操作系统往往将主存和磁盘存储区分割为连续的大小相等的块，每个存储块称为一页（在许多操作系统中，页得大小通常为4k），主存和磁盘以页为单位交换数据。当程序要读取的数据不在主存中时，会触发一个缺页异常，此时系统会向磁盘发出读盘信号，磁盘会找到数据的起始位置并向后连续读取一页或几页载入内存中，然后异常返回，程序继续运行。
B-/+Tree索引的性能分析
到这里终于可以分析B-/+Tree索引的性能了。
上文说过一般使用磁盘I/O次数评价索引结构的优劣。先从B-Tree分析，根据B-Tree的定义，可知检索一次最多需要访问h个节点。数据库系统的设计者巧妙利用了磁盘预读原理，将一个节点的大小设为等于一个页，这样每个节点只需要一次I/O就可以完全载入。为了达到这个目的，在实际实现B-Tree还需要使用如下技巧：
每次新建节点时，直接申请一个页的空间，这样就保证一个节点物理上也存储在一个页里，加之计算机存储分配都是按页对齐的，就实现了一个node只需一次I/O。
B-Tree中一次检索最多需要h-1次I/O（根节点常驻内存），渐进复杂度为O(h)=O(logdN)。一般实际应用中，出度d是非常大的数字，通常超过100，因此h非常小（通常不超过3）。
而红黑树这种结构，h明显要深的多。由于逻辑上很近的节点（父子）物理上可能很远，无法利用局部性，所以红黑树的I/O渐进复杂度也为O(h)，效率明显比B-Tree差很多。
综上所述，用B-Tree作为索引结构效率是非常高的。
6.连接的种类
查询分析器中执行：
--建表table1,table2：
create table table1(id int,name varchar(10))
create table table2(id int,score int)
insert into table1 select 1,'lee'
insert into table1 select 2,'zhang'
insert into table1 select 4,'wang'
insert into table2 select 1,90
insert into table2 select 2,100
insert into table2 select 3,70
-------------------------------------------------
table1 | table2 |
-------------------------------------------------
id name |id score |
1 lee |1 90|
2 zhang| 2 100|
4 wang| 3 70|
-------------------------------------------------
以下均在查询分析器中执行
一、外连接
1.概念：包括左向外联接、右向外联接或完整外部联接
2.左连接：left join 或 left outer join
(1)左向外联接的结果集包括 LEFT OUTER 子句中指定的左表的所有行，而不仅仅是联接列所匹配的行。如果左表的某行在右表中没有匹配行，则在相关联的结果集行中右表的所有选择列表列均为空值(null)。
(2)sql 语句
select * from table1 left join table2 on table1.id=table2.id
-------------结果-------------
idnameidscore
------------------------------
2zhang2100
4wangNULLNULL
------------------------------
注释：包含table1的所有子句，根据指定条件返回table2相应的字段，不符合的以null显示
3.右连接：right join 或 right outer join
(1)右向外联接是左向外联接的反向联接。将返回右表的所有行。如果右表的某行在左表中没有匹配行，则将为左表返回空值。
(2)sql 语句
select * from table1 right join table2 on table1.id=table2.id
-------------结果-------------
idnameidscore
------------------------------
2zhang2100
NULLNULL370
------------------------------
注释：包含table2的所有子句，根据指定条件返回table1相应的字段，不符合的以null显示
4.完整外部联接:full join 或 full outer join
(1)完整外部联接返回左表和右表中的所有行。当某行在另一个表中没有匹配行时，则另一个表的选择列表列包含空值。如果表之间有匹配行，则整个结果集行包含基表的数据值。
(2)sql 语句
select * from table1 full join table2 on table1.id=table2.id
-------------结果-------------
idnameidscore
------------------------------
2zhang2100
4wangNULLNULL
NULLNULL370
------------------------------
注释：返回左右连接的和（见上左、右连接）
二、内连接
1.概念：内联接是用比较运算符比较要联接列的值的联接
2.内连接：join 或 inner join
3.sql 语句
select * from table1 join table2 on table1.id=table2.id
-------------结果-------------
idnameidscore
------------------------------
2zhang2100
------------------------------
注释：只返回符合条件的table1和table2的列
4.等价（与下列执行效果相同）
A:select a.*,b.* from table1 a,table2 b where a.id=b.id
B:select * from table1 cross join table2 where table1.id=table2.id (注：cross join后加条件只能用where,不能用on)
三、交叉连接(完全)
1.概念：没有 WHERE 子句的交叉联接将产生联接所涉及的表的笛卡尔积。第一个表的行数乘以第二个表的行数等于笛卡尔积结果集的大小。（table1和table2交叉连接产生3*3=9条记录）
2.交叉连接：cross join (不带条件where...)
select * from table1 cross join table2
-------------结果-------------
idnameidscore
------------------------------
2zhang2100
------------------------------
注释：返回3*3=9条记录，即笛卡尔积
4.等价（与下列执行效果相同）
A:select * from table1,table2
7.数据库范式
1 第一范式（1NF）
在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。
所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含一个实例的信息。简而言之，第一范式就是无重复的列。
2 第二范式（2NF）
第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。这个惟一属性列被称为主关键字或主键、主码。
第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。简而言之，第二范式就是非主属性非部分依赖于主关键字。
3 第三范式（3NF）
满足第三范式（3NF）必须先满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。简而言之，第三范式就是属性不依赖于其它非主属性。（我的理解是消除冗余）
8.数据库优化的思路
这个我借鉴了慕课上关于数据库优化的课程。
1.SQL语句优化
1）应尽量避免在 where 子句中使用!=或&&操作符，否则将引擎放弃使用索引而进行全表扫描。
2）应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：
select id from t where num is null
可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：
select id from t where num=0
3）很多时候用 exists 代替 in 是一个好的选择
4）用Where子句替换HAVING 子句 因为HAVING 只会在检索出所有记录之后才对结果集进行过滤
2.索引优化
看上文索引
3.数据库结构优化
1）范式优化： 比如消除冗余（节省空间。。） 2）反范式优化：比如适当加冗余等（减少join） 3）拆分表： 分区将数据在物理上分隔开，不同分区的数据可以制定保存在处于不同磁盘上的数据文件里。这样，当对这个表进行查询时，只需要在表分区中进行扫描，而不必进行全表扫描，明显缩短了查询时间，另外处于不同磁盘的分区也将对这个表的数据传输分散在不同的磁盘I/O，一个精心设置的分区可以将数据传输对磁盘I/O竞争均匀地分散开。对数据量大的时时表可采取此方法。可按月自动建表分区。
4）拆分其实又分垂直拆分和水平拆分： 案例： 简单购物系统暂设涉及如下表： 1.产品表（数据量10w，稳定） 2.订单表（数据量200w，且有增长趋势） 3.用户表 （数据量100w，且有增长趋势） 以为例讲述下水平拆分和垂直拆分，mysql能容忍的数量级在百万静态数据可以到千万 垂直拆分： 解决问题：表与表之间的io竞争 不解决问题：单表中数据量增长出现的压力 方案： 把产品表和用户表放到一个server上 订单表单独放到一个server上 水平拆分： 解决问题：单表中数据量增长出现的压力 不解决问题：表与表之间的io争夺
方案： 用户表通过性别拆分为男用户表和女用户表 订单表通过已完成和完成中拆分为已完成订单和未完成订单 产品表 未完成订单放一个server上 已完成订单表盒男用户表放一个server上 女用户表放一个server上(女的爱购物 哈哈)
4.服务器硬件优化
这个么多花钱咯！
9.存储过程与触发器的区别
触发器与存储过程非常相似，触发器也是SQL语句集，两者唯一的区别是触发器不能用EXECUTE语句调用，而是在用户执行Transact-SQL语句时自动触发（激活）执行。触发器是在一个修改了指定表中的数据时执行的存储过程。通常通过创建触发器来强制实现不同表中的逻辑相关数据的引用完整性和一致性。由于用户不能绕过触发器，所以可以用它来强制实施复杂的业务规则，以确保数据的完整性。触发器不同于存储过程，触发器主要是通过事件执行触发而被执行的，而存储过程可以通过存储过程名称名字而直接调用。当对某一表进行诸如UPDATE、INSERT、DELETE这些操作时，SQLSERVER就会自动执行触发器所定义的SQL语句，从而确保对数据的处理必须符合这些SQL语句所定义的规则。更多相关文档在一个千万级的数据库查寻中,如何提高查询效率？_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
在一个千万级的数据库查寻中,如何提高查询效率？
阅读已结束，下载本文需要
想免费下载本文？
定制HR最喜欢的简历
下载文档到电脑，同时保存到云知识，更方便管理
加入VIP
还剩2页未读，
定制HR最喜欢的简历
你可能喜欢数据库 - 搜狗百科
&&历史版本
该版本已锁定
数据库（Database）是电脑化的资料保存。数据库本身可视为的档案柜——电脑化档案的处所，使用者可以新增档案或删除档案，也可以对档案中的资料执行新增、撷取、更新、删除等操作。数据库是以一定组织方式储存在一起的，能为多个用户的，具有尽可能小的冗余度的、与应用彼此独立的相互关联的。
数据库定义1数据库，简单来说是本身可视为电子化的文件柜——存储电子文件的处所，用户可以对文件中的数据运行新增、截取、更新、删除等操作。数据库指的是以一定方式储存在一起、能为多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合。在经济管理的日常工作中，常常需要把某些相关的数据放进这样的“仓库”，并根据管理的需要进行相应的处理。例如，企业或事业单位的人事部门常常要把本单位职工的基本情况(职工号、姓名、年龄、性别、籍贯、工资、简历等)存放在表中，这张表就可以看成是一个数据库。有了这个&数据仓库&我们就可以根据需要随时查询某职工的基本情况，也可以查询工资在某个范围内的职工人数等等。这些工作如果都能在计算机上自动进行，那我们的人事管理就可以达到极高的水平。此外，在财务管理、仓库管理、生产管理中也需要建立众多的这种&数据库&，使其可以利用计算机实现财务、仓库、生产的自动化管理。定义2数据库是依照某种数据模型组织起来并存放二级存储器中的数据集合。这种数据集合具有如下特点：尽可能不重复，以最优方式为某个特定组织的多种应用服务，其数据结构独立于使用它的应用程序，对数据的增、删、改和检索由统一软件进行管理和控制。从发展的历史看，数据库是数据管理的高级阶段，它是由文件管理系统发展起来的。数据整体数据库是一个单位或是一个应用领域的通用数据处理系统，它存储的是属于企业和事业部门、团体和个人的有关数据的集合。数据库中的数据是从全局观点出发建立的，按一定的数据模型进行组织、描述和存储。其结构基于数据间的自然联系，从而可提供一切必要的存取路径，且数据不再针对某一应用，而是面向全组织，具有整体的结构化特征。数据共享数据库中的数据是为众多用户所共享其信息而建立的，已经摆脱了具体程序的限制和制约。不同的用户可以按各自的用法使用数据库中的数据；多个用户可以同时共享数据库中的数据资源，即不同的用户可以同时存取数据库中的同一个数据。数据共享性不仅满足了各用户对信息内容的要求，同时也满足了各用户之间信息通信的要求。
数据库数据库的基本结构分三个层次，反映了观察数据库的三种不同角度。以内模式为框架所组成的数据库叫做物理数据库；以概念模式为框架所组成的数据叫概念数据库；以外模式为框架所组成的数据库叫用户数据库。⑴物理数据层。它是数据库的最内层，是物理存贮设备上实际存储的数据的集合。这些数据是原始数据，是用户加工的对象，由内部模式描述的指令操作处理的位串、字符和字组成。⑵概念数据层。它是数据库的中间一层，是数据库的整体逻辑表示。指出了每个数据的逻辑定义及数据间的逻辑联系，是存贮记录的集合。它所涉及的是数据库所有对象的逻辑关系，而不是它们的物理情况，是数据库管理员概念下的数据库。⑶逻辑数据层。它是用户所看到和使用的数据库，表示了一个或一些特定用户使用的数据集合，即逻辑记录的集合。数据库不同层次之间的联系是通过映射进行转换的。
⑴实现数据共享数据共享包含所有用户可同时存取数据库中的数据，也包括用户可以用各种方式通过接口使用数据库，并提供数据共享。⑵减少数据的冗余度同文件系统相比，由于数据库实现了数据共享，从而避免了用户各自建立应用文件。减少了大量重复数据，减少了数据冗余，维护了数据的一致性。数据库⑶数据的独立性数据的独立性包括逻辑独立性（数据库中数据库的逻辑结构和应用程序相互独立）和物理独立性（数据物理结构的变化不影响数据的逻辑结构）。⑷数据实现集中控制文件管理方式中，数据处于一种分散的状态，不同的用户或同一用户在不同处理中其文件之间毫无关系。利用数据库可对数据进行集中控制和管理，并通过数据模型表示各种数据的组织以及数据间的联系。⑸数据一致性和可维护性，以确保数据的安全性和可靠性。主要包括：①安全性控制：以防止数据丢失、错误更新和越权使用；②完整性控制：保证数据的正确性、有效性和相容性；③并发控制：使在同一时间周期内，允许对数据实现多路存取，又能防止用户之间的不正常交互作用。⑹故障恢复由数据库管理系统提供一套方法，可及时发现故障和修复故障，从而防止数据被破坏。数据库系统能尽快恢复数据库系统运行时出现的故障，可能是物理上或是逻辑上的错误。比如对系统的误操作造成的数据错误等。
数据库通常分为层次式数据库、网络式数据库和关系式数据库三种。而不同的数据库是按不同的数据结构来联系和组织的。1.数据结构模型⑴数据结构所谓数据结构是指数据的组织形式或数据之间的联系。如果用D表示数据，用R表示数据对象之间存在的关系集合，则将DS=(D，R)称为数据结构。例如，设有一个电话号码簿，它记录了n个人的名字和相应的电话号码。为了方便地查找某人的电话号码，将人名和号码按字典顺序排列，并在名字的后面跟随着对应的电话号码。这样，若要查找某人的电话号码(假定他的名字的第一个字母是Y)，那么只须查找以Y开头的那些名字就可以了。该例中，数据的集合D就是人名和电话号码，它们之间的联系R就是按字典顺序的排列，其相应的数据结构就是DS=(D，R)，即一个数组。数据库⑵数据结构种类数据结构又分为数据的逻辑结构和数据的物理结构。数据的逻辑结构是从逻辑的角度(即数据间的联系和组织方式)来观察数据，分析数据，与数据的存储位置无关。数据的物理结构是指数据在计算机中存放的结构，即数据的逻辑结构在计算机中的实现形式，所以物理结构也被称为存储结构。这里只研究数据的逻辑结构，并将反映和实现数据联系的方法称为数据模型。比较流行的数据模型有三种，即按图论理论建立的层次结构模型和网状结构模型以及按关系理论建立的关系结构模型。2.层次、网状和关系数据库系统⑴层次结构模型层次结构模型实质上是一种有根结点的定向有序树(在数学中&树&被定义为一个无回的连通图)。下图是一个高等学校的组织结构图。这个组织结构图像一棵树，校部就是树根(称为根结点)，各系、专业、教师、学生等为枝点(称为结点)，树根与枝点之间的联系称为边，树根与边之比为1:N，即树根只有一个，树枝有N个。按照层次模型建立的数据库系统称为层次模型数据库系统。IMS(Information Manage-mentSystem)是其典型代表。⑵网状结构模型按照网状数据结构建立的数据库系统称为网状数据库系统，其典型代表是DBTG(Data Base Task Group)。用数学方法可将网状数据结构转化为层次数据结构。⑶关系结构模型数据库关系式数据结构把一些复杂的数据结构归结为简单的二元关系(即二维表格形式)。例如某单位的职工关系就是一个二元关系。由关系数据结构组成的数据库系统被称为关系数据库系统。在关系数据库中，对数据的操作几乎全部建立在一个或多个关系表格上，通过对这些关系表格的分类、合并、连接或选取等运算来实现数据的管理。dBASEⅡ就是这类数据库管理系统的典型代表。对于一个实际的应用问题（如人事管理问题），有时需要多个关系才能实现。用dBASEⅡ建立起来的一个关系称为一个数据库（或称数据库文件），而把对应多个关系建立起来的多个数据库称为数据库系统。dBASEⅡ的另一个重要功能是通过建立命令文件来实现对数据库的使用和管理，对于一个数据库系统相应的命令序列文件，称为该数据库的应用系统。因此，可以概括地说，一个关系称为一个数据库，若干个数据库可以构成一个数据库系统。数据库系统可以派生出各种不同类型的辅助文件和建立它的应用系统。
Database Browser万能数据库查看器：数据一般都保存在数据库中，而要打开相对应的数据库必须使用打开该数据库的相应软件，例如：Access、MS SQL、MY SQL等，而Database Browser这款小小工具可以实用能够查看各种类型的数据库，号称是万能数据库查看器，你可以用它连接到任何一个数据库，然后进行修改或者浏览，该软件打开查询的速度也非常的快。他支持表的浏览，数据浏览，数据导出可以是CSV，Excel和HTML文件，执行历史记录时，SQL生成器导出与广泛支持的数据库，执行日志和增量表搜索，可以说这款Database Browser万能数据库查看器是我们工作中不可缺少的有利工具。
数据库技术发展使用计算机后，随着数据处理量的增长，产生了数据管理技术。数据管理技术的发展与计算机硬件（主要是外部存储器）系统软件及计算机应用的范围有着密切的联系。数据管理技术的发展经历了以下四个阶段：人工管理阶段、文件系统阶段、数据库阶段和高级数据库技术阶段。数据管理的诞生数据库的历史可以追溯到五十年前，那时的数据管理非常简单。通过大量的分类、比较和表格绘制的机器运行数百万穿孔卡片来进行数据的处理，其运行结果在纸上打印出来或者制成新的穿孔卡片。而数据管理就是对所有这些穿孔卡片进行物理的储存和处理。然而，1 9 5 0 年雷明顿兰德公司（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）。1964年通用电气公司（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路数据共享、消息队列共享等先进特性的支持。这个具有30年历史的数据库产品在如今的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等等。
数据库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定义是ANSⅨ3135-89，“Database Language - SQL with Integrity Enhancement”[ANS89]，一般叫做SQL-89。SQL-89定义了模式定义、数据操作和事务处理。SQL- 89和随后的ANSⅨ，“Database Language-Embedded SQL”构成了第一代SQL标准。ANSⅨ[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 1966年就发表了关系数据库理论，并在IBM研究机构开发原型，这个项目就是R系统，存取数据表的语言就是SQL。Ellison看完后，敏锐意识到在这个研究基础上可以开发商用软件系统。而当时大多数人认为关系数据库不会有商业价值。Ellison认为这是他们的机会：他们决定开发通用商用数据库系统Oracle，这个名字来源于他们曾给中央情报局做过的项目名。几个月后，他们就开发了Oracle 1.0。但这只不过是个玩具，除了完成简单关系查询不能做任何事情，他们花相当长的时间才使Oracle变得可用，维持公司运转主要靠承接一些数据库管理项目和做顾问咨询工作。而IBM却没有计划开发，为什么蓝色巨人放弃了这个价值上百亿的产品，原因有很多：IBM的研究人员大多是学术出身，他们最感兴趣的是理论，而非推向市场的产品，从学术上看，研究成果应公开，发表论文和演讲能使他们成名，为什么不呢？还有一个很主要的原因就是IBM当时有一个销售得还不错的层次数据库产品IMS。直到1985年IBM才发布了关系数据库DB2 ,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语言的出现，给数据库系统的发展开辟了一片新的天地。数据库发展阶段大致划分为如下几个阶段：人工管理阶段、文件系统阶段、数据库系统阶段、高级数据库阶段。
数据库50年代中期之前，计算机的软硬件均不完善。硬件存储设备只有磁带、卡片和纸带，软件方面还没有操作系统，当时的计算机主要用于科学计算。这个阶段由于还没有软件系统对数据进行管理，程序员在程序中不仅要规定数据的逻辑结构，还要设计其物理结构，包括存储结构、存取方法、输入输出方式等。当数据的物理组织或存储设备改变时，用户程序就必须重新编制。由于数据的组织面向应用，不同的计算程序之间不能共享数据，使得不同的应用之间存在大量的重复数据，很难维护应用程序之间数据的一致性。这一阶段的主要特征可归纳为如下几点：*计算机中没有支持数据管理的软件。*数据组织面向应用，数据不能共享，数据重复。*在程序中要规定数据的逻辑结构和物理结构，数据与程序不独立。*数据处理方式——批处理。
数据库这一阶段的主要标志是计算机中有了专门管理数据库的软件——操作系统（文件管理）。上世纪50年代中期到60年代中期，由于计算机大容量存储设备（如硬盘）的出现，推动了软件技术的发展，而操作系统的出现标志着数据管理步入一个新的阶段。在文件系统阶段，数据以文件为单位存储在外存，且由操作系统统一管理。操作系统为用户使用文件提供了友好界面。文件的逻辑结构与物理结构脱钩，程序和数据分离，使数据与程序有了一定的独立性。用户的程序与数据可分别存放在外存储器上，各个应用程序可以共享一组数据，实现了以文件为单位的数据共享。但由于数据的组织仍然是面向程序，所以存在大量的数据冗余。而且数据的逻辑结构不能方便地修改和扩充，数据逻辑结构的每一点微小改变都会影响到应用程序。由于文件之间互相独立，因而它们不能反映现实世界中事物之间的联系，操作系统不负责维护文件之间的联系信息。如果文件之间有内容上的联系，那也只能由应用程序去处理。
60年代后，随着计算机在数据管理领域的普遍应用，人们对数据管理技术提出了更高的要求：希望面向企业或部门，以数据为中心组织数据，减少数据的冗余，提供更高的数据共享能力，同时要求程序和数据具有较高的独立性，当数据的逻辑结构改变时，不涉及数据的物理结构，也不影响应用程序，以降低应用程序研制与维护的费用。数据库技术正是在这样一个应用需求的基础上发展起来的。数据库技术有如下特点：* 面向企业或部门，以数据为中心组织数据，形成综合性的数据库，为各应用共享。* 采用一定的数据模型。数据模型不仅要描述数据本身的特点，而且要描述数据之间的联系。* 数据冗余小，易修改、易扩充。不同的应用程序根据处理要求，从数据库中获取需要的数据，这样就减少了数据的重复存储，也便于增加新的数据结构，便于维护数据的一致性。*程序和数据有较高的独立性。* 具有良好的用户接口，用户可方便地开发和使用数据库。* 对数据进行统一管理和控制，提供了数据的安全性、完整性、以及并发控制。数据库从文件系统发展到数据库系统，这在信息领域中具有里程碑的意义。在文件系统阶段，人们在信息处理中关注的中心问题是系统功能的设计，因此程序设计占主导地位；而在数据库方式下，数据开始占据了中心位置，数据的结构设计成为信息系统首先关心的问题，而应用程序则以既定的数据结构为基础进行设计。大事记1951：Univac系统使用磁带和穿孔卡片作为数据存储。1956：IBM公司在其Model 305 RAMAC中第一次引入了磁盘驱动器1961：通用电气(GE)公司的Charles Bachman开发了第一个数据库管理系统——IDS1969： 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 ；1991年W.H. Inmon 发表了《构建数据仓库》；1995年Database。
实时数据库系统介绍实时数据库系统是数据库理论在新领域的扩展，在电力、化工、钢铁、冶金、造纸、交通控制和证券金融等领域有着非常广阔的应用前景。它可以为企业提供高速、及时的实时数据服务，能够对快速变化的实时数据进行长期高效的历史存储，是工厂控制层（现场总线、DCS、PLC等）与生产管理系统之间连接的桥梁，同时也是流程模拟、先进控制、在线优化、故障诊断等系统的数据平台。openPlant实时数据库系统采用当今先进的技术和架构，可安全、稳定地实现与现场各控制系统的接口，并能对采集来的数据进行高效的数据压缩和长期的历史存储，同时提供方便易用的客户端应用和通用的数据接口（API/DDE/ODBC/JDBC/OPC等），使企业的管理和决策人员能及时、全面的了解当前的生产情况，也可回顾过去的生产情况，及时发现生产中所存在的问题，提高设备利用率，降低生产成本，增强企业的核心竞争力。数据库实时数据库系统特点■ 企业级的生产实时数据平台■分布式数据库架构，满足集团级需求■ 实时访问全厂生产数据■ 高效的数据压缩和长期历史存储■ 支持在线计算和统计■ 专业的图形仿真技术，监视画面与控制系统完全一致■ 丰富的客户端应用工具■ 优异的跨平台性能，支持Unix/Linux/Windows等操作系统■ 开放的数据接口，如API/DDE/ODBC/JDBC/OPC■ 200,000点上万小时现场稳定运行考验■ 支持远程访问，随时随地享用生产信息■ 个性化定制服务，让您从容应对不断变化的用户需求关系数据作为关系数据库领域的开拓者和领航人，IBM在1977年完成了System R系统的原型，1980年开始提供集成的数据库服务器—— System/38，随后是SQL/DSforVSE和VM，其初始版本与SystemR研究原型密切相关。DB2 for MVSV1在1983年推出。该版本的目标是提供这一新方案所承诺的简单性，数据不相关性和用户生产率。1988年DB2 for MVS 提供了强大的在线事务处理（OLTP）支持。1989年和1993年分别以远程工作单元和分布式工作单元实现了分布式数据库支持。推出的DB2 Universal Database 6.1则是通用数据库的典范，是第一个具备网上功能的多媒体关系数据库管理系统，支持包括Linux在内的一系列平台。管理系统Oracle前身叫SDL，由Larry Ellison 和另两个编程人员在1977创办，他们开发了自己的拳头产品，在市场上大量销售。1979 年Oracle公司引入了第一个商用SQL关系数据库管理系统。Oracle公司是最早开发关系数据库的厂商之一，其产品支持最广泛的操作系统平台。Oracle关系数据库产品的市场占有率名列前茅。Oracle数据库包含三种：大型数据库（主流是10g/11g）、My Sql数据库、内存数据库。商业数据Informix在1980年成立，目的是为Unix等开放操作系统提供专业的关系型数据库产品。公司的名称Informix便是取自Information ；和Unix的结合。Informix第一个真正支持SQL语言的关系数据库产品是Informix SE（StandardEngine）。InformixSE是在当时的微机Unix环境下主要的数据库产品。它也是第一个被移植到Linux上的商业数据库产品。数据体系Sybase公司成立于1984年，公司名称“Sybase”取自“system”和“database”相结合的含义。Sybase公司的创始人之一Bob Epstein是Ingres大学版（与System/R同时期的关系数据库模型产品）的主要设计人员。公司的第一个关系数据库产品是1987年5月推出的Sybase SQLServer1.0。Sybase首先提出Client/Server数据库体系结构的思想，并率先在Sybase SQLServer中实现。数据库关系型数据1987年，微软和IBM合作开发完成OS/2，IBM在其销售的OS/2 Extended Edition ；系统中绑定了OS/2 Database Manager，而微软产品线中尚缺少数据库产品。为此，微软将目光投向Sybase，同Sybase签订了合作协议，使用Sybase的技术开发基于OS/2平台的关系型数据库。1989年，微软发布了SQL Server 1.0版。自由数据PostgreSQL 是一种特性非常齐全的自由软件的对象——关系性数据库管理系统（ORDBMS），它的很多特性是当今许多商业数据库的前身。PostgreSQL最早开始于BSD的Ingres项目。PostgreSQL 的特性覆盖了SQL-2/SQL-92和SQL-3。首先，它包括了可以说是世界上最丰富的数据类型的支持；其次，PostgreSQL 是唯一支持事务、子查询、多版本并行控制系统、数据完整性检查等特性的唯一的一种自由软件的数据库管理系统.小型数据MySQL是一个小型关系型数据库管理系统，开发者为瑞典MySQL AB公司。在号被Sun公司收购。而2009年，SUN又被Oracle收购。对于Mysql的前途，没有任何人抱乐观的态度。MySQL被广泛地应用在Internet上的中小型网站中。由于其体积小、速度快、总体拥有成本低，尤其是开放源码这一特点，许多中小型网站为了降低网站总体拥有成本而选择了MySQL作为网站数据库。微机数据美国Microsoft公司于1994年推出的微机数据库管理系统。它具有界面友好、易学易用、开发简单、接口灵活等特点，是典型的新一代桌面数据库管理系统。其主要特点如下：⑴ 完善地管理各种数据库对象，具有强大的数据组织、用户管理、安全检查等功能。⑵ 强大的数据处理功能，在一个工作组级别的网络环境中，使用Access开发的多用户数据库管理系统具有传统的XBASE(DBASE、FoxBASE的统称)数据库系统所无法实现的客户服务器(Cient/Server)结构和相应的数据库安全机制，Access具备了许多先进的大型数据库管理系统所具备的特征，如事务处理/出错回滚能力等。⑶ 可以方便地生成各种数据对象，利用存储的数据建立窗体和报表，可视性好。⑷ 作为Office套件的一部分，可以与Office集成，实现无缝连接。⑸ 能够利用Web检索和发布数据，实现与Internet的连接。 Access主要适用于中小型应用系统，或作为客户机/服务器系统中的客户端数据库。关联数据SQLite是遵守ACID的关联式资料库管理系统，它包含在一个相对小的C库中。它是D.RichardHipp建立的公有领域项目。不像常见的客户端/服务器结构范例，SQLite引擎不是个程序与之通信的独立进程，而是连接到程序中成为它的一个主要部分。所以主要的通信协议是在编程语言内的直接API调用。这在消耗总量、延迟时间和整体简单性上有积极的作用。整个数据库（定义、表、索引和数据本身）都在宿主主机上存储在一个单一的文件中。它的简单的设计是通过在开始一个事务的时候锁定整个数据文件而完成的。
数据库随着互联网web2.0网站的兴起，非关系型的数据库成了一个极其热门的新领域，非关系数据库产品的发展非常迅速。而传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，例如：⒈High performance ；– ；对数据库高并发读写的需求web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘IO就已经无法承受了。其实对于普通的BBS网站，往往也存在对高并发写请求的需求，例如像JavaEye网站的实时统计在线用户状态，记录热门帖子的点击次数，投票计数等，因此这是一个相当普遍的需求。⒉Huge Storage ；– ；对海量数据的高效率存储和访问的需求类似Facebook，twitter，Friendfeed这样的SNS网站，每天用户产生海量的用户动态，以Friendfeed为例，一个月就达到了2.5亿条用户动态，对于关系数据库来说，在一张2.5亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的。再例如大型web网站的用户登录系统，例如腾讯，盛大，动辄数以亿计的帐号，关系数据库也很难应付。⒊High Scalability && High Availability- ；对数据库的高可扩展性和高可用性的需求在基于web的架构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，你的数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移，为什么数据库不能通过不断的添加服务器节点来实现扩展呢？在上面提到的“三高”需求面前，关系数据库遇到了难以克服的障碍，而对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地，例如：⒈数据库事务一致性需求很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求也不高。因此数据库事务管理成了数据库高负载下一个沉重的负担。⒉数据库的写实时性和读实时性需求对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应用来说，并不要求这么高的实时性，比方说我（JavaEye的robbin）发一条消息之后，过几秒乃至十几秒之后，我的订阅者才看到这条动态是完全可以接受的。⒊对复杂的SQL查询，特别是多表关联查询的需求任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询，特别是SNS类型的网站，从需求以及产品设计角度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。因此，关系数据库在这些越来越多的应用场景下显得不那么合适了，为了解决这类问题的非关系数据库应运而生，各种各样非关系数据库，特别是键值数据库(Key-Value Store DB)风起云涌，多得让人眼花缭乱。
数据库最初由美国Fox公司1988年推出，1992年Fox公司被Microsoft公司收购后，相继推出了FoxPro2.5、2.6和VisualFoxPro等版本，其功能和性能有了较大的提高。 FoxPro2.5、2.6分为DOS和Windows两种版本，分别运行于DOS和Windows环境下。FoxPro比FoxBASE在功能和性能上又有了很大的改进，主要是引入了窗口、按纽、列表框和文本框等控件，进一步提高了系统的开发能力。商业信息INFOBANK数据库，中国资讯行1995年推出，经历17年的发展，已成为全球最大的中文商业信息数据库之一。INFOBANK采集来自国内1200多家媒体、国外100家媒体的公开信息，同时与国内百余家官方和行业权威机构合作，为广大用户提供丰富的中文商业信息。INFOBANK由14个子数据库组成，100亿的汉字储量，累计包含专业文献超过600万篇，资讯内容涉及19个大类，197个行业，日增新250万汉字。同时还设有特点栏目，满足用户撰写论文、了解行业信息等多样化需求。病毒检查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上更好了。服务器上可能还没有特洛伊，但是如果感觉到有问题，那么凶手就可以很容易发现。查询优化⒈对数据库查询进行优化，应尽量避免全表扫描，首先应考虑在where 及order by 涉及的列上建立索引。⒉应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：select id from t where num is null可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：select id from t where num=0⒊应尽量避免在 where 子句中使用！=或&&操作符，否则将引擎放弃使用索引而进行全表扫描。⒋应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：select id from t where num=10 or num=20可以这样查询：select id from t where num=10union allselect id from t where num=20⒌ in 和 not in 也要慎用，否则会导致全表扫描，如：select id from t where nm in（1，2，3）对于连续的数值，能用 between ；就不要用 in ；了：select id from t where num between 1 and 3⒍下面的查询也将导致全表扫描：select id from t where name like &%abc%&若要提高效率，可以考虑全文检索。⒎如果在 where 子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描：select id from t wherenum=@num数据库可以改为强制查询使用索引：select id from t with(index(索引名)) wherenum=@num⒏应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：select id from t where num/2=100应改为：select id from t where num=100*2⒐应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如：select id from t where substring(name，1，3）=&abc&--name以abc开头的idselect id from t where datediff(day，createdate，&&)=0--‘’生成的id管理工具Navicat for MySQL是一个强大的MySQL数据库服务器管理和开发工具。它可以与任何3.21或以上版本的MySQL一起工作，并支持大部分的MySQL最新功能，包括触发器、存储过程、函数、事件、视图、管理用户，等等。它不仅对专业开发人员来说是非常尖端的技术，而且对于新手来说也易学易用。其精心设计的图形用户界面（GUI），Navicat for MySQL可以让你用一种安全简便的方式快速并容易地创建，组织，访问和共享信息。
导致安全问题原因导致电子商务网站数据库存在安全隐患的原因主要表现在以下几个方面：⑴用户对数据库的不正确访问，引起数据库数据的错误；⑵为了某种目的，故意破坏数据库，使其不能恢复；⑶非法访问不该访问的数据库信息，但又不留痕迹；⑷用户通过网络进行数据库访问时，有可能受到各种技术（如搭线窃听等）的攻击；⑸非法用户绕过安全内核，窃取信息资源等现象；⑹未经授权非法修改数据库数据，使其数据失去真实性等等。数据库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对象可以有效阻止这一情况的发生。数据库保障的措施（一）、存在漏洞的保护措施⒈数据库文件名应复杂下载Access数据库文件，首先必须知道该数据库文件的存储路径和文件名。如果你将原本非常简单的数据库文件名修改得更加复杂，这样那些“不怀好意”者就要花费更多的时间去猜测数据库文件名，无形中增强了Access数据库的安全性。很多ASP程序为方便用户使用，它的数据库文件通常都被命名为“data.mdb”，这大大方便了有经验的攻击者。如果我们将数据库文件名修改得复杂一些，他人就不易猜到，如将“data.mdb”修改为“1rtj0ma27xi.mdb”，然后修改数据库连接文件中的相应信息。这样Access数据库就相对安全一些。此方法适合于那些租用Web空间的用户使用。但其不足之处是，一旦查看到数据库连接文件中的内容，再复杂的文件名也无济于事。⒉利用ODBC数据源很多网站Web程序，将Access数据库文件的存储路径和文件名存放在数据库连接文件中。一旦这些连接文件中的内容外泄，那么不管数据库文件名多么复杂，都会暴露出踪迹。这时就可以使用ODBC数据源方法，即使连接文件的内容外泄，他人也只能知道网站程序所使用的ODBC数据源名称，而数据库文件的存储路径和文件名却无法找到。接着在ⅡS服务器中新建名为“rtjmaxi”的ODBC数据源，并在其中指定“1rtj0ma27xi.mdb”数据库文件的位置即可，最后点击“确定”按钮完成配置。但其不足之处是，此方法不适合于租用Web空间的用户使用，要想使用ODBC数据源方法，必须要有管理和维护ⅡS服务器的权限。⒊改变存储位置一般情况下，Access数据库文件存放在相应的Web目录中，很多黑客就是利用这种规律来查找并下载数据库文件。因此可以采用改变数据库文件存储位置的方法，将数据库文件存放在Web目录以外的某个文件夹中，让黑客难以猜测存储位置。接着修改好数据库连接文件中的数据库文件相应信息，这样Access数据库文件就安全多了。即使攻击者通过连接文件找到数据库文件的存储路径，由于数据库文件存放在Web目录以外的地方，攻击者就无法通过HTTP方式下载数据库文件。但其不足之处是，此方法不适合于租用Web空间的用户使用，因为将Access数据库文件移至Web目录之外，一般需要很大的权限。以上方法，在不同程度上增强了数据库文件的安全性，但我们不能将它们当成“仙丹妙药”，毕竟网络环境是复杂的，黑客的破坏手段也在不断增强，我们可以根据自己的需要，选择其中的多种方法配合使用，效果才会更理想，网站数据库后台文件才会更加安全。数据库网站管理措施服务器管理员还应在ⅡS中为每个网站设置好执行权限，可千万别给人家静态网站以&脚本和可执行&权限。一般情况下给个&纯脚本&权限就够了，对于那些通过网站后台管理中心上传的文件存放的目录，就更吝啬一点吧，执行权限设为&无&好了，这样做是为了防止人家上传ASP木马，执行权限设为&无&，人家上传ASP木马也运行不了。一般情况下，SQL注入漏洞仅是涉及一个网站安全的事，如果人家通过这个漏洞上传了ASP木马并运行起来，那整个服务器都失陷了。所以有远见的、有责任心的服务器管理员应该十分吝啬的配置ⅡS的执行权限。程序员主要要做两件事，最重要的一件事，当然是对客户端提交的变量参数进行仔细地检测。对客户端提交的变量进行检查以防止SQL注入。二是给用户密码加密。比如用MD5加密。MD5是没有反向算法，不能解密的。人家即使知道经加密后存在数据库里的像乱码一样的密码，他也没办法知道原始密码了。}