关系数据 规范化的理解
原則：
規范化的目的是一份數據只存儲在一個地方。
?
根據上面的原則來理解3種范式：
第一范式：
列的原子性；
保證行的唯一性---一份數據只存儲在一個地方。
第二范式：非屬性鍵與主鍵的關系
1.滿足第一范式
2.非鍵屬性依賴于整體主鍵，而不是非鍵屬性僅僅依賴于主鍵中的某個部分。即：無部分依賴:
????? 違反第二范式就是存在部分依賴（非鍵屬性僅僅依賴于主鍵中的某個部分）。
違反第二范式這有點像：
? ? ? 在一個由諸多長老全部舉手表才能表決的組織里，你卻只聽一個或個別長老的話，這可是壞了規矩的。
?
例如，如下的關系就違背了第二范式：
關系名：PersonPet（人寵物）????
主鍵：PesonId 、PetId
非鍵屬性：PesonName、PetName、PetType
違背第二范式：PesonName只依賴于PesonId
????????????????????PetName只依賴于PetId
舉個例子，違反了第二范式存儲的數據的樣子：
PesonId?? ?PetId???????????PesonName????PetName?
????? 1????????? 1??????????????????? 人才1?????????? 寵物1
??????2????????? 2??????????????????? 人才2????????? ?寵物2
????? 3????????? 1????????????????????人才3 ??????????寵物1
在現實生活中，人和寵物的關系是多對多的關系，即：
1個人可以有0、1、1以上個寵物
1個寵物可以屬于0（如流浪狗）、1（單身IT男）、1個以上（一對情侶）個人
我們從上表因為違反第二范式而存儲的數據違反規范化的原則：
規范化的目的是一份數據只存儲在一個地方。
?
?即：PetId為1的寵物，在存儲數據的時候，被復制了多次，存放的不同的地方。
這樣會對數據的增、刪、改。會有什么影響：
增:
1.通常來說，當需要對單個事物（單個人、單個寵物）進行處理，而不是處理他們之間關系時，
?? 因為沒有專門為“人”這個實體建立了的表（如:Person表）為了增加一個人，不得不在PersonPet（人寵物表）中添加人
???的相關信息，而在“寵物”相關的列輸入無意義的值。
???在單獨查詢人（不查詢寵物）的時，不得不額外去除掉那些來自寵物相關信息。
??
???2.只要一個人有多個寵物,這個人的信息將被多次復制。同樣：
?? 3.只要一個寵物屬于多個人，這個寵物的信息也將被多少復制。???
?
刪：
當需要對單個事物（單個人、單個寵物）進行處理，而不是處理他們之間關系時，對刪除的影響：
如果PesonId為1和3（這對情侶可能同時出現車禍）的人都沒，要刪除這兩個人，存儲的數據就是這樣的：
PesonId?? PetId??????? PesonName??????? ?PetName
NULL????????????1???????????????NULL?????????????????寵物1
?? 2???????????? ?2?????????????? 人才2?????????????????寵物2
NULL????????????1???????????????NULL?????????????????寵物1
?
可以看到這樣的設計基本廢掉了。
改：
數據同步問題，?例如：通過主鍵（PesonId ，PetId）=（1,1）修改?PetName的值“寵物1”為“寵物007”，如果在編程時沒有
注意同步
PesonId?? PetId??? PesonName? ?PetName
?3????????????? 1??????????? 人才3???????? 寵物1
那么就破壞了數據。
?
第三范式：非屬性鍵之間的關系
1.滿足第二范式
2.非屬性鍵不依賴于非屬性鍵，即：不存在傳遞依賴。
?
違反第三范式這有點像：
? ? ? 在朝廷中有個皇帝（主鍵）就夠了，有人結黨私營，搞小團體，聽命于一個小頭目（非屬性鍵依賴于非屬性鍵），也是壞了規矩的。
?
Book表
主鍵：BookIsbnNunmber
非屬性鍵：Title
?????????????? Price
?????????????? PublishName
?????????????? PublishCity
?
這個表滿足了第二范式.
但是違反了第三范式：
非屬性鍵PublishCity依賴于非屬性鍵PublishName。
?
違反了第三范式將導致如下問題，例如下面違反了第三范式的表存儲的數據：
BookIsbnNunmber???? Title????????????????Price?????? PublishName?????? PublishCity
?? 1001???????????????? 《我是人才》????? ? 63.1??????????人才出版社??????????? 地球村
???1002???????????????? 《我是蠢材》??????? ?87.2???????? 人才出版社??????????? 地球村
?
按常規，我們都是通過“主鍵”去唯一定位要修改的數據,所以，用如下SQL語句：
Update adb.Book
Set PublishCity='月亮城'
Where BookIsbnNunmber=‘1001’;
執行以上SQL后，表中的數據如下：
BookIsbnNunmber??????? Title????????????? Price???????PublishName?? PublishCity
1001?????????????????????? 《我是人才》?????? 63.1???????? 人才出版社????? 月亮城
1002?????????????????????? 《我是蠢材》???????87.2???????? 人才出版社?????? 地球村
?
這就產生了數據同步的問題，數據在更新時被破壞了。
?PublishName???? PublishCity
人才出版社?????? ??? 月亮城
人才出版社?????????? 地球村
由于違反了第三范式（非屬性鍵PublishCity依賴于非屬性鍵PublishName），
我們就得寫額外的處理去更新所有列的PublishName
Update adb.Book
Set PublishCity='月亮城'
Where PublishCity='地球村' And PublishName='人才出版社'
這樣，說明一點，違反第三范式，為了更細數據時，避免非屬性鍵之間依賴產生的數據同步問題，不得不
????????進行而不處理數據同步問題，但是這額外的同步數據操作很容易被忘記，
???????? 更糟糕的是，系統的關系會隨著時間的關系不斷變化，你也將越來越頭痛。
?
?
?
?
?
?
?
?
?
?
?
?
?????
?
?
?
轉載于:https://www.cnblogs.com/easy5weikai/archive/2013/06/12/3133177.html
總結
以上是生活随笔為你收集整理的关系数据 规范化的理解的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： GSM-串口和GPRS-网口通信
- 下一篇： 如何打开.etl文件？