系统架构设计师教材：数据库设计基础知识
数据库基本概念
数据模型
数据库的基础结构是数据模型，是用来描述数据的一组概念和定义。数据模型的三要素是数据结构、数据操作和数据的约束条件。
- 数据结构：对象类型的集合。
- 数据操作：对数据库中的数据结构以及数据的可操作类型集合，包括操作及操作规则。如操作有增删改查，操作规则有优先级等。
- 数据的约束条件：如数据非空，唯一等。
按照不同的数据模型，可以将数据库的发展历史分为3个阶段。
- 层次和网状数据库系统：看不懂，没接触过，不知道是什么。
- 关系数据库系统：如mysql。
- 第三代数据库系统：nosql数据库。
数据库管理系统（DBMS）
DBMS 功能主要包括数据定义、数据库操作、数据库运行管理、数据组织、存储和管理、数据库的建立和维护。
就是mysql，pgsql这种就是DBMS。
数据库三级模式
站在数据库管理系统的角度看，数据库系统一般采用三级模式结构，其体系结构如图所示。
- 视图层：提供数据视图，展示部分用户关心的数据。
- 逻辑层：描述存储的数据，以及数据之间的关系。
- 物理层：描述数据如何存储在磁盘中。
从数据库管理系统的角度，数据库也分为三级模式，分别是外模式、概念模式和内模式。
- 外模式：数据库提供给用户的接口。
- 概念模式：对数据的类型以及关系。
- 内模式：描述数据如何存储在磁盘中。
两者其实都是一层对接用户，一层抽象底层，一层实际底层。
关系数据库
基本概念
- 关系的基本术语
- 属性：如人的性别，年龄就是一种属性。
- 域：对属性的限制成为域，比如性别只能是男女，年龄必须大于0。关系性数据对域还加了一个原子性限制，也就是数据库设计中的第一范式，但也有些关系数据模型突破了限制。
- 目或度：一个关系中属性的个数。
- 候选码：相较于其他个体唯一的属性，比如说id或者身份证等。
- 主码：主键，候选码中可以选择一个作为主码。
- 主属性：术语候选码的属性就是主属性。
- 外码：外键。表示一个表中的一个属性与另一个表中的主码（或候选码）之间的关联的约束。
- 全码：某个关系模式中的所有属性集都作为候选码的情况。
- 笛卡尔积：如（1，2）和（a，b）的笛卡尔积就是（1，a）（1，b）（2，a）（2，b），应用在数据库中时就是代表了数据库表各个字段的组合。
- 关系数据库模式
可以理解为就是表结构。
- 关系的完整性约束
完整性规则提供了一种手段来保证当授权用户对数据库做修改时不会破坏数据的一致性。关系的完整性约束共分3类：实体完整性、参照完整性(也称引用完整性)和用户定义完整性。
（1）实体完整性：每个数据必须有主键，主键属性必须唯一。
（2）参照完整性：两个关系之间存在的引用，比如说在公司系统中，个人关系模式和部门关系模式中，个人关系模式中包含部门信息，所有这个信息必须是部门关系模式的数据的其中之一，如果没有则设置为空（其实就是外键的定义）。
（3）用户定义完整性：就是对于某一个属性的限制，比如设置年龄必须小于一百。
关系运算
并、差、广义笛卡尔积、投影、选择、交、连接、除、广义投影、外链接、聚集函数。
关系数据库设计基本理论
函数依赖
X值的确定，能够确定Y的值，则称X函数决定Y，记作X→Y。
如果X的任意真子集都无法单独确定Y的值，则称X→Y是完全依赖。反之如果任何一个真子集都能确定Y的值，则称为部分依赖。比如说在学生，课程，和成绩三者之间，只有同时确定学生和课程后，才能确定成绩，这个就是完全依赖。
如果X→Y，Y→Z，则称X→Z是传递依赖。
如果Y包含在X中，则称X→Y是平凡的。反之如果不在，则证明是非平凡的。
多值依赖
在一个给定的关系模式下，X集合决定了Y集合的所有可能取值，并且与剩余的Z集合无关，则称X多值决定Y，记作X→→Y。
规范化
1NF（第一范式）
若关系模式每一个属性都不能再分，则该关系模式属于第一范式。
第一范式存在四个问题：
（1）冗余度大
（2）容易引起操作的不一致性（因为区分的不能再分，可能会将具有函数关系的两部分在修改时一个修改，而另一个没修改）
（3）插入异常（主键为空时不能插入）
（4）删除异常（如果X属性关联的属性变为空，我们需要删除这个属性的相关记录，但是当X属性关联的所有属性设置为空时，删除他们会导致X也会从数据中消失，但X又是客观存在的）
2NF（第二范式）
在满足第一范式的条件下，第二范式致力于消除非主键对于主键和候选键（候选键和主键一样，能够作为当前数据的标识的属性）的部分依赖（因为是部门依赖，所以第二范式限制的是联合主键），比如说订单编号和商品编号如果放在一个关系模式中就是违反第二范式的，因为这个两个任意一个都能够确认当前一条数据，是部分依赖，对于这种情况，需要将当前关系模式拆解为两个关系模式。
3NF（第三范式）
在满足第二范式的条件下，第三范式要求所有非主键必须直接依赖于候选键，不能存在传递依赖。比如说学号、姓名、身份证号、学院编号、学院的关系模式当中，虽然学院编号不能作为候选键，但是由于学生决定学院编号，学院编号又决定学院，存在传递依赖，在这个关系模式下，也是违反第三范式的，需要拆解为两个关系模式。
BCNF（巴克斯范式）
在满足第三范式的条件下，巴克斯范式要求在一个关系模式中，对于X→Y，必须满足Y属于X的一部分，也就是平凡依赖，或X是R的超键（超键的定义我也没太看明白，但应该和主键差不多）。
4NF（第四范式）
在满足巴克斯范式的条件下，第四范式要求在关系模式中，对于X集合→→Y集合，必须满足Y集合属于X集合的一部分，也就是平凡的多值依赖，或X是R的超键。
数据库设计
数据库设计的基本步骤包括：用户需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库实施阶段、数据库运行和维护阶段。
用户需求分析
步骤：了解用户需求；调查处理对象；了解现行系统；收集系统基础数据以及处理方法；
最终目的要求得到系统需要哪些信息，信息如何处理，以及系统的要求（如安全要求等）。
概念结构设计
概念结构设计的目标是产生反映系统信息需求的数据库概念结构。概念结构设计最著名最常用的方法是实体-联系方法（Entity - Relationship Approach），简称E-R 方法。它采用 E-R 模型将现实世界的信息结构统一由实体、属性，以及实体之间的联系来描述。对现实事物抽象认识的3种方法分别是分类、聚集和概括。
- 分类：对现实世界的事物，按照其具有的共同特征和行为，定义一种类型。
- 聚合：定义某一类型所具有的属性。
- 概括：:由一种已知类型定义新的类型。通常把已知类型称为超类（Superclass），新定义的类型称为子类（Subclass）。
概念结构设计工作步骤包括：选择局部应用、逐一设计分E-R 图和E-R 图合并。
- 选择局部应用：需求分析阶段会得到大量的数据，需要利用数据流图来理清数据，最终确定实体、属性和联系。
数据流图是对业务处理过程从高层到底层的一级级抽象，高层抽象流图一般反映系统的概貌，对数据的引用较为笼统，而底层又可能过于细致，不能体现数据的关联关系，因此要选择适当层次的数据流图，让这一层的每一部分对应一个局部应用，实现某一项功能。从这一层入手，就能很好地设计分E-R 图。
- 逐一设计分E-R图：给每个局部应用绘制E-R图。
- E-R图合并：对各分E-R 图进行合并，解决分E-R 图中相互间存在的冲突，消除信息冗余。E-R图合并时主要存在三种冲突，包括属性冲突，命名冲突，结构冲突。合并过程中的优化主要涉及：实体类型的合并（相似的关系模式），冗余属性的消除，冗余联系的消除。
逻辑结构设计
逻辑结构设计阶段的主要工作步骤包括确定数据模型、将E-R 图转换成为指定的数据模型、确定完整性约束和确定用户视图。
- E-R图转化为关系模式
（1）将E-R 图中的实体逐一转换成为一个关系模式，实体名对应关系模式的名称，实体的属性转换为关系模式的属性，实体标识符就是主键。
（2）E-R图中的联系有3种，一对一联系将两个E-R图合并为一个关系模式。 一对多联系单独设置一个关系模式记录联系关系。多对多联系和一对多一样。
-
关系模式规范化：根据范式理论规范化关系模式。
-
确定完整性约束
-
确定用户视图
根据数据流图及用户信息建立视图模式，提高数据的安全性和独立性。
（1）根据数据流图确定处理过程使用的视图（可以理解为业务图）。
（2）根据用户类别确定不同用户使用的视图（不同权限的用户使用的功能，或者说可以使用的功能不同，所以对应的业务图也不同）。
- 反规范化
针对业务，对数据库进行优化，范式设计虽然能够降低数据冗余，但对性能方面是负优化，针对业务对数据库进行适当的反规范化，可以提供整个系统的运行速度。
物理设计
一般来说，物理设计的主要工作步骤包括确定数据分布、存储结构和访问方式。
- 确认数据分布：需要确定数据是集中管理还是分布式管理。
- 确定数据的存储结构：可以采用顺序存储、哈希存储、堆存储和 B 树存储等方式。要根据数据处理和修改要求，确定数据库文件的索引字段和索引类型。
- 确定数据的访问方式：
数据库实施
- 建立实际的数据库结构：创建数据库及数据库表。
- 数据加载：存入数据。
- 数据库试运行及评价：测试数据库性能。
数据库运行维护
- 对数据库性能高检测和改善：压测。
- 数据库的备份及恢复：这个基本上各个数据库关系系统都有解决方案。
- 数据库重组和重构：针对性修改。
应用程序与数据库的交互
没啥用感觉，说的都是废话
NoSQL数据库
指非关系型的数据库，区别于关系数据库，它们不保证关系数据的 ACID 特性。
分类与特点
晦涩难懂，不写了