【翻译】数据库设计——范式

最新推荐文章于 2024-06-13 09:00:30 发布
最新推荐文章于 2024-06-13 09:00:30 发布
阅读量167 收藏
点赞数
文章标签： 数据库
原文链接：http://www.cnblogs.com/cposture/p/5053853.html
版权

简介

数据库所需要的特性是为了有效的存储以及容易维护数据。

第一点，有效的存储是指应避免数据冗余；第二点，易于维护是指一个好的数据库设计是将数据有逻辑地分散在数据表中。

规范化是一种实现这些目的的数据库设计方法。

什么是规范化？

数据库规范化，又称数据库或资料库的正规化、标准化，是数据库设计中的一系列原理和技术，以减少数据库中数据冗余，增进数据的一致性。(wikipedia.com)

规范化提供了一系列原则来帮助：

  • 有效的组织数据
  • 减少数据冗余
  • 确保只有相关的数据被存储在一张表中

范式

随着时间的推移，已经发展出了一些好的规则，这些规则允许一个数据库被设计成具有不同程度的数据库。这些规则被称为范式，这些范式用0到5数字进行编号，即0NF，1NF，2NF，3NF，4NF，5NF。

在这里，你并不需要关心4NF和5NF，因为它们暂时在这里不做讨论。我们将只讨论1NF，2NF，3NF。

你应该知道范式是数据库设计者的唯一指导方针——但是他们并不一定要遵循它们！

You should be aware that normal forms are only guidelines for the database designer - they do not have to follow them!

数据库设计者根据需要开发的数据库类型来选择范式。他们也许不规范化他们的数据库，此时这种数据库被称为未规范化数据库或0NF。

第一范式-1NF

对于一个属于第一范式的数据库，数据库中的每一张表都必须符合下面的规则：

  • 没有重复的或相似数据的列
  • 每一项都不能再分割
  • 每一行都是唯一的，也就是说数据库有一个主码
  • 每一个域都有一个唯一的名字

原子性这个词用于描述一个数据项不可再分割的性质。

untitled.jpg

原子性数据示例

  • 身份证号码
  • 社会保险号
  • 书的ISBN编码，如1-931841-62-4
  • 股票代码
  • 一个人的姓
  • 一个人的名
  • 电话号码
  • 学校名字，如 'Abington Hall Comprehensive School'
  • 一个完整的说明，如'A fountain pen is a writing instrument'

最后的两个示例说明了原子性并不代表是一个单词。它只是简单的指当我们去除数据项中的某些字符时，它将会变得无法理解，因为它失去了原本的意思。

非原子性数据示例

  • 一个人的全名，如John Hunt，它实际包括了姓和名，一起存储在数据库
  • 一个完整的地址，如6 Picton Road, London, WR1 4PG，它实际包括了街道，城市等信息
  • 一个更大数据集的部分数据（Data that are part of a larger dataset），如Oxford Book club and Coventry Health club

重复数据示例

IDFirst nameSurnameTelePhone1TelePhone2TelePhone3
2TomSmith22323456343456345

在这种情况下，数据库尝试保存每一个人的多个号码。数据库设计者创建了三个域用于保存电话号码。这就是所谓的重复数据，电话号码属于同一种类型的数据。

1NF示例 1

提醒：第一范式规则

  • 没有重复的或相似数据的列
  • 每一项都不能再分割
  • 每一行都是唯一的，也就是说数据库有一个主码
  • 每一个域都有一个唯一的名字

下面哪个数据表不符合第一范式？

  1. TitleFirstnameSurnameFull nameAddressCity
    MrTomSmithTom Smith42 Mill StreetLondon
  2. ID[主码]IP Addressusernamelast accessedActivityResultactive
    1003[主码]198.168.1.5Smith20081021:14.10Save filesuccessy
  3. ItemID[主码]ProductDescriptionSizeColourColourColour
    234ShoeHigh Heel6redbluebrown
  4. StudentID[主码]FirstnameSurnameSchoolID*ClassID*
    354TomSmith65F

说明：

表一：不属于1NF，没有定义主码，因此每一条记录不能保证是唯一的。Full name 是冗余的——数据并非原子性，因为它是 Firstname和Surname的简单组合。
表二：至少属于1NF，它有一个主码。数据是原子性的。每一个域都有唯一的名字。没有重复数据。
表三：不属于1NF，它有主码，数据是原子性，但是color域重复了，并且这些域的名字也是相同的！
表四：属于1NF，符合1NF的所有规则

思考问题判断1NF
  • 它是否有主码
  • 每一个域的名字是否唯一
  • 数据是否原子性
  • 是否有重复或冗余的域

1NF示例 2

假设为一个粉丝俱乐部网站设计数据库。粉丝们访问网站来寻找志同道合的朋友。

存储的实体如下面所示

2.jpg

这表明每一个乐队都拥有许多粉丝，每一个人是唯一一个乐队的粉丝。

BANDFAN
The attributes of band are:band id ,band name , musictypeThe attributes of a fan are: fan id,firstname, surname,email addresse(s)

数据库需要满足第一范式。

第一次尝试

这是数据库设计者第一次设计数据库，他真的不太确定如何进行。他设计了一个FAN表，并且加载以下记录

FanID[主码]FirstnameSurnameBandID*email
1TomSmith23tm@fan.org
2MaryHolden56mh@fan.org , mary@myhome.org

他成功的建立了一个主码，并且也使用了外码来引用乐队。但是这不属于1NF，因为Mary拥有的两个邮箱地址加载在同一个email域。数据不是原子性了。这样存储数据也很难提取邮箱地址。同时email域的数据长度必须足够大以存储许多邮箱地址，这非常低效率且如果超出一定的范围会产生一定的问题。

第二次尝试

他马上意识到这不是一个好主意，所以打算创建两个email域

FanIDFirstnameSurnameBandID*emailemail2
1TomSmith23tm@fan.org
2MaryHolden56mh@fan.orgmary@myhome.org

这也是一个不好的方法——注意：email2在TOM的记录中未被使用到，造成一定的空间浪费，因此不属于1NF（用于避免冗余和浪费）。另一个问题是假如一个粉丝拥有更多的邮箱那该怎么办？增加更多的email域会使空间浪费更严重。

另一个问题是查询提取邮箱地址更加复杂，因为需要检验每一个email域的邮箱地址。

解决方案

在尝试了几种不同的方法之后，他想到了一个不错的方法——创建另一个email实体，同时在表中使用一个外码去链接粉丝和邮箱地址。ER图如下：

3.jpg

ER表示了每一个粉丝能够拥有许多邮箱地址，但是一个邮箱地址只能属于一个粉丝。

现在FAN和EMAIL表如下所示：

FAN

FanID[主码]FirstnameSurnameBandID*
1TomSmith23
2MaryHolden56

EMAIL

EID[主码]FanID*email
11tm@fan.org
22mh@fan.org
32mary@myhome.org

第二范式-2NF

大多数表格通常都有一个单属性的主码。就像这样：

CUSTOMER

ID [主码]FirstnameSurnameTelephoneemail
2TomSmith22323ts@aol.com

但是有时候一个表拥有的主码是由多个属性构成的，即拥有一个复合主码

CONCERT

Venue [主码]Artist [主码]AttendanceProfitStyle
WembleyGirls Aloud5300012334Girl band
NECLeona Lewis4500066433Female soloist

上面表格中使用了venue和artist作为复合主码。

正是在这种情况下，对于第二范式的额外规则就派上用场了。

  • 非关键属性必须依赖主码的每一部分
  • 表必须已经符合第一范式

所以本质上，任何符合1NF并且有一个单一属性的主码的表同时也符合第二范式了。
思考上面的CONCERT表格——它不属于第二范式。注意到Style属性用于描述artist的风格，它和CONCERT在哪儿演出（即venue）没有任何联系！因此它的值并不依赖主码的每一部分，所以不符合第二范式的规则。

这个规则是为了确保没有冗余的数据被存储。

比如，我们添加另一个Girls Aloud的演唱会记录到表格中

Venue [主码]Artist [主码]AttendanceProfitStyle
WembleyGirls Aloud5300012334Girl band
NECLeona Lewis4500066433Female soloist
NECGirls Aloud7609053789Girl band

注意到Girl band值是重复的，因此导致数据库比原来所需的更大。

构建一个2NF数据库

继续看CONCERT表

Venue [主码]Artist [主码]AttendanceProfitStyle
WembleyGirls Aloud5300012334Girl band
NECLeona Lewis4500066433Female soloist
NECGirls Aloud7609053789Girl band

这个表格需要分解，移除不依赖全部主码的非关键属性，保证它只被存储一次。

在这种情况下，STYLE表格拥有一个artist单一主码

CONCERT

Venue [主码]Artist [主码]AttendanceProfit
WembleyGirls Aloud5300012334
NECLeona Lewis4500066433
NECGirls Aloud7609053789

STYLE

Artist [主码]Style
Girls AloudGirl band
Leona LewisFemale soloist

现在，上面这两个表格已经符合2NF的规则了——每一个非关键属性依赖于全部主码。这里没有冗余的数据了。

构建一个2NF数据库 2

当然，可能有多个属性依赖主码的不同部分，考虑下面的表格

CONCERT

Venue [主码]Artist [主码]DateAttendanceProfitCityNo1HitsStyle
WembleyGirls Aloud1/10/095300012334London5Girl band
NECLeona Lewis1/10/094500066433Birmingham2Female soloist
NECGirls Aloud7/11/097609053789Birmingham5Girl band

像前面的Style属性只依赖于Artist一样，现在NO1Hits也只依赖于Artist。这个表格也包括了只依赖于Venue的City。

所以为了使表格符合第二范式，需要创建四个表格

CONCERT

VenueID [主码]Artist [主码]DateAttendanceProfit
00501121/10/095300012334
00601151/10/094500066433
00601127/11/097609053789

STYLE

Style ID [主码]Style
001Girl band
002Solo artist
003Rap

ARTIST

ArtistID [主码]ArtistNo1HitsStyleID
0112Girls Aloud20001
0115Leona Lewis3002

VENUE

Venue ID [主码]VenueCity
005WemblyLondon
006NECBirmingham

总结

第二范式的规则是

  • 非关键属性必须依赖主码的每一部分
  • 表必须已经符合第一范式

第三范式-3NF

对于一个属于3NF的数据库，需要符合一下规则：

  • 它已经是2NF
  • 没有任何非关键属性依赖其他非关键属性

这么做是为了发现冗余数据的其他来源。如果一个属性的值可以简单的通过表格中的其他属性获得，那么它就不需要存储在这张表格中了。把属性加载到另一张表，同时链接到它会使数据库变得更小。

思考下面的表格

CONCERT

Venue[主码]Artist[主码]Date[主码]AttendanceProfitCityCountry
WembleyGirls Aloud1/10/085300012334LondonUK
NECLeona Lewis1/10/084500066433BirminghamUK
Carnegie HallGirls Aloud7/11/087609053789New YorkUSA

注意到county国家能够通过城市获得——如果演唱会在伦敦举办，那么同时也可以得出也在英国举办——不需要查看主码！
所以为了使数据库符合第三范式，那么可以按下面分解该表格

CONCERT

Venue[主码]Artist[主码]Date[主码]AttendanceProfitCity
WembleyGirls Aloud1/10/085300012334London
NECLeona Lewis1/10/084500066433Birmingham
Carnegie HallGirls Aloud7/11/087609053789New York

CITIES

City[主码]Country
LondonUK
BiminghamUK
New YorkUSA

新的表格CITIES拥有一个City主码和county属性。Concert表格拥有City作为外码，因此现在你能够获取某一特定演唱会举办的国家，同时没有冗余数据产生。

3NF示例

提醒，3NF意味着

  • 它已经是一个2NF
  • 没有任何非关键属性依赖其他非关键属性
示例 1

CUSTOMER

CustomerID[主码]FirstnameSurnameCityPostCode
12123HarryEnfieldLondonSW7 2AP
12443LeonaLewisLondonWC2H 7JY
354SarahBrightmanCoventryCV4 7AL

这不完全符合3NF，因为City能够通过Postcode获得。如果你创建一个包含Postcode的表格，则City可以得到。

CustomerID[主码]FirstnameSurnamePostCode*
12123HarryEnfieldSW7 2AP
12443LeonaLewisWC2H 7JY
354SarahBrightmanCV4 7AL

POSTCODES

PostCode[主码]City
SW7 2APLondon
WC2H 7JYLondon
CV4 7ALCoventry
示例 2
VideoID[主码]TitleCertificateDescription
12123Saw IV18Eighteen and over
12443IgorPGParental Guidance
354BambiUUniversal Classification

Certificate（证书）意思的描述，即Description属性可以从Certificate属性获得——它并不需要查看参考主码VideoID。因此可以使用主码和辅助码的方式分解表格。

示例 3

CLIENT

ClientID[主码]CinemaID*CinemaAddress
12123LON231 Leicester Square. London
12443COV234 Bramby St, Coventry
354MAN456 Croydon Rd, Manchester

CINEMAS

CinemaID[主码]CinemaAddress
LON231 Leicester Square. London
COV234 Bramby St, Coventry
MAN456 Croydon Rd, Manchester

在这种情况下，数据库已经接近3NF，但是因为某些原因，CinemaAddress在CLIENT表格中重复了，即使它可以在CINEMAS表格中获得。因此可以简单的移除CLIENT中的CinemaAddress列。

示例 4

ORDER

OrderID[主码]QuantityPriceCost
12123210.0020.00
12443320.0060.00
354430.00120.00

在这种情况下，Cost能够通过Quantity乘以Price获得。这是一个计算域。数据库会比原本所需的大，因为原本任一菜单的消费能够通过一次查询计算出。因此为了完全符合3NF，需要移除Cost列。

规范化优点

  1. 数据库不含冗余数据，大小更小，节省存储成本
  2. 因为更少的数据需要搜索，因此查询效率更快
  3. 因为没有数据重复，可以更好的保持数据一致性和更少的错误
  4. 因为没有数据重复，所以存储多于2次不同数据的拷贝机会更少
  5. 一旦变化，变化能够立即级联任何相关的记录

规范化缺点

  1. 你需要细心地使数据保持原子性。仅仅因为你能够再次分解数据的类型，它并不总是正确的做法。例如，电话号码可能包含下面这些代码0123456789，但是将电话号码分解成两部分是不明智的。
  2. 和仅有一个未规范化的表格相比，你最后得到的是多个表格
  3. 数据库表格越多，越复杂，查询的速度会越慢
  4. 它需要分配更多的关系来表示大量表格之间的交互
  5. 对于更多表格，建立一个搜索会变得更加复杂

总结

规范化的目的是为了避免数据冗余和更好的维护数据库，只需在一处地方更新一个记录即可。

规范化的特性和范式：

未规范化形式(0NF)

  • 数据可能重复
  • 数据可能非原子性
  • 表格可能没有主码
  • 可能存在重复的域，也就是说每一个域的名字不是唯一的

第一范式(1NF)

  • 没有重复的或相似数据的列
  • 每一项都不能再分割
  • 每一行都是唯一的，也就是说数据库有一个主码
  • 每一个域都有一个唯一的名字

第二范式(2NF)

  • 表必须已经符合第一范式
  • 非关键属性必须依赖主码的每一部分

第三范式(3NF)

  • 它已经是2NF
  • 没有任何非关键属性依赖其他非关键属性

原文链接：Database Design
本文链接：数据库设计

转载于:https://www.cnblogs.com/cposture/p/5053853.html

weixin_34259232
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
数据库设计基础[翻译]
weixin_30828379的博客
07-12 213
译者小语: 原文讲的是针对Microsoft Office Access 2007的数据库设计, 不过个人认为文章内容对其他数据库的设计也适用. 译文: 此文提供关于规划一个数据库的指导。你将学到怎样确定什么资料是你所需要的， 怎样划分资料到适当的表和列，以及这些表格如何相互关联到对方。 妥善设计的数据库，可以提供切合时宜的，准确的信息让你访问。 从事与数据库有关的工作...
what is the normal form in English
ctpyfkdu018623的博客
02-24 138
All relational databases require unique keys to identify primary table rows.A key is required whenever we need to ...
数据库范式的选择使用
10-03 173
关系型数据库：关系模式设计原则 1.范式与数据冗余度从0NF到1NF、2NF、3NF、BCNF、4NF、5NF？数据库设计的过程是个拆分表的过程，拆分的目的是降低数据的冗余度。 数据的冗余度越低，事务持续时间就越短（它不需要额外的操作去维持数据一致性和完整性）。与此同时，拆得越细，查询的代价越高（需要更多耗时的连接运算）。 2.关系模式的设计原则 如果表（集）主要用于数据更新（O...
数据库学习第二季大结局：以一些实例看数据模式规范化
weixin_34275734的博客
11-29 334
为什么80%的码农都做不了架构师？>>> ...
数据库1NF 2NF 3NF范式解释
在下李逍遥的博客
07-13 8544
范式（NF）”是什么意思。按照教材中的定义，范式是“符合某一种级别的关系模式的集合，表示一个关系内部各属性之间的联系的合理化程度”。 数据库范式也分为1NF，2NF，3NF，BCNF，4NF，5NF。一般在我们设计关系型数据库的时候，最多考虑到BCNF就够。符合高一级范式的设计，必定符合低一级范式，例如符合2NF的关系模式，必定符合1NF。
数据库营销——一对一营销新范式.doc
05-09
数据库营销——一对一营销新范式.doc
数据库——列车订票系统设计
09-03
包括系统分析，功能模块图，分、总ER图，系统关系模型和表设计（满足第三范式）及创建，系统界面设计，以及表创建和界面功能的SQL语句实现。
数据库编程技术3——关系数据库设计核心
12-14
2、关系数据库设计理论有三个方面的内容：函数依赖、范式和模式设计。函数依赖起核心作用， 它是模式分解和模式设计的基础，范式是模式分解的标准。 【例1】设计一个学生课程数据库，其关系模式SDSC(Sno, Sname, Age...
范式解析——数据库
05-23
范式解析——数据库
“MySQL数据库”课程教学难点分析——以数据库设计为例.pdf
10-10
数据库系统设计最为关键的问题是范式化的选择，规范的 normalization 设计过程，不仅要小心、自动去除冗余，还要解决数据库内的数据冗余问题。规范规则是数学.ibm 生和研究人员一起提出数学规则，并创建相应的规则，...
数据库的1NF,2NF和3NF的区别
Paul_Huang的Footprint
05-10 1万+
1NF（第一范式） 1NF的限定条件如下： 1. 每个列必须有一个唯一的名称 2. 行和列的次序无关紧要 3. 每一列都必须有单个数据类型 4. 不允许包含相同值的两行 5. 每一列都必须包含一个单值 （一个列不能保存多个数据值） 6. 列不能包含重复的组 第一范式会存在更新、删除和插入异常。 2NF（第二范式） 2NF的限定条件如下： 1. 它符合第一范式 2
数据库范式简单讲解(1NF、2NF、3NF、4NF、BCNF)
Seven
08-29 5万+
    近期在学习数据库范式，这很是让博主纠结了一阵呢，所以简单总结一下，奉上一点案例分析，与您分享~   一、概念        R-关系模式      r-关系      U-属性集      FD-函数依赖      X→Y："X函数决定Y"，"Y函数依赖于X"。      A⊆B   A包含于B，A小，B大，B→A        元组：二维表中的行      属性：...
一看就懂的数据库范式介绍（1NF—5NF)
若是凉夜已成梦
01-08 5117
一、基本介绍设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。满足最低要求的范式是第一范式（1NF）。在第一范式的基础上进一步满足更多规范
用实例讲SQL三大范式
luckdog_hot的专栏
05-20 2451
 第一范式(1NF)(必须有主键，列不可分)数据库表中的任何字段都是单一属性的，不可再分 create table aa(id int,NameAge varchar(100)) insert aa values(1,无限-女) 没有达到第一范式 create table aa(id int,name varcahr(10),age char(2
数据库范式讲解(1NF、2NF、3NF、4NF、BCNF)
0729Liang
05-23 6705
一、概念     R-关系模式     r-关系     U-属性集     FD-函数依赖     X→Y："X函数决定Y"，"Y函数依赖于X"。     A⊆B   A包含于B，A小，B大，B→A      元组：二维表中的行     属性：二维表中的列      超键：能唯一标识元祖的属性集     候选键：不含多余属性的超建     主键：用户选作元组标识的候选键     外键：对于当前模...
范式通俗理解：1NF、2NF、3NF和BNCF
热门推荐
Yesterday You Said Tomorrow.
10-24 12万+
范式通俗理解：1NF、2NF、3NF和BNCF准备知识超键、候选键、主键函数依赖部分依赖传递依赖范式1NF2NF3NFBCNF参考 准备知识 超键、候选键、主键 超键 超键(super key)：在关系中能唯一标识元组的属性集称为关系模式的超键 候选键 候选键(candidate key)：不含有多余属性的超键称为候选键。也就是关系中的一个属性组，其值能唯一标识一个元组。若从属性组中去掉任...
【redis的基本数据类型】
最新发布
m0_50116974的博客
06-13 513
压缩列表的基本信息包括压缩列表的大小，压缩列表的长度以及最后一个entry的偏移，之所以要有这个偏移，是为了找到最后一个entry,而每个entry都记录上一个元素的大小，通过计算就知道上一个entry的地址，这样方便的从后向前进行遍历。的结构，其分为两部分，8字节的Redis对象元数据信息，8字节的指针，其中Redis对象的元数据信息存储了类型的LRU信息，真正的编码格式等等，而如果字符串存储的是数字类型，则复用了8字节的指针的位置。的操作，但是当列表的元素非常少的时候，其内部使用。
canal应用
qq_33816292的博客
06-12 130
canal分享模块链接。
教务系统数据库设计范式规范
05-26
教务系统数据库设计应该遵循数据库设计的范式规范，这样可以保证数据库的数据一致性、完整性和可靠性。常用的数据库设计范式规范有三个：第一范式、第二范式和第三范式。 第一范式（1NF）要求关系模型中的属性值不...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值