作者:寒小陽
時間:2013年8月。
出處:http://blog.csdn.net/han_xiaoyang/article/details/10473845。
聲明:版權所有,轉載請注明出處,謝謝。
一、相關概念和知識點
1.:反映一個關系內(nèi)部屬性與屬性之間的約束關系,是現(xiàn)實世界屬性間相互聯(lián)系的抽象,屬于數(shù)據(jù)內(nèi)在的性質和語義的體現(xiàn)。
:是用來設計良好的關系模式的基本理論。它通過分解關系模式來消除其中不合適的數(shù)據(jù)依賴,以解決插入異常、刪除異常、更新異常和數(shù)據(jù)冗余問題。
:簡單地說,對于關系模式的兩個屬性子集X和Y,若X的任一取值能唯一確定Y的值,則稱Y函數(shù)依賴于X,記作X→Y。
:對于關系模式的兩個屬性子集X和Y,如果X→Y,但Y!?X,則稱X→Y為非平凡函數(shù)依賴;如果X→Y,但Y?X,則稱X→Y為非平凡函數(shù)依賴。
:對于關系模式的兩個屬性子集X和Y,如果X→Y,并且對于X的任何一個真子集X',都沒有X'→Y,則稱Y對X完全函數(shù)依賴。
:指符合某一種級別的關系模式的集合。在設計關系數(shù)據(jù)庫時,根據(jù)滿足依賴關系要求的不同定義為不同的范式。
:指將一個低一級范式的關系模式,通過模式分解轉換為若干個高一級范式的關系模式的集合的過程。
:若關系模式的所有屬性都是不可分的基本數(shù)據(jù)項,則該關系模式屬于1NF。
:1NF關系模式如果同時滿足每一個非主屬性完全函數(shù)依賴于碼,則該關系模式屬于2NF。
:若關系模式的每一個非主屬性既不部分依賴于碼也不傳遞依賴于碼,則該關系模式屬于3NF。
:若一個關系模式的每一個決定因素都包含碼,則該關系模式屬于BCNF。
:是指對于一個給定的應用環(huán)境,構造優(yōu)化的數(shù)據(jù)庫邏輯模式和物理結構,并據(jù)此建立數(shù)據(jù)庫及其應用系統(tǒng),使之能夠有效地存儲和管理數(shù)據(jù),滿足各種用戶的應用需求,包括信息管理要求和數(shù)據(jù)操作要求。
數(shù)據(jù)庫設計的6個基本步驟:
,
,
,
,
,
和
。
:指將需求分析得到的用戶需求抽象為信息結構即概念模型的過程。也就是通過對用戶需求進行綜合、歸納與抽象,形成一個獨立于具體DBMS的概念模型。
:將概念結構模型(基本E-R圖)轉換為某個DBMS產(chǎn)品所支持的數(shù)據(jù)模型相符合的邏輯結構,并對其進行優(yōu)化。
:指為一個給定的邏輯數(shù)據(jù)模型選取一個最適合應用環(huán)境的物理結構的過程。包括設計數(shù)據(jù)庫的存儲結構與存取方法。
:指對實際的人、物、事和概念進行人為處理,抽取所關心的共同特性,忽略非本質的細節(jié),并把這些特性用各種概念精確地加以描述,這些概念組成了某種模型。
數(shù)據(jù)庫設計必須遵循
和
結合的原則。
數(shù)據(jù)字典主要包括
、
、
、
和
五個部分。
三種常用抽象方法是
、
和
。
局部 E-R 圖之間的沖突主要表現(xiàn)在
、
和
三個方面。
數(shù)據(jù)庫常用的存取方法包括
、
和
三種。
確定數(shù)據(jù)存放位置和存儲結構需要考慮的因素主要有:
、
和
等。
二、細說數(shù)據(jù)庫三范式
第一范式(1NF)中數(shù)據(jù)庫表的每一列都是不可分割的基本數(shù)據(jù)項
同一列中不能有多個值
即實體中的某個屬性不能有多個值或者不能有重復的屬性。
簡而言之,第一范式就是無重復的列。
在任何一個關系數(shù)據(jù)庫中,第一范式(1NF)是對關系模式的基本要求,不滿足第一范式(1NF)的數(shù)據(jù)庫就不是關系數(shù)據(jù)庫。
滿足第二范式(2NF)必須先滿足第一范式(1NF)。
第二范式(2NF)要求數(shù)據(jù)庫表中的每個實例或行必須可以被惟一地區(qū)分。
為實現(xiàn)區(qū)分通常需要為表加上一個列,以存儲各個實例的惟一標識。
第二范式(2NF)要求實體的屬性完全依賴于主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性,如果存在,那么這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體,新實體與原實體之間是一對多的關系。為實現(xiàn)區(qū)分通常需要為表加上一個列,以存儲各個實例的惟一標識。簡而言之,第二范式就是屬性完全依賴于主鍵。
滿足第三范式(3NF)必須先滿足第二范式(2NF)。
簡而言之,第三范式(3NF)要求一個數(shù)據(jù)庫表中不包含已在其它表中已包含的非主關鍵字信息。
例如,存在一個部門信息表,其中每個部門有部門編號(dept_id)、部門名稱、部門簡介等信息。那么在的員工信息表中列出部門編號后就不能再將部門名稱、部門簡介等與部門有關的信息再加入員工信息表中。如果不存在部門信息表,則根據(jù)第三范式(3NF)也應該構建它,否則就會有大量的數(shù)據(jù)冗余。簡而言之,第三范式就是屬性不依賴于其它非主屬性。
下面列舉一個學校的學生系統(tǒng)的實例,以示幾個范式的應用。
在設計數(shù)據(jù)庫表結構之前,我們先確定一下要設計的內(nèi)容包括那些。學號、學生姓名、年齡、性別、課程、課程學分、系別、學科成績,系辦地址、系辦電話等信息。為了簡單我們暫時只考慮這些字段信息。我們對于這些信息,說關心的問題有如下幾個方面。
1)學生有那些基本信息
2)學生選了那些課,成績是什么
3)每個課的學分是多少
4)學生屬于那個系,系的基本信息是什么。
:數(shù)據(jù)庫表中的字段都是單一屬性的,不可再分。這個單一屬性由基本類型構成,包括整型、實數(shù)、字符型、邏輯型、日期型等。在當前的任何關系數(shù)據(jù)庫管理系統(tǒng)(DBMS)中,不允許你把數(shù)據(jù)庫表的一列再分成二列或多列,因此做出的都是符合第一范式的數(shù)據(jù)庫。
,把所有這些信息放到一個表中(學號,學生姓名、年齡、性別、課程、課程學分、系別、學科成績,系辦地址、系辦電話)下面存在如下的依賴關系。
1)(學號)→ (姓名, 年齡,性別,系別,系辦地址、系辦電話)
2) (課程名稱) → (學分)
3)(學號,課程)→ (學科成績)
根據(jù)依賴關系我們可以把選課關系表SelectCourse改為如下三個表:
學生:Student(學號,姓名, 年齡,性別,系別,系辦地址、系辦電話);
課程:Course(課程名稱, 學分);
選課關系:SelectCourse(學號, 課程名稱, 成績)。
事實上,對照第二范式的要求,這就是滿足第二范式的數(shù)據(jù)庫表,若不滿足第二范式,會產(chǎn)生如下問題
數(shù)據(jù)冗余: 同一門課程由n個學生選修,"學分"就重復n-1次;同一個學生選修了m門課程,姓名和年齡就重復了m-1次。
更新異常:
1)若調整了某門課程的學分,數(shù)據(jù)表中所有行的"學分"值都要更新,否則會出現(xiàn)同一門課程學分不同的情況。
2)假設要開設一門新的課程,暫時還沒有人選修。這樣,由于還沒有"學號"關鍵字,課程名稱和學分也無法記錄入數(shù)據(jù)庫。
刪除異常 :
假設一批學生已經(jīng)完成課程的選修,這些選修記錄就應該從數(shù)據(jù)庫表中刪除。但是,與此同時,課程名稱和學分信息也被刪除了。很顯然,這也會導致插入異常。
,接著看上面的學生表Student(學號,姓名, 年齡,性別,系別,系辦地址、系辦電話),關鍵字為單一關鍵字"學號",因為存在如下決定關系:
(學號)→ (姓名, 年齡,性別,系別,系辦地址、系辦電話)
但是還存在下面的決定關系
(學號) → (所在學院)→(學院地點, 學院電話)
即存在非關鍵字段"學院地點"、"學院電話"對關鍵字段"學號"的傳遞函數(shù)依賴。
它也會存在數(shù)據(jù)冗余、更新異常、插入異常和刪除異常的情況(這里就不具體分析了,參照第二范式中的分析)。根據(jù)第三范式把學生關系表分為如下兩個表就可以滿足第三范式了:
學生:(學號, 姓名, 年齡, 性別,系別);
系別:(系別, 系辦地址、系辦電話)。