DBPA · 1.3

三级模式结构

逻辑独立性和物理独立性

VER. 2608 Built with impress.js

学习目标

应用读取外模式，模式组织关系，内模式管理记录和索引

01区分型与值、模式与实例
02说明外模式、模式和内模式分别描述什么，以及它们的数量关系
03解释两级映像怎样连接三级模式
04判断一个变化发生在哪一层、需要调整哪一级映像
05判断加表或加索引后要改哪一级对应关系，以及原查询语句是否可以不改

2/18

LEARNING OBJECTIVES

型和值：结构描述和具体状态

型规定表示方式，值说明实际内容

结构描述（型）	一次具体赋值（值）
学生（学号、姓名、性别、生日）	（180003、王敏、女、2008-08-01）

型 Type

说明一类数据具有怎样的结构和属性

值 Value

给某一类数据的一次具体赋值

把“王敏”换成“李明”只换了值；给所有学生新增“专业”字段才改变型

Takeaway

可以类比于 Java 语言的“类”和“实例”

3/18

TYPE AND VALUE

模式描述结构，实例描述特定时刻的状态

模式相对稳定，实例会随数据库更新而变化

模式 Schema

描述数据库中全体数据的逻辑结构、联系以及安全性与完整性要求

例如，模式规定 Student、Course 等关系的结构、联系与约束

实例 Instance

是模式的一个具体值，它是数据库在某一时刻的数据状态

例如，2026 年秋季的学生、课程和选课记录是一个实例，它会变化

Takeaway

模式相对稳定，实例随更新变化

4/18

SCHEMA AND INSTANCE

判断：实例更新还是模式修改

看数据库的结构描述有没有改变

变化情境	判断	需要检查什么
新增一条选课记录	实例更新	模式和映像不变
修改一名学生的成绩	实例更新	模式和映像不变
全局模式新增培养方案关系	模式修改	检查相关外模式/模式映像
全局模式新增一个属性	模式修改	检查相关外模式/模式映像

Takeaway

同一个模式可以有许多不同实例；实例更新不等于模式修改

5/18

SCHEMA STABILITY

三级模式：用户视图、全局结构和存储

学生和课表应用看课表视图；模式组织全体关系；内模式规定记录页和索引

Three-schema architecture connecting external schemas, the conceptual schema, and the internal schema

外模式 → 外模式/模式映像 → 模式 → 模式/内模式映像 → 内模式

Takeaway

三级模式分别描述用户视图、全局逻辑结构和内部存储方式

6/18

THREE SCHEMA LEVELS

模式 Schema 组织全局逻辑结构

模式规定 Student、Course 和 Enrollment 的字段、联系和合法取值

数据库中的关系 Student、Course、Teaching、Enrollment 是模式中的业务对象结构，不是四个模式

模式负责全局的数据结构、数据操作和完整性约束

一个数据库对应一个模式

全体数据的逻辑结构、联系和约束

不负责物理细节

不规定记录如何写入物理存储器

Takeaway

模式描述全体数据的逻辑结构和联系，不写记录位于哪个物理页

7/18

CONCEPTUAL SCHEMA

外模式 External Schema

面向具体用户和应用，描述局部数据的逻辑结构

提供不同视图

学生看到自己的课表与成绩

教师看到所授教学班

教务处看到更完整的业务数据

外模式不是摘录

在不同外模式中，同一数据可能有不同的名称、结构、类型、长度或保密级别

是应用的逻辑入口

一个应用往往依据一个外模式工作

同一外模式也可以供多个应用使用

外模式可以缩小可见范围，有助于安全

8/18

EXTERNAL SCHEMA

内模式 Internal Schema 描述物理存储

描述记录、索引和物理页在数据库内部怎样组织

如何组织记录

采用堆存储、顺序存储还是聚簇存储

如何组织索引

采用 B+ 树索引还是哈希索引

物理表示是怎样的

记录是否压缩或加密，怎样安排物理页

内模式解决数据库内部如何组织和表示数据的问题

Takeaway

一个数据库只有一个内模式，用户不必直接管理存储细节

9/18

INTERNAL SCHEMA

区分三级模式

每一级模式描述什么、面向谁以及有多少个

层次	描述什么	面向谁	数量
外模式	局部数据的逻辑结构	用户与应用	多个
模式	全体数据的逻辑结构与联系	所有用户共享	一个
内模式	数据的物理结构与存储方式	DBMS 与 DBA	一个

Takeaway

用户看到什么、数据逻辑怎样组织、数据怎样存储

10/18

SCHEMA COMPARISON

两层映像

课表视图对应 Course、Teaching 等关系，这些关系再对应记录页和索引

外模式→模式→内模式

外模式/模式映像

每个外模式与全局逻辑结构的对应

模式变化时，原外模式尽量保持稳定

一个外模式对一个外模式/模式映像

模式/内模式映像

定义全局逻辑结构与内部存储结构之间的对应关系

内模式变化时，让模式保持稳定

11/18

TWO MAPPINGS

模式变化时

只要原外模式仍能表达原应用需求，原应用就可能继续工作

01

模式变化

全局模式增加新关系：培养方案

02

映像调整

维护外模式/模式映像，原学生课表外模式继续对应模式

03

外模式稳定

原外模式仍只提供课表和成绩

04

应用稳定

原有程序不必因新增关系而重写

新增“培养方案”关系后，DBA 检查并维护课表视图到全局模式的对应；原课表字段和查询需求不变，所以原程序不必重写

12/18

LOGICAL INDEPENDENCE

内模式变化时

只要逻辑结构和应用需求不变，上层结构和应用就可以保持稳定

01

内模式变化

为成绩查询增加 B+ 树索引

02

映像调整

更新模式/内模式映像，让逻辑模式继续对应新的物理组织

03

模式稳定

成绩查询的逻辑结构不变

04

应用稳定

程序仍通过原外模式提交同样查询需求

物理细节由 DBMS 管理

用户说明要做什么，数据库管理系统决定怎样找到和处理记录

13/18

PHYSICAL INDEPENDENCE

对照不同变化判断层次和映像

区分数据行、逻辑结构、用户视图或存储的变化，再判断映像和查询是否要改

情境	变化起点	调整位置	判断
新增一条选课记录	实例	数据本身	不是模式变化
增加成绩索引	内模式	模式/内模式映像	物理独立性
新增培养方案关系	模式	外模式/模式映像	逻辑独立性
增加课程完成度功能	外模式与应用	新功能与视图	业务变化，修改应用

Takeaway

先判断哪一层的具体对象变了，再判断哪一级映像需要调整

14/18

CHANGE JUDGMENT

案例：电商系统同时发生三种变化

分析每一项变化，再判断改模式、映像还是应用

先找变化起点，再找需要调整的映像，最后确认哪些对象保持稳定

全局结构变化

订单新增售后工单数据，但对顾客不可见

顾客仍然只需要原有订单摘要，顾客外模式和原应用保持不变

内部存储变化

订单时间和用户编号增加联合索引

调整模式/内模式映像后，模式、外模式和应用不必改变

业务需求变化

新增售后处理功能

新的业务需求，需要新的或修改后的外模式与应用；原有映像不能吸收这个变化

15/18

CASE JUDGMENT

用层次和映像追踪数据库变化

加逻辑关系时检查外模式/模式映像，换索引时检查模式/内模式映像

模式与实例

模式描述结构，实例描述某时刻的状态

新增选课记录是实例变化。为学生表添加一个新属性是模式变化，会影响所有实例

三级模式

外模式面向用户，模式组织全局逻辑，内模式描述物理存储

数量关系是多个外模式、一个模式、一个内模式

数据独立性

映像能吸收不改变原应用需求的部分逻辑和存储变化

判断变化层次、要调整的映像和依然保持稳定的对象

Takeaway

只有原字段和原业务需求没变，原查询才可能通过调整映像继续使用

16/18

SECTION REVIEW

本节知识地图

17/18

KNOWLEDGE MAP

本节问题

01如何理解模式与实例的区别？
02为什么一个数据库可以有多个外模式，却只有一个模式和一个内模式？
03使用教务系统为例，解释三级模式
04外模式/模式映像与模式/内模式映像的作用是什么？
05增加索引为什么属于物理独立性？
06教务系统给成绩增加索引，是否需要改原应用程序？为什么？

18/18

SECTION QUESTIONS