# 老师视角的数据库设计检查清单

本清单面向《数据库系统概论》课程设计答辩，不以“工程上能跑”为唯一标准，而以“数据库设计是否完整、规范、可论证”为核心标准。

## 一、选题与范围

- 题目与实际实现范围一致，没有“题目很大、真正只做很少内容却说不清”的问题
- 明确说明本轮聚焦的子系统，而不是把所有历史模块都算进课程设计成果
- 所选业务具备一定复杂度，能体现多实体、多联系、多约束和多角色

## 二、数据库设计全过程

- 有需求分析，不是直接从代码或 SQL 开始
- 有概念结构设计，至少给出主要 E-R 图
- 有逻辑结构设计，明确关系模式、主键、外键、候选键
- 有物理结构设计，说明索引、存储与性能考虑
- 能说明从 E-R 图到关系模式的转换过程

## 三、规范化与关系理论

- 主要业务表至少能说明是否满足 3NF
- 若存在冗余字段，能说明为什么保留冗余
- 若为了性能保留冗余，必须说明如何保证一致性
- 能识别传递依赖、部分依赖和多对多拆分
- 不把“派生数据”“快照数据”“审计数据”误当作普通冗余

## 四、完整性约束

### 1. 实体完整性

- 每张核心表都有明确主键
- 主键设计稳定、简洁，不随业务变化频繁修改
- 应为非空的字段没有随意允许 `NULL`

### 2. 参照完整性

- 核心业务关系尽量有显式物理外键
- 外键删除策略明确：`RESTRICT`、`CASCADE`、`SET NULL` 有业务依据
- 不使用“逻辑外键”逃避核心关系约束
- 若故意不建物理外键，必须给出可答辩的原因

### 3. 用户定义完整性

- 合法取值范围通过 `CHECK`、`UNIQUE`、枚举等方式落库
- 状态字段与辅助字段的一致性尽量通过数据库约束体现
- 关键业务规则不只写在后端服务里
- 约束失败时数据库能直接拒绝非法数据

## 五、数据库对象是否丰富

- 不只有表，还能展示部分数据库对象的合理使用
- 至少包含以下几类中的多项：
  - 索引
  - 视图
  - 触发器
  - 数据库函数 / 存储过程
  - 约束
  - 审计表 / 历史表

## 六、事务与并发控制

- 能指出哪些操作必须放在事务中
- 能识别并发冲突风险，而不是只考虑单用户场景
- 对关键业务给出数据库层的一致性保证方案
- 至少有一个例子能说明“如果并发发生，会如何保证正确性”

## 七、查询与物理设计

- 核心查询有明确索引支撑
- 联合索引、部分索引不是随便建的，能说明对应查询场景
- 能展示 3 到 8 条典型 SQL，包括查询、统计或聚合
- 能说明为什么某些统计用事件表更合适

## 八、安全与权限

- 能说明数据库与应用之间的职责边界
- 至少讲清楚权限模型，不是只讲登录页
- 若使用 RLS、审计日志等能力，要说明当前是否真正落地
- 不把“未来可能做”说成“已经完成”

## 九、文档与答辩表达

- 有数据字典：字段名、类型、含义、是否可空、默认值、约束
- 有核心表之间的联系说明
- 有异常输入测试或约束失败示例
- 能用数据库术语解释设计，而不是只用前后端术语

## 十、优秀作品常见加分点

- 使用闭包表、排斥约束、复合外键、约束触发器等较强数据库特性
- 对“范式”和“必要冗余”讲得清楚
- 对删除策略、历史保留、审计追踪有完整说明
- 有意地把关键规则下沉到数据库，而不是全部放在业务代码

## 十一、常见扣分点

- 只有页面和接口，没有像样的数据库设计过程
- 关系主要靠应用层维护，数据库里外键很少
- 结构里冗余字段很多，但说不清为什么
- 大量业务规则只写在后端 `if` 中
- 报告里几乎没有主键、外键、约束、索引与事务分析
- 把“用了某个云服务”误当成数据库设计亮点