数据库系统概述

数据库系统由一个互相关联的数据的集合和一组用以访问这些数据的程序组成。这个数据的集合通常被称为数据库。
主要目的：方便、高效地对共享数据有效的组织、管理和存取。

文件系统

早期使用文件系统管理大量的数据（将数据存储在多个文件中），但在使用中发现以下问题：

• (1) 无法判断数据是否冗余
  同一数据可能存储在多个独立的文件中（比如文件和程序是在很长的一段时间内，由不同的程序员创建），这种冗余除了导致存储和访问开销增大外，还可能导致数据不一致（同一数据的不同副本不一致）问题。
• (2) 数据访问困难
  传统的文件处理环境不支持以一种方便而高效的方式去获取所需的数据，需要开发通用的、能对变化的需求做出更快反应的数据检索系统。
• (3) 数据孤立
  数据分散在多个文件，无法统一规范文件的格式，可能需要编写多套代码去读取不同类型文件里的数据。
• (4) 数据完整性问题
  数据库存储的数据必须满足某些特定的一致性约束（如非空约束、唯一性约束、范围约束等等），对于文件系统，只能在程序中强制执行某些约束。使用文件系统，会使约束的处理变得麻烦起来。
• (5) 原子性问题
  计算机系统也会存在故障，一旦故障发生，数据就应被恢复到故障发生之前的一致状态。如对某应用来说，需要将A账户余额中的500元转到B账户余额中。假如A账户的余额减去500元，但B账户的余额还未调试时，系统发生故障，这将会造成数据库状态的不一致。为保证数据库的一致性，上述两个操作必须是要么都发生，要么都不发生。在传统的文件系统中，保持原子性是很难做到的。
• (6) 并发访问异常
  为提高系统的总体性能以及加快响应速度，许多系统允许多个用户同时更新数据。在这样的情况下，并发的更新操作可能相互影响，有可能导致数据的不一致。如A账户有1000元，用户1和用户2同时分别向该账户存入200元和300，那么A账户的余额既不应该是1200，也不是1300，而是1500。为了消除这种情况发生的可能性，系统必须进行某种形式的管理。但，由于数据可能被多个不同的应用程序访问，且程序之间事先并没有协调，必须在文件系统层面给出处理，但文件系统在这方面的处理不是很好。
• (7) 安全性问题
  访问数据时，不同类型的用户仅能访问与之相关的数据，而不是所有数据。文件系统对权限管理方面还需要加强。

数据视图

数据库系统的一个主要目的是给用户提供数据的抽象视图，也就是说，系统隐藏关于数据存储和维护的某些细节。

数据抽象(data abstraction)

一个可用的系统必须能高效地检索数据。这种高效性的需求促使数据库设计者使用复杂的数据结构来表示数据。同时，为简化用户与系统的交互，系统开发人员通过分层抽象，对用户屏蔽复杂性。
数据抽象是指，只向外界提供关键信息，并隐藏其后台的实现细节，即只表现必要的信息而不呈现细节。数据抽象是一种依赖于接口和实现分离的技术。
让我们举一个现实生活中的真实例子，比如一台电视机，您可以打开和关闭、切换频道、调整音量、添加外部组件（如喇叭、录像机、DVD 播放器），但是您不知道它的内部实现细节，也就是说，您并不知道它是如何通过缆线接收信号，如何转换信号，并最终显示在屏幕上。
因此，我们可以说电视把它的内部实现和外部接口分离开了，您无需知道它的内部实现原理，直接通过它的外部接口（比如电源按钮、遥控器、声量控制器）就可以操控电视。
数据抽象技术应用到不同的领域，其抽象层次是不同的。数据库的数据抽象分为三个层次：
(1) 物理层
最低层次的抽象，描述数据实际上的怎样存储的。物理层详细描述复杂的底层数据结构。
(2) 逻辑层
比物理层层次稍高的抽象，描述数据库中存储何种数据，以及这些数据存在什么关系。这样逻辑层就可以通过少量相对简单的结构描述整个数据库。虽然逻辑层的简单结构实现可能涉及复杂的物理层结构，但逻辑层的用户不必知道这样的复杂性。这称作物理数据独立性（physical data independence）。（分层的价值）
(3) 视图层
最高层次的抽象，只描述整个数据库的某个部分。尽管在逻辑层使用了比较简单的结构，但由于一个大型数据库所存储信息的多样性，仍存在一定程度的复杂性。
数据库数据抽象的三个层次图示如下：

在物理层，数据可能被描述为连续存储位置组成的存储块。编译器为数据库程序设计人员屏蔽了这一层的细节。与此类似，数据库系统为数据库程序设计人员屏蔽许多最底层的存储细节。
在逻辑层，数据通过类型定义进行描述。与此同时，在逻辑层还要定义这些数据类型的相关关系。程序设计人员正是在这个抽象层次上使用某种程序设计语言进行工作。
在视图层，计算机用户看见的是为其屏蔽了数据类型细节的一组应用程序。视图层定义了数据库的多个视图，数据库用户看到的就是这些视图。除了屏蔽数据库的逻辑层细节外，视图还提供了防止用户访问数据库的某部分安全性机制。（权限控制）

模式

数据库的总体设计称作数据库模式（schema）。数据库系统可以分为几种不同的模式。物理模式（physical schema，也称内模式）在物理层描述数据库的设计，而逻辑模式（logical schema，也称概念模式）则在逻辑层描述数据库的设计。数据库在视图层也有几种模式，有时称为子模式（subschema，也称外模式）。数据库模式和数据抽象关系图如下：

两种数据独立性

(1) 物理数据独立性
由内模式与概念模式之间的映射实现。物理数据独立性是指当数据库的内模式发生改变时，数据的逻辑结构不变，从而用户编写的应用程序可以不变。
(2) 逻辑数据独立性
由概念模式与外模式之间的映射实现。逻辑数据独立性是指当概念数据库模式发生改变时，数据库的外模式不变，从而建立在外模式上的应用程序不需要修改。

数据模型

数据模型是一种描述数据、数据联系、数据语义以及一致性约束的概念工具的集合。数据模型提供了一种描述物理层、逻辑层以及视图层数据库设计的方式。目前，主流数据模型主要有四类：

• (1) 关系模型
  关系模型用表的集合来表示数据和数据间的联系。关系模型是基于记录的模型的一种。
• (2) 实体-联系模型
  实体-联系（Entity-Relation）数据模型基于对现实世界的这样一种认知：现实世界由一组称作实体的基本对象以及这些对象间的联系构成。实体-联系模型广泛用于数据库设计。
• (3) 基于对象的数据模型
  面向对象设计已经成为占主导地位的软件开发方法。这导致了面向对象数据模型的发展。面向对象模型可以看做E-R模型增加了封装、方法（函数）和对象标识等概念后的扩展。
• (4) 半结构化数据模型
  半结构化数据模型允许相同类型的数据项含有不同的属性集的数据定义。之前介绍的三种数据模型，所有数据项都必须具有相同的属性集。如XML、JSON、YAML等。

数据库设计

数据库系统被设计用来管理大量的信息。数据库设计的主要内容是数据库模式的设计。高层的数据模型为数据库设计者提供了一个概念框架，去说明数据库用户的数据需求，以及将怎样构造数据库结构以满足这些需求。因此，数据库设计的初始阶段是全面刻画预期的数据库用户的数据需求。这个阶段的成果是指定出用户需求的规格文档（用户需求说明书，明确需要提供哪些功能）。
下一步，在概要设计阶段，数据库设计者需要选择一个数据模型（如关系模型、实体-联系模型等），并运用该选定的数据模型的概念，将需求转换成一个数据库的概念模式。从关系模型的角度来看，概念设计阶段涉及决定数据库中应包含哪些属性，以及如何将这些属性组织到多个表中。解决这个问题有两种方法：一种是使用实体-联系模型，另一种是引入一套算法，这套算法将所有属性集作为输入，生成一组关系表。在这个阶段，数据设计者可以对模式进行复审，确保它满足功能需求。
接着，在逻辑设计阶段，数据库设计者将高层的概念模式映射到要使用的数据库系统的实现数据模型（如关系模型）上；然后设计者将得到的特定于系统的数据库模式用到物理设计阶段。在这个阶段，指定数据库的物理特性，这些特性包括文件组织形式以及内部的存储结构。

规范化

设计关系数据库需要用到的另外一种方法是通常称为规范化的过程。它的目标是生成一个关系模式集合，使我们存储信息时，没有不必要的冗余，同时又能轻松地检索数据。这种方法是设计一种符合适当的范式（normal form）的模式。
规范化的详尽理论已经研究形成，它有助于形式化地定义什么样的数据库是不好的，以及如何得到我们想要的设计。

数据库体系结构

一个数据库系统各个部分以及它们之间的联系如下图所示：

数据库系统的体系结构很大程度取决于数据库系统所运行的计算机系统。数据库系统可以是集中式的、客户/服务器式的(一台服务器为多个客户机执行任务)，也可以针对并行计算机体系结构设计数据库系统；分布式数据库包含地理上分离的多台计算机。
现今，数据库系统的大多数用户并不直接面对数据库系统，而是通过网络与其连接。数据库应用也由两层体系结构过渡到三层体系结构：

数据挖掘和信息检索

数据挖掘（Data Mining）指半自动地分析大型数据库并从中找出有用的模式的过程。数据挖掘是在数据库中发现知识。
为在各式各样的数据上高效地执行查询，企业建立了数据仓库（Data Warehouse）。数据仓库从多个来源收集数据，建立统一的模式，驻留在单个节点上。于是，就为用户提供了单个统一的数据界面。
文本数据也爆炸式增长。文本数据是非结构化的，与关系数据库中严格的结构化数据不同。查询非结构化的文本数据被称为信息检索（Information Retrieval）。

特种数据库

除了基于关系模型的关系数据库，还有基于对象模型的对象数据库、基于半结构化数据的XML等。

参考

https://www.db-book.com/
https://www.runoob.com/cplusplus/cpp-data-abstraction.html
https://blog.csdn.net/zcj18537150970/article/details/105327117