DBPA · 7.3

逻辑、物理设计与实施维护

把概念模型落到可运行的数据库系统

VER. 2608.2 Built with impress.js

学习目标

E-R 图需要转换为关系模式，再用运行证据评价物理和实施方案

01按联系类型把 E-R 图转换为关系模式
02标出转换结果中的主码、复合码、外码和联系属性
03用依赖、范式、分解和事务需求优化逻辑模型
04根据工作负载选择索引、哈希或聚簇，并说明代价
05用时间、空间、吞吐和维护证据评价物理方案
06说明装载、应用调试、试运行、恢复和维护如何形成反馈闭环

2/19

LEARNING OBJECTIVES

逻辑设计：基本 E-R 图转为目标模型

先用一个 m:n 示例说明属性、码、外码和联系属性如何落位

Takeaway

学生(学号 PK, 姓名, 所在学院) 教学班(教学班号 PK, 课程号 FK, 开课学期) 选课(学号 PK/FK, 教学班号 PK/FK, 成绩)

选课主码为（学号，教学班号）；两列分别作为外码，指向学生和教学班

3/19

LOGICAL DESIGN

联系类型决定关系转换方式

联系属性和参照关系不能在转换中丢失

E-R 元素	关系落点	码／外码动作	选择判据
实体型	一个关系模式	实体码成为主码	实体属性直接成为关系属性
1:1 联系	独立关系，或并入一端	独立关系时两端码为候选码；合并时加入另一端外码	参与约束、联系属性、空值与访问方式
1:n 联系	独立关系，或并入 n 端	n 端加入 1 端主码作外码；独立关系通常以 n 端码作码	联系属性与访问方式
m:n 联系	独立关系	两端码是外码，通常共同组成复合主码	联系本身承载事实
多元联系	独立关系	各参与码和联系属性进入；候选码由业务语义判断	事实是否由多端共同确定

Takeaway

候选码不一定都选作主码；联系属性不能丢失，外码是否可空要由参与约束决定

4/19

TRANSFORMATION RULES

转换后用依赖与事务评价逻辑模型

规范化提供理论边界，合并、分解和适度冗余是设计动作

先诊断

先写出数据依赖，识别部分、传递和多值依赖

再选结构

再按事务选择水平或垂直分解，也可合并或保留适度冗余

检查保真

检查分解是否无损连接并保持依赖

最后评价

最后比较连接代价、更新频率、事务路径和维护成本

Takeaway

规范化等级要与语义约束和工作负载共同评价

5/19

LOGICAL OPTIMIZATION

分解要兼顾还原与约束维护

拆分关系前先明确按什么拆，拆分后再检查结果是否可靠

分解方式	关系代数记法	适合的问题与风险
水平分解	`Ri = σpi(R)`	按元组条件分开；要防止遗漏或不必要重叠，重构通常靠并集
垂直分解	`Ri = πK∪Ai(R)`	按属性集合分开；公共码必须保留，重构依赖连接

无损连接

无损连接要求重新连接子关系后只能得到原关系，不能产生伪元组

依赖保持

依赖保持要求重要函数依赖尽量能在子关系中局部检查，不必每次都回到全局连接

Takeaway

Student(Sno, Name, Dept, BirthDate, Address) 可按事务拆成 StudentCore(Sno, Name, Dept) 与 StudentProfile(Sno, BirthDate, Address)，但要保留公共码并检查连接代价

6/19

DECOMPOSITION CHECKS

用户外模式让全局结构适应不同用户

视图可以同时简化使用和收紧可见范围

需要	视图做法	结果
用户习惯不同	提供别名或重排列	不改全局列名
权限范围不同	教师视图隐藏学生身份；学生视图只展示本人记录	收紧可见范围
查询过于复杂	封装选课与课程查询	简化常用操作

Takeaway

视图表达用户外模式；实际谁可以使用视图，仍由目标 DBMS 的权限或安全策略控制

7/19

USER SCHEMAS

物理设计：把工作负载转为存取路径

物理设计依赖目标 DBMS 的能力、事务工作负载和响应目标

工作负载+DBMS 能力→候选物理方案→时间、空间、吞吐与维护评价→保留、调整，或回退到逻辑设计

8/19

PHYSICAL DESIGN

先分析事务，再决定索引和存储

一个字段是否建索引不能脱离访问模式

事务信息	需要记录	影响选择
查询关系	访问哪些表和视图	存取路径
选择与连接	条件属性、等值或范围、选择性	B+ 树、哈希和组合索引候选
投影与更新	读取列、修改列和更新频率	物理维护代价；垂直分解另作逻辑判断
频率与时限	关系规模、增长、调用频率和响应目标	响应、吞吐和存储目标

Takeaway

按学号查询选课并在开学高峰写入选课表时，索引选择不能只看“学号是不是主码”，还要看选择性、频率和更新代价

9/19

TRANSACTION PROFILE

B+ 树、哈希和聚簇服务不同访问模式

选择重点是收益与维护代价的平衡

B+ 树

B+ 树适合作为范围、排序、聚集函数或连接条件的候选路径

哈希

哈希适合等值查找或等值连接，不适合范围查找

聚簇

聚簇把相同键的元组集中存放，适合主要访问路径

在当前聚簇模型中，一个关系只能参加一个聚簇；B+ 树、哈希和聚簇的具体实现与参数要核对目标 DBMS

10/19

ACCESS METHODS

索引不是越多越好

每条索引都可能增加写入和维护成本

观察	可能收益	可能代价
高频且有选择性的条件	可能更快定位元组	更新时维护索引
连接条件	可能减少连接代价	占用存储空间
多列组合条件	组合索引可能匹配常用路径	列顺序与选择性需按事务评价
高频更新关系	少量关键索引	过多索引拖慢写入
聚簇码集中访问	减少物理块读取	元组移动和索引重建

Takeaway

主码和外码是逻辑约束；是否为外码另建索引，是另一项物理设计选择

11/19

INDEX TRADEOFF

存储安排要同时考虑负载、评价证据和 DBMS 边界

表、索引、日志和备份的安排必须结合访问与变化特征

01工作负载：记录事务、频率、响应目标和更新特征
02物理方案：选择索引、哈希、聚簇、存储位置和系统参数
03评价证据：比较响应时间、吞吐量、空间利用率和维护代价
04回退判断：达标后实施；不达标时调整物理设计，必要时返回逻辑设计

存储布局、缓冲区和块大小受目标 DBMS 的能力与参数边界约束，不能脱离产品直接承诺

12/19

STORAGE PLAN

实施：把设计变成可运行的 DBMS 对象

数据转换和应用程序开发要与模式实现同步

目标模式实现 ├─ 数据抽取、清洗、映射、装载与校验 └─ 应用编码与调试 ↓ 联合试运行

装载与应用开发同步推进，在联合调试处汇合；目标模式是目标 DBMS 可接受的结构描述

13/19

IMPLEMENTATION

试运行：验证功能、性能与恢复

试运行把纸面假设变成可测量证据，合格后才进入正式运行

阶段	观察证据	不达标时回到哪里
小批量装载	清洗映射、主外码和完整性通过率	数据转换与映射
应用联合调试	业务场景、事务结果和错误处理	应用程序，必要时逻辑设计
性能评价	响应时间、吞吐量和空间使用	物理设计，必要时逻辑设计
恢复演练	能否回到一致状态、恢复时间是否可接受	转储与恢复方案

Takeaway

试运行流程：小批量装载 → 联合调试 → 实测 → 修正 → 复测 → 合格后扩大装载并进入正式运行

14/19

PILOT RUN

运行维护是设计工作的延伸

数据、用户和业务变化会持续改变设计约束；DBA 用运行证据触发调整

恢复

制定转储和恢复计划

控制

根据用户和业务变化更新安全和完整性规则

监督

采集性能数据并分析瓶颈

调整

按需重组或重构数据库

监测→分析→调整配置、索引或存储→重组／重构→再评价

15/19

MAINTENANCE

重组和重构解决不同层次的变化

先判断问题在物理存储还是模式语义

维护动作	改变什么	典型场景
重组	按原物理设计重新整理实际存储，不改逻辑结构和物理设计	回收空间、减少指针链
重构	部分修改模式或内模式	增删属性、表或索引，改变数据类型
新系统评估	变化超出局部重构能力	业务变化已改变系统生命周期

Takeaway

重组解决存储状态变坏；重构响应业务语义变化；变化过大时才评估新系统

16/19

REORGANIZE OR RESTRUCTURE

用反馈闭合逻辑、物理与运行设计

逻辑语义、访问路径和运行证据需要相互反馈

逻辑产出

关系模式、主码／外码、分解和外模式构成逻辑产出

物理产出

工作负载画像、存取方法、存储安排和评价指标构成物理产出

运行产出

装载、应用调试、试运行和恢复结果支撑运行与维护判断

Takeaway

工作负载和运行反馈共同决定物理设计是否适合

17/19

RECAP

本节知识地图

18/19

KNOWLEDGE MAP

本节问题

01给定含 1:1、1:n、m:n 和多元联系的 E-R 子图，如何写出关系模式并标注主码、外码和联系关系的复合码？
02规范化、水平分解、垂直分解和用户外模式分别解决什么问题？无损连接与依赖保持分别有什么作用？
03给定查询条件、选择性、更新频率和响应目标，如何选择 B+ 树、哈希、聚簇或不增加索引，并写出一个维护代价？
04根据装载、功能、性能或恢复失败的试运行证据，应回到数据转换、应用、逻辑设计、物理设计还是恢复方案？如何区分重组、重构和新系统评估？

19/19

CHECK YOUR UNDERSTANDING