11种重要的数据库设计规则

十一种重要的数据库设计规则十一种重要的数据库设计规则 2012 年 4 月 4 日 作者 Shivprasad 2010 年 4 月 15 日 译者 lixh 译者话 我在网上无意中看到这篇文章 是中文版的 出自 CSDN 当时我想收藏 但版主声明 了转发需要他本人同意 所以我决定重新翻译此英文原文 这篇文章写的真不错 可以好 好的揣摩一下作者的深意 唯一让我感觉到不舒服的地方是作者太过方言化了 以至于部 分句子我家的专业翻译也没弄明白 由于本人能力有限 此文章只做参考 建立您阅读原 文 英文原文地址 http www c database designing rules Introduction 这篇文章将描述 11 种重要的数据库设计规则 简介简介 在读这篇文章之前 让我确认一下 我不是数据设计方面的大师 如下所示的十一点 是我经过学习项目所获得到的经验 我个人认为 在数据库设计过程中对我来说帮助很大 欢迎任何批评 我写这个完整的文章原因是 当开发者座下来设计一个数据库时 他们趋向于三种常 规模式 like a silver bullet 没翻译成功 不知道是什么意思 应该是根深蒂固的意思吧 他们常常认为常规化设计是唯一的途径 由于这种心态 修改问题 原文 hit road blocks 作为项目推进的方法 如果你是一个新的常规化设计 则点击观看 3 种常规模式 这里详细介绍了所有三 种常规模式 我们所说 所做的标准化规则 是非常重要的准则 but taking them as a mark on stone is calling for troubles 没翻译好 但是在使用它们存在着顽固的调用麻烦 接下来是 我自己理解的 11 条规则 记得在前面提到 这 11 条规则用于数据库设计 规则规则 1 应用的本质 应用的本质 OLTP 或或 OLAP 当你开始你的数据库设计时 第一件事是分析你设计的应用本质是什么 是事务型还 是分析型 你会发现许多开发者默认使用常规化的规则 而不考虑应用的本质 最后考虑 性能与定制问题 说到这里 是基于事务性和基于分析性两种方法 让我们来理解这两种 方法 Transactional 事务型 事务型 在这类应用中 用户最感兴趣的是 CRUD Create Retrieve Update Delete 即创建 查询 更新和删除记录 这类数据 库的正式命名为 OLTP On Line Transaction Processing 在线事务处理 Analytical 分析型 分析型 在这类应用中 用户最感兴趣的是分析 报告 预测等 这类 数据库很少用到插入与更新操作 这里主要的目的是尽可能快速的获取和分析数据 这类 数据库正式命名为 OLAP On Line Analytical Processing 在线分析处理 换句话说 如果你认为插入 更新或删除更重要 则使用常规化的表单设计或者建立 一个简单的非常规化的数据结构 下面是一个简单的图表 左边的表显示了名称 Name 和地址 Address 是应用非 规范化结构创建出来的一个简单地常规化表单 规则规则 2 数据进行逻辑分块 使你的生活更简单 数据进行逻辑分块 使你的生活更简单 这个规则实际上是从第一范式演变过来的第一种规则 违反这种规则的第一种模式是 如果你查询使用了太多字符串解析功能 像子串 字符索引等 可能需要应用此规则 例如 如下表所示 其中有学生的名字 Student Name 如果你想查询学生的名字包 含 Koirala 而没有 Harisingh 你可以想像使用什么方法可以实现 所以更好的方法是打破这一字段 进行更多的逻辑分块 所以我们能写出最简洁 高 效的查询方法 规则规则 3 不要过多的使用规则 不要过多的使用规则 2 开发者们思维很单一 如果你告诉他这个方法 他们会一直这样做下去 过度使用它 会导致不必要的后果 这也适用于刚刚谈到的规则 2 当你考虑分解时 你会停顿一下 问自己是否需要这样做 分解必须具有一定逻辑性 例如 你可以看到电话号码字段 Phone Number 你将操作 ISD international subscriber dialing 国际电话加入者拨号通话 代码 将电话号码段分离 直到满足你的需求 因此 这将是明智的选择 当然 分离它可能会导致更多的并发症 规则规则 4 重复 无规则的数据将是你最大的敌人 重复 无规则的数据将是你最大的敌人 聚焦 重构重复的数据 我个人担心的不是关于重复数据它占用空间 而是它造成混 乱 例如 在接下来的图表中 你能看到 5th Standard 和 Fifth standard 含义相同 现在 你可以说因为录入了坏数据或者数据验证错误是系统原因 现在如果你想获得一份 报表 它们可能显示为不同的实体 从最终用户角度来看 是非常困难的 其中一个解决办法是移动数据到另外的主表中 使用外键关联 你可以看到下图中 我们是如何建立一个新的主表叫做 Standards 作为一个简单的关联外键 规则规则 5 注意分离器的数据分离 注意分离器的数据分离 第二条规则即第一范式所提到的重复分组 重复分组的例子之一如下图表解释 如你 看到的 syllabus 字段 在这一字段中 有太多的数据冗余 这种字段被称为 重复组 如果我们要去处理这些数据 查询起来会很复杂 而且我也怀疑查询的性能 这些列存在数据冗余 带有分离的数据需要特别注意 一个更好的办法是将一个字段 移动不同的表单中 连接这些主键 从而更好的去管理 现在让我们应用第一范式的第二条规则 避免重复分组 如上图所示 我创建的分离 syllabus 表与 subject 具有多对多的关系 这种方法在主表中 syllabus 字段避免了过多的重复和数据分离 规则规则 6 注意数据依赖 注意数据依赖 注意主键字段的部分依赖 例如 在上表所示 我们注意创建的 roll number 和 standard 的主键 现在观察 syllabus 字段已删除 Syllabus 字段是关联到 standard 而没有直接与 student 产生关联 即 roll number Syllabus 是由 standard 关联在一起 学生与学习的科目没有直接的联系 如果 明天我们要更新 syllabus 字段 我们必须更新所有 student 字段 这是一件痛苦的事 而且也不符合逻辑 将这些字段移出 并与 standard 表建立关联将更有意义 你应该能观察出如何移出 syllabus 字段 并与 standard 表建立关联 这些规则是什么 但第二范式提及到 所有键都须完全依赖主键 而不是部分 规则规则 7 重视派生列的选择 重视派生列的选择 如果你使用 OLTP 应用在你的工作中 正确的作法是获得派生列的列标识 直到获得 性能的提升 OLAP 是做了很多的优化 计算这些字段所必须的内容 从而进一步提升性能 上图所示 你可以看出 average 字段是如何依赖 marks 字段与 subject 字段 的 这也是冗余形式之一 这类字段由其它字段衍变而来 这样做确实有必要 这个规则也称为第三范式 属性不依赖于其它非主属性 我个人而言 不会盲目地使 用这个规则 而要看它的处境 它不是多余数据 但也不是好的数据 如果多余数据经过 计算 看情况去决定实施第三范式 规则规则 8 如果注重性能 不要避开冗余数据 如果注重性能 不要避开冗余数据 不要一味的使用规则 你将永远去避免冗余 如果迫切的考虑到性能规范问题 正常 你需要多表关联和减少非规范化 从而提高性能 规则规则 9 多维数据区分于复杂数据 多维数据区分于复杂数据 OLAP 项目更多的是处理多维数据 例如 如下图所示 你想获得每个国家 客户和日 期的销量 简单的说 你可以看一下销售图表 三条相交的维度数据 对于这种情况一维表有更好的设计方法 简单地说 你可以创建一个简单的中间销售 表 其中有销售金额字段 它与所有的维度表通过外键关联 规则规则 10 名称 名称 值表的设计值表的设计 很多次 我所遇到的名称 值表 名称和值表存在一些键 这些键值与一些关键数据相 连 例如在接下来的图表中 你能看到我们的货币表 Currency Table 与国家表 Country Table 你观察数据很相近的数据 实际上只有键 Key 和值 Value 这类表需要创建一个中间表 使用一个类型字段 Type 来区分数据 这样才更有意 义 规则规则 11 无限制的自我参数等级数据 无限制的自我参数等级数据 PK 和和 FK 很多时候 我遇到过无限制父子层次结构的数据 例如 考虑一个多层次的营销方案 一个销售人员下面有多个销售人员 在这