6.1数据库基本概念
数据：数据 (Data) 是描述事物的符号记录，它具有多种表现形式，可以是文字、图形、图像、声音和语言等。
数据库系统 ：数据库系统 (DataBase System,DBS) 是一个采用了数据库技术，有组织地、动态地存储大量相关联数据，从而方便多用户访问的计算机系统。
广义上讲，数据库系统DBS包括了数据库管理系统(DataBase Management System,DBMS)
数据库：数据库 (DataBase,DB) 是统一管理的、长期储存在计算机内的，有组织的相关数据的集合。
6.1.1数据库技术的发展
数据处理是对各种数据进行收集、存储、加工和传播的一系列活动。
数据管理是对数据进行分类、组织、编码、存储、检索和维护的活动。
数据管理技术的发展经历了3个阶段：人工管理、文件系统和数据库系统阶段。
人工管理阶段
(1)数据量较少
(2)数据不保存
(3)没有软件系统对数据进行管理
缺点
(1)应用程序与数据之间的依赖性太强，不相互独立。
(2)数据组和数据组之间可能有许多重复数据，造成数据冗余。
文件系统阶段
(1)数据可以长期保留
(2)数据不属于某个特定的应用
(3)文件组织形式的多样化
缺点
(1)数据冗余 (Data Redundancy)
(2)数据不一致性 (Data Inconsistency)
(3)数据孤立 (Data Isolation)
数据库系统阶段
数据库系统是由计算机软件、硬件资源组成的系统，它有组织地、动态地存储大量关联数据，方便多用户访问。
它与文件系统重要的区别是数据的充分共享、交叉访问、与应用程序的高度独立性。
(1)采用复杂的数据模型表示数据结构。
(2)有较高的数据独立性。
6.1.2数据模型
数据库的基础结构是数据模型，是用来描述数据的一组概念和定义。
数据模型的三要素：数据模型的三要素是数据结构、数据操作和数据的约束条件。
(1)数据结构。对象类型的集合，是对系统静态特性的描述。
(2)数据操作。对数据库中各种对象(型)的实例(值)允许执行的操作集合，包括操作及操作规则。如操作有检索、插入、删除和修改，操作规则有优先级等。数据操作是对系统动态特性的描述。
(3)数据的约束条件。是一组完整性规则的集合。也就是说，对于具体的应用数据必须遵循特定的语义约束条件，以保证数据的正确、有效和相容。
数据库的3个发展历史
| 数据库系统三类模型 | 数据模型 | 结构形式 | 核心特点与约束 | 优势/适用场景 | 共性/关键说明 |
|---|---|---|---|---|---|
| 第一代数据库 | 层次模型 | 树形结构 | 根结点外其他结点有且仅有一个双亲；上层与下层为 1:n 联系 | 结构简单，适合具有严格层次关系的数据 | 1. 底层数据结构可用图表示 2. 支持三级模式 3. 用存取路径表示数据联系 4. 独立数据定义语言 5. 导航式数据操纵语言 |
| 网状模型 | 网络结构 | 允许多个结点无双亲，或一个结点有多个双亲；可表示复合联系；需引入联结记录表示多对多联系 | 比层次模型更通用，可直接描述更复杂的现实世界 | ||
| 第二代数据库 | 关系模型 | 二维表格结构 | 用表格表达实体集及联系，描述一致性；由关系模式集合组成，关系为实例（表），内容可动态更新 | 简单灵活，使用最普遍，适用于传统商业事务处理 | 取代层次、网状模型成为主流 |
| 第三代数据库 | 新型数据库（含NoSQL） | 非关系型、分布式等 | 支持面向对象、语义、XML、半结构化等模型；NoSQL 为 Not Only SQL，非关系型、分布式、不强调ACID | 适配Web2.0、超大规模高并发、大数据、多类型数据管理场景 | 为解决传统关系库在新型应用中的不足而产生 |
6.1.3数据库管理系统
DBMS功能主要包括数据定义、数据库操作、数据库运行管理、数据组织、存储和管理、数据库的建立和维护。
| 功能名称 | 核心内容 |
|---|---|
| 数据定义 | 提供数据定义语言 (Data Definition Language,DDL)，定义数据库的模式、外模式、内模式，以及完整性约束、视图等 |
| 数据库操作 | 提供数据操纵语言 (Data Manipulation Language,DML)，进行数据增、删、改、查（CRUD）操作 |
| 数据库运行管理 | 并发控制、安全性控制、完整性检查、事务管理、故障恢复 |
| 数据组织、存储和管理 | 负责数据的存储结构、存取路径、存储空间管理 |
| 数据库的建立和维护 | 数据库的创建、数据导入、备份恢复、性能监控、重组重构 |
| DBMS的特点 | 具体内容 |
|---|---|
| 1. 数据结构化且统一管理 | 由 DBMS 统一管理；用数据模型描述数据及联系；数据面向整个应用系统；减少冗余，实现数据共享，易维护、易扩展。 |
| 2. 较高的数据独立性 | 数据与程序分离，由 DBMS 负责存储；应用程序只需关心逻辑结构；包含物理独立性 和逻辑独立性，简化应用开发。 |
| 3. 数据控制功能 | 1. 安全性 ：防止非法使用，控制访问权限，避免泄露、篡改、破坏。 2. 完整性 ：保证数据正确、相容，防止不符合语义的数据进入。 3. 并发控制 ：协调多用户并发操作，保证数据一致性，避免错误结果。 4. 故障恢复 ：从事务、系统、介质等故障中恢复；通过冗余数据将数据库恢复到一致状态。 |
6.1.4数据库三级模式
| 层次名称 | 对应模式 | 别称 | 核心说明 |
|---|---|---|---|
| 视图层 | 外模式 | 用户模式、子模式 | 描述整个数据库的某个部分的数据 |
| 逻辑层 | 模式 | 概念模式、逻辑模式 | 描述数据库中存储的数据以及这些数据间存在的关系。 |
| 物理层 | 内模式 | 存储模式 | 描述数据在存储器中是如何存储的 |
6.2关系数据库
关系模型是关系数据库的基础。
关系模型由关系数据结构、关系操作集合和关系完整性规则3部分组成
6.2.1关系数据库基本概念
关系的基本术语
| 术语 | 含义 | 备注 |
|---|---|---|
| 属性 | 描述事物的特征 |
学生：学号、姓名、性别 |
| 域 | 属性的取值范围 |
性别：{男, 女}；要求原子值 |
| 目/度 | 关系中属性的个数 |
3个属性 → 三度关系 |
| 候选码 | 能唯一标识一个元组的属性/属性组 | 候选的主键 |
| 主码 | 从候选码中选定的一个主键 |
一个关系只有一个主码 |
| 主属性 | 包含在任意候选码中的属性 |
例如学号/身份证号的属性 |
| 外码 | 外键，不是本关系的码，但却是另一关系的码 |
用于表间关联参照 |
| 全码 | 所有属性组合起来才是候选码 | R(T,C,S) 需三个属性一起唯一标识 |
| 笛卡尔积 | 域上所有可能的组合集合 | 关系是笛卡尔积的子集 |
关系数据库模式
在数据库中要区分型和值。
关系数据库中的型也称为关系数据库模式，是关系数据库结构的描述。它包括若干域的定义以及在这些域上定义的若干关系模式。
关系数据库的值是这些关系模式在某一时刻对应的关系的集合，通常称之为关系数据库。
关系完整性约束三类
| 完整性类型 | 约束内容 | 核心考点 | 备注 |
|---|---|---|---|
| 实体完整性 | 主码的值唯一且非空 | 针对主码 | 主键相关 |
| 参照完整性 | 外码取值要么为空，要么等于被参照关系的主码值 | 针对外码，也称引用完整性 | 外键相关 |
| 用户定义完整性 | 用户根据业务规则自定义的约束（如性别、范围、非空等） | 反映具体业务语义 | 自定义 |
6.2.2关系运算
| 关系代数运算符分类 | 具体运算符 | 解释 |
|---|---|---|
| 集合运算符 | ∪（并）、∩（交）、−（差）、×（笛卡尔积） | 基于传统数学集合运算，用于关系间的整体集合操作 |
| 专门的关系运算符 | σ（选择）、π（投影）、⋈（连接）、÷（除） | 数据库关系模型特有运算，用于数据的筛选、列提取、表关联等操作 |
| 算术比较符 | >、<、=、≥、≤、≠ | 用于构成运算条件，比较数值或数据大小关系 |
| 逻辑运算符 | ¬（非）、∧（与）、∨（或） | 用于组合多个运算条件，实现复杂逻辑判断 |
6.2.3关系数据库设计基本理论
关系数据理论是指导数据库设计的基础，关系数据库设计是数据库语义学的问题。
1.函数依赖
数据依赖 ：数据依赖是通过一个关系中属性间值的相等与否体现出来的数据间的相互关系，是现实世界属性间联系和约束的抽象，是数据内在的性质，是语义的体现。
函数依赖：函数依赖则是一种最重要、最基本的数据依赖。
设R(U) 是属性集U上的关系模式， X Y是 U的子集。若对 R(U) 的任何一个可能的关系r , r中不可能存在两个元组在X 上的属性值相等，而在Y 上的属性值不等，则称X 函数决定 Y 或 Y 函数依赖于X , 记作：X→Y。
在R(U) 中，如果X Y, 并且对于X的任何一个真子集X′, 都有X 不能决定 Y, 则称 Y 对X 完全函数依赖，记作： X --- → Y 。
如果X → Y , 但 Y 不完全函数依赖于X, 则称 Y 对X 部分函数依赖，记作： X---P→Y。 部分函数依赖也称作局部函数依赖。
在R(U,F) 中，如果X→Y,Y≠x,Y+X,Y→Z, 则称Z对X传递依赖
结合你给出的原文，整理成标准定义+通俗解释的表格，和你之前范式的风格一致：
| 概念 | 严格定义 | 通俗解释 |
|---|---|---|
| 函数依赖 | 设R(U)是属性集U上的关系模式，X、Y是U的子集。若对R(U)的任何一个可能的关系r，r中不可能存在两个元组在X上的属性值相等，而在Y上的属性值不等，则称X函数决定Y或Y函数依赖于X，记作：X→Y。 | X定下来了，Y就唯一跟着定下来，比如：学号→姓名。 |
| 完全函数依赖 | 在R(U)中，如果X→Y，并且对于X的任何一个真子集X′，都有X′不能决定Y，则称Y对X完全函数依赖。 | 必须整个X才能决定Y，少一个属性都不行，常用于联合主键。 |
| 部分函数依赖 | 如果X→Y，但Y不完全函数依赖于X，则称Y对X部分函数依赖。 | Y只由X里的一部分属性就能决定，不用看整个X。 |
| 传递函数依赖 | 在R(U,F)中，如果X→Y，Y≠X，Y⊈X，Y→Z，则称Z对X传递依赖。 | X决定Y，Y决定Z，于是Z间接靠X决定，形成传递。 |
2.多值依赖
若关系模式R(U) 中，X Y Z是 U的子集，并且Z=U-X-Y 当且仅当对R(U)的任何一个关系 r, 给定一对(x, z) 值，有一组 Y 的值，这组值只由x值决定而与 z 值无关，则称 "Y多值依赖于X" 或 "X多值决定Y"成立。记为： X→→Y。
3.规范化
⭐⭐⭐范式（Normal Form，简称 NF），就是一张数据表设计的 "规范标准"。
范式的本质就是 "逐步升级"，范式有从低到高的等级（1NF、2NF、3NF...），等级越高，规范越严，表结构越合理。
| 范式 | 严格定义 | 说明1 | 说明2 |
|---|---|---|---|
| 1NF | 若关系模式R的每一个分量都是不可再分的数据项，则关系模式R属于第一范式。记为R∈1NF。 | 最基本的范式，要求属性具有原子性，不可再分。 |
每个字段都不能再拆成更小的字段，比如不能把 "姓名 + 学号" 放在同一个字段里 |
| 2NF | 若关系模式R∈1NF，且每一个非主属性完全函数依赖于主码，则R∈2NF。 | 消除非主属性对主码的部分函数依赖。 | 先满足 1NF，再保证：表里的非主键字段，必须依赖整个主键，不能只依赖主键的一部分。比如主键是 "学号 + 课程号"，成绩必须依赖这两个一起，不能只依赖 "学号"。 |
| 3NF | 若关系模式R∈2NF，且每一个非主属性都不传递函数依赖于主码，则R∈3NF。 | 在2NF基础上，消除非主属性对主码的传递函数依赖。 | 先满足 2NF，再保证：非主键字段之间，不能互相推导。比如主键是 "学号"，"系主任" 依赖 "系别"，而 "系别" 依赖 "学号"，这就不行，要拆开成两个表。 |
| BCNF | 关系模式R∈1NF，若对于R的每个函数依赖X→Y（Y∉X），X必为候选码，则R∈BCNF。 | 修正的3NF，消除主属性对候选码的部分与传递依赖，所有决定因素都是候选码。 | 比 3NF 更严格，不管是主键还是其他字段，只要一个字段能决定另一个字段，那这个 "决定字段" 必须是候选码（能唯一标识一行数据的字段 / 字段组），不能有 "非候选码决定其他字段" 的情况。 |
| 4NF | 关系模式R∈1NF，若对于R的每个非平凡多值依赖X→→Y（Y∉X），X都含有候选码，则R∈4NF。 | 在BCNF基础上，消除非平凡且非函数依赖的多值依赖。 | 先满足 BCNF，再保证：一个表里，不要同时放两组不相关的多值信息。比如 "老师" 表，不能同时放 "老师教的课程" 和 "老师的兴趣爱好"（两组多值，互不相关），要拆成两个表。 |
| 5NF | 关系模式R中的每一个连接依赖均由R的候选码所蕴含，则R∈5NF。 | 最高级别范式，消除不是由候选码蕴含的连接依赖。 | 最高级别的范式，把表拆到不能再合理拆分，没有任何冗余。简单说，就是不管怎么组合表的数据，都能通过候选码关联起来，不用额外加多余字段。 |
6.3数据库设计
6.3.1数据库设计的基本步骤
数据库设计六大阶段
| 阶段 | 标准任务 | 通俗解释 |
|---|---|---|
| 1. 用户需求分析 | 分析功能、性能、限制等要求，收集数据需求 | 搞清楚用户到底要什么、需要存哪些数据、有什么规矩必须遵守。 |
| 2. 概念结构设计 | 抽象企业信息模型，常用 E-R图 表示 | 用"实体+属性+联系"把现实世界画出来，不依赖具体数据库。这是最关键的一步。 |
| 3. 逻辑结构设计 | 将概念模型转换成 DBMS 能支持的数据模型（如关系模型） | 把 E-R 图变成真正的"表结构"和字段，确定主外键、视图、数据类型。 |
| 4. 物理结构设计 | 确定存储结构、索引、分区、存储位置等 | 考虑电脑到底怎么存数据、建哪些索引能查得快、文件放哪里。 |
| 5. 数据库实施 | 建立数据库、编写调试程序、导入数据、试运行 | 正式建库、写代码、塞数据，跑起来看看有没有问题。 |
| 6. 运行和维护 | 评价性能、修复问题、调整结构、升级系统 | 上线后不断优化、修补 bug、保证系统稳定运行。 |
6.3.2数据需求分析
数据需求分析是在项目确定之后，用户和设计人员对数据库应用系统所要涉及的内容(数据)和功能(行为)的整理和描述，是以用户的角度来认识系统。
6.3.3概念结构设计
概念结构设计的目标是产生反映系统信息需求的数据库概念结构，即概念模式。
概念结构是独立于支持数据库的D B M S 和使用的硬件环境的。
概念结构设计工作步骤
| 步骤 | 主要工作内容 |
|---|---|
| 1. 选择局部应用 | 根据数据流图，选择适当层次，使每一部分对应一个局部应用，以此为基础设计分E-R图。 |
| 2. 逐一设计分E-R图 | 对每个局部应用，依据数据流图和数据字典，确定实体、属性、标识符及实体间联系类型，形成局部E-R图。 |
| 3. E-R图合并 | 以相同实体为中心合并各分E-R图，解决冲突、消除冗余，最终形成统一的全局E-R图。 |
6.3.4逻辑结构设计
1、E-R 图方法所得到的全局概念模型是对信息世界的描述，并不适用于计算机处理，为适合关系数据库系统的处理，必须将E-R 图转换为关系模式。
2、由E-R 图转换得来的初始关系模式并不能完全符合要求，还会有数据冗余、更新异常存在，这就需要经过进一步的规范化处理
3、根据规范化理论确定了关系模式之后，还要对关系模式加以约束，包括数据项的约束、表级约束及表间约束，可以参照S Q L 标准来确定不同的约束，如检查约束、主码约束、参照完整性约束，以保证数据的正确性。
4、确定了整个系统的关系模式之后，还要根据数据流图及用户信息建立视图模式，提高数据的安全性和独立性。
6.3.5物理设计
| 工作步骤 | 核心工作内容 | 具体说明 |
|---|---|---|
| 1. 确定数据分布 | 确定数据管理方式（集中/分布式），规划数据分布方案 | 1. 按不同部门应用分布数据，让对应部门数据存储在对应场地，跨场地业务通过网络处理； 2. 按处理要求分布，高频、快响应数据存于高速设备； 3. 数据分布后需调整关系模式，回到逻辑设计阶段修改 |
| 2. 确定数据的存储结构 | 定义数据文件中记录的物理结构，确定存储方式和索引 | 1. 存储方式可选：顺序存储、哈希存储、堆存储、B树存储，根据数据处理要求和变更频度选择； 2. 设计索引，根据数据处理和修改需求，确定索引字段和索引类型，提升访问速度 |
| 3. 确定数据的访问方式 | 明确数据的访问逻辑，匹配存储结构 | 1. 访问方式由存储结构决定，存储结构不同，访问方式对应不同； 2. 数据库物理结构包含：存储记录格式、记录物理安排、访问路径（存取方法） |
6.3.6数据库实施
据库的实施 ：根据逻辑和物理设计的结果，在计算机上建立起实际的数据库结构，数据加载(或称装
入),进行试运行和评价的过程，叫作数据库的实施(或称实现)
6.3.7数据库运行维护
数据库维护工作的主要内容包括对数据库性能的监测和改善、故障恢复、数据库的重组和重构。
在数据库运行阶段，对数据库的维护主要由D B A完成。
| 维护内容 | 具体说明 |
|---|---|
| 数据库性能的监测和改善 | 用I/O量、CPU时间、响应时间度量性能；DBA使用工具监控运行、存储空间、响应时间并优化。 |
| 数据库的备份及故障恢复 | DBA制定备份方案，利用DBMS恢复手段，故障后恢复到一致性状态。 |
| 数据库重组 | 不改变逻辑与物理结构，清理废弃空间与碎片，提升存取效率。 |
| 数据库重构 | 修改数据库结构，包括表、视图、约束、表的分解与合并；注意逻辑独立性与视图安全性。 |
6.4应用程序与数据库的交互
6.4.1库函数级别访间接口
库函数级别的数据访问接口往往是数据库提供的最底层的高级程序语言访问数据接口，如Oracle 数据库的 Oracle Call Interface(OCI)。 开发者可以使用高级程序语言编写程序实现人机交互和业务逻辑，而使用 O C I来访问数据库。
6.4.2嵌入SQL访问接口
嵌入式SQL(Embedded SQL) 是一种将 S Q L语句直接写入某些高级程序语言，如 C、COBOL、Java、Ada等编程语言的源代码中的方法。借此方法，可使得应用程序拥有了访问数据以及处理数据的能力。
6.4.3通用数据接口标准
开放数据库连接 (Open DataBase Connectivity,ODBC) 是为解决异构数据库间的数据共享而产生的。 O D B C为异构数据库访问提供统一接口，允许应用程序以S Q L为数据存取标准，存取不同D B M S 管理的数据；使应用程序直接操纵数据库中的数据，免除随数据库的改变而改变，也可以访问如 Excel表和ASCII数据文件这类非数据库对象。
6.4.4ORM访问接口
对象关系映射 (Object Relational Mapping, 简称 O R M或 O / R M或 O/R mapping) 是一种程序设计技术，用于实现面向对象编程语言里不同类型系统数据之间的转换。
O R M是通过使用描述对象和数据库之间映射的元数据，将程序中的对象与关系数据库相互映射；O R M 可以解决数据库与程序间的异构性。
6.5NoSQL数据库
N o S Q L 最常见的解释是Non-Relational,Not Only SQL也被很多人接受。
N o S Q L仅仅是一个概念，泛指非关系型的数据库，区别于关系数据库，它们不保证关系数据的 A C I D特性。
6.5.1分类与特点
⭐⭐⭐NoSQL数据库分类
| 类型 | 详细特点说明 | 典型产品 |
|---|---|---|
| 列式存储数据库 | 与传统关系型行式存储不同，按列组织和存储数据；每个表由一组页链集合组成，每条页链对应一个存储列；面向分布式海量数据，键指向多个列，列按列家族安排。 |
Cassandra、HBase、Riak |
| 键值对存储数据库 | 基于哈希表结构，通过Hash算法定位数据；Key对应指针指向具体数据；Key-value模型结构简单、易部署；但只对部分值查询或更新时效率较低。 |
Redis、Tokyo Cabinet/Tyrant、Voldemort、Oracle BDB |
| 文档型数据库 | 可看作键值数据库升级版，支持嵌套键值；存储半结构化文档（如JSON）；查询能力优于传统键值数据库；灵感来自Lotus Notes。 |
MongoDB、CouchDB、SequoiaDB |
| 图数据库 | 使用灵活图形模型，可扩展到多服务器；无标准SQL，通过REST接口或查询API操作；适合社交网络、生物信息网络、交通网络等图结构数据。 |
Neo4J、InfoGrid、Infinite Graph |
NoSQL共同特征：
- 易扩展：数据之间无关系，易于扩展
- 大数据量，高性能：结构简单，大数据场景下读写性能高
- 灵活的数据模型：无需预先建字段，可随时存储自定义格式
- 高可用：可方便实现高可用架构，部分通过复制模型实现
6.5.2体系框架
| 层次（由下至上） | 详细说明 |
|---|---|
| 数据持久层 | 定义数据的存储形式，共4种： 1. 基于内存：存取速度最快，但可能丢失数据 2. 基于硬盘：数据可长期保存，但速度较慢 3. 内存+硬盘结合：兼顾速度与数据安全性 4. 订制可插拔：数据存取灵活性高 |
| 数据分布层 | 定义数据分布方式，主要3种形式： 1. CAP支持，可水平扩展 2. 多数据中心支持，跨数据中心平稳运行 3. 动态部署支持，集群中可动态增删节点 |
| 数据逻辑模型层 | 表述数据的逻辑表现形式 |
| 接口层 | 为上层应用提供数据调用接口，共5种： Rest、Thrift、Map/Reduce、Get/Put、特定语言API |