数据库1

数据冗余

是指数据之间的重复，也可以说是同一数据存储在不同数据文件中的现象。可以说增加数据的独立性和减少数据冗余是企业范围信息资源管理和大规模信息系统获得成功的前提条件。

数据冗余或者信息冗余是生产、生活所必然存在的行为，没有好与不好的总体倾向。

数据的应用中为了某种目的采取数据冗余方式。

1、重复存储或传输数据以防止数据的丢失。

2、对数据进行冗余性的编码来防止数据的丢失、错误，并提供对错误数据进行反变换得到原始数据的功能。

3、为简化流程所造成额数据冗余。例如向多个目的发送同样的信息、在多个地点存放同样的信息，而不对数据进行分析而减少工作量。

4、为加快处理过程而将同一数据在不同地点存放。例如并行处理同一信息的不同内容，或用不同方法处理同一信息等。

5、为方便处理而使同一信息在不同地点有不同的表现形式。例如一本书的不同语言的版本。

6、大量数据的索引,一般在数据库中经常使用。其目的类似第4点。

7、方法类的信息冗余：比如每个司机都要记住同一城市的基本交通信息；大量个人电脑都安装类似的操作系统或软件。

8、为了完备性而配备的冗余数据。例如字典里的字很多，但我们只查询其中很少的一些字。软件功能很多，但我们只使用其中一部分。

9、规则性的冗余。根据法律、制度、规则等约束进行的。例如合同中大量的模式化的内容。

10、为达到其他目的所进行的冗余。例如重复信息以达到被重视等等。

key是键，value是值。打个比方吧！定义了一个map，我们可以用map.put("a","b")。此时a就是健，b就是指。我们可以用map.get("a")根据健取得值“b”
关系型数据库 菲关系型数据库 

作者：陈鼎星
链接：https://www.zhihu.com/question/24225007/answer/81501685
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

1. 关系型数据库

关系型数据库，是指采用了关系模型来组织数据的数据库。

关系模型是在1970年由IBM的研究员E.F.Codd博士首先提出的，在之后的几十年中，关系模型的概念得到了充分的发展并逐渐成为主流数据库结构的主流模型。

简单来说，关系模型指的就是二维表格模型，而一个关系型数据库就是由二维表及其之间的联系所组成的一个数据组织。

关系模型中常用的概念：

• 关系：可以理解为一张二维表，每个关系都具有一个关系名，就是通常说的表名
• 元组：可以理解为二维表中的一行，在数据库中经常被称为记录
• 属性：可以理解为二维表中的一列，在数据库中经常被称为字段
• 域：属性的取值范围，也就是数据库中某一列的取值限制
• 关键字：一组可以唯一标识元组的属性，数据库中常称为主键，由一个或多个列组成
• 关系模式：指对关系的描述。其格式为：关系名(属性1，属性2， ... ... ，属性N)，在数据库中成为表结构

关系型数据库的优点：

• 容易理解：二维表结构是非常贴近逻辑世界的一个概念，关系模型相对网状、层次等其他模型来说更容易理解
• 使用方便：通用的SQL语言使得操作关系型数据库非常方便
• 易于维护：丰富的完整性(实体完整性、参照完整性和用户定义的完整性)大大减低了数据冗余和数据不一致的概率

2. 关系型数据库瓶颈

• 高并发读写需求

网站的用户并发性非常高，往往达到每秒上万次读写请求，对于传统关系型数据库来说，硬盘I/O是一个很大的瓶颈

• 海量数据的高效率读写

网站每天产生的数据量是巨大的，对于关系型数据库来说，在一张包含海量数据的表中查询，效率是非常低的

• 高扩展性和可用性

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

对网站来说，关系型数据库的很多特性不再需要了：

• 事务一致性

关系型数据库在对事物一致性的维护中有很大的开销，而现在很多web2.0系统对事物的读写一致性都不高

• 读写实时性

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

• 复杂SQL，特别是多表关联查询

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

在关系型数据库中，导致性能欠佳的最主要原因是多表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询。为了保证数据库的ACID特性，我们必须尽量按照其要求的范式进行设计，关系型数据库中的表都是存储一个格式化的数据结构。每个元组字段的组成都是一样，即使不是每个元组都需要所有的字段，但数据库会为每个元组分配所有的字段，这样的结构可以便于标语表之间进行链接等操作，但从另一个角度来说它也是关系型数据库性能瓶颈的一个因素。

3. NoSQL

NoSQL一词首先是Carlo Strozzi在1998年提出来的，指的是他开发的一个没有SQL功能，轻量级的，开源的关系型数据库。这个定义跟我们现在对NoSQL的定义有很大的区别，它确确实实字如其名，指的就是“没有SQL”的数据库。但是NoSQL的发展慢慢偏离了初衷，我们要的不是“no sql”，而是“no relational”，也就是我们现在常说的非关系型数据库了。

2009年初，Johan Oskarsson举办了一场关于开源分布式数据库的讨论，Eric Evans在这次讨论中再次提出了NoSQL一词，用于指代那些非关系型的，分布式的，且一般不保证遵循ACID原则的数据存储系统。Eric Evans使用NoSQL这个词，并不是因为字面上的“没有SQL”的意思，他只是觉得很多经典的关系型数据库名字都叫“**SQL”,所以为了表示跟这些关系型数据库在定位上的截然不同，就是用了“NoSQL“一词。

注：数据库事务必须具备ACID特性，ACID是Atomic原子性，Consistency一致性，Isolation隔离性，Durability持久性。

非关系型数据库提出另一种理念，例如，以键值对存储，且结构不固定，每一个元组可以有不一样的字段，每个元组可以根据需要增加一些自己的键值对，这样就不会局限于固定的结构，可以减少一些时间和空间的开销。使用这种方式，用户可以根据需要去添加自己需要的字段，这样，为了获取用户的不同信息，不需要像关系型数据库中，要对多表进行关联查询。仅需要根据id取出相应的value就可以完成查询。但非关系型数据库由于很少的约束，他也不能够提供像SQL所提供的where这种对于字段属性值情况的查询。并且难以体现设计的完整性。他只适合存储一些较为简单的数据，对于需要进行较复杂查询的数据，SQL数据库显的更为合适。

4. 关系型数据库  V.S.  非关系型数据库

关系型数据库的最大特点就是事务的一致性：传统的关系型数据库读写操作都是事务的，具有ACID的特点，这个特性使得关系型数据库可以用于几乎所有对一致性有要求的系统中，如典型的银行系统。

但是，在网页应用中，尤其是SNS应用中，一致性却不是显得那么重要，用户A看到的内容和用户B看到同一用户C内容更新不一致是可以容忍的，或者说，两个人看到同一好友的数据更新的时间差那么几秒是可以容忍的，因此，关系型数据库的最大特点在这里已经无用武之地，起码不是那么重要了。

相反地，关系型数据库为了维护一致性所付出的巨大代价就是其读写性能比较差，而像微博、facebook这类SNS的应用，对并发读写能力要求极高，关系型数据库已经无法应付(在读方面，传统上为了克服关系型数据库缺陷，提高性能，都是增加一级memcache来静态化网页，而在SNS中，变化太快，memchache已经无能为力了)，因此，必须用新的一种数据结构存储来代替关系数据库。

关系数据库的另一个特点就是其具有固定的表结构，因此，其扩展性极差，而在SNS中，系统的升级，功能的增加，往往意味着数据结构巨大变动，这一点关系型数据库也难以应付，需要新的结构化数据存储。

于是，非关系型数据库应运而生，由于不可能用一种数据结构化存储应付所有的新的需求，因此，非关系型数据库严格上不是一种数据库，应该是一种数据结构化存储方法的集合。

必须强调的是，数据的持久存储，尤其是海量数据的持久存储，还是需要一种关系数据库这员老将。

 

5. 非关系型数据库分类

由于非关系型数据库本身天然的多样性，以及出现的时间较短，因此，不想关系型数据库，有几种数据库能够一统江山，非关系型数据库非常多，并且大部分都是开源的。

这些数据库中，其实实现大部分都比较简单，除了一些共性外，很大一部分都是针对某些特定的应用需求出现的，因此，对于该类应用，具有极高的性能。依据结构化方法以及应用场合的不同，主要分为以下几类：

• 面向高性能并发读写的key-value数据库：

key-value数据库的主要特点即使具有极高的并发读写性能，Redis,Tokyo Cabinet,Flare就是这类的代表

• 面向海量数据访问的面向文档数据库：

这类数据库的特点是，可以在海量的数据中快速的查询数据，典型代表为MongoDB以及CouchDB

• 面向可扩展性的分布式数据库：

这类数据库想解决的问题就是传统数据库存在可扩展性上的缺陷，这类数据库可以适应数据量的增加以及数据结构的变化

非关系型数据库的优势：

1. 性能
NOSQL是基于键值对的，可以想象成表中的主键和值的对应关系，而且不需要经过SQL层的解析，所以性能非常高。
2. 可扩展性
同样也是因为基于键值对，数据之间没有耦合性，所以非常容易水平扩展。

关系型数据库的优势：

1. 复杂查询
可以用SQL语句方便的在一个表以及多个表之间做非常复杂的数据查询。
2. 事务支持
使得对于安全性能很高的数据访问要求得以实现。

对于这两类数据库，对方的优势就是自己的弱势，反之亦然。

但是近年来这两种数据库都在向着另外一个方向进化。例如：
NOSQL数据库慢慢开始具备SQL数据库的一些复杂查询功能的雏形，比如Couchbase的index以及MONGO的复杂查询。对于事务的支持也可以用一些系统级的原子操作来实现例如乐观锁之类的方法来曲线救国。
SQL数据库也开始慢慢进化，比如HandlerSocker技术的实现，可以在MYSQL上实现对于SQL层的穿透，用NOSQL的方式访问数据库，性能可以上可以达到甚至超越NOSQL数据库。可扩展性上例如Percona Server，可以实现无中心化的集群。

虽然这两极都因为各自的弱势而开始进化出另一极的一些特性，但是这些特性的增加也会消弱其本来具备的优势，比如Couchbase上的index的增加会逐步降低数据库的读写性能。所以怎样构建系统的短期和长期存储策略，用好他们各自的强项是架构师需要好好考虑的重要问题。

 

数据库事务(Database Transaction) ，

是指作为单个逻辑工作单元执行的一系列操作，要么完全地执行，要么完全地不执行。 事务处理可以确保除非事务性单元内的所有操作都成功完成，否则不会永久更新面向数据的资源。通过将一组相关操作组合为一个要么全部成功要么全部失败的单元，可以简化错误恢复并使应用程序更加可靠。一个逻辑工作单元要成为事务，必须满足所谓的ACID（原子性、一致性、隔离性和持久性）属性。事务是数据库运行中的逻辑工作单位，由DBMS中的事务管理子系统负责事务的处理。

 

ACID原则

事务的原子性(Atomicity)

是指一个事务要么全部执行,要么不执行.也就是说一个事务不可能只执行了一半就停止了.比如你从取款机取钱,这个事务可以分成两个步骤:1划卡,2出钱.不可能划了卡,而钱却没出来.这两步必须同时完成.要么就不完成.

 

事务的一致性(Consistency)

是指事务的运行并不改变数据库中数据的一致性.例如,完整性约束了a+b=10,一个事务改变了a,那么b也应该随之改变.

 

独立性(Isolation）:

事务的独立性也有称作隔离性,是指两个以上的事务不会出现交错执行的状态.因为这样可能会导致数据不一致.

 

持久性(Durability）:

事务的持久性是指事务执行成功以后,该事务对数据库所作的更改便是持久的保存在数据库之中，不会无缘无故的回滚.

 

外键

如果公共关键字在一个关系中是主关键字，那么这个公共关键字被称为另一个关系的外键。由此可见，外键表示了两个关系之间的相关联系。以另一个关系的外键作主关键字的表被称为主表，具有此外键的表被称为主表的从表。外键又称作外关键字。

 

标识列，是SQL Server中的标识列又称标识符列，习惯上又叫自增列。标识列的创建与修改，通常在企业管理器和用Transact-SQL语句都可实现。

该种列具有以下三种特点：

1、列的数据类型为不带小数的数值类型

2、在进行插入（Insert）操作时，该列的值是由系统按一定规律生成，不允许空值

3、列值不重复，具有标识表中每一行的作用，每个表只能有一个标识列。

由于以上特点，使得标识列在数据库的设计中得到广泛的使用。

创建一个标识列，通常要指定三个内容：

1、类型（type）

在SQL Server 2000中，标识列类型必须是数值类型，如下：

decimal、int、numeric、smallint、bigint 、tinyint

其中要注意的是，当选择decimal和numeric时，小数位数必须为零

另外还要注意每种数据类型所有表示的数值范围

2、种子（seed)

是指派给表中第一行的值，默认为1

3、递增量（increment)

相邻两个标识值之间的增量，默认为1。

标识列的创建与修改，使用企业管理管理器比较简单，请参考SQL Server的联机帮助，这里只讨论使用Transact-SQL的方法

1、创建表时指定标识列

标识列可用 IDENTITY 属性建立，因此在SQL Server中，又称标识列为具有IDENTITY属性的列或IDENTITY列。

下面的例子创建一个包含名为ID，类型为int，种子为1，递增量为1的标识列

CREATE TABLE T_test

（ID int IDENTITY（1,1），

Name varchar（50）

）

2、在现有表中添加标识列

下面的例子向表T_test中添加一个名为ID，类型为int，种子为1，递增量为1的标识列

--创建表

CREATE TABLE T_test

（Name varchar（50）

）

--插入数据

INSERT T_test(Name) VALUES（’张三’）

--增加标识列

ALTER TABLE T_test

ADD ID int IDENTITY（1,1）

3、判段一个表是否具有标识列

可以使用 OBJECTPROPERTY 函数确定一个表是否具有 IDENTITY（标识）列，用法：

Select OBJECTPROPERTY(OBJECT_ID（’表名’），’TableHasIdentity’）

如果有，则返回1，否则返回0

4、判断某列是否是标识列

可使用 COLUMNPROPERTY 函数确定 某列是否具有IDENTITY 属性，用法

SELECT COLUMNPROPERTY(OBJECT_ID（’表名’），’列名’，’IsIdentity’）

如果该列为标识列，则返回1，否则返回0

5、查询某表标识列的列名

SQL Server中没有现成的函数实现此功能，实现的SQL语句如下

SELECT COLUMN_NAME FROM INFORMATION_SCHEMA.columns

WHERE TABLE_NAME=’表名’ ANDCOLUMNPROPERTY(

OBJECT_ID（’表名’），COLUMN_NAME，’IsIdentity’）=1

6、标识列的引用

如果在SQL语句中引用标识列，可用关键字IDENTITYCOL代替

例如，若要查询上例中ID等于1的行，

以下两条查询语句是等价的

SELECT * FROM T_test WHERE IDENTITYCOL=1

SELECT * FROM T_test WHERE ID=1

7、获取标识列的种子值

可使用函数IDENT_SEED，用法：

SELECT IDENT_SEED （’表名’）

8、获取标识列的递增量

可使用函数IDENT_INCR，用法：

SELECT IDENT_INCR（’表名’）

9、获取指定表中最后生成的标识值

可使用函数IDENT_CURRENT，用法：

SELECT IDENT_CURRENT（’表名’）

注意事项：当包含标识列的表刚刚创建，为经过任何插入操作时，使用IDENT_CURRENT函数得到的值为标识列的种子值，这一点在开发数据库应用程序的时候尤其应该注意。

数据完整性分为以下3类

（1）域完整性：是指一个列的输入有效性，是否允许为空值。强制域完整性的方法有：限制类型（通过设定列的数据类型）、格式（通过CHECK约束和规则）或可能值的范围（通过FOREIGN KEY约束、CHECK约束、DEFAULT定义、NOT NULL定义和规则）。如：学生的考试成绩必须在0～100之间，性别只能是“男”或“女”。
（2）实体完整性：是指保证表中所有的行唯一。实体完整性要求表中的所有行都有一个唯一标识符。这个唯一标识符可能是一列，也可能是几列的组合，称为主键。也就是说，表中的主键在所有行上必须取唯一值。强制实体完整性的方法有：索引、UNIQUE约束、PRIMARY KEY约束或IDENTITY属性。如：student表中sno（学号）的取值必须唯一，它唯一标识了相应记录所代表的学生，学号重复是非法的。学生的姓名不能作为主键，因为完全可能存在两个学生同名同姓的情况。
（3）参照完整性：是指保证主关键字（被引用表）和外部关键字（引用表）之间的参照关系。它涉及两个或两个以上表数据的一致性维护。外键值将引用表中包含此外键的记录和被引用表中主键与外键相匹配的记录关联起来。在输入、更改或删除记录时，参照完整性保持表之间已定义的关系，确保键值在所有表中一致。这样的一致性要求确保不会引用不存在的值，如果键值更改了，那么在整个数据库中，对该键值的所有引用要进行一致的更改。参照完整性是基于外键与主键之间的关系。例如学生学习课程的课程号必须是有效的课程号，score表（成绩表）的外键cno（课程号）将参考course表（课程表）中主键cno（课程号）以实现数据完整性。
域完整性、实体完整性及参照完整性分别在列、行、表上实施。数据完整性任何时候都可以实施，但对已有数据的表实施数据完整性时，系统要先检查表中的数据是否满足所实施的完整性，只有表中的数据满足了所实施的完整性，数据完整性才能实施成功。
（4）用户自定义完整性
自己设置 如性别 男或女 不能出现 不男不女