1. 程式人生 > >DB設計三大正規化

DB設計三大正規化

資料庫的設計正規化是資料庫設計所需要滿足的規範,滿足這些規範的資料庫是簡潔的、結構明晰的,同時,不會發生插入(insert)、刪除(delete)和更新(update)操作異常。反之則是亂七八糟,不僅給資料庫的程式設計人員製造麻煩,而且面目可憎,可能儲存了大量不需要的冗餘資訊。

正規化說明

1.1 第一正規化(1NF)無重複的列

    所謂第一正規化(1NF)是指資料庫表的每一列都是不可分割的基本資料項,同一列中不能有多個值,即實體中的某個屬性不能有多個值或者不能有重複的屬性。如果出現重複的屬性,就可能需要定義一個新的實體,新的實體由重複的屬性構成,新實體與原實體之間為一對多關係。在第一正規化(1NF)中表的每一行只包含一個例項的資訊。簡而言之,第一正規化就是無重複的列。

說明:在任何一個關係資料庫中,第一正規化(1NF)是對關係模式的基本要求,不滿足第一正規化(1NF)的資料庫就不是關係資料庫。

例如,如下的資料庫表是符合第一正規化的:

欄位1

欄位2

欄位3

欄位4

而這樣的資料庫表是不符合第一正規化的:

欄位1

欄位2

欄位3

欄位4

欄位3.1

欄位3.2

資料庫表中的欄位都是單一屬性的,不可再分。這個單一屬性由基本型別構成,包括整型、實數、字元型、邏輯型、日期型等。很顯然,在當前的任何關係資料庫管理系統(DBMS)中,傻瓜也不可能做出不符合第一正規化的資料庫,因為這些DBMS不允許你把資料庫表的一列再分成二列或多列。因此,你想在現有的DBMS中設計出不符合第一正規化的資料庫都是不可能的。

1.2 第二正規化(2NF)屬性完全依賴於主鍵 [ 消除部分子函式依賴 ]

如果關係模式R為第一正規化,並且R中每一個非主屬性完全函式依賴於R的某個候選鍵, 則稱為第二正規化模式。

第二正規化(2NF)是在第一正規化(1NF)的基礎上建立起來的,即滿足第二正規化(2NF)必須先滿足第一正規化(1NF)。第二正規化(2NF)要求資料庫表中的每個例項或行必須可以被惟一地區分。為實現區分通常需要為表加上一個列,以儲存各個例項的惟一標識。這個惟一屬性列被稱為主關鍵字或主鍵、主碼。

例如員工資訊表中加上了員工編號(emp_id)列,因為每個員工的員工編號是惟一的,因此每個員工可以被惟一區分。

簡而言之,第二正規化(2NF)就是非主屬性完全依賴於主關鍵字。

所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性(設有函式依賴W→A,若存在XW,有X→A成立,那麼稱W→A是區域性依賴,否則就稱W→A是完全函式依賴)。如果存在,那麼這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體,新實體與原實體之間是一對多的關係。

假定選課關係表為SelectCourse(學號, 姓名, 年齡, 課程名稱, 成績, 學分),關鍵字為組合關鍵字(學號, 課程名稱),因為存在如下決定關係:

(學號, 課程名稱) → (姓名, 年齡, 成績, 學分)

這個資料庫表不滿足第二正規化,因為存在如下決定關係:

(課程名稱) → (學分)

(學號) → (姓名, 年齡)

即存在組合關鍵字中的欄位決定非關鍵字的情況。

由於不符合2NF,這個選課關係表會存在如下問題:

(1) 資料冗餘:

同一門課程由n個學生選修,"學分"就重複n-1次;同一個學生選修了m門課程,姓名和年齡就重複了m-1次。

(2) 更新異常:

若調整了某門課程的學分,資料表中所有行的"學分"值都要更新,否則會出現同一門課程學分不同的情況。

(3) 插入異常:

假設要開設一門新的課程,暫時還沒有人選修。這樣,由於還沒有"學號"關鍵字,課程名稱和學分也無法記錄入資料庫。

(4) 刪除異常:

假設一批學生已經完成課程的選修,這些選修記錄就應該從資料庫表中刪除。但是,與此同時,課程名稱和學分資訊也被刪除了。很顯然,這也會導致插入異常。

把選課關係表SelectCourse改為如下三個表:

學生:Student(學號, 姓名, 年齡);

課程:Course(課程名稱, 學分);

選課關係:SelectCourse(學號, 課程名稱, 成績)。

這樣的資料庫表是符合第二正規化的, 消除了資料冗餘、更新異常、插入異常和刪除異常。

另外,所有單關鍵字的資料庫表都符合第二正規化,因為不可能存在組合關鍵字。

1.3 第三正規化(3NF)屬性不依賴於其它非主屬性 [ 消除傳遞依賴 ]

如果關係模式R是第二正規化,且每個非主屬性都不傳遞依賴於R的候選鍵,則稱R為第三正規化模式。

    滿足第三正規化(3NF)必須先滿足第二正規化(2NF)。第三正規化(3NF)要求一個數據庫表中不包含已在其它表中已包含的非主關鍵字資訊。

例如,存在一個部門資訊表,其中每個部門有部門編號(dept_id)、部門名稱、部門簡介等資訊。那麼在的員工資訊表中列出部門編號後就不能再將部門名稱、部門簡介等與部門有關的資訊再加入員工資訊表中。如果不存在部門資訊表,則根據第三正規化(3NF)也應該構建它,否則就會有大量的資料冗餘。

第三正規化(3NF):在第二正規化的基礎上,資料表中如果不存在非關鍵欄位對任一候選關鍵欄位的傳遞函式依賴則符合第三正規化。簡而言之,第三正規化就是屬性不依賴於其它非主屬性。

所謂傳遞函式依賴,指的是如果存在"A → B → C"的決定關係,則C傳遞函式依賴於A。

因此,滿足第三正規化的資料庫表應該不存在如下依賴關係:

關鍵欄位 → 非關鍵欄位x → 非關鍵欄位y

假定學生關係表為Student(學號, 姓名, 年齡, 所在學院, 學院地點, 學院電話),關鍵字為單一關鍵字"學號",因為存在如下決定關係:

(學號) → (姓名, 年齡, 所在學院, 學院地點, 學院電話)

這個資料庫是符合2NF的,但是不符合3NF,因為存在如下決定關係:

(學號) → (所在學院) → (學院地點, 學院電話)

即存在非關鍵欄位"學院地點"、"學院電話"對關鍵欄位"學號"的傳遞函式依賴。

它也會存在資料冗餘、更新異常、插入異常和刪除異常的情況,讀者可自行分析得知。

把學生關係表分為如下兩個表:

學生:(學號, 姓名, 年齡, 所在學院);

學院:(學院, 地點, 電話)。

這樣的資料庫表是符合第三正規化的,消除了資料冗餘、更新異常、插入異常和刪除異常。

相關推薦

DB設計三大正規化

資料庫的設計正規化是資料庫設計所需要滿足的規範,滿足這些規範的資料庫是簡潔的、結構明晰的,同時,不會發生插入(insert)、刪除(delete)和更新(update)操作異常。反之則是亂七八糟,不僅給資料庫的程式設計人員製造麻煩,而且面目可憎,可能儲存了大量不需要的冗餘

資料庫設計三大正規化和五大約束

【三大正規化】 第一正規化(1NF):   資料表中的每一列(欄位),必須是不可拆分的最小單元,也就是確保每一列的原子性。   例如: userInfo: '山東省煙臺市 1318162008' 依照第一正規化必須拆分成        &

資料庫系統學習筆記--關係設計三大正規化

第一正規化(1NF) 定義:資料庫表的每一列都是不可分割的原子資料項,而不能是集合,陣列,記錄等非原子資料項。如果實體中的某個屬性有多個值時,必須拆分為不同的屬性。 說明:E-R模型允許實體集和聯絡集具有某些程度的子結構,比如多值屬性(一個教師有多個電話號碼)、組合屬性(包含多個子屬性,

轉:資料庫設計三大正規化

http://www.cnblogs.com/linjiqin/archive/2012/04/01/2428695.html 為了建立冗餘較小、結構合理的資料庫,設計資料庫時必須遵循一定的規則。在關係型資料庫中這種規則就稱為正規化。正規化是符合某一種設計要求的總結。要想設計一個結構合理的關係型資料庫,必須

資料庫設計三大正規化簡析

為了建立冗餘較小、結構合理的資料庫,設計資料庫時必須遵循一定的規則。在關係型資料庫中這種規則就稱為正規化。正規化是符合某一種設計要求的總結。要想設計一個結構合理的關係型資料庫,必須滿足一定的正規化。       在實際開發中最為常見的設計正規化有三

資料庫表設計三大正規化原則

a  所有欄位值都是不可分解的原子值 b  也就是說在一個數據庫表中,一個表中只能儲存一種資料,不可以把多種資料儲存在同一張資料庫表中 c   資料表中的每一列資料都和主鍵直接相關,而不能間接相關 1.第一正規化(確保每列保持原子性) 第一正規化是最基本的正規化。如果資料

資料庫設計三大正規化

為了建立冗餘較小、結構合理的資料庫,設計資料庫時必須遵循一定的規則。在關係型資料庫中這種規則就稱為正規化。正規化是符合某一種設計要求的總結。要想設計一個結構合理的關係型資料庫,必須滿足一定的正規化。 在實際開發中最為常見的設計正規化有三個: 1.第一正規化(確保每

Python設計三大正規化

為了建立冗餘較小、結構合理的資料庫,設計資料庫時必須遵循一定的規則。在關係型資料庫中這種規則就稱為正規化。正規化是符合某一種設計要求的總結。要想設計一個結構合理的關係型資料庫,必須滿足一定的正規化。在實際開發中最為常見的設計正規化有三個:1.第一正規化(確保每列保持原子性)第

關係型資料庫設計三大正規化

1.何為資料庫正規化? 設計關係資料庫時,遵從不同的規範要求,設計出合理的關係型資料庫,這些不同 規範要求被稱為不同的正規化,各種正規化呈遞次規範,越高的正規化資料庫冗餘越小。 目前關係資料庫有六種正規化:第一正規化(1NF)、第二正規化(2NF)、第

資料庫設計三大正規化NF

       國內絕大多數院校用的王珊的《資料庫系統概論》這本教材,某些方面並沒有給出很詳細很明確的解釋,與實際應用聯絡不那麼緊密,你有這樣的疑問也是挺正常的。我教《資料庫原理》這門課有幾年了,有很多學生提出了和你一樣的問題

資料庫設計三大正規化,分散計算思想

資料庫設計的三大正規化 1第一正規化:做到每列不可拆分,(一列資料中不要出現可以拆分的資料) 2.第二正規化:確保一個表只做一件事情(不要讓一個表儲存的資料可以做多個事情) 3.第三正規化:在滿足正規化二時,消除表的傳遞依賴。(比如說,表A裡的資料可以通過表A的其他資料

資料庫設計原則之三大正規化

                     首先宣告,本文為筆記記錄。可能不適合作為部落格文章,所以如果看著不舒服,還望“另請高明”,(^__^) 嘻嘻……資料庫設計的時候有三大正規化,現簡述如下:第一正規化(1NF): 原子性,資料不可再分原則就是使得表列為原子性,每一個欄位內容不能再分解。第二正規化(2NF

Oracle學習總結(2)——Oracle資料庫設計總結(三大正規化

一、實體與表對應關係 表<=>實體,欄位<=>屬性。 二、表與表的關係(實體間的關係):一對一、一對多、多對多 一對一:一條記錄只對應其他表中的一條記錄有關係 學生基本資訊表t_student,成績表t_studentScore含有一個外來

【轉】資料庫的設計(E-R圖,資料庫模型圖,三大正規化

一.資料庫設計的概念 資料庫設計是將資料庫中的資料實體及這些資料實體之間的關係,進行規劃和結構化的過程. 二.資料庫設計的重要性 如果一個數據庫沒有進行一個良好的設計,那麼這個資料庫完成之後他的缺點是: 1.效率會很低 2更新和檢索資料時會出現很多問題, 反之,一個數據庫被盡心策劃了一番,具有良好的設計,那他

資料庫設計——步驟、E-R圖、三大正規化

一、資料庫設計步驟(1)收集資訊(2)標識實體(3)標識每個實體需要儲存的詳細資訊(4)標識實體間的關係二、E-R圖*****矩形表示實體集*****橢圓表示實體*****菱形表示關係*****直線用來連線屬性和實體集,也用來連線實體集和聯絡集三、三大正規化(Normal F

資料庫設計三大正規化、BCNF、4NF

一、理解資料庫的正規化需要理解幾個基本概念: 碼:表中可以唯一確定一個元組的某個屬性(或者屬性組),如果這樣的碼有不止一個,那麼大家都叫候選碼,我們從候選碼中挑一個出來做老大,它就叫主碼。相當於鍵值的意思。 主屬性:一個屬性只要在任何一個候選碼中出現過,這個屬性就是主屬性

資料設計三大基本正規化

第一正規化: 所有屬性都是原子性的,即不可拆分。 這是關係型資料庫最基本的要求。 正例: 反例: 第二正規化 滿足第一正規化的情況下,所有非主屬性都完全依賴於候選關鍵字。 這是正規化主要針對關

SqlServer資料庫三大正規化設計標準

1 概述 一般地,在進行資料庫設計時,應遵循三大原則,也就是我們通常說的三大正規化,即第一正規化要求確保表中每列的原子性,也就是不可拆分;第二正規化要求確保表中每列與主鍵相關,而不能只與主鍵的某部分相關(主要針對聯合主鍵),主鍵列與非主鍵列遵循完全函式

關於數據庫設計三大範式

3-9 個數 logs 訂單 根據 添加 原子 mage 分解   為了建立冗余較小、結構合理的數據庫,設計數據庫時必須遵循一定的規則。在關系型數據庫中這種規則就稱為範式。範式是符合某一種設計要求的總結。要想設計一個結構合理的關系型數據庫,必須滿足一定的範式。   在實際開

數據庫設計三大範式

ron 獲取 結構 用戶 聯合主鍵 產生 重新 設計 一個數據庫 為了建立冗余較小、結構合理的數據庫,設計數據庫時必須遵循一定的規則。在關系型數據庫中這種規則就稱為範式。範式是符合某一種設計要求的總結。要想設計一個結構合理的關系型數據庫,必須滿足一定的範式。 在實際開發