数据库设计

一、数据库设计的第一性原理（Principles）

1. 数据库设计的本质

数据库设计的本质目标只有一个：

用结构化的数据模型，稳定、低歧义地表达现实世界中的对象、关系与约束。

由此衍生出三大核心问题：

  1. 现实世界中有哪些“对象”？（实体）
  2. 对象之间如何发生关联？（关系）
  3. 哪些规则在任何时刻都必须成立？（约束）

数据库设计 = 现实建模 + 约束形式化

2. 数据库设计中的核心矛盾

维度矛盾描述
数据冗余冗余可提升性能，但破坏一致性
约束表达强约束提升正确性，但降低灵活性
结构稳定稳定结构利于长期演进，但难以适应快速变化

所有设计技术（ER、范式、分解）本质上都是在这些矛盾中寻找平衡点。

3. 为什么需要“规范化”

规范化（范式）的根本动机不是“数学优雅”，而是：

消除由于设计不当而产生的数据异常（Anomalies）

这些异常包括：

范式 = 用结构约束，避免异常的系统性方法

二、数据库设计的认知主干（Cognitive Backbone）

本节回答一个关键问题：ER 模型、函数依赖、范式、分解之间究竟是什么关系？

1. 认知主干链路

现实世界   ↓ER 模型（对象 & 关系）   ↓候选码 / 业务约束   ↓函数依赖（约束形式化）   ↓范式（异常消除标准）   ↓模式分解（结构重构）

函数依赖是连接“现实约束”与“范式理论”的桥梁。

2. 设计阶段的层次划分

层次关注点是否稳定
概念层现实对象、关系、语义高
逻辑层关系模式、键、依赖中
物理层存储、索引、性能低

设计应始终遵循：先稳定抽象，再做实现优化。

三、概念设计：ER 建模的设计哲学

1. ER 模型的核心抽象

概念本质含义
实体现实中可独立识别的对象
属性描述实体状态的特征
联系实体之间发生的事实
约束永远必须成立的规则

ER 模型的价值在于：在不考虑数据库实现的前提下，冻结业务语义。

2. 实体 vs 属性：设计原则

判断原则：

能独立存在并被多方引用的，应建模为实体。

3. 实体 vs 联系：语义区分

当你在描述一个“行为 / 事件”，而非状态时，应使用联系集。

4. 扩展 ER 的本质

特性解决的问题
ISA（特化/概化）分类与继承
弱实体依赖存在
聚集联系之间的关系

这些都是为了解决：现实语义复杂度 > 基本 ER 表达能力 的问题。

四、逻辑设计：从 ER 到关系模型

1. 转换的本质

逻辑设计不是“翻译”，而是 约束保持的结构映射。

核心目标：

2. 主码的哲学

主码的本质是：

对现实世界中“唯一性”的最小抽象表达

错误的设计往往源于：

3. 联系模式设计的原则

联系类型主码策略
多对多各参与实体主码并集
一对多多的一方
一对一任意一方（视语义）

五、规范化理论：范式的真正含义

1. 范式不是等级，而是约束强度

范式消除的问题
1NF非原子值
2NF部分依赖
3NF传递依赖
BCNF非键决定属性

范式越高，设计自由度越低，结构约束越强。

2. 函数依赖的真实角色

函数依赖不是数学游戏，而是：

现实业务规则在关系模型中的形式化表达。

3. BCNF vs 3NF 的设计权衡

维度BCNF3NF
异常控制最强足够
依赖保持不保证保证
实现复杂度高中

工程实践中，3NF 是最常见的理性选择。

六、分解：重构而不丢失信息

1. 分解的三个目标

这是一个 不可能三角，必须取舍。

2. 分解是“重构”，不是“拆表”

分解的本质：

在不改变语义的前提下，重排结构。

七、性能与反范式：工程现实

1. 何时可以反范式

反范式不是否定理论，而是：

在理解代价后做出的工程决策。

关联内容（自动生成）