什么是数据库、数据库管理系统、数据库系统、数据库管理员？
- 数据库（DB）：信息的集合，或者说数据库是由数据库管理系统的数据的集合
- 数据库管理系统（DBMS）：是一种操作和管理数据库的大型软件，通常用于建立、使用和维护数据库
- 数据库系统（DBS）：通常由软件、数据库和数据库管理员组成
- 数据库管理员（DBA）：负责全面管理和控制数据库系统
元组、码、候选码、主码、外码、主属性、非主属性？
- 元组：tuple，是关系型数据库中的基本概念，关系是一张表，表中的每行即每条记录，就是一个元组，每一列就是一个属性，在二维表里，元组也被称为行
- 码：是能唯一标识实体的属性，对应表中的列
- 候选码：如果关系中的某一属性或属性组的值能唯一的标识一个元组，任何、子集都不能再标识，则称该属性组为候选码
- 主码：主键，是从候选码中选出来的，一个实体集中只能有一个主码，但可以有多个候选码
- 外码：外键，如果一个关系中的一个属性是另外一个关系中的主码则这个属性为外码
- 主属性：候选码中出现过的属性称为主属性
- 非主属性：不包含在任何一个候选码中的属性称为非主属性
ER图？
全称：Entity Relationship Diagram，实体联系图
由三要素组成
- 实体：通常是现实世界的业务对象，使用矩形框表示
- 属性：某个实体拥有的属性，用来描述组成实体的要素，使用椭圆形表示
- 联系：实体与实体间的关系，使用菱形表示
数据库范式？
三种
- 第一范式（1NF）：属性不可再分
- 第二范式（2NF）：1NF的基础上消除了非主属性对于码的部分函数依赖
- 第三范式（3NF）：3NF在2NF的基础上消除了非主属性对于码的传递函数依赖
第一范式（1NF）
属性不能再被分割，即该字段只能是一个值，不能再分为多个其他的字段，1NF是所有关系型数据库的最基本要求，关系型数据库种创建的表一定满足第一范式
第二范式（2NF）
2NF在1NF的基础上消除了非主属性对于码的部分函数依赖，例如：
满足1NF但不满足2NF：
CREATE TABLE Custom_Order(
ID INT NOT NULL,
Custom_ID INT NOT NULL,
Custom_Name VARCHAR (20) NOT NULL,
Order_ID INT NOT NULL,
Sale_Date DATETIME NOT NULL,
Order_Detail DOUBLE NOT NULL,
PRIMARY KEY (ID)
);主键和列存在部分依赖关系
- Custom_Name依赖于Custom_ID
- 客户名与购买的商品没有直接关系
于是：
-- 用户信息表
CREATE TABLE Customs(
ID INT NOT NULL,
NAME VARCHAR (20) NOT NULL,
PRIMARY KEY (ID)
);
-- 订单表
CREATE TABLE Orders(
ID INT NOT NULL,
Detail DOUBLE NOT NULL,
PRIMARY KEY (ID)
);
-- 用户订单表
CREATE TABLE CUSTMERORDERS(
Custom_ID INT NOT NULL,
Order_ID INT NOT NULL,
Sale_Date DATETIME,
PRIMARY KEY (CUST_ID, ORDER_ID)
);拆成三个表，满足2NF
- 函数依赖（function dependency）：如果在一张表中，在属性X的值确定的情况下，必定能确定Y的值，那么就可以说Y函数依赖于X，写作X->Y
- 部分函数依赖（partial function dependency）：如果X->Y，并且存在X的一个真子集X0，使得X0->Y，则称Y对X部分函数依赖
- 完全函数依赖（full function dependency）：在一个关系中如果某个非主属性数据项依赖于全部关键字则成为完全函数依赖
- 传递函数依赖（transitive function dependency）：在关系模式R(U)中，设X，Y，Z是U的不同的属性子集，如果X确定Y，Y确定Z，且有X不包含Y，Y不确定X，(X∪Y)∩Z=空集合，则称Z传递函数依赖，传递函数依赖会导致数据冗余和异常
第三范式（3NF）
3NF在2NF的基础上消除了非主属性对于码的传递函数依赖，符合3NF要求的数据库设计，基本上解决了数据冗余过大，插入异常，修改异常，删除异常等问题
例：
| 学生id | 学生 | 性别 | 籍贯 | 院系 | 院系电话 |
|---|---|---|---|---|---|
| 1 | 张三 | 男 | 广东广州 | 计算机系 | 123 |
| 2 | 李四 | 女 | 山东青岛 | 电子系 | 234 |
| 3 | 王五 | 男 | 广东深圳 | 数学系 | 345 |
| 4 | 赵六 | 女 | 山东临沂 | 土木系 | 456 |
该例子满足了第一第二范式，不满足第三范式，非主键字段也完全依赖于主键字段，但是院系电话字段，其实是依赖于院系字段的，也就是说院系电话字段是非主键值，而以来了另一个非主键值：院系，所以不符合第三范式
优化后：
学生表
| 学生id | 学生 | 性别 | 籍贯 | 院系id |
|---|---|---|---|---|
| 1 | 张三 | 男 | 广东广州 | 1 |
| 2 | 李四 | 女 | 山东青岛 | 2 |
| 3 | 王五 | 男 | 广东深圳 | 3 |
| 4 | 赵六 | 女 | 山东临沂 | 4 |
院系表：
| 院系id | 院系 | 院系电话 |
|---|---|---|
| 1 | 计算机系 | 123 |
| 2 | 电子系 | 234 |
| 3 | 数学系 | 345 |
| 4 | 土木系 | 456 |
主键和外键有什么区别？
- 主键（主码）：用于唯一标识一个元组，不能有重复，不允许为空，一个表只能有一个主键
- 外键（外码）：外键用来和其他表建立联系，外键是另一张表的主键，外键可以有重复的，可以是控制，一个表可以有多个外键
为什么不推荐使用外键与级联？
在阿里巴巴Java开发手册中提到：
外键与级联更新适用于单机低并发，不适合分布式、高并发集群，联系更新是强阻塞，存在数据库更新风暴的风险，外键影响数据库的插入速度
但同时，外键能阿波正数据库数据的一致性和完整性，联机操作方便，减轻了代码量
存储过程？
在阿里巴巴Java开发手册中提到：
存储过程可以看作是一些SQL语句的集合，中间添加了逻辑控制语句，存储过程在业务较为复杂的时候是非常实用的，很多时候完成一个操作需要一长串的SQL语句，而写一个存储过程可以方便我们下一次进行调用。存储过程一旦调试完成通过后就能稳定运行，另外，使用存储过程比单纯SQL语句执行要快，因为存储过程是编译过的
DROP、DELETE、TRUNCATE？
用法方面
DROP：丢弃数据，语法为DROP TABLE 表名，直接将表删除，在删除表的时候使用DELETE：删除数据，语法为DELETE FROM 表名 WHERE 列名=值，删除某一行数据，如果不加WHERE，则和TRUNCATE TABLE 表名作用类似TUNCATE：清空数据，语法为TRUNCATE TABLE 表名，只删除表中的所有数据并让id归0，再次插入数据的时候id自增长又从1开始
TRUNCATE和 不带WHERE的DELETE以及DROP都会删除表内的数据，但是TRUNCATE和DELETE都只是删除表内的数据，表结构还在，但是DROP语句会直接把表结构也删除，执行DROP后对应的表将不存在
数据库语言方面
TRUNCATE 和 DROP 都数据DDL（数据定义语言）语句，操作立刻生效，原数据不放到rollback segment中，不能回滚，不触发trigger，而DELETE语句是DML（数据库操作语言）语句，这个操作会放到rollback segment中，事务提交后才会生效
DML语句和DDL语句的区别：
- DML是数据操作语言（Data Manipulation Language）的缩写，是指对数据库中表记录的操作，主要是对表记录进行增删改查的操作，是开发人员日常使用最频繁的操作
- DDL是数据定义语言（Data Definition Language）的缩写，是对数据库内部的对象进行增、删、改的操作语言，和DML最大的区别就是，DML只是对表内部数据进行操作，不会涉及表的定义、结构的修改，而DDL会修改到表的结构，一般由DBA进行使用
另外：由于
SELECT不会对表进行破坏，所以有时也会把SELECT单独区分开作为DQL（Data Query Language）数据查询语言
执行速度方面
DELETE命令执行的时候会产生数据库的binlog日志，而日志记录是消耗时间的，但是方便数据回滚恢复TRUNCATE命令执行的时候不会产生日志，所以比DELETE快，此外还会把表的自增值重置和索引恢复到初始大小DROP命令执行的时候会把表占用的空间全部释放掉
所以理论上应该是：DROP > TRUNCATE > DELETE
