database 理论

关系数据库有几种设计范式？
第一范式（1NF）：表中的任何一列或者一组列不允许有重复值，如果出现重复值，先创建一个包含这些列的新表，然后在旧表中创建外键关联新表。满足第一范式是对关系数据库的最基本要求；
强调的是列的原子性，即列不能够再分成其他几列。
考虑这样一个表：【联系人】（姓名，性别，电话）
如果在实际场景中，一个联系人有家庭电话和公司电话，那么这种表结构设计就没有达到 1NF。要符合 1NF 我们只需把列（电话）拆分，即：【联系人】（姓名，性别，家庭电话，公司电话）
第二范式（2NF）：在满足第一范式的基础上，表中的每行都必须依赖于一个唯一标识列，在主表中创建外键关联副表的主键；
包含两部分内容，一是表必须有一个主键；二是没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分
第三范式（3NF）：在满足第二范式的基础上，表中不允许出现已经存在于关联表中的冗余列；
非主键列必须直接依赖于主键，不能存在传递依赖。即不能存在：非主键列 A 依赖于非主键列 B，非主键列 B 依赖于主键的情况。

数据库事务有哪些特性？
原子性（Atomic）：事务中包含的所有SQL语句组成一个不可分割的工作单元，要么全部都完成，要么什么都不做；
一致性（Consist）：无论在事务的开始之前或结束之后，数据库完整性都必须保持一致；
隔离性（Isolated）：多个事务独立运行，互不影响，在任何事务的运行期间无法看到其他事务运行期的数据变化；
持久性（Dutable）：事务被提交后，该事务对数据库所做的更改会被永远地保存下来，即使数据库服务器崩溃了也是如此；

数据库完整性（DatabaseIntegrity）是指数据库中数据的正确性和相容性。数据库完整性由各种各样的完整性约束来保证，因此可以说数据库完整性设计就是数据库完整性约束的设计
 
数据库中常见的事务并发问题有哪些？
不可重复读（Nonrepeatable Read）：首先，事务T1执行查询读取了一行记录。紧接着事务T2修改了T1刚读取的记录。然后T1再次读取那行记录，却发现已经与第一次读取的结果不同了；
幻读（Phantom Read）：首先，事务T1执行一句查询语句获得了N行记录。紧接着事务T2插入一行新记录，该记录恰好满足T1刚执行查询的行件。然后T1再次执行同样的查询语句，却获得了N+1行记录，包含T2新插入的那行记录；
脏读（Dirty Read）：事务T1更新了一行记录的内容，但并没有提交。紧接着事务T2读取了更新后的行。然后T1执行了回滚操作，这时T2所读取的行就无效了；

数据库有哪些锁技术？
读锁：当前事务结束之前，不允许其他事务修改正在读取的数据，只能读取，用于读取操作。可以避免不可重复读；
写锁：当前事务结束之前，不允许其他事务修改数据，用于更新操作。可以避免幻读和不可重复读；
排他写锁：当前事务结束之前，不允许其他事务读取或修改数据，用于更新操作，可以避免幻读、不可重复读和脏读；

数据库事务有哪些隔离级别？
ReadUncommitted：事务可以读取未被提交的数据；
Read Committed：事务不能读取未被提交的数据，只能避免脏读；
RepeatableRead：事务不能修改其他事务正在读取的数据，可以避免脏读和不可重复读；
Serializable：具有排他的读写权限，避免了脏读、不可重复读和幻读；

数据库采用日志来保证事务的原子性，一致性和持久性，日志记录了事务对数据库所做的更新，如果某个事务在执行过程中发生错误，就可以根据日志，撤销事务对数据库已做的更改，使数据库退回到执行事务前的初始状态。

数据库使用锁机制来保证事务的隔离性，拥有各自独立的空间。

那么事务的隔离级别与锁有什么关系呢？
    事务的隔离级别是通过锁的机制实现的，事务的隔离级别是数据库开发商根据业务逻辑的实际需要定义的一组锁的使用策略。
    锁是实现隔离级别的基础
锁是通过数据库管理系统的隔离级别（Isolation Level）来定义的
隔离级别可以控制锁的行为，间接控制数据库的并发性

在数据库的锁机制定义中有乐观锁（或积极锁，optimistic locking）和悲观锁（或消极锁，pessimistic locking）两种分类。
乐观锁，顾名思义，对发生并发的情况估计比较乐观，所以对锁的控制比较宽松，只有当对某项记录进行修改操作的时候，才对其进行锁定。这样如果两个事务（transaction）先后修改了某项记录，可能会导致数据修改的失败，因为这不是事务一级的锁，事务处理过程中会有某些时段对记录是没有加锁的，另一事务在这个时段就可能修改同一记录，导致前者修改失败。

乐观锁的实现策略
版本 (Version) 字段：在我们的实体中增加一个版本控制字段，每次事务更新后就将版本字段的值加1.
时间戳 (timestamps): 采取这种策略后，当每次要提交更新的时候就会将系统当前时间和修改时间。

悲观锁，与乐观锁相反，与事务结合在一起，对数据库的并发性进行控制（可能完全没有并发 性，对每个事务串行处理），对数据库管理系统(DBMS)有额外的负担，但能保证对记录修改的成功。
悲观锁也就是上面讲到的我们认为的通常意义上的锁 。