简介

数据库中表的描绘是一个陈词滥调的论题，关于表的描绘却仍然存在某些误区，本篇文章对来从范式和功能的视点谈一谈数据库的描绘。

描绘数据库?

首要榜首个疑问是，关于表的描绘而言，咱们终究需要何种程度的描绘。这取决于您数据库的计划，打个比如，就比如您盖一个两层小楼，根本无需啥描绘，直接 上手即可，若是盖一个两层小楼也去找描绘院的话，那岂不是弄巧成拙。可是对盖一座大厦来说，不做计划和描绘，就不行思议了。

但与盖楼这个比方不一样的是，数据库会增加，将来数据量的增加和并发量能够超出您的估量。因而，若是做一个好的描绘，在面临将来数据和并发的增加时，或许就不会那么难堪。

请记住，做一个好的描绘和坏的描绘所需话费的本钱差不多，那咱们为啥不在一开端描绘表时就有所注意。

范式?

范式也是一个老论题了，关于范式的介绍也是满天飞了，这里就不在细说了。关于范式，我喜爱分为两大类：榜首范式和其他范式。榜首范式意味着数据不行再分， 对此详细的解说我会接下来说到。而其他范式讲的是一件事，表中主键仅有标识其所代表的行，其他列都是对该行的描绘。

范式化使得您的描绘契合联系数据库。也是一个规范化数据的进程。尤其是榜首范式，即便是数据仓库，也是需要遵从的。

下面先说说榜首范式。

榜首范式

榜首范式意味着将数据分化到最低层级，那数据分化到榜首层级的规范分为以下3条：

• 列值契合原子性
• 没有重复列
• 每一行代表一个值

首要，列值依照事务类型不应该能够再分。这也是为啥表的命名应该是复数方法，而列的命名往往是奇数方法。因为列所代表的含义契合榜首范式的话，那应该是仅有的。

那反过来，啥样的表不契合榜首范式呢，比如说：

•     列值能够再分，比如说一组值以逗号切割
•     特点后边带有数字，比如说Description1，Description2

下面咱们来举一组简略的比如，来阐明榜首范式：

假定咱们有一个图书表：

图1.图书表

假定咱们有大于一位作者时，莫非表布局需要成为这样？

图2.不契合榜首范式的解决方法

图2中的方法显然是十分欠好的，正确的做法应该是榜首范式化，如图3所示。

图3.榜首范式话后的表

咱们再来看一个简略的比如，假定说最简略的一个用户表模型，如图4所示。

图4.

图4中的表是不是契合榜首范式要取决于运用该表的应用程序，若是运用该表的应用程序在运用进程中无需做拆分，则阐明该表是契合榜首范式的，不然，需要将地址字段做进一步拆分，如图5所示。

图5.进一步对表做拆分，来满意榜首范式

那为啥非要满意榜首范式呢？这是因为为了避免在运用数据进程中存在花样百出的代码，这些代码包含：

• Substring
• Charindex
• Patindex
• CASE表达式
• &或|
• Distinct或不聚合的情况下运用Group By

其实运用上述代码并没有啥错，但因为上述代码而形成功能和数据完好性疑问的时分，就不对了。下面咱们再来看一个因为不契合榜首范式而形成的致使功能疑问的代码，如代码清单1所示。

--过错

SELECT * from Person

     Where SUBSTRING(fullname,0,1) =‘王’

--正确

SELECT * from Person where FirstName = ‘王’

代码清单1.不契合榜首范式，致使在Where条件做运算，然后致使十分低效的查询句子

第二范式、第三范式、BC范式

其实这几种范式阐明的都是同一个疑问：“键用来标识表，非键用来描绘键所标识的表”。几种范式的联系是顺次递进的，这意味着满意第三范式，首要一定会满意第二范式。简略来说几种范式的效果：

• 第二范式消除对主键的有些依靠，其次，每列都需要和主键关联
• 第三范式消除对主键的传递依靠
• BC范式消除对非主键的数据依靠

让咱们来看一个简略的比如，如图6所示。

图6.简略的比如

首要来看图6所示的表，咱们思考到主键是UserID，这意味着该表是用来描绘用户的，每行代表的是一个用户，而该表中国只是是UserName和 UserEmail列是和用户直接关联的。其次，Province和City这两列存在二义性，这两列终究是描绘商品地点的城市仍是用户地点的城市呢？另 外，晓得City的值，就完全能够晓得Province的值，这存在潜在的数据不一致的危险。最终ProductColor传递依靠于UserID这个主 键。

因而，咱们依据“键用来标识表，非键用来描绘键所标识的表”这个简略的概念，把图6的表做一个拆分，如图7所示。

图7.拆分后的表契合BCNF

从图7中咱们能够看出，每一个表的含义都是仅有的，主键标识每一行，其他列描绘这一行。

因而对范式做一个小小的总结，榜首范式是有必要遵从的，即便在数据仓库也是要遵从的，在描绘数据库的时分要把范式作为一个参阅，但也不要教条。

反范式

由范式的概念不难看出，越高等级的范式所发生的表越多，而在应用程序运用的进程中越多的表Join越简单形成功能损耗的疑问。因而，在某些场景下需要反范式化来进行Trade-Off。

首要一个适宜反范式化的场景是，数据库的读写比趋近于无量，那么削减表无疑是十分适宜的。

第二个是在描绘表的时分过度范式话，表现即是数据库中存在许多4+个表的衔接，这能够因为是开端描绘的时分过度描绘，或是数据库中数据增加的量使得过多的表衔接发生了功能疑问。

一个挺有意思的观念是不断范式化，直道影响了功能，然后进行反范式化。这个观念所疏忽的是，一般对功能发生影响是数据量在出产环境中现已发生了功能疑问，而在出产环境中进行反范式话的话，不只是是本钱的疑问，还有危险的疑问。

所以非常好的方法是思考范式到只是满意用户的需要即可，范式只是是一个参阅，不要过于教条，当然，关于用户需要的不断改变，就不在这篇文章的评论之列了：-）

主键的挑选

其实关于主键的挑选我之前现已有一篇文章对此进行论述了(参看我之前的文章:从功能的视点谈SQL Server集合索引键的挑选)，再次我想多说一句，尽量思考运用署理键作为主键，运用署理键的优点如下：

• 避免事务更改致使主键的更改
• 便利将数据由多个数据源合并到单个数据源
• 非署理件能够是多列,或许过长,然后致使集合索引建过长,因而形成功能的疑问.
• 署理键不会参加数据仓库的核算,比如说聚合函数

末节

本篇文章简略从功能和范式的视点谈了一下表的描绘和主键的挑选。依照用户的需要灵敏的描绘表才是正路，至于用户需要改变的事，那就超出了这篇文章的评论范围了

引荐网址

亮点百科