11招教你如何玩转数据库设计-2
上一篇 / 下一篇 2012-04-13 09:47:46 / 个人分类：数据库
那么，让我们现在就应用规则2（第一范式） “避免重复组” 吧。你可以看到上面这个图表，我创建了一个单独的 syllabus（课程） 表，然后使用 “多对多” 关系将它与 subject（科目） 表关联起来。
通过这个方法，主表（student 表）的 syllabus（课程） 字段就不再有重复数据和分隔符了。
◆ 规则6：当心那些仅仅部分依赖主键的列
留心注意那些仅仅部分依赖主键的列。例如上面这个图表，我们可以看到这个表的主键是 Roll No.+Standard。现在请仔细观察 syllabus 字段，可以看到 syllabus（课程） 字段仅仅关联（依赖） Standard（课程级别） 字段而不是直接地关联（依赖）某个学生（Roll No. 字段）。
Syllabus（课程） 字段关联的是学生正在学习的哪个课程级别（Standard 字段）而不是直接关联到学生本身。那如果明天我们要更新教学大纲（课程）的话还要痛苦地为每个同学也修改一下，这明显是不符合逻辑的（不正常的做法）。更有意义的做法是将这些字段从这个表移到另外一个表，然后将它们与 Standard（课程级别）表关联起来。
你可以看到我们是如何移动 syllabus（课程）字段并且同样地附上 Standard 表。
这条规则只不过是 “三范式” 里的 “第二范式”：“所有字段都必须完整地依赖主键而不是部分依赖”。
◆ 规则7：仔细地选择派生列
如果你正在开发一个 OLTP 型的应用程序，那强制不去使用派生字段会是一个很好的思路，除非有迫切的性能要求，比如经常需要求和、计算的 OLAP 程序，为了性能，这些派生字段就有必要存在了。
通过上面的这个图表，你可以看到 Average 字段是如何依赖 Marks 和 Subjects 字段的。这也是冗余的一种形式。因此对于这样的由其他字段得到的字段，需要思考一下它们是否真的有必要存在。
这个规则也被称为 “三范式” 里的第三条：“不应该有依赖于非主键的列”。我的个人看法是不要盲目地运用这条规则，应该要看实际情况，冗余数据并不总是坏的。如果冗余数据是计算出来的，看看实际情况再来决定是否应用这第三范式。
◆ 规则8：如果性能是关键，不要固执地去避免冗余
不要把 “避免冗余” 当作是一条绝对的规则去遵循。如果对性能有迫切的需求，考虑一下打破常规。常规情况下你需要做多个表的连接操作，而在非常规的情况下这样的多表连接是会大大地降低性能的。
◆ 规则9：多维数据是各种不同数据的聚合
OLAP 项目主要是解决多维数据问题。比如你可以看看下面这个图表，你会想拿到每个国家、每个顾客、每段时期的销售额情况。简单的说你正在看的销售额数据包含了三个维度的交叉。
为这种情况做一个实际的设计是一个更好的办法。简单的说，你可以创建一个简单的主要销售表，它包含了销售额字段，通过外键将其他所有不同维度的表连接起来。
◆ 规则10：将那些具有“名值表”特点的表统一起来设计
很多次我都遇到过这种 “名值表” 。 “名值表” 意味着它有一些键，这些键被其他数据关联着。比如下面这个图表，你可以看到我们有 Currency（货币型）和 Country（国家）这两张表。如果你仔细观察你会发现实际上这些表都只有键和值。
对于这种表，创建一个主要的表，通过一个 Type（类型）字段来区分不同的数据将会更有意义。
◆ 规则11：无限分级结构的数据，引用自己的主键作为外键
我们会经常碰到一些无限父子分级结构的数据（树形结构？）。例如考虑一个多级销售方案的情况，一个销售人员之下可以有多个销售人员。注意到都是 “销售人员” 。也就是说数据本身都是一种。但是层级不同。这时候我们可以引用自己的主键作为外键来表达这种层级关系，从而达成目的。
这篇文章的用意不是叫大家不要遵循范式，而是叫大家不要盲目地遵循范式。根据你的项目性质和需要处理的数据类型来做出正确的选择。
TAG:
我的栏目
标题搜索
日历
|
|||||||||
| 日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
| 1 | 2 | 3 | 4 | ||||||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 | |||
| 12 | 13 | 14 | 15 | 16 | 17 | 18 | |||
| 19 | 20 | 21 | 22 | 23 | 24 | 25 | |||
| 26 | 27 | 28 | 29 | 30 | 31 | ||||
我的存档
数据统计
- 访问量: 3343093
- 日志数: 1640
- 建立时间: 2011-12-07
- 更新时间: 2019-12-24
