关系型数据库设计总结

一、设计阶段流程

1. 规划阶段：主要工作是对数据库的必要性和可行性进行分析。确定是否需要使用数据库，使用哪种类型的数据库，使用哪个数据库产品。

2. 概念阶段：主要工作是收集并分析需求。识别需求，主要是识别数据实体和业务规则。对于一个系统来说，数据库的主要包括业务数据和非业务数据，而业务数据的定义，则依赖于在此阶段对用户需求的分析。需要尽量识别业务实体和业务规则，对系统的整体有初步的认识，并理解数据的流动过程。理论上，该阶段将参考或产出多种文档，比如“用例图”，“数据流图”以及其他一些项目文档。如果能够在该阶段产出这些成果，无疑将会对后期进行莫大的帮助。

   记录用户需求时，可以使用一些技巧，当然这部分内容有些可能会超出数据库设计人员的职责：

   • 努力维护一系列包含了系统设计和规格说明信息的文档，如会议记录、访谈记录、关键用户期望、功能规格、技术规格、测试规格等。
   • 频繁与干系人沟通并收集反馈。
   • 标记出你自己添加的，不属于客户要求的，未决内容。
   • 与所有关键干系人尽快确认项目范围，并力求冻结需求。

   此外，必须严谨处理业务规则，并详细记录。在之后的阶段，将会根据这些业务规则进行设计。当该阶段结束时，你应该能够回答以下问题：

   • 需要哪些数据？
   • 数据该被怎样使用？
   • 哪些规则控制着数据的使用？
   • 谁会使用何种数据？
   • 客户想在核心功能界面或者报表上看到哪些内容？
   • 数据现在在哪里？
   • 数据是否与其他系统有交互、集成或同步？
   • 主题数据有哪些？
   • 核心数据价值几何，对可靠性的要求程度？

   并且得到如下信息：

   • 实体和关系
   • 属性和域
   • 可以在数据库中强制执行的业务规则
   • 需要使用数据库的业务过程
3. 逻辑阶段：主要工作是绘制E-R图，或者说是建模。主要就是识别实体关系，其次还应该考虑属性的域（值类型、范围、约束）。
4. 实现阶段：主要针对选择的RDBMS定义E-R图对应的表，考虑属性类型和范围以及约束。
5. 物理阶段：是一个验证并调优的阶段，是在实际物理设备上部署数据库，并进行测试和调优。

二、设计原则

1. 降低对数据库功能的依赖：功能应该由程序实现，数据库仅仅负责数据的存储，以达到最低的耦合。

2. 定义实体关系的原则：
   当定义一个实体与其他实体之间的关系时，需要考量如下：

   • 牵涉到的实体 识别出关系所涉及的所有实体。
   • 所有权 考虑一个实体“拥有”另一个实体的情况。
   • 基数考量一个实体的实例和另一个实体实例关联的数量。

   关系与表数量：

   • 描述1:1关系最少需要1张表。
   • 描述1:n关系最少需要2张表。
   • 描述n:n关系最少需要3张表。

3. 列意味着唯一的值：如果表示坐标（0,0），应该使用两列表示，而不是将“0,0”放在1个列中。

4. 列的顺序：习惯上采用“主键 + 外键 + 实体数据 + 非实体数据”这样的顺序对列进行排序显然能得到比较好的可读性。
5. 定义主键和外键：数据表必须定义主键和外键（如果有外键）。在性能没有出现问题时应该保留外键，而即便性能真的出现问题，也应该对SQL文进行优化，而非放弃外键约束。
6. 尽量不允许NULL：
   关于NULL我们需要了解它的几个特性：
   
   • 任何值和NULL拼接后都为NULL。
   • 所有与NULL进行的数学操作都返回NULL。
   • 所有使用NULL值的情况，都可以通过一个有意义的值的表示，这样有利于代码的可读性和可维护性，并能从约束上增强业务数据的规范性。
   • NULL值到非NULL的更新无法做到原地更新，更容易发生索引分裂，从而影响性能。
   • NULL值在timestamp类型下容易出问题，特别是没有启用参数explicit_defaults_for_timestamp。
   • NOT IN、!= 等负向条件查询在有 NULL 值的情况下返回永远为空结果，查询容易出错。
   • Null 列需要更多的存储空间：需要一个额外字节作为判断是否为 NULL 的标志位。

7. 规范化—范式：范式将帮助我们来保证数据的有效性和完整性。

   • 目的：
     
     • 消灭重复数据。
     • 避免编写不必要的，用来使重复数据同步的代码。
     • 保持表的瘦身，以及减从一张表中读取数据时需要进行的读操作数量。
     • 最大化聚集索引的使用，从而可以进行更优化的数据访问和联结。
     • 减少每张表使用的索引数量，因为维护索引的成本很高。
   • 推荐做法：
     
     • 尽可能地遵守上述规范化原则。
     • 所有属性描述的都应该是体现被建模实体的本质的内容。
     • 至少必须有一个键，它唯一地标识和描述了所建实体的本质。
     • 主键要谨慎选择。
     • 在逻辑阶段能做多少规范化就做多少（性能不是逻辑阶段考虑的范畴）。

8. 选择数据类型：类型选择的最基本规则是选择满足需要的最轻的类型，因为这样查询更快。

四、命名规则

1. 表：“模块名_表名”。表名最好不要用复数，原因是在使用ORM框架开发时，代码生成器根据DB生成类定义，表生成了某个实例的类型定义，而不是实例集合。表名不要太长。
2. 字段：bool类型用“Is”、“Can”、“Has”等表示；日期类型命名必须包含“Date”；时间类型必须包含“Time”。
3. 存储过程：使用“proc_”前缀。
4. 视图：使用“view_”前缀。
5. 触发器：使用“trig_”前缀。