数据库基础

部分转载自：
https://www.zhihu.com/question/24225007/answer/257969925
https://www.zhihu.com/question/24225007/answer/81501685
http://blog.csdn.net/qq_27093465/article/details/54693607
http://blog.csdn.net/bitcarmanlee/article/details/51011515
https://www.zhihu.com/question/24696366/answer/29189700

1、关系型数据库

关系型数据库是由多张能互相联接的二维行列表格组成的数据库。
非关系型数据库，又被称为NoSQL（Not Only SQL )。指非关系型、分布式、不提供ACID (数据库事务处理的四个本要素)的数据库设计模式，并强调Key-Value 存储和文档数据库的优点，而不是单纯地反对RDBMS。

关系型数据库和非关系型数据库在使用场景上差别比较大，只有结合自身的业务特点才能发挥出这两类数据库的优势。

下面说说这两类数据库的一些特点：

首先一般非关系型数据库是基于CAP模型，而传统的关系型数据库是基于ACID模型的

• 1.数据存储结构

首先关系型数据库一般都有固定的表结构，并且需要通过DDL语句（数据库模式定义语言，Data Definition Language）来修改表结构，不是很容易进行扩展，而非关系型数据库的存储机制就有很多了，比如基于文档的，K-V键值对的，还有基于图的等，对于数据的格式十分灵活没有固定的表结构，方便扩展，因此如果业务的数据结构并不是固定的或者经常变动比较大的，那么非关系型数据库是个好的选择。

• 2.可扩展性

传统的关系型数据库给人一种横向扩展难，不好对数据进行分片等，而一些非关系型数据库则原生就支持数据的水平扩展(比如mongodb的sharding机制)，并且这可能也是很多NoSQL的一大卖点，其实象Mysql这种关系型数据库的水平扩展也并不是难，即使NoSQL水平扩展容易但对于向跨分片进行joins这种场景都没有什么太好的解决办法，不管是关系型还是非关系型数据库，解决水平扩展或者跨分片Joins这种场景，在应用层和数据库层中间加一层中间件来做数据处理也许是个好的办法

• 3.数据一致性

非关系型数据库一般强调的是数据最终一致性，而不没有像ACID一样强调数据的强一致性，从非关系型数据库中读到的有可能还是处于一个中间态的数据，因此如果你的业务对于数据的一致性要求很高，那么非关系型数据库并不一个很好的选择，非关系型数据库可能更多的偏向于OLAP场景，而关系型数据库更多偏向于OLTP场景.

非关系型数据库的优势：

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

关系型数据库的优势：

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

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

2、ACID

ACID，指数据库事务正确执行的四个基本要素的缩写。包含：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。一个支持事务（Transaction）的数据库，必须要具有这四种特性，否则在事务过程（Transaction processing）当中无法保证数据的正确性，交易过程极可能达不到交易方的要求。

1、A (Atomicity) 原子性

原子性很容易理解，也就是说事务里的所有操作要么全部做完，要么都不做，事务成功的条件是事务里的所有操作都成功，只要有一个操作失败，整个事务就失败，需要回滚。

比如银行转账，从A账户转100元至B账户，分为两个步骤：1）从A账户取100元；2）存入100元至B账户。这两步要么一起完成，要么一起不完成，如果只完成第一步，第二步失败，钱会莫名其妙少了100元。

2、C (Consistency) 一致性

一致性也比较容易理解，也就是说数据库要一直处于一致的状态，事务的运行不会改变数据库原本的一致性约束。

例如现有完整性约束a+b=10，如果一个事务改变了a，那么必须得改变b，使得事务结束后依然满足a+b=10，否则事务失败。

3、I (Isolation) 独立性

所谓的独立性是指并发的事务之间不会互相影响，如果一个事务要访问的数据正在被另外一个事务修改，只要另外一个事务未提交，它所访问的数据就不受未提交事务的影响。

比如现有有个交易是从A账户转100元至B账户，在这个交易还未完成的情况下，如果此时B查询自己的账户，是看不到新增加的100元的。

4、D (Durability) 持久性

持久性是指一旦事务提交后，它所做的修改将会永久的保存在数据库上，即使出现宕机也不会丢失。

3、OLTP和OLAP的区别

联机事务处理OLTP（on-line transaction processing）
主要是执行基本日常的事务处理，比如数据库记录的增删查改。比如在银行的一笔交易记录，就是一个典型的事务。

OLTP的特点一般有：

1.实时性要求高。我记得之前上大学的时候，银行异地汇款，要隔天才能到账，而现在是分分钟到账的节奏，说明现在银行的实时处理能力大大增强。
2.数据量不是很大，生产库上的数据量一般不会太大，而且会及时做相应的数据处理与转移。
3.交易一般是确定的，比如银行存取款的金额肯定是确定的，所以OLTP是对确定性的数据进行存取
4.高并发，并且要求满足ACID原则。比如两人同时操作一个银行卡账户，比如大型的购物网站秒杀活动时上万的QPS请求。

联机分析处理OLAP（On-Line Analytical Processing）
是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。典型的应用就是复杂的动态的报表系统。

OLAP的特点一般有：

1.实时性要求不是很高，比如最常见的应用就是天级更新数据，然后出对应的数据报表。
2.数据量大，因为OLAP支持的是动态查询，所以用户也许要通过将很多数据的统计后才能得到想要知道的信息，例如时间序列分析等等，所以处理的数据量很大;
3.OLAP系统的重点是通过数据提供决策支持，所以查询一般都是动态，自定义的。所以在OLAP中，维度的概念特别重要。一般会将用户所有关心的维度数据，存入对应数据平台。

总结：

OLTP即联机事务处理，就是我们经常说的关系数据库，增删查改就是我们经常应用的东西，这是数据库的基础；TPCC(Transaction Processing Performance Council)属于此类。
OLAP即联机分析处理，是数据仓库的核心部心，所谓数据仓库是对于大量已经由OLTP形成的数据的一种分析型的数据库，用于处理商业智能、决策支持等重要的决策信息；数据仓库是在数据库应用到一定程序之后而对历史数据的加工与分析，读取较多，更新较少，TPCH属于此类。
随着大数据时代的到来，对于OLAP，列存储模式或者说nosql模式比传统意义的行存储模式可能更具优势。

4、数据库的简单组成：

直观的看，一个数据库由多张表构成的，那么每张表有不重复的名称（表名），而且每个表是有多列组成的。可以这么理解一张表就是一个关系。

关于表的还有一些概念要交代一下。
属性。一张关系表中的一个列就是一个属性，一个列又有它的名称和类型。
元组。一张关系表中的一行数据就是元组，也称为记录。
键。键是为在元组中快速查找而设置的。键有主键和候选键之分。

5、范式

定义：范式是“符合某一种级别的关系模式的集合，表示一个关系内部各属性之间的联系的合理化程度”。
可以粗略地理解为一张数据表的表结构所符合的某种设计标准的级别。就像家里装修买建材，最环保的是E0级，其次是E1级，还有E2级等等。

数据库范式也分为1NF，2NF，3NF，BCNF，4NF，5NF。一般在我们设计关系型数据库的时候，最多考虑到BCNF就够。符合高一级范式的设计，必定符合低一级范式，例如符合2NF的关系模式，必定符合1NF。

第一范式：

–指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。

符合1NF的关系中的每个属性都不可再分。

（1）元组中的每个属性只能包含一个值
（2）关系中的每个元组必须包含相同的数量
（3）关系中的每个元组一定不能相同

第一条就是说每个单元格必须只有一个值。第二条就是每行都有相同数量的列。第三条就是一个表中不能有相同的行。
下面这个表就不符合要求。

第二范式：

–满足第二范式必须先满足第一范式
–要求数据表中的每一行记录必须可以被唯一的区分
–通常需要为表添加主键

2NF在1NF的基础之上，非主属性完全依赖于码。
如对于（学号，课名） → 姓名，有 学号 → 姓名，存在非主属性 姓名 对码（学号，课名）的部分函数依赖。
造成插入异常、删除异常和修改异常。

码：关系中的某个属性或者某几个属性的组合，用于区分每个元组.

设 K 为某表中的一个属性或属性组，若除 K 之外的所有属性都完全函数依赖于 K，那么我们称 K 为候选码，简称为码。
在实际中我们通常可以理解为：假如当 K 确定的情况下，该表除 K 之外的所有属性的值也就随之确定，那么 K 就是码。一张表中可以有超过一个码。
（实际应用中为了方便，通常选择其中的一个码作为主码）

非主属性:包含在任何一个码中的属性成为主属性，否则为非主属性。

完全函数依赖：在一张表中，若 X → Y，且对于 X 的任何一个真子集（假如属性组 X 包含超过一个属性的话），X ’ → Y 不成立，那么我们称 Y 对于 X 完全函数依赖，记作 X F→ Y。

部分函数依赖：假如 Y 函数依赖于 X，但同时 Y 并不完全函数依赖于 X，那么我们就称 Y 部分函数依赖于 X，记作 X P→ Y。

传递函数依赖：假如 Z 函数依赖于 Y，且 Y 函数依赖于 X，且Y 不包含于 X，且 X 不函数依赖于 Y，那么我们就称 Z 传递函数依赖于 X ，记作 X T→ Z。

第三范式

–必须先满足第二范式，且消除传递依赖。
–要求一个数据库表中不包含已在其他表中已包含的非主关键字信息，也就是外键。

3NF在2NF的基础之上，消除了非主属性对于码的传递函数依赖。
符合3NF要求的数据库设计，基本上解决了数据冗余过大，插入异常，修改异常，删除异常的问题。

举例：
对于选课表，主码为（学号，课名），主属性为学号和课名，非主属性只有一个，为分数，不可能存在传递函数依赖，所以选课表的设计，符合3NF的要求。
对于学生表，主码为学号，主属性为学号，非主属性为姓名、系名和系主任。因为 学号 → 系名，同时 系名 → 系主任，所以存在非主属性系主任对于码学号的传递函数依赖，所以学生表的设计，不符合3NF的要求。

BCNF:

非主属性完全函数依赖于码，且不传递依赖于码，且仅一个候选码，并为单属性。

符合3NF，且主属性不依赖于主属性；
符合2NF，且每个属性都不传递依赖于键码；
符合3NF，且只有一个候选码，或每个候选码都是单属性。

4NF：

要求把同一张表中多对多的关系删除，即不允许存在非平凡的多值依赖。

5NF：

从最终结构重建原始结构。

6、约束

SQL约束主要有以下几种:

NOT NULL :
用于控制字段的内容一定不能为空（NULL）。

UNIQUE :
控制字段内容不能重复，一个表允许有多个 Unique 约束。

PRIMARY KEY:
也是用于控制字段内容不能重复，但它在一个表只允许出现一个。

FOREIGN KEY:
FOREIGN KEY 约束用于预防破坏表之间连接的动作，FOREIGN KEY 约束也能防止非法数据插入外键列，因为它必须是它指向的那个表中的值之一。

CHECK:
用于控制字段的值范围。

DEFAULT:
用于设置新记录的默认值。