数据库知识

1、关系型数据库与非关系型数据库

数据库类型	数据模型	扩展性	性能	举例
关系型数据库	基于严格的关系模型->表格	较差	查询时要优化	电商网站的商品信息
非关系型数据库	相对灵活 比如键值对(redis) 文档数据库(MongoDB)	较好	较好	用户行为日志

2、DBS DBMS OS 关系

用户通过DBMS接口与数据库进行交互
DBMS负责解析用户的请求，同时需要调用操作系统的一些功能来完成数据的操作和管理（eg.创建表时，DBMS会在硬盘上创建相应的数据文件…）

3、三层模式二级映射

（1）表示：

（2）实现概念模式最常用的表示方法是E-R关系（可以想象成记录仓库货物的表单）：

（3）内模式 ：数据库的物理实现（仓库里的货物）：

（4）特定的用户看到指定的信息（供应商，仓库管理人员只能看到允许他看到的）

4、范式

1、第一范式（1NF）：
特点：表中的每个列都是不可分割的基本数据项，即列的值是原子的，不可以再分解。
举例：假设有一个学生信息表，其中包含姓名和联系方式两个字段。如果联系方式字段中存储了多个电话号码，并且这些电话号码可以用逗号分隔，那么这个字段就违反了第一范式，因为它可以被分解为更小的数据单元。正确的做法是将每个电话号码存储在单独的行中。

2、第二范式（2NF）：
特点：在满足1NF的基础上，要求表中的每个非主属性完全依赖于主键，没有部分依赖。即表中的所有非主键字段都必须依赖于整个主键，而不是主键的一部分。
举例：如果有一个课程成绩表，其中包含学号、课程编号和成绩三个字段，并且学号和课程编号共同作为复合主键。如果成绩只依赖于课程编号而不是整个复合主键，那么就违反了第二范式。应该将课程和学生信息分别存储在不同的表中，并通过主键与课程成绩表关联。

3、第三范式（3NF）：
特点：在满足2NF的基础上，要求非主属性之间没有传递依赖，即一个非主属性不能依赖于另一个非主属性。
举例：如果有一个员工表，其中包含员工ID、部门ID、员工姓名、部门名称和部门位置。如果部门名称和部门位置依赖于部门ID，而部门ID是员工表的非主属性，那么这就违反了第三范式。应该将部门信息存储在单独的表中，并通过部门ID与员工表关联。

4、BCNF（巴斯-科德范式）：
特点：是3NF的加强版，要求任何非平凡的（non-trivial）函数依赖X → Y，X都必须是超键。即对于任何非主属性对候选键的依赖，该候选键必须是表的候选键。
举例：考虑一个教师授课表，包含教师ID、课程ID、授课时间，其中教师ID和课程ID组成复合主键。如果存在函数依赖教师ID → 授课时间，那么这违反了BCNF，因为教师ID不是超键。应该将授课时间与教师ID分开，单独存储在以教师ID为主键的表中。

5、第四范式（4NF）：
特点：要求表中不存在多值依赖，即一个表中不应该有两个或多个独立的多值事实关于同一个主键。
举例：如果有一个项目表，其中包含项目经理ID、项目ID、任务和任务负责人ID。如果一个项目有多个任务，并且每个任务由不同的负责人负责，那么任务和任务负责人ID对于项目ID存在多值依赖，这违反了第四范式。应该将任务和任务负责人信息分离到单独的表中。

6、第五范式（5NF）：
特点：又称完美范式，要求消除所有类型的连接依赖（join dependency），即表中的任何非平凡且非隐含的连接依赖都必须是对候选键的依赖。
举例：如果有一个学生选课表，包含学生ID、课程ID、教师ID，并且学生ID和课程ID共同作为主键。如果存在连接依赖学生ID → 教师ID，那么这违反了第五范式，因为这种依赖不是基于整个主键的。应该将教师信息分离到单独的表中，并通过课程ID与学生选课表关联。
在实际的数据库设计中，通常只需要满足第三范式或BCNF即可，因为更高的范式可能会导致过度规范化，从而增加查询的复杂性和降低性能。然而，在某些需要严格数据完整性和减少冗余的场景下，可能会采用更高级别的范式。