资料库 : 资料库(DataBase 全称 DB)是重要信息的开集换句话说资料库是由资料库重要信息系统管理工作的统计数据的开集。
资料库重要信息系统: 资料库重要信息系统(Database Management System 简称 DBMS)是一类操纵者和管理工作资料库的应用软件产品，一般来说用作创建、采用和保护资料库。
资料库系统: 资料库系统(Data Base System，全称 DBS)一般来说由应用软件、资料库和统计数据管理工作员(DBA)共同组成。
资料库管理工作员 : 资料库管理工作员(Database Administrator, 全称 DBA)负责管理全面性管理工作和掌控资料库系统。
资料库系统基本上形成如下表所示图右图：
甚么是位元, 码, 备选码, 主码, 外码, 主特性, 非主特性？
位元 ： 位元（tuple）是亲密关系资料库中的基本上原理，亲密关系是两张表，附注的第一行（即资料库中的每一历史记录）是两个位元，每列是两个特性。 在三维UX21LI2677E，位元也称作行。
码：码是能惟一标记实体的特性，相关联附注的列。
备选码： 若亲密关系中的某一特性或特性组的值能惟一的标记两个位元，而其任何人、开集都无法再标记，则称该特性组与备选码。比如：在小学生虚拟中，“序号”是能惟一的界定小学生虚拟的，与此同时又假定“联系电话”、“年级”的特性女团不足以界定小学生虚拟，所以{序号}和{联系电话，年级}都是备选码。
主码 : 主码也叫换行符。主码从备选码穿鞘出的。 两个虚拟分散根本无法有两个主码，但能有数个备选码。
外码: 外码也叫外键。如果两个亲密关系中的两个特性是另外两个亲密关系中的主码则这个特性为外码。
主特性： 备选码中出现过的特性称作主特性。比如亲密关系 工人（工号，身份证号，联系电话，性别，部门）. 显然工号和身份证号都能够惟一标示这个亲密关系，所以都是备选码。工号、身份证号这两个特性是主特性。如果主码是两个特性组，所以特性组中的特性都是主特性。
非主特性：不包含在任何人两个备选码中的特性称作非主特性。比如在亲密关系——小学生（序号，联系电话，年龄，性别，年级）中，主码是“序号”，所以其他的“联系电话”、“年龄”、“性别”、“年级”就都能称作非主特性。
换行符和外键有甚么区别?
换行符(主码)：换行符用作惟一标记两个位元，无法有重复，不允许为空。两个表只能有两个换行符。
外键(外码) ：外键用来和其他表创建联系用，外键是另一表的换行符，外键是能有重复的，能是空值。两个表能有数个外键。
为甚么不推荐采用外键与级联？
对于外键和级联，阿里巴巴开发手册这样说到：
【强制】不得采用外键与级联，一切外键概念必须在应用层解决。
说明: 以小学生和成绩的亲密关系为例，小学生附注的 student_id 是换行符，所以成绩附注的 student_id 则为外键。如果更新小学生附注的 student_id，与此同时触发成绩附注的 student_id 更新，即为级联更新。外键与级联更新适用作单机低并发，不适合分布式、高并发集群; 级联更新是强阻塞，存在资料库更新风暴的风 险; 外键影响资料库的插入速度
为甚么不要用外键呢？大部分人可能会这样回答：
增加了复杂性：a. 每次做DELETE 或者UPDATE都必须考虑外键约束，会导致开发的时候很痛苦, 测试统计数据极为不方便; b. 外键的主从亲密关系是定的，假如那天需求有变化，资料库中的这个字段根本不需要和其他表有关联的话就会增加很多麻烦。
增加了额外工作： 资料库需要增加保护外键的工作，比如当我们做一些涉及外键字段的增，删，更新操作之后，需要触发相关操作去检查，保证统计数据的的一致性和正确性，这样会不得不消耗资源；（个人觉得这个不是不用外键的原因，因为即使你不采用外键，你在应用层面也还是要保证的。所以，我觉得这个影响能忽略不计。）
外键还会因为需要请求对其他表内部加锁而容易出现死锁情况；对分库分表不友好 ：因为分库分表下外键是无法生效的。
……我个人觉得上面这种回答不是特别的全面性，只是说了外键存在的两个常见的问题。实际上，我们知道外键也是有很多好处的，比如：
保证了资料库统计数据的一致性和完整性；级联操作方便，减轻了程序代码量；……所以说，不要一股脑的就抛弃了外键这个概念，既然它存在就有它存在的道理，如果系统不涉及分库分表，并发量不是很高的情况还是能考虑采用外键的。
# 甚么是 ER 图？
我们做两个项目的时候一定要试着画 ER 图来捋清资料库设计，这个也是面试官问你项目的时候经常会被问道的。
E-R 图也称虚拟-联系图(Entity Relationship Diagram)，提供了表示虚拟类型、特性和联系的方法，用来描述现实世界的概念模型。 它是描述现实世界亲密关系概念模型的有效方法。 是表示概念亲密关系模型的一类方式。
下图是一个小学生选课的 ER 图，每个小学生能选若干门课程，同一门课程也能被若干人选择，所以它们之间的亲密关系是多对多（M: N）。另外，还有其他两种亲密关系是：1 对 1（1:1）、1 对多（1: N）。
我们试着将上面的 ER 图转换成资料库实际的亲密关系模型(实际设计中，我们一般来说会将任课教师也作为两个虚拟来处理)：
资料库范式了解吗?
1NF(第一范式)
特性（相关联于附注的字段）无法再被分割，也是这个字段根本无法是两个值，无法再分为数个其他的字段了。1NF 是所有亲密关系型资料库的最基本上要求 ，也是说亲密关系型资料库中创建的表一定满足第一范式。
2NF(第二范式)
2NF 在 1NF 的基础之上，消除了非主特性对于码的部分函数依赖。如下表所示图右图，展示了第一范式到第二范式的过渡。第二范式在第一范式的基础上增加了两个列，这个列称作换行符，非主特性都依赖于换行符。
一些重要的概念：
函数依赖（functional dependency）：若在两张附注，在特性（或特性组）X 的值确定的情况下，必定能确定特性 Y 的值，所以就能说 Y 函数依赖于 X，写作 X → Y。部分函数依赖（partial functional dependency）：如果 X→Y，并且存在 X 的两个真开集 X0，使得 X0→Y，则称 Y 对 X 部分函数依赖。比如小学生基本上重要信息表 R 中（序号，身份证号，联系电话）当然序号特性取值是惟一的，在 R 亲密关系中，（序号，身份证号）->（联系电话），（序号）->（联系电话），（身份证号）->（联系电话）；所以联系电话部分函数依赖与（序号，身份证号）；完全函数依赖(Full functional dependency)：在两个亲密关系中，若某个非主特性统计数据项依赖于全部关键字称之为完全函数依赖。比如小学生基本上重要信息表 R（序号，年级，联系电话）假定不同的年级序号有相同的，年级内序号无法相同，在 R 亲密关系中，（序号，年级）->（联系电话），但是（序号）->(联系电话)不成立，（年级）->(联系电话)不成立，所以联系电话完全函数依赖与（序号，年级）；传递函数依赖： 在亲密关系模式 R(U)中，设 X，Y，Z 是 U 的不同的特性开集，如果 X 确定 Y、Y 确定 Z，且有 X 不包含 Y，Y 不确定 X，（X∪Y）∩Z=空开集，则称 Z 传递函数依赖(transitive functional dependency) 于 X。传递函数依赖会导致统计数据冗余和异常。传递函数依赖的 Y 和 Z 开集往往同属于某两个事物，因此可将其合并放到两个附注。比如在亲密关系 R(序号 , 联系电话, 系名，系主任)中，序号 → 系名，系名 → 系主任，所以存在非主特性系主任对于序号的传递函数依赖。。3NF(第三范式)
3NF 在 2NF 的基础之上，消除了非主特性对于码的传递函数依赖 。符合 3NF 要求的资料库设计，基本上上解决了统计数据冗余过大，插入异常，修改异常，删除异常的问题。比如在亲密关系 R(序号 , 联系电话, 系名，系主任)中，序号 → 系名，系名 → 系主任，所以存在非主特性系主任对于序号的传递函数依赖，所以该表的设计，不符合 3NF 的要求。
总结
1NF：特性不可再分。2NF：1NF 的基础之上，消除了非主特性对于码的部分函数依赖。3NF：3NF 在 2NF 的基础之上，消除了非主特性对于码的传递函数依赖 。# 甚么是存储过程?
我们能把存储过程看成是一些 SQL 语句的开集，中间加了点逻辑掌控语句。存储过程在业务比较复杂的时候是非常实用的，比如很多时候我们完成两个操作可能需要写一大串 SQL 语句，这时候我们就能写有两个存储过程，这样也方便了我们下一次的调用。存储过程一旦调试完成通过后就能稳定运行，另外，采用存储过程比单纯 SQL 语句执行要快，因为存储过程是预编译过的。
存储过程在互联网公司应用不多，因为存储过程难以调试和扩展，而且没有移植性，还会消耗资料库资源。
阿里巴巴 Java 开发手册里要求禁止采用存储过程。
drop、delete 与 truncate 区别？
用法不同
drop(丢弃统计数据): drop table 表名 ，直接将表都删除掉，在删除表的时候采用。truncate (清空统计数据) : truncate table 表名 ，只删除附注的统计数据，再插入统计数据的时候自增长 id 又从 1 开始，在清空附注统计数据的时候采用。delete（删除统计数据） : delete from 表名 where 列名=值，删除某一列的统计数据，如果不加 where 子句和truncate table 表名作用类似。truncate 和不带 where 子句的 delete、以及 drop 都会删除表内的统计数据，但是truncate 和 delete 只删除统计数据不删除表的结构(定义)，执行 drop 语句，此表的结构也会删除，也是执行 drop 之后相关联的表不复存在。
# 属于不同的资料库语言
truncate 和 drop 属于 DDL(统计数据定义语言)语句，操作立即生效，原统计数据不放到 rollback segment 中，无法回滚，操作不触发 trigger。而 delete 语句是 DML (资料库操作语言)语句，这个操作会放到 rollback segement 中，事务提交之后才生效。
DML 语句和 DDL 语句区别：
DML 是资料库操作语言（Data Manipulation Language）的缩写，是指对资料库中表历史记录的操作，主要包括表历史记录的插入（insert）、更新（update）、删除（delete）和查询（select），是开发人员日常使用最频繁的操作。DDL （Data Definition Language）是统计数据定义语言的缩写，简单来说，是对资料库内部的对象进行创建、删除、修改的操作语言。它和 DML 语言的最大区别是 DML 只是对表内部统计数据的操作，而不涉及到表的定义、结构的修改，更不会涉及到其他对象。DDL 语句更多的被资料库管理工作员（DBA）所采用，一般的开发人员很少采用。# 执行速度不同
一般来说:drop>truncate>delete（这个我没有设计测试过）。
