收藏 分享(赏)

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

上传人:kpmy5893 文档编号:5153797 上传时间:2019-02-10 格式:DOC 页数:12 大小:747.50KB
下载 相关 举报
11种重要的数据库设计规则.doc_第1页
第1页 / 共12页
11种重要的数据库设计规则.doc_第2页
第2页 / 共12页
11种重要的数据库设计规则.doc_第3页
第3页 / 共12页
11种重要的数据库设计规则.doc_第4页
第4页 / 共12页
11种重要的数据库设计规则.doc_第5页
第5页 / 共12页
点击查看更多>>
资源描述

1、十一种重要的数据库设计规则2012 年 4 月 4 日 作者:Shivprasad 2010 年 4 月 15 日 译者:lixh 译者话:我在网上无意中看到这篇文章,是中文版的,出自 CSDN,当时我想收藏,但版主声明了转发需要他本人同意,所以我决定重新翻译此英文原文。这篇文章写的真不错,可以好好的揣摩一下作者的深意,唯一让我感觉到不舒服的地方是作者太过方言化了,以至于部分句子我家的专业翻译也没弄明白。由于本人能力有限,此文章只做参考,建立您阅读原文。英文原文地址:http:/www.c- 11 种重要的数据库设计规则。简介在读这篇文章之前,让我确认一下,我不是数据设计方面的大师,如下所示的

2、十一点是我经过学习项目所获得到的经验。我个人认为,在数据库设计过程中对我来说帮助很大。欢迎任何批评。我写这个完整的文章原因是,当开发者座下来设计一个数据库时,他们趋向于三种常规模式(“like a silver bullet.”没翻译成功,不知道是什么意思,应该是根深蒂固的意思吧) 。他们常常认为常规化设计是唯一的途径。由于这种心态,修改问题(原文“hit road blocks”)作为项目推进的方法。如果你是一个新的常规化设计,则点击观看“3 种常规模式 ”,这里详细介绍了所有三种常规模式。我们所说、所做的标准化规则,是非常重要的准则, (“but taking them as a mark

3、 on stone is calling for troubles.”没翻译好)但是在使用它们存在着顽固的调用麻烦。接下来是我自己理解的 11 条规则,记得在前面提到,这 11 条规则用于数据库设计。规则 1:应用的本质(OLTP 或 OLAP)?当你开始你的数据库设计时,第一件事是分析你设计的应用本质是什么,是事务型还是分析型,你会发现许多开发者默认使用常规化的规则,而不考虑应用的本质,最后考虑性能与定制问题。说到这里,是基于事务性和基于分析性两种方法,让我们来理解这两种方法:Transactional(事务型):在这类应用中,用户最感兴趣的是CRUD( Create、Retrieve 、U

4、pdate 、Delete ) ,即创建、查询、更新和删除记录。这类数据库的正式命名为 OLTP(On-Line Transaction Processing 在线事务处理) 。Analytical(分析型): 在这类应用中,用户最感兴趣的是分析、报告、预测等。这类数据库很少用到插入与更新操作。这里主要的目的是尽可能快速的获取和分析数据。这类数据库正式命名为 OLAP(On-Line Analytical Processing 在线分析处理) 。换句话说,如果你认为插入、更新或删除更重要,则使用常规化的表单设计或者建立一个简单的非常规化的数据结构。下面是一个简单的图表,左边的表显示了名称(Na

5、me)和地址(Address) ,是应用非规范化结构创建出来的一个简单地常规化表单。规则 2:数据进行逻辑分块,使你的生活更简单这个规则实际上是从第一范式演变过来的第一种规则。违反这种规则的第一种模式是,如果你查询使用了太多字符串解析功能,像子串、字符索引等,可能需要应用此规则。例如,如下表所示,其中有学生的名字(Student Name) ,如果你想查询学生的名字包含“Koirala”而没有“Harisingh” ,你可以想像使用什么方法可以实现。所以更好的方法是打破这一字段,进行更多的逻辑分块,所以我们能写出最简洁、高效的查询方法。规则 3:不要过多的使用规则 2开发者们思维很单一,如果你

6、告诉他这个方法,他们会一直这样做下去,过度使用它,会导致不必要的后果。这也适用于刚刚谈到的规则 2。当你考虑分解时,你会停顿一下,问自己是否需要这样做,分解必须具有一定逻辑性。例如,你可以看到电话号码字段(Phone Number) ,你将操作 ISD(international subscriber dialing 国际电话加入者拨号通话)代码,将电话号码段分离(直到满足你的需求),因此,这将是明智的选择,当然,分离它可能会导致更多的并发症。规则 4:重复、无规则的数据将是你最大的敌人聚焦、重构重复的数据。我个人担心的不是关于重复数据它占用空间,而是它造成混乱。例如,在接下来的图表中,你能看

7、到“5th Standard”和“Fifth standard”含义相同。现在,你可以说因为录入了坏数据或者数据验证错误是系统原因。现在如果你想获得一份报表,它们可能显示为不同的实体,从最终用户角度来看,是非常困难的。其中一个解决办法是移动数据到另外的主表中,使用外键关联。你可以看到下图中,我们是如何建立一个新的主表叫做“Standards”作为一个简单的关联外键。规则 5:注意分离器的数据分离第二条规则即第一范式所提到的重复分组。重复分组的例子之一如下图表解释。如你看到的“syllabus”字段,在这一字段中,有太多的数据冗余。这种字段被称为“重复组” 。如果我们要去处理这些数据,查询起来会

8、很复杂,而且我也怀疑查询的性能。这些列存在数据冗余,带有分离的数据需要特别注意,一个更好的办法是将一个字段移动不同的表单中,连接这些主键,从而更好的去管理。现在让我们应用第一范式的第二条规则“避免重复分组” 。如上图所示,我创建的分离“syllabus”表与“subject”具有多对多的关系。这种方法在主表中“syllabus ”字段避免了过多的重复和数据分离。规则 6:注意数据依赖注意主键字段的部分依赖。例如,在上表所示,我们注意创建的“roll number”和“standard”的主键。现在观察“syllabus”字段已删除。 “Syllabus”字段是关联到“standard”,而没有

9、直接与 “student”产生关联(即“roll number”) 。“Syllabus”是由“standard”关联在一起,学生与学习的科目没有直接的联系。如果明天我们要更新“syllabus” 字段,我们必须更新所有“student”字段,这是一件痛苦的事,而且也不符合逻辑。将这些字段移出,并与“standard”表建立关联将更有意义。你应该能观察出如何移出“syllabus ”字段,并与“standard”表建立关联。这些规则是什么,但第二范式提及到“所有键都须完全依赖主键,而不是部分” 。规则 7:重视派生列的选择如果你使用 OLTP 应用在你的工作中,正确的作法是获得派生列的列标识,

10、直到获得性能的提升。OLAP 是做了很多的优化,计算这些字段所必须的内容,从而进一步提升性能。上图所示,你可以看出, “average”字段是如何依赖“marks”字段与“subject”字段的,这也是冗余形式之一。这类字段由其它字段衍变而来,这样做确实有必要。这个规则也称为第三范式(属性不依赖于其它非主属性) 。我个人而言,不会盲目地使用这个规则,而要看它的处境。它不是多余数据,但也不是好的数据。如果多余数据经过计算,看情况去决定实施第三范式。规则 8:如果注重性能,不要避开冗余数据不要一味的使用规则,你将永远去避免冗余。如果迫切的考虑到性能规范问题,正常你需要多表关联和减少非规范化,从而提

11、高性能。规则 9:多维数据区分于复杂数据OLAP 项目更多的是处理多维数据,例如,如下图所示,你想获得每个国家、客户和日期的销量,简单的说,你可以看一下销售图表,三条相交的维度数据。对于这种情况一维表有更好的设计方法,简单地说,你可以创建一个简单的中间销售表,其中有销售金额字段,它与所有的维度表通过外键关联。规则 10:名称-值表的设计很多次,我所遇到的名称-值表,名称和值表存在一些键,这些键值与一些关键数据相连。例如在接下来的图表中,你能看到我们的货币表(Currency Table)与国家表(Country Table) ,你观察数据很相近的数据,实际上只有键(Key)和值(Value)

12、。这类表需要创建一个中间表,使用一个类型字段(Type)来区分数据,这样才更有意义。规则 11:无限制的自我参数等级数据 PK 和 FK。很多时候,我遇到过无限制父子层次结构的数据。例如,考虑一个多层次的营销方案,一个销售人员下面有多个销售人员,在这种方案中,可以使用自定义主键和外键来实现统一。本文不是说不按正常的模式,但不要盲目的追随它,要看你现实中的项目和你处理的数据类型。充分参考了下面一个视频,这里一步一步地介绍了三种模式建立一个简单的学校表(school table) 。你可以观看我的站点,一步一步讲解 设计模式、UML、SharePoint 2010、.NET 基础、VSTS、SQL Server、MVC 以及更多视频。

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 网络科技 > 数据库

本站链接:文库   一言   我酷   合作


客服QQ:2549714901微博号:道客多多官方知乎号:道客多多

经营许可证编号: 粤ICP备2021046453号世界地图

道客多多©版权所有2020-2025营业执照举报