笔者闲扯
从笔者毕业以来，关于数据库的知识就停留在大学老师上课讲的那点内容，甚至还不如一个刚学完数据库的师弟，就这么浑浑噩噩的过了三年多。刚毕业那会感觉还好，做做crud就好，不用去考虑什么效率、数据库设计、表结构是否合理，数据库出现问题都有专门的高级工程师去解决，日子过的倒也轻松。但随着工作年龄的上升，职称也混了上去，和近年来越来越卷的社会环境，让我感到了焦虑。回首这几年，偶尔三分钟热血学些东西，追逐最新的技术，热门的开源工具，却都只是停留在怎么用，能用就行，得过且过，没时间也没精力（沉迷直播，逃避现实，FGNB！）去了解内部的原理。我整个知识体系仿佛一个倒三角，薄弱的地基使得整个职业生涯摇摇欲坠，此诚危急存亡之秋也。因此我决定以空杯心态去重新学习数据库，同时也讲学习记录下来。有时候看懂了不一定真的懂了，还要会用，会写，另外程序员的文档能力也是十分重要的。Talk is cheap,show me your code.
简介
本系列以《Database System Concepts》第六版中文版《数据库系统概念》为学习书籍，结合官网第七版教材https://www.db-book.com/db7/（第六版官网ppt资源没了）进行学习，文章中的初始数据库生成也通过官网下载，在本地数据库执行。本章主要对数据库做一个简单的概述，对数据库是什么，为什么用数据库，数据库语言，数据库设计，数据库存储和查询，数据库事务，数据库体系结构做一个简单的介绍。
数据库是什么
数据库管理系统（DataBase-Management System,DBMS）由一个互相关联的数据的集合和一组用以访问这些数据的程序组成。这里的数据集合就是数据库，存储如企业信息、大学信息等一系列复杂且相关数据。数据库管理系统提供了一种方便、高效的途径去存取数据库信息。
为什么用数据库系统
数据库系统作为商业数据计算机化管理的早期方法而产生，一开始是用文件处理系统去实现数据库系统，对文件的操作需要各式各样的程序，并且数据的存储格式也五花八门，随着体量的增长，整个系统变得愈发臃肿和难以维护，而且一旦要开发新需求时，可能又要从零开始再进行新一轮的程序开发，大大加深了程序员的负担。在文件处理系统中存储组织信息的主要弊端包括：
- 数据冗余和不一致。可能相同的信息存储在多个不同文件中，有时候对某一数据文件的修改并不会同步到其他数据文件中，造成了数据不一致。
- 数据访问困难。每次数据访问都通过应用程序访问，当现有的业务逻辑无法满足新的需求时，要么通过之前程序得到的数据再人工加工处理，要么就需要开发新的程序，两种方法都耗时耗力。
- 数据孤立。数据分散在不同文件中，这些文件又可能有不同的格式，因此编写新的应用程序来检索适当的数据是困难的。
- 完整性问题。数据库对字段的约束和限制以及表之间的关系约束只能集成在程序代码内，造成了约束的难以修改和调整。
- 原子性问题。数据原子性即数据应当能保证从一个稳定状态到另外一个稳定状态。如我们通过银行转账500元给他人，系统应当同时从我们账户减去500元，并且在收款方账户增加500元，从而保证数据状态的稳定。当出现我们账户系统刚减去500元，系统发生故障，收款方并未增加这500元，此时数据处于不稳定状态，系统恢复后，应当有能力将数据从不稳定状态恢复过来。但在传统的文件处理系统里，原子性很难做到。
- 并发访问异常。并发访问数据时，两个程序可能同时对文件数据进行修改，因此系统必须进行某种形式的管理，但是在文件处理系统层面去进行程序管理十分困难，管理很难进行。
- 安全性问题。并非系统的所有用户都能访问所有数据，但在文件处理系统中，对应用程序访问哪些数据难以控制，安全性的约束难以实现。
数据视图
数据抽象
将整个数据库抽象成三层，物理层，逻辑层，视图层。
- 物理层（physical level）：最低层次的抽象，描述数据实际上时怎么存储的。
- 逻辑层（logical level）：比物理层层次稍高的抽象，描述数据库存储什么数据以及这些数据间存在什么关系。
- 视图层（view level）：最高层次的抽象，只描述整个数据库的某个部分。以可视化的方式将数据进行展示。
我们日常打交道最多的应该是逻辑层，对数据库表结构和关系进行设计，操作数据，并进行程序编写。
在视图层，计算机用户看到了为其屏蔽了数据类型细节的一组应用程序，即可以理解为用户看到的报表、员工信息等。
最后，物理层主要由数据库系统实现，为设计和开发人员屏蔽了很多细节，一般只有数据库管理员需要了解数据物理组织的某些细节。
数据库语言
数据库语言，作为吃饭干活的家伙，我们应当熟练掌握，在接下来的章节中，我们会详细介绍各个命令，在本节中，我将简单就对概念进行介绍。
数据库系统提供数据定义语言（data-definition language,DDL）来定义数据库模式（schema），以及数据库操纵语言（data-manipulation language,DML）来表达数据库查询和更新。
- DDL主要负责表创建、表结构调整、约束调整、权限管理等功能。
- DML主要负责对表数据进行增删改查等操作。
数据库设计
设计步骤
数据库设计大致可分为六个部分：
- 前期调研，收集需求，形成规格文档。
- 设计数据库模式，定义数据类型和数据关系。
- 定义完整性约束。
- 选择合适的数据库，决定物理层。
- 定义需要实现的业务接口，通过程序实现。
- 初始化数据库。
E-R图
实体-联系（E-R）数据模型使用一组称作实体的基础对象，以及这些对象间的联系。
日常工作中，一般在进行新需求的开发时，如果有涉及到表的新增或者调整，都应生成对应的E-R图。
数据库存储和查询
数据库系统划分为不同的模块，每个模块负责不同的功能。数据库系统的功能部件大致可划分为存储管理器和查询处理器。
存储管理器
存储管理器将各种DML编译器生成的低级指令翻译成底层文件系统命令，负责与文件管理器进行交互。存储管理器负责数据库中数据的存储、检索和更新。
存储管理管理部件包括：
- 权限及完整性管理器（authorization and integrity manager）：它检测是否满足完整性约束，并检查试图访问数据的用户的权限。
- 事务管理器（transcation manager）：它保证了即使发生了故障，数据库也保持在一致的状态，并保证并发事务的执行不发生冲突。
- 文件管理器（file manager）：管理磁盘存储空间的分配，管理用于表示磁盘上所存储信息的数据结构。
- 缓冲区管理器（buffer manager）：负责将数据从磁盘取到内存，并决定哪些数据应被缓冲存储在内存上。
存储管理器实现了几种数据结构，作为系统物理实现的一部分：
- 数据文件（data files）：存储数据库自身。
- 数据字典（data dictionary）：存储关于数据结构的元数据，尤其是数据库模式（schema）。
- 索引（index）：提供对数据项的快速访问。
查询处理器
查询处理器包括：
- DDL解释器（DDL interpreter）：解释DDL语句，并将这些定义记录在数据字典中。
- DML编译器（DML compiler）：将DML语句翻译为一个执行方案，包括一系列查询执行引擎能理解的低级指令。DML编译器还会进行查询优化，选择最优的执行方案。
- 查询执行引擎（query evaluation engine）：执行DML编译器产生的低级指令。
事务管理
事务，可以看作对数据库进行的几个操作的集合，可以看成一个逻辑单元。为了保证事务是正确可靠的，事务必须具备ACID特性。
- 原子性（atomicity）：一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被恢复（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
- 一致性（consistency）：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。
- 隔离性（isolation）：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）。
- 持久性（durability）：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。
数据库体系结构
总结
本章对数据库的整体概念做了个概述，相当于思维导图的根目录，后续的章节会在每个点上往外发散，深入。就我个人而言，之前对数据库内部的体系结构了解的不是很多，知其然，不知其所以然，还是有很大收获的。
扫一扫
211
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
