relational-database-design

关系数据库设计

一种与 RDBMS 无关的逻辑方法，用于设计健全的关系数据库——说明架构会带来哪些决策，以及严谨的逻辑设计方法如何解决这些问题，便于 Agent 在设计或审查架构时应用。每条规则都指出并纠正一个具体的错误默认做法；对于模型本来就能正确处理的事项，不另设规则。

整套方法首先生成逻辑结构——组织信息所需的表、字段、键、关系和完整性规则，并有意将其与任何特定 RDBMS 产品或物理性能方面的考量分离。若严格遵循，就能得到完全规范化的表，无需把规范化视为单独的后端阶段。

适用场景

• 根据需求设计新的关系架构
• 审查或重构现有架构，确保其结构健全
• 处理重复组、多值／多部分字段或冗余数据
• 为表选择候选键、主键和外键
• 建模一对一、一对多、多对多或自引用关系
• 决定删除规则（限制、级联、置空、拒绝、设为默认值）和参与约束
• 决定约束应归属何处——字段规范、关系、验证表或应用程序
• 诊断会重复、丢失或损坏数据的架构

本技能涵盖逻辑设计，不涵盖 SQL 方言、索引、分区、查询调优或分析／维度（星型架构）建模——这些属于物理／实现层面的事项，应在逻辑设计健全后处理。

规则类别

#	类别	前缀	涵盖内容
1	设计流程与需求	proc-	在选择 RDBMS 前进行逻辑设计，遵循设计顺序，从使命与分析出发，规范化内置于设计之中
2	表结构	tbl-	每张表只表示一个主题，理想的表，不使用引用字段，尽量减少冗余
3	字段设计	fld-	理想的字段、单一值、原子字段、不存储计算结果、名称清晰
4	键	key-	候选键元素、每张表一个主键、外键与主键保持一致、稳定且不敏感的键
5	关系	rel-	多对多关系使用联结表、外键位置、删除规则、参与约束、自引用关系
6	数据完整性、规则与视图	intg-	四种完整性级别、字段规范、数据库规则与应用程序规则、验证表、视图
7	反模式	anti-	平面文件、把电子表格当作数据库、由 RDBMS 驱动的设计，以及何时可以合理地变通
8	术语	term-	数据与信息、空值、核心关系数据库术语

快速参考

1. 设计流程与需求

• proc-follow-the-design-sequence — 后续步骤依赖前序步骤；跳过步骤会导致完整性不佳
• proc-design-logically-before-choosing-rdbms — 不考虑 RDBMS，先设计逻辑结构；之后再选择并实现
• proc-start-from-mission-and-objectives — 使命声明和目标界定数据库范围，并揭示其主题
• proc-analyze-and-interview-before-designing — 在自行设计字段前，先分析当前系统并访谈用户和管理层
• proc-normalization-is-built-in — 理想字段、理想表和键的指南会生成规范化的表；规范化不是单独的阶段

2. 表结构

• tbl-one-subject-per-table — 每张表恰好表示一个主题（对象或事件）
• tbl-ideal-table-checklist — 检验表结构是否合理的六项检查
• tbl-no-reference-fields — 不要为了方便报表而从其他表复制字段
• tbl-minimize-redundant-data — 外键驱动的冗余可以接受；其他冗余应尽可能减少

3. 字段设计

• fld-ideal-field-checklist — 检验字段是否合理的检查
• fld-store-single-values-not-lists — 多值字段应拆分为独立的表
• fld-keep-fields-atomic — 将多部分／复合字段分解为每个不同项各一个字段
• fld-derive-dont-store-calculated-values — 计算结果应放在视图中，而不是存储为字段
• fld-clear-singular-field-names — 每个特征使用一个明确且单数的名称

4. 键

• key-candidate-key-elements — 检验字段（或字段集）是否符合候选键要求
• key-one-primary-key-per-table — 每张表恰好有一个非空、唯一且稳定的主键
• key-foreign-key-mirrors-its-primary-key — 名称相同、类型规范一致，且值取自被引用的主键
• key-prefer-stable-non-sensitive-keys — 键值应很少变化，且不得泄露敏感数据

5. 关系

• rel-junction-table-for-many-to-many — 使用以两个外键为键的关联表来解析 M:N 关系
• rel-foreign-key-on-the-many-side — 一对多关系中的外键位于多的一侧
• rel-deletion-rule-guards-orphans — 每种关系都要设置删除规则；默认限制删除
• rel-participation-encodes-constraints — 通过必选／可选和基数（min,max）体现实际业务限制
• rel-self-referencing-relationships — 表与自身关联时，需要使用名称明确不同的外键

6. 数据完整性、规则与视图

• intg-four-levels-of-data-integrity — 综合保障表、字段、关系和业务规则的完整性
• intg-field-specifications — 明确规定每个字段的通用、物理和逻辑要素
• intg-database-vs-application-rules — 在架构中强制执行结构规则；在应用程序中处理条件规则和派生规则
• intg-validation-tables-for-allowed-values — 使用查找表优于硬编码值列表
• intg-views-for-derived-and-restricted-data — 使用数据视图、汇总视图和验证视图，而不是增加额外的存储字段

7. 反模式

• anti-flat-file-design — 什么是把所有内容都塞进一个表的结构，以及如何识别它
• anti-spreadsheet-as-database — 电子表格布局不是关系模式
• anti-rdbms-driven-design — 不要让你熟悉的产品左右设计
• anti-bend-rules-only-deliberately — 仅有的两个合理破例理由，以及如何记录

8. 术语

• term-data-versus-information — 数据会被存储；信息是经过赋予意义、用于呈现的数据
• term-null-is-unknown-not-zero — null 表示缺失或未知值，而非零或空白
• term-relational-vocabulary — 键是逻辑概念，索引是物理结构；视图不是表

使用方法

遇到相关决策时，请阅读对应的参考文件。每条规则都会指出它要纠正的错误默认做法，然后展示规范做法（仅当错误做法确实容易导致问题时，才会对比错误与正确做法）。

• 章节定义 — 类别结构
• 规则模板 — 用于添加新规则
• AGENTS.md — 自动构建的所有规则目录

参考文件

文件	说明
references/_sections.md	类别定义及排序
assets/templates/_template.md	新规则模板
metadata.json	版本和来源参考