2.4 数据库系统结构
考察数据库系统结构可以有不同的层次或不同的角度。
1）从数据库管理角度看，数据库系统通常采用三级模式结构。这是数据库系统的内部结构。
2）从最终用户角度看，数据库系统的结构分为集中式结构、文件服务器结构、客户/服务器结构等。这是数据库系统的外部结构。
本节讨论数据库系统的内部结构。它是为后续章节的内容建立一个框架结构，这个框架用于描述一般数据库管理系统的概念，但并不是所有的数据库管理系统都一定要使用这个框架，它在数据库管理系统中并不是唯一的，特别是一些“小”的数据库管理系统将难以支持这个结构的所有方面。这里介绍的数据库系统结构基本上能很好地适应大多数数据库管理系统，而且，它基本上与ANSI/SPARC DBMS研究组提出的数据库管理系统的体系结构（称作ANSI/SPARC体系结构）相同。
2.4.1 模式的基本概念
数据模型（组织层数据模型）用于描述数据的组织形式，模式则是用给定的数据模型对具体数据的描述（就像用某一种编程语言编写具体应用程序一样）。
模式是数据库中全体数据的逻辑结构和特征的描述，它仅仅涉及“型”的描述，不涉及具体的值。关系模式是关系的“型”或元组的结构共性的描述，它对应的是关系表的表头。
模式的一个具体值称为模式的一个实例，比如表2-1中的每一行数据就是其表头结构（模式）的一个具体实例。一个模式可以有多个实例。模式是相对稳定的（结构不会经常变动），而实例是相对变动的（具体的数据值可以经常变化）。数据模式描述一类事物的结构、属性、类型和约束，实质上是用数据模型对一类事物进行模拟，而实例是反映某类事物在某一时刻的当前状态。
虽然实际的数据库管理系统产品种类很多，支持的数据模型和数据库语言也不尽相同，数据的存储结构也各不相同，但它们在体系结构上通常都具有相同的特征，即采用三级模式结构并提供两级映像功能。
2.4.2 三级模式结构
数据库的三级模式结构是指数据库的外模式、模式和内模式。图2-11所示为各级模式之间的关系。
1）内模式：最接近物理存储，也就是数据的物理存储方式，包括数据存储位置、存储方式等。
2）外模式：最接近用户，也就是用户所看到的数据视图。
3）模式：是介于内模式和外模式之间的中间层，是数据的逻辑组织方式。
在图2-11中，外模式是面向每类用户的数据需求而设计的，而模式描述的是一个部门或公司的全体数据。换句话说，外模式可以有许多，每一个都或多或少地抽象表示整个数据库的某一部分数据，而模式只有一个，它是对包含现实世界业务中的全体数据的抽象表示，注意这里的抽象指的是记录和字段这些更加面向用户的概念，而不是位和字节那些面向机器的概念。内模式也只有一个，它表示数据的物理存储。
我们这里所讨论的内容与数据库是否是关系型的没有直接关系，但简要说明一下关系系统中的三级模式结构，将有助于理解这些概念。
第一，关系数据库中的模式一定是关系的，在该层可见的实体是关系的表和关系的操作符。
第二，外模式也是关系的或接近关系的，它们的内容来自模式。例如我们可以定义两个外模式，一个记录学生的姓名、性别［表示为：学生基本信息1（姓名，性别）］，另一个记录学生的姓名和所在系［表示为：学生基本信息2（姓名，所在系）］，这两个外模式的内容均来自“学生基本信息”这个模式。外模式对应到关系数据库中是“外部视图”或简称为“视图”，它在关系数据库中有特定的含义，我们将在第7章详细讨论视图的概念。
第三，内模式不是关系的，它是数据的物理存储方式。其实，不管是什么系统，其内模式都是一样的，都是存储记录、指针、索引、散列表等。事实上，关系模型与内模式无关，它关心的是用户的数据。
下面我们以图2-11为基础，从外模式开始进一步详细讨论这三层结构。
1.?外模式
外模式也称为用户模式或子模式，它是对现实系统中用户感兴趣的整体数据的局部描述，用于满足数据库的不同用户对数据的需求。外模式是对数据库用户能够看见和使用的局部数据的逻辑结构和特征的描述，是数据库整体数据结构（即模式）的子集或局部重构。
外模式通常是模式的子集。一个数据库可以有多个外模式。由于它是各个用户的数据视图，如果不同的用户在应用需求、看待数据的方式、对数据保密要求等方面存在差异，则其外模式的描述就是不同的。即使对模式中同样的数据，在外模式中的结构、类型、长度等都可以不同。
例如，学生性别信息（学号，姓名，性别）视图就是表2-1所示关系的子集，它是宿舍分配部门所关心的信息，是学生基本信息的子集。又例如，学生成绩（学号，姓名，课程号，成绩）外模式是任课教师所关心的信息，这个外模式的数据就是表2-1的学生基本信息表（模式）和表2-2的学生选课信息表（模式）所含信息的组合（或称为重构）。
外模式同时也是保证数据库安全的一个措施。每个用户只能看到和访问其所对应的外模式中的数据，并屏蔽掉不需要的数据，因此保证不会出现由于用户的误操作和有意破坏而造成数据损失。例如，假设有描述职工信息的关系模式，结构如下：
职工（职工号，姓名，所在部门，基本工资，职务工资，奖励工资）
如果不希望一般职工看到每个职工的奖励工资，则可生成一个包含一般职工可以看的信息的外模式，结构如下：
职工信息（职工号，姓名，所在部门，基本工资，职务工资）
这样就可以保证一般用户不会看到“奖励工资”项。
外模式就是特定用户所看到的数据库的内容，对那些用户来说，外模式就是他们的数据库。
2.?模式
模式也称为逻辑模式或概念模式，是对数据库中全体数据的逻辑结构和特征的描述，是所有用户的公共数据视图。概念模式表示数据库中的全部信息，其形式要比数据的物理存储方式抽象。它是数据库结构的中间层，既不涉及数据的物理存储细节和硬件环境，也与具体的应用程序、所使用的应用开发工具和环境无关。
模式实际上是数据库数据在逻辑级上的视图。一个数据库只有一种模式。数据库模式以某种数据模型为基础，综合地考虑了所有用户的需求，并将这些需求有机地结合成一个逻辑整体。定义数据库模式时不仅要定义数据的逻辑结构，比如数据记录由哪些数据项组成，数据项的名字、类型、取值范围等，而且还要定义数据之间的联系，定义与数据有关的安全性、完整性要求。
模式不涉及存储字段的表示，不涉及存储记录对列、索引、指针或其他存储的访问细节。如果模式以这种方式真正地实现了数据独立性，那么根据这些模式定义的外模式也会有很强的独立性。
数据库管理系统提供了模式定义语言（DDL）来定义数据库的模式。
3.?内模式
内模式也称为存储模式。内模式是对整个数据库的底层表示，它描述了数据的存储结构，比如数据的组织与存储方式，是顺序存储、B树存储还是散列存储，索引按什么方式组织、是否加密等。注意，内模式与物理层不一样，它不涉及物理记录的形式（即物理块或页，输入／输出单位），也不考虑具体设备的柱面或磁道大小。换句话说，内模式假定了一个无限大的线性地址空间，地址空间到物理存储的映射细节是与特定系统有关的，并不反映在体系结构中。
2.4.3 模式映像与数据独立性
数据库的三级模式是对数据的三个抽象级别，它把数据的具体组织留给DBMS，使用户能逻辑、抽象地处理数据，而不必关心数据在计算机中的具体表示方式与存储方式。为了能够在内部实现这三个抽象层次间的联系和转换，数据库管理系统在三个模式之间提供了以下两级映像（参见图2-11）：
外模式/模式映像。
模式/内模式映像。
正是这两级映像功能保证了数据库中的数据能够具有较高的逻辑独立性和物理独立性，使数据库应用程序不随数据库数据的逻辑或存储结构的变动而变动。
1.?外模式/模式映像
模式描述的是数据的全局逻辑结构，外模式描述的是数据的局部逻辑结构。对应于同一个模式可以有多个外模式。对于每个外模式，数据库管理系统都有一个外模式到模式的映像，它定义了该外模式与模式之间的对应关系，即如何从外模式找到其对应的模式。这些映像定义通常包含在各自的外模式描述中。
当模式改变时（比如增加新的关系、新的属性，改变属性的数据类型等），可由数据库管理员用外模式定义语句，调整外模式到模式的映像，从而保持外模式不变。由于应用程序一般是依据数据的外模式编写的，因此也不必修改应用程序，从而保证了程序与数据的逻辑独立性。
2.?模式/内模式映像
模式/内模式映像定义了数据库的逻辑结构与物理存储之间的对应关系，该映像关系通常被保存在数据库的系统表（由数据库管理系统自动创建和维护，用于存放维护系统正常运行的表）中。当数据库的物理存储改变了，比如选择了另一个存储位置，只需要对模式/内模式映像作相应的调整，就可以保持模式不变，从而也不必改变应用程序。因此，保证了数据与程序的物理独立性。
在数据库的三级模式结构中，模式（即全局逻辑结构）是数据库的中心与关键，它独立于数据库的其他层。设计数据库时也是首先设计数据库的逻辑模式。
数据库的内模式依赖于数据库的全局逻辑结构，它独立于数据库的用户视图（也就是外模式），也独立于具体的存储设备。内模式将全局逻辑结构中所定义的数据结构及其联系按照一定的物理存储策略进行组织，以达到较好的时间与空间效率。
数据库的外模式面向具体的用户需求，它定义在逻辑模式之上，独立于存储模式和存储设备。当应用需求发生变化，相应的外模式不能满足用户的要求时，就需要对外模式作相应的修改以适应这些变化。因此设计外模式时应充分考虑到应用的扩充性。
原则上，应用程序都是在外模式描述的数据结构上编写的，而且它应该只依赖于数据库的外模式，并与数据库的模式和存储结构独立（但目前很多应用程序都是直接针对模式进行编写的）。不同的应用程序有时可以共用同一个外模式。数据库管理系统提供的两级映像功能保证了数据库外模式的稳定性，从而从底层保证了应用程序的稳定性，除非应用需求本身发生变化，否则应用程序一般不需要修改。
数据与程序之间的独立性使得数据的定义和描述可以从应用程序中分离出来。另外，由于数据的存取由DBMS负责管理和实施，因此，用户不必考虑存取路径等细节，从而简化了应用程序的编制，减少了对应用程序的维护和修改工作。