关系型数据库设计总结

一、设计阶段流程
  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_”前缀。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值