BLOG

数据库定义

从形式上来说，“数据库”是指通过使用“数据库管理系统”（DBMS）访问的一组相关数据，它是一套集成的计算机软件，允许用户与一个或多个数据库交互并提供对数据库中包含的所有数据（尽管可能存在限制对特定数据的访问的限制）。DBMS 提供了允许输入、存储和检索大量信息的各种功能，并提供了管理信息组织方式的方法。

小型数据库可以存储在文件系统上，而大型数据库则托管在计算机集群或云存储上。数据库的设计跨越形式技术和实际考虑，包括数据建模、高效的数据表示和存储、查询语言、敏感数据的安全和隐私以及分布式计算问题，包括支持并发访问和容错。

关系数据库在 20 世纪 80 年代占据主导地位。这些模型数据作为一系列表中的行和列，并且绝大多数使用 SQL 来写入和查询数据。 2000年代，非关系型数据库开始流行，统称为NoSQL，因为它们使用不同的查询语言。

由于它们之间的密切关系，术语“数据库”经常被随意使用来指代数据库和用于操作数据库的 DBMS。

现有的 DBMS 提供了各种允许管理数据库及其数据的功能，这些功能可分为四个主要功能组：

• 数据定义：创建、修改和删除定义数据组织的定义。
• 更新：插入、修改和删除实际数据。
• 检索：以可直接使用或供其他应用程序进一步处理的形式提供信息。检索到的数据可以以与存储在数据库中基本相同的形式提供，或者以通过改变或组合来自数据库的现有数据获得的新形式提供。
• 管理：注册和监视用户、强制数据安全、监视性能、维护数据完整性、处理并发控制以及恢复因某些事件（例如意外系统故障）而损坏的信息。

数据库及其 DBMS 都符合特定数据库模型的原则。“数据库系统”是指数据库模型、数据库管理系统、数据库的统称。

从物理上讲，数据库服务器是保存实际数据库并仅运行 DBMS 和相关软件的专用计算机。数据库服务器通常是多处理器计算机，具有充足的内存和用于稳定存储的RAID磁盘阵列。通过高速通道连接到一台或多台服务器的硬件数据库加速器也用于大容量事务处理环境。DBMS 是大多数数据库应用程序的核心。DBMS 可以围绕具有内置网络支持的自定义多任务 内核构建，但现代 DBMS 通常依赖于标准操作系统来提供这些功能。

由于 DBMS 构成了一个重要的市场，计算机和存储供应商通常会在自己的开发计划中考虑 DBMS 的需求。

数据库和 DBMS 可以根据它们支持的数据库模型（例如关系型或XML）、运行的计算机类型（从服务器集群到移动电话）、查询语言（ s) 用于访问数据库（例如 SQL 或XQuery）及其内部工程，这会影响性能、可扩展性、弹性和安全性。

数据库内核

数据库内核是指数据库管理系统（DBMS）的核心组件，它负责处理数据库的基本操作和管理任务。数据库内核管理数据的存储、检索、更新和删除，还负责实现事务管理、并发控制、数据完整性等重要功能。数据库内核通常由许多子系统组成，它们共同协作以提供高效、可靠的数据库服务。

数据库内核的设计和实现取决于具体的数据库管理系统，如关系型数据库管理系统（如MySQL、Oracle、SQL Server）或非关系型数据库管理系统（如MongoDB、Redis）。它们会根据不同的数据存储需求、性能要求和功能特点来选择不同的内核架构和算法。

总之，数据库内核是数据库系统的核心引擎，负责处理数据管理和操作，确保数据库的稳定性、性能和一致性。

数据库类型

早期数据库种类有3种，分别是层次式数据库、网络式数据库和关系型数据库。目前最常见的数据库种类是关系型数据库和非关系型数据库。根据数据库存储体系分类，还可分为关系型数据库、键值（Key-Value）数据库、列存储数据库、文档数据库和搜索引擎数据库等类型。

(1)关系型数据库。这种类型的数据库是最传统的数据库类型，关系型数据库模型是把复杂的数据结构归结为简单的二元关系，在数据库中，对数据的操作几乎全部建立在一个或多个关系表格上。在大型系统中通常有多个表，且表之问有各种关系。 实际使用就是通过对这些关联的表格进行分类、合并、连接或选取等运算来实现数据库的管理。

(2)键值数据库。键值数据库是一种非关系型数据库，它使用简单的键值方法来存储数据。 键值数据库将数据存储为键值对集合，其中键作为唯一标识符。

(3)列存储数据库。列式存储 (Column-Based)是相对于传统关系型数据库的行式存储 ( Row-Based storage) 来说的。简单来说两者的区别就是对表中数据的存储形式的差异。

(4)文档数据库。此类数据库可存放并获取文档，可以是XML、JSON、BSON 等格式，这些文档具备可述性 (Self Describing)，呈现分层的树状结构 (Htierarchical Tree Data Structure), 可以包含映射表、集合和纯量值。数据库中的文档彼此相似，但不必完全相同。 文档数据库所存放的文档，就相当于键值数据库所存放的“值”。文档数据库可视为其值可查的键值数据库

(5)搜索引擎数据库。搜素引擎数据库是应用在搜素引擎领域的数据存储形式，由于搜索引擎会爬取大量的数据，并以特定的格式进 行存储，这样在检索的时候才能保证性能最优

历史

数据库及其各自的 DBMS 的大小、功能和性能已呈数量级增长。这些性能的提高得益于处理器、计算机内存、计算机存储和计算机网络领域的技术进步。磁盘等直接存取存储介质的出现使数据库的概念成为可能，磁盘在 20 世纪 60 年代中期得到广泛应用；早期的系统依赖于磁带上数据的顺序存储。随后数据库技术的发展根据数据模型或结构可以分为三个时代：导航型、  SQL/关系型和后关系型。

早期的两个主要导航数据模型是层次模型和CODASYL模型（网络模型）。它们的特点是使用指针（通常是物理磁盘地址）来跟踪从一个记录到另一个记录的关系。

关系模型由 Edgar F. Codd 于 1970 年首次提出，它背离了这一传统，坚持应用程序应按内容搜索数据，而不是按链接搜索数据。关系模型采用一组分类帐样式的表，每个表用于不同类型的实体。直到 20 世纪 80 年代中期，计算硬件才变得强大到足以允许关系系统（DBMS 加上应用程序）的广泛部署。然而，到 20 世纪 90 年代初，关系系统在所有大规模数据处理应用程序中占据主导地位，并且截至 2018 年，它们仍然占据主导地位：IBM Db2、Oracle、MySQL 和 Microsoft SQL Server 是搜索次数最多的 DBMS。  占主导地位的数据库语言（用于关系模型的标准化 SQL）已经影响了其他数据模型的数据库语言。

对象数据库于 20 世纪 80 年代开发，旨在克服对象关系阻抗不匹配的不便，这导致了“后关系”一词的创造，也导致了混合对象关系数据库的发展。

2000 年代末的下一代后关系数据库被称为 NoSQL 数据库，引入了快速键值存储和面向文档的数据库。称为 NewSQL 数据库的竞争性“下一代”数据库尝试了新的实现，保留了关系/SQL 模型，同时旨在与商用关系 DBMS 相比，匹配 NoSQL 的高性能。

20 世纪 60 年代，导航 DBMS

随着计算机速度和性能的提高，出现了许多通用数据库系统。到 20 世纪 60 年代中期，许多此类系统已投入商业使用。人们对标准的兴趣开始增长，集成数据存储 (IDS) 等产品的作者 Charles Bachman 在 CODASYL 内成立了数据库任务组，该小组负责 COBOL 的创建和标准化。 1971 年，数据库任务组发布了他们的标准，该标准通常被称为 CODASYL 方法，很快，许多基于该方法的商业产品进入了市场。

CODASYL 方法为应用程序提供了导航形成大型网络的链接数据集的能力。应用程序可以通过以下三种方法之一查找记录：

1. 使用主键（称为 CALC 键，通常通过散列实现）
2. 将关系（称为集）从一条记录导航到另一条记录
3. 按顺序扫描所有记录

后来的系统添加了 B 树来提供备用访问路径。许多 CODASYL 数据库还为最终用户添加了声明性查询语言（与导航 API 不同）。然而，CODASYL 数据库非常复杂，需要大量培训和努力才能生成有用的应用程序。

IBM 也在 1966 年拥有了自己的 DBMS，称为信息管理系统 (IMS)。 IMS 是为 System/360 上的 Apollo 计划编写的软件开发。 IMS 在概念上与 CODASYL 大致相似，但其数据导航模型使用严格的层次结构，而不是 CODASYL 的网络模型。由于数据的访问方式，这两个概念后来都被称为导航数据库：该术语因巴赫曼 1973 年图灵奖演讲《程序员作为导航员》而流行。 IMS 被 IBM 归类为分层数据库。 IDMS 和 Cincom Systems 的 TOTAL [broken anchor] 数据库被归类为网络数据库。截至 2014 年，IMS 仍在使用。

20 世纪 70 年代，关系型 DBMS

Edgar F. Codd 在位于加利福尼亚州圣何塞的 IBM 分支机构之一工作，主要从事硬盘系统的开发。他对 CODASYL 方法的导航模型不满意，特别是缺乏“搜索”设施。 1970 年，他撰写了多篇论文，概述了一种新的数据库构建方法，最终形成了突破性的大型共享数据库数据关系模型。

在本文中，他描述了一种用于存储和使用大型数据库的新系统。 Codd 的想法不是像 CODASYL 那样将记录存储在某种自由格式记录的链接列表中，而是将数据组织为多个“表”，每个表用于不同类型的实体。每个表将包含固定数量的列，其中包含实体的属性。每个表的一列或多列被指定为主键，通过主键可以唯一标识表的行；表之间的交叉引用始终使用这些主键，而不是磁盘地址，查询将基于这些键关系连接表，使用一组基于关系演算数学系统（模型由此得名）的操作。将数据拆分为一组规范化表（或关系），旨在确保每个“事实”仅存储一次，从而简化更新操作。称为视图的虚拟表可以为不同的用户以不同的方式呈现数据，但视图不能直接更新。

Codd 使用数学术语来定义模型：关系、元组和域，而不是表、行和列。现在熟悉的术语来自早期的实现。科德后来批评实际实现偏离模型所依据的数学基础的趋势。

使用主键（面向用户的标识符）来表示跨表关系而不是磁盘地址有两个主要动机。从工程角度来看，它使表能够重新定位和调整大小，而无需昂贵的数据库重组。但 Codd 对语义上的差异更感兴趣：显式标识符的使用使得使用干净的数学定义来定义更新操作变得更加容易，并且还使得查询操作能够根据一阶谓词演算的既定规则来定义；因为这些操作具有清晰的数学属性，所以可以以可证明正确的方式重写查询，这是查询优化的基础。与层次结构或网络模型相比，虽然表之间的连接不再那么明确，但表达能力没有损失。

在层次结构和网络模型中，记录被允许具有复杂的内部结构。例如，员工的工资历史记录可能表示为员工记录中的“重复组”。在关系模型中，规范化过程导致这种内部结构被多个表中保存的数据所取代，这些表仅通过逻辑键连接。

例如，数据库系统的常见用途是跟踪有关用户的信息、用户姓名、登录信息、各种地址和电话号码。在导航方法中，所有这些数据都将放置在单个可变长度记录中。在关系方法中，数据将被规范化为用户表、地址表和电话号码表（例如）。仅当实际提供了地址或电话号码时，才会在这些可选表中创建记录。

除了使用逻辑标识符而不是磁盘地址来标识行/记录之外，Codd 还改变了应用程序从多个记录中组装数据的方式。他们不会要求应用程序通过导航链接一次收集一条记录的数据，而是使用一种声明性查询语言来表达所需的数据，而不是找到数据的访问路径。寻找有效的数据访问路径成为数据库管理系统的责任，而不是应用程序程序员的责任。这个过程称为查询优化，取决于查询是用数学逻辑表达的。

科德的论文被伯克利分校的两个人尤金·黄（Eugene Wong）和迈克尔·斯通布雷克（Michael Stonebraker）选中。他们启动了一个名为 INGRES 的项目，利用已分配给地理数据库项目的资金和学生程序员来编写代码。从 1973 年开始，INGRES 交付了第一批测试产品，并于 1979 年普遍准备好广泛使用。INGRES 在许多方面与 System R 相似，包括使用称为 QUEL 的数据访问“语言”。随着时间的推移，INGRES 转向了新兴的 SQL 标准。

IBM 本身对关系模型 PRTV 进行了一项测试实现，还对 Business System 12 进行了生产测试，两者现已停产。 Honeywell 为 Multics 编写了 MRDS，现在有两个新的实现：Alphora Dataphor 和 Rel。大多数通常称为关系型的其他 DBMS 实现实际上是 SQL DBMS。

1970年，密歇根大学开始开发基于D.L.的MICRO信息管理系统  。蔡尔兹的集合论数据模型。    美国劳工部、美国环境保护署和阿尔伯塔大学的研究人员使用 MICRO 来管理非常大的数据集、密歇根大学和韦恩州立大学。它在使用密歇根终端系统的 IBM 大型计算机上运行。  该系统一直生产到 1998 年。

综合方法

20世纪70年代和80年代，人们尝试构建硬件和软件集成的数据库系统。基本理念是这种集成将以更低的成本提供更高的性能。例如 IBM System/38（Teradata 的早期产品）和 Britton Lee, Inc. 数据库机。

另一种为数据库管理提供硬件支持的方法是 ICL 的 CAFS 加速器，它是一种具有可编程搜索功能的硬件磁盘控制器。从长远来看，这些努力普遍不成功，因为专用数据库机无法跟上通用计算机的快速发展和进步。因此，当今大多数数据库系统都是在通用硬件上运行的软件系统，使用通用计算机数据存储。然而，Netezza 和 Oracle (Exadata) 等一些公司在某些应用程序中仍然追求这种想法。

20 世纪 70 年代末，SQL DBMS

IBM 在 20 世纪 70 年代初开始开发基于 Codd 概念的原型系统 System R。第一个版本于 1974 年 5 月准备就绪，然后开始在多表系统上工作，其中数据可以拆分，以便记录的所有数据（其中一些是可选的）不必存储在单个大“块”。随后的多用户版本在 1978 年和 1979 年由客户进行了测试，此时添加了标准化查询语言 – SQL [citation needed] 。 Codd 的想法是使自己既可行又优于 CODASYL，推动 IBM 开发 System R 的真正生产版本，称为 SQL/DS，以及后来的 Database 2 (IBM Db2)。

Larry Ellison 的 Oracle 数据库（或更简单地说，Oracle）从不同的链条开始，基于 IBM 关于 System R 的论文。尽管 Oracle V1 实现于 1978 年完成，但直到 Ellison 在 1979 年击败 IBM 推出 Oracle Version 2 后才进入市场。

Stonebraker 随后应用 INGRES 的经验开发了新数据库 Postgres，即现在的 PostgreSQL。 PostgreSQL 通常用于全球关键任务应用程序（.org 和 .info 域名注册机构将其用作主要数据存储，许多大公司和金融机构也是如此）。

在瑞典，Codd 的论文也被阅读，Mimer SQL 于 20 世纪 70 年代中期在乌普萨拉大学开发。 1984年，该项目被合并为独立企业。

另一种数据模型，即实体关系模型，于 1976 年出现，并在数据库设计中广受欢迎，因为它强调比早期关系模型更熟悉的描述。后来，实体-关系结构被改造为关系模型的数据建模结构，两者之间的差异变得无关紧要。

20 世纪 80 年代，在桌面上

20 世纪 80 年代迎来了桌面计算时代。新计算机为用户提供了 Lotus 1-2-3 等电子表格和 dBASE 等数据库软件。 dBASE 产品重量轻，任何计算机用户都可以轻松理解。 dBASE 的创建者 C. Wayne Ratliff 表示：“dBASE 与 BASIC、C、FORTRAN 和 COBOL 等程序不同，因为许多脏工作已经完成。数据操作是由 dBASE 完成的，而不是由用户，这样用户就可以专注于他正在做的事情，而不必处理打开、读取和关闭文件以及管理空间分配等肮脏的细节。”  dBASE 是 20 世纪 80 年代和 90 年代初最畅销的软件之一。

20世纪90年代，面向对象

20 世纪 90 年代，随着面向对象编程的兴起，各种数据库中的数据处理方式也随之增长。程序员和设计师开始将数据库中的数据视为对象。也就是说，如果一个人的数据存在于数据库中，那么该人的属性（例如地址、电话号码和年龄）现在被认为属于该人，而不是无关的数据。这允许数据之间的关系与对象及其属性相关，而不是与各个字段相关。  术语“对象关系阻抗不匹配”描述了编程对象和数据库表之间转换的不便。对象数据库和对象关系数据库试图通过提供一种面向对象的语言（有时作为 SQL 的扩展）来解决这个问题，程序员可以将其用作纯关系 SQL 的替代方案。在编程方面，称为对象关系映射（ORM）的库试图解决同样的问题。

2000 年代，NoSQL 和 NewSQL

XML 数据库是一种面向结构化文档的数据库，允许基于 XML 文档属性进行查询。 XML 数据库主要用于将数据方便地视为文档集合的应用程序，其结构可以从非常灵活到高度严格：示例包括科学文章、专利、税务申报和人事记录。

NoSQL 数据库通常速度非常快，不需要固定的表模式，通过存储非规范化数据来避免联接操作，并且被设计为水平扩展。

近年来，人们对具有高分区容错性的大规模分布式数据库有强烈的需求，但根据CAP定理，分布式系统不可能同时提供一致性、可用性和分区容错性保证。分布式系统可以同时满足这些保证中的任何两个，但不能同时满足全部三个。因此，许多 NoSQL 数据库正在使用所谓的最终一致性来提供可用性和分区容错性保证，同时降低数据一致性级别。

NewSQL 是一类现代关系数据库，旨在为在线事务处理（读写）工作负载提供与 NoSQL 系统相同的可扩展性能，同时仍然使用 SQL 并保持传统数据库系统的 ACID 保证。

分类

对数据库进行分类的一种方法涉及其内容的类型，例如：书目、文档文本、统计或多媒体对象。另一种方式是按应用领域划分，例如：会计、音乐创作、电影、银行、制造或保险。第三种方法是通过某些技术方面，例如数据库结构或接口类型。本节列出了一些用于描述不同类型数据库的形容词。

• 内存数据库是主要驻留在主存储器中的数据库，但通常由非易失性计算机数据存储进行备份。主内存数据库比磁盘数据库更快，因此通常在响应时间至关重要的地方使用，例如电信网络设备。
• 活动数据库包括事件驱动的体系结构，可以响应数据库内部和外部的条件。可能的用途包括安全监控、警报、统计数据收集和授权。许多数据库以数据库触发器的形式提供主动数据库功能。
• 云数据库依赖于云技术。数据库及其大部分 DBMS 都远程驻留在“云中”，而其应用程序均由程序员开发，然后由最终用户通过 Web 浏览器和开放 API 进行维护和使用。
• 数据仓库存档来自运营数据库的数据，通常来自市场研究公司等外部来源。仓库成为管理人员和其他可能无法访问运营数据的最终用户使用的中心数据源。例如，销售数据可能会汇总为每周总计，并从内部产品代码转换为使用UPC，以便可以与ACNielsen数据进行比较。数据仓库的一些基本和重要组成部分包括提取、分析和挖掘数据，转换、加载和管理数据以供进一步使用。
• 演绎数据库将逻辑编程与关系数据库结合起来。
• 分布式数据库是一种数据和 DBMS 都跨越多台计算机的数据库。
• 面向文档的数据库旨在存储、检索和管理面向文档或半结构化的信息。面向文档的数据库是NoSQL数据库的主要类别之一。
• 嵌入式数据库系统是与应用程序软件紧密集成的 DBMS，该应用程序软件需要以这样的方式访问存储的数据，即 DBMS 对应用程序的最终用户隐藏，并且需要很少或不需要持续维护。
• 最终用户数据库由各个最终用户开发的数据组成。例如，文档、电子表格、演示文稿、多媒体和其他文件的集合。几种产品的存在是为了支持此类数据库。
• 联合数据库系统由多个不同的数据库组成，每个数据库都有自己的 DBMS。它由联合数据库管理系统 (FDBMS) 作为单个数据库进行处理，该系统透明地集成多个可能不同类型的自治 DBMS（在这种情况下，它也将是异构数据库系统），并为它们提供集成的概念视图。
• 有时，术语“多数据库”被用作联合数据库的同义词，尽管它可能指的是在单个应用程序中协作的集成度较低（例如，没有FDBMS和托管集成模式）的数据库组。在这种情况下，通常使用中间件进行分发，其通常包括原子提交协议(ACP)，例如两阶段提交协议，以允许跨参与数据库的分布式(全局)事务。
• 图数据库是一种NoSQL数据库，它使用具有节点、边和属性的图结构来表示和存储信息。可以存储任何图的通用图数据库与三元组和网络数据库等专用图数据库不同。
• 数组DBMS是一种 NoSQL DBMS，允许对（通常很大）多维数组（例如卫星图像和气候模拟输出）进行建模、存储和检索。
• 在超文本或超媒体数据库中，表示对象的任何单词或文本片段，例如另一文本片段、文章、图片或电影，可以超链接到该对象。超文本数据库对于组织大量不同的信息特别有用。例如，它们对于组织在线百科全书非常有用，用户可以在其中方便地跳转文本。因此，万维网是一个大型分布式超文本数据库。
• 知识库（缩写为KB、kb或Δ ）是一种特殊的知识管理数据库，为计算机化的知识收集、组织和检索提供手段。还有代表问题及其解决方案和相关经验的数据集合。
• 移动数据库可以承载在移动计算设备上或从移动计算设备同步。
• 运营数据库存储有关组织运营的详细数据。他们通常使用事务处理相对大量的更新。例如，记录有关企业客户的联系人、信用和人口统计信息的客户数据库，保存工资、福利、员工技能数据等信息的人事数据库，记录有关产品组件、零件库存和财务的详细信息的企业资源规划系统。跟踪组织的资金、会计和财务交易的数据库。
• 并行数据库并行化旨在通过加载数据、构建索引和评估查询等任务来提高性能。由底层硬件架构引发的主要并行 DBMS 架构有：
  • 共享内存架构，其中多个处理器共享主内存空间以及其他数据存储。
  • 共享磁盘架构，其中每个处理单元（通常由多个处理器组成）都有自己的主存储器，但所有单元共享其他存储。
  • 无共享架构，其中每个处理单元都有自己的主内存和其他存储。
• 概率数据库模糊逻辑采用从不精确的数据中得出推论。
• 实时数据库处理事务的速度足够快，可以立即返回结果并采取行动。
• 空间数据库可以存储具有多维特征的数据。对此类数据的查询包括基于位置的查询，例如“我所在地区最近的酒店在哪里？”。
• 时态数据库具有内置的时间方面，例如时态数据模型和SQL的时态版本。更具体地说，时间方面通常包括有效时间和交易时间。
• 面向术语的数据库建立在面向对象的数据库之上，通常针对特定领域进行定制。
• 非结构化数据数据库旨在以可管理和受保护的方式存储不自然且方便地适合常见数据库的各种对象。它可能包括电子邮件、文档、期刊、多媒体对象等。该名称可能会产生误导，因为某些对象可能是高度结构化的。然而，整个可能的对象集合并不适合预定义的结构化框架。大多数成熟的 DBMS 现在都以各种方式支持非结构化数据，并且新的专用 DBMS 正在出现。

数据库管理系统

Connolly 和 Begg 将数据库管理系统 (DBMS) 定义为“使用户能够定义、创建、维护和控制对数据库的访问的软件系统”。  DBMS 的示例包括 MySQL、MariaDB、PostgreSQL、Microsoft SQL Server、Oracle 数据库和 Microsoft Access。

DBMS 缩写词有时会扩展以表示底层数据库模型，其中 RDBMS 表示关系模型，OODBMS 表示对象（面向），ORDBMS 表示对象关系模型。其他扩展可以指示一些其他特性，例如分布式数据库管理系统的 DDBMS。

DBMS 提供的功能差异很大。核心功能是数据的存储、检索和更新。 Codd 提出成熟的通用 DBMS 应提供以下功能和服务：

• Data storage, retrieval and update

  数据存储、检索和更新

• User accessible catalog or data dictionary describing the metadata

  用户可访问的目录或描述元数据的数据字典

• Support for transactions and concurrency

  支持事务和并发

• Facilities for recovering the database should it become damaged

  用于在数据库损坏时恢复数据库的设施

• Support for authorization of access and update of data

  支持数据访问授权和更新

• Access support from remote locations

  从远程位置获取支持

• Enforcing constraints to ensure data in the database abides by certain rules

  强制约束以确保数据库中的数据遵守某些规则

通常还期望 DBMS 将提供一组用于有效管理数据库所需的实用程序，包括导入、导出、监视、碎片整理和分析实用程序。  DBMS 的核心部分是数据库和应用程序接口之间交互的部分，有时也称为数据库引擎。

DBMS 通常具有可以静态和动态调整的配置参数，例如数据库可以使用的服务器上的最大主内存量。趋势是尽量减少手动配置的数量，对于嵌入式数据库等情况，实现零管理的需求至关重要。

大型企业 DBMS 的规模和功能趋于增加，并且在其整个生命周期中涉及长达数千年的开发工作。

早期的多用户 DBMS 通常只允许应用程序驻留在同一台计算机上，并通过终端或终端仿真软件进行访问。客户端-服务器架构是一种开发，其中应用程序驻留在客户端桌面上，数据库驻留在服务器上，从而允许分布式处理。这演变成一种多层架构，将应用程序服务器和 Web 服务器与通过 Web 浏览器的最终用户界面结合起来，数据库仅直接连接到相邻层。

通用 DBMS 将提供公共应用程序编程接口 (API) 和可选的用于数据库语言（例如 SQL）的处理器，以允许编写应用程序来与数据库交互和操作数据库。专用 DBMS 可以使用私有 API 并进行专门定制并链接到单个应用程序。例如，电子邮件系统执行通用 DBMS 的许多功能，例如消息插入、消息删除、附件处理、阻止列表查找、将消息与电子邮件地址关联等，但是这些功能仅限于处理所需的功能。电子邮件。

应用程序接口

程序员将通过应用程序编程接口（API）或通过数据库语言编写与数据库（有时称为数据源）的交互。所选的特定 API 或语言需要得到 DBMS 的支持，可能通过预处理器或桥接 API 间接支持。一些 API 的目标是独立于数据库，ODBC就是一个众所周知的例子。其他常见 API 包括JDBC和ADO.NET。

数据库语言

数据库语言是特殊用途的语言，它允许执行以下一项或多项任务，有时被区分为子语言：

• 数据控制语言（DCL）——控制对数据的访问；
• 数据定义语言(DDL) – 定义数据类型，例如创建、更改或删除表以及它们之间的关系；
• 数据操作语言(DML) – 执行插入、更新或删除数据出现等任务；
• 数据查询语言(DQL) – 允许搜索信息和计算派生信息。数据库语言特定于特定的数据模型。值得注意的例子包括：
• SQL 将数据定义、数据操作和查询的角色结合在单一语言中。它是关系模型的最早的商业语言之一，尽管它在某些方面与 Codd 描述的关系模型不同（例如，表的行和列可以排序）。SQL 于 1986 年成为美国国家标准协会(ANSI)的标准，并于 1987 年成为国际标准化组织(ISO) 的标准。此后，这些标准不断得到增强，并受到所有主流商业应用程序的支持（具有不同程度的一致性）。关系型 DBMS。
• OQL是一种对象模型语言标准（来自对象数据管理组）。它影响了一些较新的查询语言（例如JDOQL和EJB QL）的设计。
• XQuery是一种标准 XML 查询语言，由 XML 数据库系统（例如MarkLogic和eXist）、具有 XML 功能的关系数据库（例如 Oracle 和 Db2）以及内存中 XML 处理器（例如Saxon ）实现。
• SQL/XML将XQuery与 SQL结合起来。

数据库语言还可以包含以下功能：

• DBMS 特定的配置和存储引擎管理
• 修改查询结果的计算，例如计数、求和、平均、排序、分组和交叉引用
• 约束执行（例如，在汽车数据库中，每辆车只允许一种发动机类型）
• 应用程序编程接口版本的查询语言，为程序员提供方便

贮存

数据库存储是数据库物理实现的容器。它包含数据库体系结构中的内部（物理）级别。它还包含在需要时从内部级别重建概念级别和外部级别所需的所有信息（例如，元数据、“关于数据的数据”和内部数据结构）。数据库作为数字对象包含必须存储的三层信息：数据、结构和语义。为了数据库的未来保存和长期使用，需要正确存储所有三层。  将数据放入永久存储通常是数据库引擎（也称为“存储引擎”）的责任。虽然 DBMS 通常通过底层操作系统进行访问（并且经常使用操作系统的文件系统作为存储布局的中间体），但存储属性和配置设置对于 DBMS 的高效操作极其重要，因此由 DBMS 密切维护数据库管理员。 DBMS 在运行时始终将其数据库驻留在多种类型的存储中（例如内存和外部存储）。数据库数据和可能数量很大的附加所需信息被编码成位。数据通常驻留在存储中，其结构看起来与数据在概念和外部级别上的外观完全不同，但在用户和程序需要时也尝试优化（尽可能最佳）这些级别的重建。至于从数据中计算其他类型的所需信息（例如，在查询数据库时）。

一些DBMS支持指定使用哪种字符编码来存储数据，因此可以在同一个数据库中使用多种编码。

存储引擎使用各种低级数据库存储结构来序列化数据模型，以便将其写入所选的介质。诸如索引之类的技术可用于提高性能。常规存储是面向行的，但也有面向列和关联数据库。

物化视图

通常采用存储冗余来提高性能。一个常见的例子是存储物化视图，它由经常需要的外部视图或查询结果组成。存储此类视图可以节省每次需要时进行昂贵的计算。物化视图的缺点是更新它们以使其与原始更新的数据库数据保持同步时产生的开销，以及存储冗余的成本。

复制

有时，数据库通过数据库对象复制（具有一个或多个副本）来采用存储冗余来提高数据可用性（既可以提高多个最终用户同时访问同一数据库对象的性能，又可以在数据库对象部分故障的情况下提供弹性）分布式数据库）。复制对象的更新需要在对象副本之间同步。在许多情况下，整个数据库都会被复制。

虚拟化

通过数据虚拟化，所使用的数据保留在其原始位置，并建立实时访问以允许跨多个来源进行分析。这可以帮助解决一些技术难题，例如组合不同平台数据时的兼容性问题，降低因错误数据而导致错误的风险，并保证使用最新的数据。此外，避免创建包含个人信息的新数据库可以更容易遵守隐私法规。然而，对于数据虚拟化，与所有必要数据源的连接必须可操作，因为没有数据的本地副本，这是该方法的主要缺点之一。

事务和并发

数据库事务可用于在从崩溃中恢复后引入某种程度的容错和数据完整性。数据库事务是一个工作单元，通常封装对数据库的许多操作（例如，读取数据库对象、写入、获取或释放锁等），是数据库和其他系统中支持的抽象。每个事务都具有明确定义的边界，即该事务中包含哪些程序/代码执行（由事务程序员通过特殊事务命令确定）。

首字母缩略词 ACID 描述了数据库事务的一些理想属性：原子性、一致性、隔离性和持久性。

迁移

使用一个 DBMS 构建的数据库不能移植到另一个 DBMS（即其他 DBMS 无法运行它）。然而，在某些情况下，需要将数据库从一个 DBMS 迁移到另一个 DBMS。原因主要是经济性（不同的 DBMS 可能有不同的总拥有成本或 TCO）、功能性和操作性（不同的 DBMS 可能有不同的功能）。迁移涉及数据库从一种 DBMS 类型转换为另一种 DBMS 类型。转换应保持（如果可能）数据库相关应用程序（即所有相关应用程序）完好无损。因此，数据库的概念和外部架构级别应该在转换中保持不变。可能还需要维护架构内部级别的某些方面。复杂或大型数据库迁移本身可能是一个复杂且成本高昂的（一次性）项目，应在迁移决策中考虑这一点。尽管事实上可能存在帮助特定 DBMS 之间迁移的工具。通常，DBMS 供应商提供工具来帮助从其他流行的 DBMS 导入数据库。

静态分析

用于软件验证的静态分析技术也可以应用在查询语言的场景中。特别是，抽象解释框架已扩展到关系数据库的查询语言领域，作为支持声音近似技术的一种方式。  查询语言的语义可以根据具体数据域的适当抽象进行调整。关系数据库系统的抽象有许多有趣的应用，特别是出于安全目的，例如细粒度访问控制、水印等。

设计与建模

数据库设计者的第一个任务是生成一个概念数据模型，该模型反映数据库中要保存的信息的结构。一种常见的方法是开发实体关系模型，通常借助绘图工具。另一种流行的方法是统一建模语言。一个成功的数据模型将准确地反映正在建模的外部世界的可能状态：例如，如果人们可以拥有多个电话号码，它将允许捕获这一信息。设计一个好的概念数据模型需要对应用领域有很好的理解；它通常涉及对组织感兴趣的事物提出深入的问题，例如“客户也可以是供应商吗？”，或者“如果产品以两种不同形式的包装出售，那么它们是相同的产品还是不同的产品？ ”，或者“如果一架飞机从纽约经法兰克福飞往迪拜，这是一趟还是两趟（甚至可能是三趟）航班？这些问题的答案建立了用于实体（客户、产品、航班、航段）的术语及其关系和属性的定义。

生成概念数据模型有时涉及业务流程的输入或组织中工作流的分析。这可以帮助确定数据库中需要哪些信息以及可以省略哪些信息。例如，它可以帮助确定数据库是否需要保存历史数据以及当前数据。

生成用户满意的概念数据模型后，下一阶段是将其转换为在数据库中实现相关数据结构的模式。这个过程通常称为逻辑数据库设计，输出是以模式形式表示的逻辑数据模型。虽然概念数据模型（至少在理论上）独立于数据库技术的选择，但逻辑数据模型将用所选 DBMS 支持的特定数据库模型来表示。 （术语数据模型和数据库模型通常可以互换使用，但在本文中，我们使用数据模型来设计特定数据库，使用数据库模型来表示用于表达该设计的建模符号）。

通用数据库最流行的数据库模型是关系模型，或者更准确地说，是以SQL语言为代表的关系模型。使用此模型创建逻辑数据库设计的过程使用了一种称为规范化的系统方法。规范化的目标是确保每个基本“事实”仅记录在一个地方，以便插入、更新和删除自动保持一致性。

数据库设计的最后阶段是做出影响性能、可伸缩性、恢复、安全性等的决策，这取决于特定的 DBMS。这通常称为物理数据库设计，输出是物理数据模型。此阶段的一个关键目标是数据独立性，这意味着出于性能优化目的而做出的决策对于最终用户和应用程序来说应该是不可见的。数据独立性有两种类型：物理数据独立性和逻辑数据独立性。物理设计主要由性能要求驱动，需要充分了解预期的工作负载和访问模式，并深入了解所选 DBMS 提供的功能。

物理数据库设计的另一个方面是安全性。它涉及定义对数据库对象的访问控制以及定义数据本身的安全级别和方法。

Models

数据库模型是一种数据模型，它决定数据库的逻辑结构，并从根本上决定数据的存储、组织和操作方式。数据库模型最流行的示例是关系模型（或关系模型的 SQL 近似），它使用基于表的格式。

数据库常见的逻辑数据模型包括：

• Navigational databases  导航数据库
  • Hierarchical database model分层数据库模型
  • Network model 网络模型
  • Graph database  图数据库
• Relational model  关系模型
• Entity–relationship model实体关系模型
  • Enhanced entity–relationship model增强的实体关系模型
• Object model 对象模型
• Document model  文档模型
• Entity–attribute–value model实体-属性-值模型
• Star schema  星型模式

对象关系数据库结合了这两种相关的结构。

物理数据模型包括：

• Inverted index  倒排索引
• Flat file  平面文件

其他型号包括：

• Multidimensional model  多维模型
• Array model  阵列模型
• Multivalue model  多值模型

专门的模型针对特定类型的数据进行了优化：

• XML database  XML数据库
• Semantic model  语义模型
• Content store  内容商店
• Event store  活动商店
• Time series model  时间序列模型

外部、概念和内部视图

数据库管理系统提供数据库数据的三个视图：

• 外部级别定义每组最终用户如何查看数据库中的数据组织。单个数据库可以在外部级别拥有任意数量的视图。
• 概念层面（或逻辑层面）将各种外部视图统一为兼容的全局视图。  它提供了所有外部视图的综合。它超出了各种数据库最终用户的范围，并且是数据库应用程序开发人员和数据库管理员相当感兴趣的。
• 内部级别（或物理级别）是 DBMS 内数据的内部组织。它涉及成本、性能、可扩展性和其他运营问题。它处理数据的存储布局，使用索引等存储结构来提高性能。有时，如果存在这种冗余的性能合理性，它会存储根据通用数据计算的各个视图（物化视图）的数据。它平衡所有外部视图的性能要求（可能是冲突的），以尝试优化所有活动的整体性能。

虽然通常只有一种数据的概念和内部视图，但可以有任意数量的不同外部视图。这允许用户以更与业务相关的方式而不是从技术、处理的角度查看数据库信息。例如，公司的财务部门需要所有员工的付款详细信息作为公司费用的一部分，但不需要符合人力资源部门利益的员工详细信息。因此，不同的部门需要公司数据库的不同视图。

三级数据库体系结构涉及数据独立性的概念，这是关系模型的主要初始驱动力之一。  这个想法是在某个级别所做的更改不会影响更高级别的视图。例如，内部级别的更改不会影响使用概念级别接口编写的应用程序，这减少了为提高性能而进行物理更改的影响。

概念视图提供了内部和外部之间的间接级别。一方面，它提供了数据库的通用视图，独立于不同的外部视图结构，另一方面，它抽象了如何存储或管理数据的细节（内部级别）。原则上，每个级别，甚至每个外部视图，都可以通过不同的数据模型来呈现。在实践中，给定的 DBMS 通常对外部层和概念层使用相同的数据模型（例如关系模型）。内部级别隐藏在 DBMS 内部并取决于其实现，需要不同的详细级别并使用其自己的数据结构类型。

研究

自 20 世纪 60 年代以来，数据库技术一直是学术界和公司研发团队（例如 IBM Research）的一个活跃的研究主题。研究活动包括理论和原型开发。值得注意的研究主题包括模型、原子事务概念、相关并发控制技术、查询语言和查询优化方法、RAID 等。

数据库研究领域有多个专门的学术期刊（例如，ACM Transactions on Database Systems-TODS、Data and Knowledge Engineering-DKE）和年会（例如，ACM SIGMOD、ACM PODS、VLDB、IEEE ICDE）。

NoSQL

NoSQL（最初指“非 SQL”或“非关系型”）  是一种数据库设计方法，重点是提供一种以非 SQL 方式建模的数据存储和检索机制。关系数据库中使用的表格关系。 NoSQL 数据库不是关系数据库的典型表格结构，而是将数据存储在一种数据结构中。由于这种非关系数据库设计不需要模式，因此它提供了快速的可扩展性来管理大型且通常是非结构化的数据集。  NoSQL 系统有时也被称为“Not Only SQL”，以强调它们可以支持类似 SQL 的查询语言，或者在多语言持久架构中与 SQL 数据库并存。

非关系数据库自 20 世纪 60 年代末以来就已经存在，但“NoSQL”这个名称直到 2000 年代初才被创造出来，  是由 Web 2.0 公司的需求引发的。   NoSQL 数据库越来越多地用于大数据和实时 Web 应用程序。

这种方法的动机包括设计简单、更简单地“水平”扩展到机器集群（这对于关系数据库来说是一个问题）、  对可用性的更精细控制以及限制对象关系阻抗不匹配。  NoSQL 数据库使用的数据结构（例如键值对、宽列、图形或文档）与关系数据库中默认使用的数据结构不同，这使得 NoSQL 中的某些操作更快。给定 NoSQL 数据库的特定适用性取决于它必须解决的问题。有时，NoSQL 数据库使用的数据结构也被视为比关系数据库表“更灵活”。 

许多 NoSQL 存储会为了可用性、分区容错性和速度而牺牲一致性（在 CAP 定理的意义上）。更广泛地采用 NoSQL 存储的障碍包括使用低级查询语言（例如，而不是 SQL）、缺乏跨表执行即席联接的能力、缺乏标准化接口以及之前对现有关系数据库的大量投资。  大多数 NoSQL 存储缺乏真正的 ACID 事务，尽管一些数据库已将它们作为其设计的核心。

相反，大多数 NoSQL 数据库提供了“最终一致性”的概念，其中数据库更改“最终”（通常在毫秒内）传播到所有节点，因此数据查询可能不会立即返回更新的数据，或者可能导致读取不更新的数据。不准确，这个问题称为陈旧读取。  此外，某些 NoSQL 系统可能会出现写入丢失和其他形式的数据丢失。  一些 NoSQL 系统提供诸如预写日志记录之类的概念来避免数据丢失。  对于跨多个数据库的分布式事务处理来说，数据一致性是一个更大的挑战，对于NoSQL和关系数据库来说都是困难的。关系数据库“不允许跨数据库的引用完整性约束”。  很少有系统同时维护 ACID 事务和用于分布式事务处理的 X/Open XA 标准。  交互式关系数据库共享构象中继分析技术作为共同特征。  使用语义虚拟化协议克服了接口环境中的限制，使得大多数操作系统都可以访问 NoSQL 服务。

历史

Carlo Strozzi 在 1998 年使用 NoSQL 一词来命名他的轻量级 Strozzi NoSQL 开源关系数据库，该数据库没有公开标准结构化查询语言 (SQL) 接口，但仍然是关系数据库。  他的 NoSQL RDBMS 与 2009 年左右 NoSQL 数据库的一般概念不同。 Strozzi 认为，由于当前的 NoSQL 运动“完全背离了关系模型，因此它应该被更恰当地称为‘NoREL’”，  指的是“非关系”。

当时 Last.fm 的开发人员 Johan Oskarsson 在 2009 年初组织了一次讨论“开源分布式非关系数据库”的活动时，重新引入了 NoSQL 一词。  这个名称试图标记越来越多的非关系型分布式数据存储的出现，包括 Google Bigtable/MapReduce 和 Amazon DynamoDB 的开源克隆。

类型和示例

NoSQL 数据库的分类方法有很多种，有不同的类别和子类别，其中一些类别和子类别是重叠的。以下是按数据模型进行的非详尽分类，并附有示例：

键值存储

键值 (KV) 存储使用关联数组（也称为映射或字典）作为其基本数据模型。在此模型中，数据表示为键值对的集合，使得每个可能的键在集合中最多出现一次。

键值模型是最简单的非平凡数据模型之一，更丰富的数据模型通常作为其扩展来实现。键值模型可以扩展到按字典顺序维护键的离散排序模型。此扩展计算能力强大，因为它可以有效地检索选择性键范围。

键值存储可以使用从最终一致性到可序列化的一致性模型。一些数据库支持键的排序。有多种硬件实现，一些用户将数据存储在内存 (RAM) 中，而其他用户则将数据存储在固态驱动器 (SSD) 或旋转磁盘（又名硬盘驱动器 (HDD)）上。

文件存储

文档存储的中心概念是“文档”。虽然这个定义的细节在面向文档的数据库之间有所不同，但它们都假设文档以某些标准格式或编码封装和编码数据（或信息）。使用的编码包括 XML、YAML 和 JSON 以及 BSON 等二进制形式。文档在数据库中通过代表该文档的唯一键进行寻址。面向文档的数据库的另一个定义特征是根据文档内容检索文档的 API 或查询语言。

不同的实现提供了不同的组织和/或分组文档的方式：

• Collections 收藏
• Tags 标签
• Non-visible metadata 不可见的元数据
• Directory hierarchies 目录层次结构

与关系数据库相比，集合可以被视为类似于表格，文档类似于记录。但它们是不同的——表中的每条记录都具有相同的字段序列，而集合中的文档可能具有完全不同的字段。

图形

图数据库是为那些关系可以很好地表示为由有限数量的关系连接的元素组成的图的数据而设计的。数据的示例包括社会关系、公共交通链接、路线图、网络拓扑等。

图数据库及其查询语言

表现

NoSQL 数据库的性能通常使用吞吐量指标来评估，吞吐量以操作数/秒来衡量。性能评估必须关注正确的基准，例如生产配置、数据库参数、预期数据量和并发用户工作负载。

Ben Scofield 对不同类别的 NoSQL 数据库进行了如下评级：

性能和可扩展性比较通常使用 YCSB 基准进行。

处理关系数据

由于大多数 NoSQL 数据库缺乏查询连接的能力，因此数据库模式通常需要进行不同的设计。在 NoSQL 数据库中处理关系数据有三种主要技术。 （有关支持联接的 NoSQL 数据库，请参阅表联接和 ACID 支持。）

多次查询

通常不是通过一个查询检索所有数据，而是执行多个查询来获取所需的数据。 NoSQL 查询通常比传统 SQL 查询更快，因此额外查询的成本可能是可以接受的。如果需要过多的查询，则其他两种方法之一更合适。

缓存、复制和非标准化数据

通常将实际的外来值与模型的数据一起存储，而不是仅存储外键。例如，每个博客评论除了用户 ID 之外还可能包含用户名，从而提供对用户名的轻松访问，而无需再次查找。但是，当用户名发生更改时，现在需要在数据库中的许多位置进行更改。因此，当读取比写入更常见时，这种方法效果更好。

嵌套数据

对于像 MongoDB 这样的文档数据库，通常会将更多数据放入较少数量的集合中。例如，在博客应用程序中，人们可能会选择将评论存储在博客文章文档中，以便通过一次检索即可获得所有评论。因此，在这种方法中，单个文档包含特定任务所需的所有数据。

ACID 和连接支持

如果数据库的文档做出了这样的声明，则数据库被标记为支持 ACID 属性（原子性、一致性、隔离性、持久性）或连接操作。但是，这并不一定意味着该功能以类似于大多数 SQL 数据库的方式得到完全支持。

向量数据库