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