数据库管理系统与数据库与表与文件

Question

我一直在试图理解数据库系统的工作方式。通过互联网，我发现了下面的图片。

1. 需要数据库系统，因为我们需要一种存储数据的方法，主要是大规模的存储数据，这样我们就可以更新、查询、删除、操作数据，并且可以轻松地执行其他操作。传统的文件系统不是为此而设计的，无法达到这个目的。
2. 我们可以用不同的方式来实现上述数据库系统，这就导致了不同的数据模型，其中RDBMS是最主要的数据模型。
3. 有一个数据库管理系统，它是一个软件，在某种程度上类似于文件管理系统，它管理创建、删除、插入数据等要求。SQLite。
4. 我们使用数据库管理系统提供的接口和与数据库管理系统兼容的语言与数据库进行交互。例如：SQL。

我希望到现在为止我的理解是正确的。

现在，数据库管理系统与数据库交互，我无法确切地理解什么是数据库。我曾经认为，所有表的集合都被称为数据库，只是一个名称。但是后来我发现有几个数据库是可能的，可以像使用文件一样使用DBMS创建数据库。进一步的研究表明，数据库是一个文件。

我的疑虑如下：

1. 如果数据库是一个文件，那么它与普通文件有什么不同(在实现方面)？
2. 我相信桌子也是档案。但是表存储在数据库中。一个文件如何在一个文件中，两者都可以被认为是独立的。
3. 不同的数据模型的实现，如关系存储在rdbms中，对象存储在基于面向对象的数据库系统中，它们是在数据库管理系统中实现还是在数据库中实现？

如果数据库不是一个文件，那么具体是什么，以及表、数据库和数据库管理系统在实现方面是如何关联的呢？

我试图找到答案，但似乎这些内容并不多，我没有运气。此外，请解释它避免了非常复杂的代码片段，因为我是一个分析。

Answer 1

下面是一种自下而上的方法的开始，它解释了一个特定DBMS如何存储和检索数据。特定的DBMS是Oracle-RDB，以前称为DEC RDB/VMS。这是一个不同于Oracle的产品，RDBMS是每个人都知道和喜欢(或者不喜欢)的产品。

数据库文件由一个主文件、多个存储区域文件以及多个快照文件组成。快照文件包含为长时间运行只读事务而保留数据库虚拟快照所需的数据。我现在要忽略那些文件。

主文件包含DBMS定位和使用存储区域文件所需的信息，以及快照文件。

每个存储区域被划分为所谓的“数据库页”。名称" pages“可能会使人产生误解，因为这与CPU内由内存映射程序管理的内存页不同。但是，数据库页大小始终是内存映射程序中页大小和文件系统中磁盘块大小的倍数。

单个存储区域中的所有数据库页都是相同大小的，但不同存储区域之间的大小可能有所不同。

每一页被分成几行。一条线是通过一个线索引来定位的。每个索引条目包含一个字节偏移量和一行大小(以字节为单位)。字节偏移量是从页面开头开始的。

一行可能包含:表行；索引节点；散列桶；或DBMS为管理存储区域内的空闲空间所需要的任何数据结构，等等。

对于使用某种编程语言编写应用程序的应用程序开发人员来说，以及在SQL中，所有这些结构都是完全不透明的。程序员根本不需要知道这些东西。为了建立一个高性能的数据库，数据库生成器可能会从了解这些内容中获益。

构成表的各种行不需要在存储区域中彼此相邻。表甚至可以跨存储区域拆分，数据库构建器利用这一事实来提高多用户数据库的性能。

DBMS可以相当快地定位给定表的所有行，但在许多情况下，对大型表的完全访问仍然是一种性能灾难。这算是最后的手段了。大多数数据访问都是通过索引和/或散列桶完成的。索引提供了一种将键访问转换为直接访问的非常快速的方法。

索引条目提供的访问信息包括存储区域号、存储区域内的页码和页面中的行号。根据这些信息，DBMS可以快速找到构成数据库页的文件块，并将该页面输入内存。然后，利用行号和行索引，快速定位页面内的直线。

所有这些似乎与程序员可能通过SELECT语句发出的SQL没有什么关系。我所说的一切都与构建DBMS可以定位和检索SELECT语句所需数据的平台有关。但这个故事比我讲的要多得多。我才刚开始想办法。

RDB内置了一个基于成本的查询优化器，该优化器帮助DBMS选择几种等效检索策略中可能需要最少的磁盘I/O操作。

我现在只想写这些。如果您有兴趣自己学习，下面是一个链接：http://neilrieck.net/docs/openvms_备注_均方根_rdb.html#rdb

但是，如果我是您，我会花更多的时间来学习Oracle RDBMS的内部结构，它的组织方式有些不同。另外，SQL Server的内部结构，另一个主要的竞争者。还有其他重要的球员，如Postgres，等等。

祝好运。

增编

值得一提的是，数据库中的一个数据结构。这是数据字典。这是存储在数据库中的数据定义的存储库。当数据库构建器使用CREATE、ALTER和DROP命令创建数据库及其内容时，DBMS以存储在数据库中的元数据的形式记录其活动。这被称为数据字典，使用行业范围的术语。Oracle使用了“系统关系”一词。这实际上是第二个数据库，其中DBMS与自身共享数据定义。每个表名、列名和存储区域名称都存储在这里，还有许多其他内容。DBMS在稍后的某个时候将需要这一点，当它解析来自程序员或DBA的SQL时。它还可以用来提取一个create脚本来创建一个没有任何数据的新数据库，但是使用当时的定义。自描述数据是任何真实数据库系统的关键元素。

(感谢沙希德·哈克的回答，他的回答激发了我对这部分的记忆。他的回答是这个问题的一个有用的反义词，因为Shaheed采用了自上而下的方法来描述DBMS的内部结构。)

可能还会有更多。

Answer 2

开始考虑不同类型存储的高级别属性/行为，而不是低级别的细节，这可能是有帮助的。

例如，我们可以考虑简单的文件(平面的、二进制的内容)、索引的文件(在单个简单文件之上的结构化访问)，在这两种情况下，OS级原语提供的都有或没有锁定。

在这种情况下，人们可能会说，不同的数据库系统(使用非常松散的术语)可以通过如下方式来描述和对比文件：

• 一种查询语言，用于根据某些复杂的标准读取(并在一定程度上写入)数据。简单文件只能通过文件偏移量来读取或写入。索引文件可以有一些条件，但查询语言通常非常简单。
• 数据库系统通常有多种类型的对象存储在其中，元数据结构允许查询语言以统一的方式处理这些对象。使用简单文件和索引文件，您必须自己构建所有这些方面。
• 数据库系统通常是网络访问的，包括具有锁定语义的.简单的文件可以由网络文件系统层公开，但是当您这样做时，锁定语义通常会丢失或更改。我不知道有任何系统(除了一些20世纪80年代的过时系统)甚至试图对索引文件这样做。

人们可以继续对许多其他行为和属性进行这种分析。当你这样做的时候，你的问题和假设的细节就可以在这些行为和属性方面得到回答。

当然，许多数据库系统都是建立在操作系统提供的简单文件之上的，这也是事实。但这并不是既定的--事实上，高性能的数据库系统也使用某种“原始”I/O来访问磁盘是很常见的。文件恰好是一个方便的抽象，以避免数据库系统不得不复制操作系统的文件访问层已经做的许多事情。