数据库系统的内部结构体系简介

你发布了数据库系统的内部结构，我刚入行的时候，已经看书很久了。
但我们先不讨论这些理论。
我就简单说一下我当时踩过的陷阱吧。

我记得那是2 006 年，我刚加入一家小公司，承担起了一些烂摊子。
这个数据库系统外部模型奇特，各个部门都有自己的系统，就像八国联军一样。
结果？概念图和内部图之间存在严重差距。
当数据更新时，一侧发生变化，另一侧还在使用旧数据，这就乱了套。
最后，我花了三个月的时间才弄清楚一切。

所以，第三级模式和第二级显示听起来很高端，但关键要看实际应用。
如果外部模式与概念模式脱节，数据一致性就会丢失，这是一个大问题。

关于你提到的扩展部分，我介绍了单用户结构、主机/终端结构、客户端/服务器结构和多层数据库应用结构。
然而，客户端/服务器结构的问题最多。
当时我们公司正在进行一个大型项目，采用C/S结构。
结果客户端出了问题，整个服务器瘫痪了。
损失是巨大的。

所以，无论使用什么结构，都必须设计得好，这样万一出了什么问题，哭都来不及了。
你所说的一切都是我的个人经历。
我希望这对您有帮助。

什么是数据库系统的体系结构？

你好。
这种三级数据库结构（架构）实际上是由美国的ANSI/X3 /SPARC小组在1 9 7 5 年提出的。
这很有趣。
当时计算机正在发展，数据管理很混乱，所以我们就提出了这些标准来规范它。

你是对的。
这三个层次的数据视图展示了不同的人如何从不同的角度看待数据。

1 .外观（顶层）：就像玩游戏时直接操作的角色界面。
应用程序程序员可以考虑这一点并将其设计得尽可能易于使用。
例如，在订票系统中，售票员看到的界面就是外部。
他只想查看车次、剩余车票和价格，并不想关心底层数据来自哪里。
您的系统可能有多种外观视图，因为不同的用户有不同的需求。
2 .全局视图（中间层）：这就像游戏设计师看着整个游戏世界。
数据库管理员（DBA）主要查看所有数据（例如所有乘客或所有火车）的整体逻辑结构。
需要整合上述多种外观需求，设计统一合理的全局逻辑结构。
只有一种观点。
3 .存储视图（底层）：类似于游戏引擎底层渲染角色动作和特效的方式。
系统维护人员（或更可能是 DBA）感兴趣的是数据如何存储在硬盘上，包括顺序文件、哈希表、B 树索引等的使用。
这一层力求最高的存储效率、最快、最简单的存储方法。
只有一种观点。

三层之间的关系也很清晰。
外部视图是全局视图的逻辑子集，全局视图是外部视图的摘要，存储视图是全局视图的具体实现。
它们之间的转换依赖于映射。
从外部视图到全局视图的映射称为逻辑映射，从全局视图到存储视图的映射称为物理映射。

然后，你提到的三级模式使用计算机可理解的DDL（数据描述语言）来定义三个视图：
1 Subschema（外部模式）：对应外部视图，是用户可见的逻辑结构的一部分，在DBMS子模式DDL中描述。
子模式可由多个用户使用，但通常用户仅使用一种。
2 、Schema（逻辑模式）：对应全局视图，描述整个数据库的逻辑结构，包括记录（字段名、类型、关系）以及完整性和安全性要求。
使用 DBMS 模式 DDL 定义。
这就是症结所在。
数据库只有一个逻辑模式。
3 .内部模式（物理模式）：对应存储视图，描述数据如何在硬盘上存储，包括使用顺序存储和索引。
使用 DBMS 的内部模式 DDL 进行定义。
数据库也只有一个物理模式。

总的来说，三级模式和三级视图是一套分层的设计思想。
模式描述的是框架，而不是数据本身。
充满数据的框架称为物理数据库（真实文件）。
逻辑模式数据收集是一个概念数据库（物理数据库的虚拟逻辑映像）。
数据收集的子模式是用户数据库（概念数据库的子集，用户实际交互的数据）。

当我参与一个项目的数据库设计时，我几乎失去了逻辑模型和物理模型之间的区别。
将指标设计要求写入到物理模型的内容中，后期修改起来非常繁琐。
因此，虽然这个三层结构理论上是一个框架，但如果你不混淆其底层实现和逻辑设计，它肯定会导致陷阱。

您还有什么想问的吗？说起来容易，但是实际使用的时候，细节还是蛮多的。

数据库包含的三级模式分别是什么

嗯...三个层次的模型...对，外部模型，概念模型，内部模型。

就是这个了...2 02 2 年了，大家还在用这个。
在北京这样的城市，很多企业的数据库都是这样划分的。

外部模式...是用户看到的层。
比如，一个电商网站的老板想看今天卖了多少钱，他看到的就是外部模型。
该模型只能包含销售额，不能包含库存。
就这样。

概念模式...是整个数据库的大框架。
所有表以及它们之间的关系都在这里定义。
例如，在2 02 2 年，当一家公司构建数据库时，其概念模式可能会指定它有用户表、产品表和订单表，以及它们之间的关联方式。
这一层是统一的。

内部模式...与硬件、数据存储模式有关。
例如，使用哪种文件组织方式以及如何建立索引。
这是一个相对较低的水平。
也许到2 02 2 年，数据库管理员会调整内部模式，将某个表从顺序文件更改为批处理文件，只是为了提高查询速度。

1 9 7 8 ANSI 建议...它正在发生。
当时大家都想把它标准化。
用户看到的是他们感兴趣的部分，构建数据库的人看到的是整体结构，系统工作的人看到的是它在机器上是如何工作的。

以这种方式分享有很多好处。
逻辑独立性是指如果概念模型发生变化，只要外部模型不变，用户就不需要改变程序。
身体独立也是如此。
如果内部模式发生改变，例如改变存储设备，则概念模式和用户模式不需要改变。

但是……似乎有时候，区分得这么清楚，有点困难。
后来我意识到，有时候概念层和物理层的设计还是会影响用户看到的外部模式。

也许我有点极端……但在我看来，实际上，界限并不那么清晰。
尤其是现在，很多NoSQL数据库可能没有那么分层。

嗯...就是这样。

以下是平行数据库的四种体系结构，在（　　）体系结构中所有处理器共享一个公共的主存储器和磁盘。

结论：存在三种并行数据库结构。

共享内存结构： 多处理器。
共享内存。
共享磁盘。
高速通信网络。
优点：消息交换效率高。
查询并行化没有额外的成本。
多磁盘数据存储，完全访问。
编译软件类似于独立机器。
任务的动态分配。
良好的负载平衡。

共享磁盘的结构： 多处理器独立内存。
没有直接的数据交换。
高速通信网络。
每个处理器读取和写入所有磁盘。
优点：成本低。
良好的可扩展性。
高可用性。
易于迁移。
负载均衡很容易实现。

没有共享源结构： 多个独立的处理节点。
每个节点都有处理器、内存和磁盘。
高速通信网络。
每个节点处理私有数据。
优点：无资源争用。
良好的可扩展性。
线性增加处理能力。
需要解决数据分布问题。
负载平衡需要一个解决方案。
扩容时需要重新分配数据。