㈠ 資料庫模式分解的原則是什麼
關系模式的分解准則
關系模式的規范化過程是通過對關系模式的分解來實現的。把低一級的關系模式分解為若干個高一級的關系模式。這種分解不是唯一的。
規范化的方式是進行模式分解，模式分解的原則是與原模式等價，模式分解的標準是：
模式分解具有無損連接性
模式分解能夠保持函數依賴
舉例：關系規范化過程
第一範式（1NF）：如果一關系模式，它的每一個分量是不可分的數據項，即其域為簡單域，則此關系模式為第一範式。
例：將學生簡歷及選課等數據設計成一個關系模式STUDENT， 其表示為：
STUDENT（SNO,SNAME,AGE,SEX,CLASS,DEPTNO,DEPTNAME,CNO,
CNAME,SCORE,CREDIT）
設該關系模式滿足下列函數依賴：
F＝{SNO-->SNAME, SNO-->AGE, SNO-->SEX, SNO-->CLASS,CLASS-->DEPTNO, DEPTNO-->DEPTNAME, CNO-->CNAME,SNO.CNO-->SCORE, CNO-->CREDIT}
由於該關系模式的每一屬性對應的域為簡單域，即其域值不可再分，符合第一範式定義，所以STUDENT關系模式為第一範式。
第二範式（2NF）：若關系模式R?1NF，且每個非主屬性完全函數依賴於碼，則稱R?2NF。
分析一下關系模式STUDENT， 它是不是2NF ？
屬性組（SNO，CNO）為關系STUDENT的碼。
例如：SNAME非主屬性，根據碼的特性具有：SNO.CNO??SNAME
根據STUDENT關系模式已知函數依賴集，下列函數依賴成立：SNO??SNAME
所以SNO.CNO??SNAME, SNAME對碼是部分函數依賴。同樣方法可得到除SCORE屬性外，其它非主屬性對碼也都是部分函數依賴。所以STUDENT關系模式不是2NF。
當關系模式R是1NF而不是2NF的模式時，對應的關系有何問題呢？我們分析STUDENT關系模式，會有下列問題：
存在大量的冗餘數據：當一個學生在學習多門課程後，他的人事信息重復出現多次。
根據關系模型完整性規則，主碼屬性值不能取空值。那麼新生剛入學，還未選修課程時，該元組就不能插入該關系中。這種情況稱為插入異常。
同樣還有刪除異常，則會丟失信息
解決上述問題方法是將大的模式分解成多個小的模式，分解後的模式可滿足更高級的範式的要求。
㈡ 資料庫求教如何分解BCNF~
答案是｛AC｝，｛CD｝，｛ABE｝。因為A->；C，C->；D，所以A->；D，先把這ACD三個從總表中分出來，得出{ACD}和{ABE}，由於A->；D，需要經過C，所以這屬於傳遞依賴，因此{ACD}又可以分為｛AC｝和｛CD｝。
(2)資料庫bcnf分解擴展閱讀：
資料庫管理系統是為管理資料庫而設計的電腦軟體系統，一般具有存儲、截取、安全保障、備份等基礎功能。資料庫管理系統可以依據它所支持的資料庫模型來作分類，例如關系式、XML；或依據所支持的計算機類型來作分類，例如伺服器群集、行動電話；
或依據所用查詢語言來作分類，例如SQL、XQuery；或依據性能沖量重點來作分類，例如最大規模、最高運行速度；亦或其他的分類方式。不論使用哪種分類方式，一些DBMS能夠跨類別，例如，同時支持多種查詢語言。
㈢ 如何將關系模式分解到BCNF
1,範式
7大範式：1NF, 2NF,3NF,BCNF,4NF,5NF,6NF
什麼叫normalization?Denormalization?
Normalization是資料庫規范化,denormalization是資料庫逆規范化.
在設計和操作維護資料庫時,關鍵的步驟就是要確保數據正確地分布到資料庫的表中.使用正確的數據結構,不僅便於對資料庫進行相應的存取操作,而且可以極大地簡化應用程序的其他內容（查詢、窗體、報表、代碼等）.正確進行表設計的正式名稱就是"資料庫規范化".目的：減少資料庫中數據冗餘,增進數據的一致性.
範式概念：
1）1NF：目標就是表中每列都不可分割；
2）2NF：目標就是表中的每行都是有標識的.前提是滿足了1NF. 當關鍵字為單field時,一定滿足2NF.當關鍵字為組合field時（即超過一個field）,不能存在組合關鍵字中有某個欄位能夠決定非關鍵欄位的某部分.非主field非部分依賴於主field,即非關鍵欄位必須完全依賴於一組 組合關鍵字,而不是組合關鍵字的某一部分.
3）3NF：目標是一個table裡面所有的列不依賴於另外一個table裡面非關鍵的列.前提是滿足了2NF,不存在某個非關鍵欄位決定另外一個非關鍵欄位.即：不存在傳遞依賴（關鍵字x->非關鍵屬性y->非關鍵屬性z）
4）BCNF：前提是滿足了2NF,不存在某個非關鍵欄位決定另外一個非關鍵欄位.也不存在某個關鍵欄位決定另外一個關鍵欄位.即：在3NF基礎上,加上約束：不存在某個關鍵欄位決定另外一個關鍵欄位.
1 第一範式（1NF）
在任何一個關系資料庫中,第一範式（1NF）是對關系模式的基本要求,不滿足第一範式（1NF）的資料庫就不是關系資料庫.所謂第一範式（1NF）是指資料庫表的每一列都是不可分割的基本數據項,同一列中不能有多個值,即實體中的某個屬性不能有多個值或者不能有重復的屬性.如果出現重復的屬性,就可能需要定義一個新的實體,新的實體由重復的屬性構成,新實體與原實體之間為一對多關系.在第一範式（1NF）中表的每一行只包含一個實例的信息.例如,對於圖3-2 中的員工信息表,不能將員工信息都放在一列中顯示,也不能將其中的兩列或多列在一列中顯示；員工信息表的每一行只表示一個員工的信息,一個員工的信息在表中只出現一次.簡而言之,第一範式就是無重復的列.
2 第二範式（2NF）
第二範式（2NF）是在第一範式（1NF）的基礎上建立起來的,即滿足第二範式（2NF）必須先滿足第一範式（1NF）.第二範式（2NF）要求資料庫表中的每個實例或行必須可以被惟一地區分.為實現區分通常需要為表加上一個列,以存儲各個實例的惟一標識.如圖3-2 員工信息表中加上了員工編號（emp_id）列,因為每個員工的員工編號是惟一的,因此每個員工可以被惟一區分.這個惟一屬性列被稱為主關鍵字或主鍵、主碼.第二範式（2NF）要求實體的屬性完全依賴於主關鍵字.所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性,如果存在,那麼這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體,新實體與原實體之間是一對多的關系.為實現區分通常需要為表加上一個列,以存儲各個實例的惟一標識.簡而言之,第二範式就是非主屬性非部分依賴於主關鍵字.
3 第三範式（3NF）
滿足第三範式（3NF）必須先滿足第二範式（2NF）.簡而言之,第三範式（3NF）要求一個資料庫表中不包含已在其它表中已包含的非主關鍵字信息.例如,存在一個部門信息表,其中每個部門有部門編號（dept_id）、部門名稱、部門簡介等信息.那麼在圖3-2的員工信息表中列出部門編號後就不能再將部門名稱、部門簡介等與部門有關的信息再加入員工信息表中.如果不存在部門信息表,則根據第三範式（3NF）也應該構建它,否則就會有大量的數據冗餘.簡而言之,第三範式就是屬性不依賴於其它非主屬性.
例子：
第一範式（1NF）：資料庫表中的欄位都是單一屬性的,不可再分.這個單一屬性由基本類型構成,包括整型、實數、字元型、邏輯型、日期型等.
例如,如下的資料庫表是符合第一範式的：欄位1 欄位2 欄位3 欄位4
而這樣的資料庫表是不符合第一範式的：欄位1 欄位2 欄位3 欄位4 欄位31欄位32
很顯然,在當前的任何關系資料庫管理系統（S）中,傻瓜也不可能做出不符合第一範式的資料庫,因為這些S不允許你把資料庫表的一列再分成二列或多列.因此,你想在現有的S中設計出不符合第一範式的資料庫都是不可能的.
第二範式（2NF）：資料庫表中不存在非關鍵欄位對任一候選關鍵欄位的部分函數依賴（部分函數依賴指的是存在組合關鍵字中的某些欄位決定非關鍵欄位的情況）,也即所有非關鍵欄位都完全依賴於任意一組候選關鍵字.
假定選課關系表為Ss(學號, 姓名, 年齡, 課程名稱, 成績, 學分),關鍵字為組合關鍵字(學號, 課程名稱),因為存在如下決定關系：
(學號, 課程名稱) → (姓名, 年齡, 成績, 學分)
這個資料庫表不滿足第二範式,因為存在如下決定關系：
(課程名稱) → (學分)
(學號) → (姓名, 年齡)
即存在組合關鍵字中的欄位決定非關鍵字的情況.
由於不符合2NF,這個選課關系表會存在如下問題：1) 數據冗餘：同一門課程由n個學生選修,"學分"就重復n-1次；同一個學生選修了門課程,姓名和年齡就重復了-1次.2) 更新異常：若調整了某門課程的學分,數據表中所有行的"學分"值都要更新,否則會出現同一門課程學分不同的情況.3) 插入異常：假設要開設一門新的課程,暫時還沒有人選修.由於還沒有"學號"關鍵字,課程名稱和學分也無法記錄入資料庫.4) 刪除異常：假設一批學生已經完成課程的選修,這些選修記錄就應該從資料庫表中刪除.但是,與此同時,課程名稱和學分信息也被刪除了.很顯然,這也會導致插入異常.
把選課關系表Ss改為如下三個表：
學生：Sn(學號, 姓名, 年齡)；
課程：s(課程名稱, 學分)；
選課關系：Ss(學號, 課程名稱, 成績).
這樣的資料庫表是符合第二範式的,消除了數據冗餘、更新異常、插入異常和刪除異常.
另外,所有單關鍵字的資料庫表都符合第二範式,因為不可能存在組合關鍵字.
第三範式（3NF）：在第二範式的基礎上,數據表中如果不存在非關鍵欄位對任一候選關鍵欄位的傳遞函數依賴則符合第三範式.所謂傳遞函數依賴,指的是如果存在"A → → "的決定關系,則傳遞函數依賴於A.因此,滿足第三範式的資料庫表應該不存在如下依賴關系：關鍵欄位 → 非關鍵欄位x → 非關鍵欄位y
假定學生關系表為Sn(學號, 姓名, 年齡, 所在[]學院[], 學院地點, 學院電話),關鍵字為單一關鍵字"學號",因為存在如下決定關系：
(學號) → (姓名, 年齡, 所在[]學院[], 學院[]地點, []學院[]電話)
這個資料庫是符合2NF的,但是不符合3NF,因為存在如下決定關系：
(學號) → (所在[]學院[]) → ([]學院[]地點, []學院[]電話)
即存在非關鍵欄位"[]學院[]地點"、"[]學院[]電話"對關鍵欄位"學號"的傳遞函數依賴.
它也會存在數據冗餘、更新異常、插入異常和刪除異常的情況,讀者可自行分析得知.
把學生關系表分為如下兩個表：
學生：(學號, 姓名, 年齡, 所在[]學院[])；
[]學院[]：([]學院[], 地點, 電話).
這樣的資料庫表是符合第三範式的,消除了數據冗餘、更新異常、插入異常和刪除異常.
鮑依斯-科得範式（BCNF）：在第三範式的基礎上,資料庫表中如果不存在任何欄位對任一候選關鍵欄位的傳遞函數依賴則符合BCNF.
假設倉庫管理關系表為Ssanag(倉庫, 存儲物品, 管理員, 數量),且有一個管理員只在一個倉庫工作；一個倉庫可以存儲多種物品.這個資料庫表中存在如下決定關系：
(倉庫, 存儲物品) →(管理員, 數量)
(管理員, 存儲物品) → (倉庫, 數量)
所以,(倉庫, 存儲物品)和(管理員, 存儲物品)都是Ssanag的候選關鍵字,表中的唯一非關鍵欄位為數量,它是符合第三範式的.但是,由於存在如下決定關系：
(倉庫) → (管理員)
(管理員) → (倉庫)
即存在關鍵欄位決定關鍵欄位的情況,所以其不符合BCNF範式.它會出現如下異常情況：1) 刪除異常：當倉庫被清空後,所有"存儲物品"和"數量"信息被刪除的同時,"倉庫"和"管理員"信息也被刪除了.2) 插入異常：當倉庫沒有存儲任何物品時,無法給倉庫分配管理員.3) 更新異常：如果倉庫換了管理員,則表中所有行的管理員都要修改.
把倉庫管理關系表分解為二個關系表：
倉庫管理：Ssanag(倉庫, 管理員)；
倉庫：Ss(倉庫, 存儲物品, 數量).
這樣的資料庫表是符合BCNF範式的,消除了刪除異常、插入異常和更新異常.
簡言之資料庫五大範式：
第一範式：對於表中的每一行,必須且僅僅有唯一的行值.在一行中的每一列僅有唯一的值並且具有原子性.
（第一範式是通過把重復的組放到每個獨立的表中,把這些表通過一對多關聯聯系起來這種方式來消除重復組的）
第二範式：第二範式要求非主鍵列是主鍵的子集,非主鍵列活動必須完全依賴整個主鍵.主鍵必須有唯一性的元素,一個主鍵可以由一個或更多的組成唯一值的列組成.一旦創建,主鍵無法改變,外鍵關聯一個表的主鍵.主外鍵關聯意味著一對多的關系.（第二範式處理冗餘數據的刪除問題.當某張表中的信息依賴於該表中其它的不是主鍵部分的列的時候,通常會違反第二範式）
第三範式：第三範式要求非主鍵列互不依賴.（第三範式規則查找以消除沒有直接依賴於第一範式和第二範式形成的表的主鍵的屬性.我們為沒有與表的主鍵關聯的所有信息建立了一張新表.每張新表保存了來自源表的信息和它們所依賴的主鍵）
第四範式：第四範式禁止主鍵列和非主鍵列一對多關系不受約束
第五範式：第五範式將表分割成盡可能小的塊,為了排除在表中所有的冗餘.
㈣ 請問資料庫設計中BCNF範式是什麼意思
BCNF範式在3NF基礎上消除對主碼子集的依賴。
以倉庫管理關系表為例：倉庫號，存儲物品號，管理員號，數量。首先該表滿足第三範式，也就是說一個管理員只在一個倉庫工作，一個倉庫能夠存儲多種物品。表中存在有如下依賴關系：
(倉庫號，存儲物品號)——>(管理員號，數量)
(管理員號，存儲物品號)——>(倉庫號，數量)
由以上依賴關系可以得知(倉庫號，存儲物品號)和(管理員號，存儲物品號)為表關系中的候選碼。
表中唯一非關鍵欄位為數量，它是符合第三範式的。但是，由於存在如下決定關系：
(倉庫號)——>(管理員號)
(管理員號)——>(倉庫號)
即存在關鍵欄位決定關鍵欄位的情況，因此其不符合BCNF。
解決方法：把倉庫管理關系表分解為兩個關系表倉庫管理表(倉庫號，管理員號)和倉庫表(倉庫號，存儲物品號，數量)，這樣這個資料庫表是符合BCNF的，並消除了刪除異常、插入異常和更新異常。
(4)資料庫bcnf分解擴展閱讀：
巴斯-科德範式（BCNF）是第三範式（3NF）的一個子集，即滿足巴斯-科德範式（BCNF）必須滿足第三範式（3NF）。通常情況下，巴斯-科德範式被認為沒有新的設計規范加入，只是對第二範式與第三範式中設計規范要求更強，因而被認為是修正第三範式。
也就是說，它事實上是對第三範式的修正，使資料庫冗餘度更小。這也是BCNF不被稱為第四範式的原因。某些書上，根據範式要求的遞增性將其稱之為第四範式是不規范，也是更讓人不容易理解的地方。而真正的第四範式，則是在設計規范中添加了對多值及依賴的要求。
參考資料來源：網路-資料庫範式
㈤ 3NF 與BCNF 有什麼區別 求舉個例子說明下~謝謝
範式是資料庫中的關於關系模式的分類，是越來越嚴苛的分類。
一、區別
1、第三範式指表中的所有數據元素不但要能唯一地被主關鍵字所標識,而且它們之間還必須相互獨立,不存在其他的函數關系。第三範式就是在第二範式的基礎上再消除表中有可能存在某些數據元素依賴於其他非關鍵字數據元素的現象。
2、BC範式是指對於關系模式R，若 R為第一範式，且每個屬性都不部分依賴於候選鍵也不傳遞依賴於候選鍵。BC比第三範式更嚴苛的條件是：要求R為第二範式且非鍵屬性不傳遞依賴於R的候選鍵，而BC範式則是對R的每個屬性都做要求。即決定因素為候選碼。
二、舉例
以下關系模式滿足第三範式
學生：(學號,姓名,年齡,所在學院)；
學院：(學院,地點,電話)。
其中的關系函數為：學號->姓名、學號->年齡、學號->學院、學院->地點、學院->電話。可以看出所有的關系函數均為一候選碼為決定因素（函數的前半部分）那麼可以說此關系模式滿足BCNF。
(5)資料庫bcnf分解擴展閱讀
資料庫範式概念引入原因
規范化目的是使結構更合理，消除存儲異常，使數據冗餘盡量小。便於插入、刪除和更新。
遵從概念單一化「一事一地」原則，即一個關系模式描述一個實體或實體間的一種聯系。規范的實質就是概念的單一化。
一個關系模式接著分解可以得到不同關系模式集合，也就是說分解方法不是惟一的。最小冗餘的要求必須以分解後的資料庫能夠表達原來資料庫所有信息為前提來實現。其根本目標是節省存儲空問，避免數據不一致性，提高對關系的操作效率，同時滿足應用需求。
實際上，並不一定要求全部模式都達到BCNF不可。有時故意保留部分冗餘可能更方便數據查詢。尤其對於那些更新頻度不高，查詢頻度極高的資料庫系統更是如此。
㈥ 資料庫系統方面的問題,求最小函數依賴集、候選碼、分解滿足範式的關系模式
1.F={A->B,C->D,AE->F，F->G}已經是F的最小函數依賴集
2.R的候選碼：ACE
3.R分解為：R1(A，B，C，D，E)和R2(F,G)均滿足BCNF範式
㈦ 如何將一個關系模式分解成無損連接的BCNF
∵(BE)+=ABCDE,，B+=BC不屬於ABCDE，E+=E不屬於ABCDE。
∴BE為R的關鍵字。
考慮A→C，不包含關鍵字。
∴將R分解為R11(AC)R12(ABDE)F11的函數依賴為{A→C}，F12的函數依賴為(AD)。
∵F11∈BCNF，F12不屬於BCNF，繼續分解。
將的R12分解為R21(AD)，R22(ABE)。
F21的函數依賴為{A→D}，F22的函數依賴為{BE→A}。
∵R21∈BCNF，R22∈BCNF。
∴R的一組BCNF模式分解為R11(AC)，R21(AD)，R22(ABE)。
註：分解的結果可能不唯一。
(7)資料庫bcnf分解擴展閱讀：
推導：
設R(U)是一個屬性集U上的關系模式，X和Y是U的子集。
若對於R(U)的任意兩個可能的關系r1、r2，若r1[x]=r2[x],則r1[y]=r2[y]，或者若r1[y]不等於r2[y],則r1[x]不等於r2[x]，稱X決定Y，或者Y依賴X。
上面一段話是某些教材上的話，比較不好理解。比如在設計學生表時，一個學生的學號能決定學生的姓名，也可稱姓名屬性依賴於學號，對於現實來說，就是如果知道一個學生的學號，就一定能知道學生的姓名。
這種情況就是姓名依賴於學號，這就是函數依賴，函數依賴又分為非平凡依賴，平凡依賴；從性質上還可以分為完全函數依賴、部分函數依賴和傳遞函數依賴。
Y=f(x)
1、數據依賴
在計算機科學中，數據依賴是指一種狀態，當程序結構導致數據引用之前處理過的數據時的狀態。其中最重要的是函數依賴和多值依賴。
2、函數依賴
設X,Y是關系R的兩個屬性集合，當任何時刻R中的任意兩個元組中的X屬性值相同時，則它們的Y屬性值也相同，則稱X函數決定Y，或Y函數依賴於X。
3、平凡函數依賴
當關系中屬性集合Y是屬性集合X的子集時(Y⊆X)，存在函數依賴X→Y，即一組屬性函數決定它的所有子集，這種函數依賴稱為平凡函數依賴。