11种重要的数据库设计规则Word格式.docx

11种重要的数据库设计规则Word格式.docx

《11种重要的数据库设计规则Word格式.docx》由会员分享，可在线阅读，更多相关《11种重要的数据库设计规则Word格式.docx（11页珍藏版）》请在冰豆网上搜索。

英文原文地址：

http:

//www.c-

---------------------------------------------------------------------------------------------------------------------------------

这篇文章将描述11种重要的数据库设计规则。

简介

在读这篇文章之前，让我确认一下，我不是数据设计方面的大师，如下所示的十一点是我经过学习项目所获得到的经验。

我个人认为，在数据库设计过程中对我来说帮助很大。

欢迎任何批评。

我写这个完整的文章原因是，当开发者座下来设计一个数据库时，他们趋向于三种常规模式（“likeasilverbullet.”没翻译成功，不知道是什么意思，应该是根深蒂固的意思吧）。

他们常常认为常规化设计是唯一的途径。

由于这种心态，修改问题（原文“hitroadblocks”）作为项目推进的方法。

如果你是一个新的常规化设计，则点击观看“3种常规模式”，这里详细介绍了所有三种常规模式。

我们所说、所做的标准化规则，是非常重要的准则，（“buttakingthemasamarkonstoneiscallingfortroubles.”没翻译好）但是在使用它们存在着顽固的调用麻烦。

接下来是我自己理解的11条规则，记得在前面提到，这11条规则用于数据库设计。

规则1：

应用的本质（OLTP或OLAP）？

当你开始你的数据库设计时，第一件事是分析你设计的应用本质是什么，是事务型还是分析型，你会发现许多开发者默认使用常规化的规则，而不考虑应用的本质，最后考虑性能与定制问题。

说到这里，是基于事务性和基于分析性两种方法，让我们来理解这两种方法：

Transactional（事务型）：

在这类应用中，用户最感兴趣的是CRUD（Create、Retrieve、Update、Delete），即创建、查询、更新和删除记录。

这类数据库的正式命名为OLTP（On-LineTransactionProcessing在线事务处理）。

Analytical（分析型）：

在这类应用中，用户最感兴趣的是分析、报告、预测等。

这类数据库很少用到插入与更新操作。

这里主要的目的是尽可能快速的获取和分析数据。

这类数据库正式命名为OLAP（On-LineAnalyticalProcessing在线分析处理）。

换句话说，如果你认为插入、更新或删除更重要，则使用常规化的表单设计或者建立一个简单的非常规化的数据结构。

下面是一个简单的图表，左边的表显示了名称（Name）和地址（Address），是应用非规范化结构创建出来的一个简单地常规化表单。

规则2：

数据进行逻辑分块，使你的生活更简单

这个规则实际上是从第一范式演变过来的第一种规则。

违反这种规则的第一种模式是，如果你查询使用了太多字符串解析功能，像子串、字符索引等，可能需要应用此规则。

例如，如下表所示，其中有学生的名字（StudentName），如果你想查询学生的名字包含“Koirala”而没有“Harisingh”，你可以想像使用什么方法可以实现。

所以更好的方法是打破这一字段，进行更多的逻辑分块，所以我们能写出最简洁、高效的查询方法。

规则3：

不要过多的使用规则2

开发者们思维很单一，如果你告诉他这个方法，他们会一直这样做下去，过度使用它，会导致不必要的后果。

这也适用于刚刚谈到的规则2。

当你考虑分解时，你会停顿一下，问自己是否需要这样做，分解必须具有一定逻辑性。

例如，你可以看到电话号码字段（PhoneNumber），你将操作ISD（internationalsubscriberdialing国际电话加入者拨号通话）代码，将电话号码段分离（直到满足你的需求），因此，这将是明智的选择，当然，分离它可能会导致更多的并发症。

规则4：

重复、无规则的数据将是你最大的敌人

聚焦、重构重复的数据。

我个人担心的不是关于重复数据它占用空间，而是它造成混乱。

例如，在接下来的图表中，你能看到“5thStandard”和“Fifthstandard”含义相同。

现在，你可以说因为录入了坏数据或者数据验证错误是系统原因。

现在如果你想获得一份报表，它们可能显示为不同的实体，从最终用户角度来看，是非常困难的。

其中一个解决办法是移动数据到另外的主表中，使用外键关联。

你可以看到下图中，我们是如何建立一个新的主表叫做“Standards”作为一个简单的关联外键。

规则5：

注意分离器的数据分离

第二条规则即第一范式所提到的重复分组。

重复分组的例子之一如下图表解释。

如你看到的“syllabus”字段，在这一字段中，有太多的数据冗余。

这种字段被称为“重复组”。

如果我们要去处理这些数据，查询起来会很复杂，而且我也怀疑查询的性能。

这些列存在数据冗余，带有分离的数据需要特别注意，一个更好的办法是将一个字段移动不同的表单中，连接这些主键，从而更好的去管理。

现在让我们应用第一范式的第二条规则“避免重复分组”。

如上图所示，我创建的分离“syllabus”表与“subject”具有多对多的关系。

这种方法在主表中“syllabus”字段避免了过多的重复和数据分离。

规则6：

注意数据依赖

注意主键字段的部分依赖。

例如，在上表所示，我们注意创建的“rollnumber”和“standard”的主键。

现在观察“syllabus”字段已删除。

“Syllabus”字段是关联到“standard”，而没有直接与“student”产生关联（即“rollnumber”）。

“Syllabus”是由“standard”关联在一起，学生与学习的科目没有直接的联系。

如果明天我们要更新“syllabus”字段，我们必须更新所有“student”字段，这是一件痛苦的事，而且也不符合逻辑。

将这些字段移出，并与“standard”表建立关联将更有意义。

你应该能观察出如何移出“syllabus”字段，并与“standard”表建立关联。

这些规则是什么，但第二范式提及到“所有键都须完全依赖主键，而不是部分”。

规则7：

重视派生列的选择

如果你使用OLTP应用在你的工作中，正确的作法是获得派生列的列标识，直到获得性能的提升。

OLAP是做了很多的优化，计算这些字段所必须的内容，从而进一步提升性能。

上图所示，你可以看出，“average”字段是如何依赖“marks”字段与“subject”字段的，这也是冗余形式之一。

这类字段由其它字段衍变而来，这样做确实有必要。

这个规则也称为第三范式（属性不依赖于其它非主属性）。

我个人而言，不会盲目地使用这个规则，而要看它的处境。

它不是多余数据，但也不是好的数据。

如果多余数据经过计算，看情况去决定实施第三范式。

规则8：

如果注重性能，不要避开冗余数据

不要一味的使用规则，你将永远去避免冗余。

如果迫切的考虑到性能规范问题，正常你需要多表关联和减少非规范化，从而提高性能。

规则9：

多维数据区分于复杂数据

OLAP项目更多的是处理多维数据，例如，如下图所示，你想获得每个国家、客户和日期的销量，简单的说，你可以看一下销售图表，三条相交的维度数据。

对于这种情况一维表有更好的设计方法，简单地说，你可以创建一个简单的中间销售表，其中有销售金额字段，它与所有的维度表通过外键关联。

规则10：

名称-值表的设计

很多次，我所遇到的名称-值表，名称和值表存在一些键，这些键值与一些关键数据相连。

例如在接下来的图表中，你能看到我们的货币表（CurrencyTable）与国家表（CountryTable），你观察数据很相近的数据，实际上只有键（Key）和值（Value）。

这类表需要创建一个中间表，使用一个类型字段（Type）来区分数据，这样才更有意义。

规则11：

无限制的自我参数等级数据PK和FK。

很多时候，我遇到过无限制父子层次结构的数据。

例如，考虑一个多层次的营销方案，一个销售人员下面有多个销售人员，在这种方案中，可以使用自定义主键和外键来实现统一。

本文不是说不按正常的模式，但不要盲目的追随它，要看你现实中的项目和你处理的数据类型。

充分参考了下面一个视频，这里一步一步地介绍了三种模式建立一个简单的学校表（schooltable）。

你可以观看我的站点，一步一步讲解设计模式、UML、SharePoint2010、.NET基础、VSTS、SQLServer、MVC以及更多视频。