資料庫正規化- JOBDAREN 工作達人

文章推薦指數: 80 %
投票人數:10人

這是MySQL 5實力養成暨評量裡的1-32.『可以消除表格部份依賴關係的是下列哪個正規化? 答案:Continue Reading| JOBDAREN 工作達人| 資料庫正規化| ... Skiptocontent截到右下角累積人氣8,888,888圖者,請送至粉絲頁,即贈送好禮,詳請洽粉絲頁小編。

Search資料庫正規化By:ㄚ琪On:2013/04/21,Modified:2021/10/14In:Database,MySQLTagged:Databasenormalization,MySQL,資料庫正規化With:0Comments點閱人數:24,714次這是MySQL5實力養成暨評量裡的1-32.『可以消除表格部份依賴關係的是下列哪個正規化?答案:(B)第二正規化已經上過資料庫的課很多次了,可是關於正規化的問題還是無法解決真是愚蠢。

所以我們參考維基的說明再好好看一遍吧。

內容目錄資料庫正規化第一正規化不符合第一正規化的情況重複群缺乏唯一識別碼關聯式資料庫裡的第一正規化單一欄位中有多個有意義的值用很多欄位來表達同一個事實第二正規化範例第三正規化正規定義範例BC正規化範例資料庫正規化資料庫正規化,又稱資料庫或資料庫正規化、標準化,是資料庫設計中的一系列原理和技術,以減少資料庫中資料冗餘,增進資料的一致性。

關聯模型的發明者埃德加·科德最早提出這一概念,並於1970年代初定義了第一正規化、第二正規化和第三正規化的概念,還與RaymondF.Boyce於1974年共同定義了第三正規化的改進範式——BC正規化。

除外還包括針對多值依賴的第四正規化,連線依賴的第五正規化,DK正規化和第六正規化。

現在資料庫設計最多滿足3NF,普遍認為範式過高,雖然具有對資料關聯更好的約束性,但也導致資料關聯表增加而令資料庫IO更易繁忙,原來交由資料庫處理的關聯約束現更多在資料庫使用程式中完成。

第一正規化第一正規化(1NF,中國大陸譯作第一範式)是資料庫正規化中所使用的一種正規形式。

第一正規化是為了要排除重複群的出現,所採用的方法是要求資料庫的每個欄位都只能存放單一值,而且每筆記錄都要能利用一個唯一的主鍵來加以識別。

不符合第一正規化的情況重複群重複群通常會出現在會計帳上,每一筆記錄可能有不定個數的值。

舉例來說:交易顧客日期數量PeteMonday19.00-28.20PeteWednesday-84.00SarahFriday100.00150.00-40.00‘數量’就是所謂的重複群了,而在這種情況下這份資料就不符合第一正規化。

想要消除重複群的話,只要把每筆記錄都轉化為單一記錄即可:交易交易ID顧客日期數量1PeteMonday19.002PeteMonday-28.203PeteWednesday-84.004SarahFriday100.005SarahFriday150.006SarahFriday-40.00缺乏唯一識別碼一樣是在交易這個例子中,同一天同一個人買了同樣的數量,這樣的交易做了兩次:交易顧客日期數量PeteMonday19.00PeteMonday19.00如上所示,這兩筆交易可以說是一模一樣,也就是說如果只靠這些資料我們沒有辦法分辨這兩筆記錄。

我們之所以說它不符合第一正規化,是因為上面這樣的表示法欠缺一個唯一識別碼,可以是一個欄位,也可以是一組欄位,而且可以保證在這個資料中唯一識別碼不會重複出現。

要將它正規化到符合第一正規化的原則只需要加入一個唯一識別碼即可:交易交易ID顧客日期數量1PeteMonday19.002PeteMonday19.00關聯式資料庫裡的第一正規化大多數的 RDBMS(關聯式資料庫),像MySQL,允許使用者在定義資料表的時候不去指定主鍵,不過這麼一來這種資料表就不符合第一正規化了。

從某個角度看來,不允許重複群的出現是關聯式資料庫表示資訊的方法,RDBMS裡資料表每一筆記錄的每一個欄位都只能有一個值。

舉例來說,如果定義了一個叫做FavoriteNumber的整數欄位,每一筆記錄的FavoriteNumber這個欄位都只會是一個整數(或是無);這也就是說,如果設定了主鍵的話,理論上不可能會有任何關聯式資料庫的資料表會違反第一正規化的原則。

不過就算是在這種情況下,還是可以設計出在骨子裡違反第一正規化的資料表。

最簡單的方法就是把多個有意義的值編碼過後存進一個欄位裡,然後在資料表中用很多欄位來表達同一個事實。

單一欄位中有多個有意義的值在單一欄位中存放多個值是違反第一正規化的做法,下面這個就是很好的例子,它把多個值用逗號分開來表示:挑食列表人不喜歡的食物JimLiver,Goat’scheeseAliceBroccoliNormanPheasant,Liver,Peas以這樣的設計看來,想要知道有什麼人不喜歡某樣特定的東西是很不容易的。

不過可以把這個資料表轉化成下面這種符合第一正規化的型式:挑食列表人不喜歡的食物JimLiverJimGoat’scheeseAliceBroccoliNormanPheasantNormanLiverNormanPeas用很多欄位來表達同一個事實在同一個資料表裡用多個欄位來表達同一個事情也是違反第一正規化的:個人資料人喜歡的顏色不喜歡的食物(1)不喜歡的食物(2)不喜歡的食物(3)JimGreenLiverGoat’scheeseAliceFuchsiaBroccoliNormanBluePheasantLiverPeasEmilyYellow就算我們能確定每個人不喜歡吃的食物最多不會超過三樣,這還是一個很糟的設計。

舉例來說,我們想要知道所有不喜歡同一種食物的人的組合的話,這就不是件容易的事,因為食物有可能出現在任何一個欄位,也就是說每一次的查詢都要去檢查9(3x3)組不同的欄位組合。

第二正規化第二正規化(2NF,中國大陸譯作第二范式)是資料庫正規化中所使用的一種正規形式。

它的規則是要求資料表裡的所有資料都要和該資料表的主鍵有完全相依關係;如果有哪些資料只和主鍵的一部份有關的話,就得把它們獨立出來變成另一個資料表。

如果一個資料表的主鍵只有單一一個欄位的話,它就一定符合第二正規化。

一個資料表符合第二正規化若且唯若它符合第一正規化所有非主鍵的欄位都一定和主鍵有關範例有一個資料表記錄了設備元件的資訊,如下所示:元件來源元件ID(主鍵)供應商ID(主鍵)供應商名稱價格供應商住址652StylizedParts59.99VA732StylizedParts20.00VA651ACMEIndustries69.99CA這個資料表的每個值都是單一值,所以它符合第一正規化。

因為同一個元件有可能由不同的供應商提供,所以得把元件ID和供應商ID合在一起組成一個主鍵。

主鍵和價格之間的關係很正確:同一個元件在不同供應商有可能會有不同的報價,所以價格確實和主鍵完全相關(完全依賴)。

另一方面,供應商的名稱和住址就只和供應商ID有關(部分依賴),這不符合第二正規化的原則。

仔細看就會發現“StylizedParts”這個名稱和“VA”這個住址重複出現了兩次;要是它改名了或是被其他公司併購了怎麼辦?這時候最好把這些資料存到第二個資料表中:供應商供應商ID(主鍵)名稱住址1ACMEIndustriesCA2StylizedPartsVA這麼一來,原本的“元件來源”資料表就得要做相對應的更動:元件來源元件ID(主鍵)供應商ID(主鍵)價格65259.9973220.0065169.99檢查資料表裡的每個欄位,確認它們是不是都和主鍵完全相關,這樣才能知道這個資料表是不是符合第二正規化;如果不是的話,就把那些不完全相關的欄位移到獨立的資料表裡。

接下來的步驟是要確保所有不是鍵的欄位都和彼此沒有相依關係,這就叫做第三正規化。

第三正規化第三正規化(3NF,中國大陸譯作第三范式)是資料庫正規化中所使用的一種正規形式,用來檢驗是否所有非鍵屬性都只和候選鍵有相關性,也就是說所有非鍵屬性互相之間應該是無關的。

第三正規化和第二正規化不同的地方在於,在第三正規化裡,所有的非鍵屬性都必須和每個候選鍵有直接相關。

如果再對第三正規化做進一步加強就成了BC正規化,它所強調的重點就在於“資料間的關係是奠基在鍵上、以整個鍵為考量、而且除了鍵之外不考慮其他因素”。

正規定義 表一個關係; 表維持  所需的一組功能相依性; 表  屬性的子集合; 表  的一個屬性如果對於  這種型式的功能相依性而言,下列敘述任一為真的話,則可以稱  符合第三正規化:;也就是說  是明顯功能相依性 是超鍵 是  的候選鍵的一部份任何一個具有部份相依性或是轉移相依性的關係都違反了第三正規化。

範例以下面這個定義機械元件的關係為例:機械元件元件編號(主鍵)製造商名稱製造商位址1000ToyotaParkAvenue1001MitsubishiLincolnStreet1002ToyotaParkAvenue本例中製造商位址很明顯地不該被列在這個關係裡面,因為和元件本身比起來,製造商位址應該和製造商比較有關係;正確的做法應該是把獨立成為一個新的資料表:製造商製造商名稱(主鍵)製造商位址ToyotaParkAvenueMitsubishiLincolnStreet然後把原本的資料表改成這樣:機械元件元件編號(主鍵)製造商名稱1000Toyota1001Mitsubishi1002Toyota先前那個資料表的問題在於每提到一次製造商名稱就要多存一次它的位址,而這就不符合第三正規化的原則。

下面提供了另一個例子:訂單(Order)訂單編號(OrderNumber)(主鍵)客戶名稱(CustomerName)單價(UnitPrice)數量(Quantity)小計(Total)1000David$35.003$105.001001Jim$25.002$50.001002Bob$25.003$75.00在本例中,非主鍵欄位完全依賴於主鍵訂單編號,也就是說唯一的訂單編號能導出唯一非主鍵欄位值,符合第二正規化。

第三正規化要求非主鍵欄位之間不能有依賴關系,顯然本例中小計依賴於非主鍵欄位單價和數量,不符合第三正規化。

小計不應該放在這個資料表裡面,只要把單價乘上數量就可以得到小計了;如果想要符合第三正規化的話,就把小計拿掉吧(不過在做查詢的時候,本來用“SELECTOrders.TotalFROMOrder”就要改成用“SELECTUnitPrice*QuantityFROMOrder”了)。

訂單(Order)訂單編號(OrderNumber)(主鍵)客戶名稱(CustomerName)單價(UnitPrice)數量(Quantity)1000David$35.0031001Jim$25.0021002Bob$25.003BC正規化Boyce-Codd範式(Boyce-Coddnormalform,BCNF),是資料庫正規化中所使用的一種正規形式。

是在第三正規化的基礎上加上更嚴格約束,每個BCNF關聯是第三正規化的子集,有從屬關聯。

它的定義是:如果對於關聯模式R中存在的任意一個非平凡函式依賴X->A,都滿足X是R的一個候選鍵,那麼關聯模式R就屬於BCNF,。

BCNF與第三正規化的不同之處在於,第三正規化允許A是主屬性(第三正規化中不存在非主屬性被另一個非主屬性決定),而在BCNF中,任何屬性(包括非主屬性和主屬性)都不能被非主屬性所決定。

範例關聯模式R:Property_id#(主鍵)County_nameLot#Area其中依賴關聯如下:Property_id#->{County_name,Lot#,Area};{County_name,Lot#}->{Property_id#,Area};Area->County_name;很明顯最後一個依賴違反了BC正規化的要求,Area不是關聯模式R的主鍵,而依賴於它的County_name是能夠決定其他屬性的主屬性。

故應當規範化為:Property_id#(主鍵)County_nameLot#Area(主鍵)County_name延伸閱讀-更多高CP值的MySQL好文在這邊:※MySQL流程控制的迴圈,用while寫mysqlforloop※何謂資料隱碼(SQLinjection)攻擊?程式設計師應如何預防?※MySQL註解語法感謝你看到這裡,很快就可以離開了,但最好的獎勵行動就是按一下幫我分享,感恩喔~點我分享到Facebook精選相關文章2013-04-21PreviousPost:分享管理十四要點NextPost:【除臭襪】一雙能防臭、除腳臭、質感好又平價的除臭襪子哪裡找?發佈留言取消回覆發佈留言必須填寫的電子郵件地址不會公開。

必填欄位標示為*留言顯示名稱*電子郵件地址*個人網站網址這個網站採用Akismet服務減少垃圾留言。

進一步了解Akismet如何處理網站訪客的留言資料。

機票比價網站家居生活生活中省錢工具學習清單出國住這裡馬來西亞住宿超過26022間飯店民宿日本超過75405間飯店民宿任君挑選美國住宿超過337034間飯店民宿韓國住宿超過20291間飯店民宿尋找泰國住宿超過70338間飯店民宿尋找新加坡住宿超過2810間飯店民宿尋找台灣住宿超過18459間飯店民宿尋找中國住宿超過194219間飯店民宿尋找香港住宿超過3463間飯店、民宿尋找澳門住宿超過485間飯店、民宿達人飯店推薦[★號=已住]台灣國內飯店台北爽爽住【台北】台北松山東旅飯店近南京三民站★優美飯店★【宜蘭】捷絲旅宜蘭礁溪館【宜蘭】宜蘭礁溪原湯商業旅館★【宜蘭】山月22宜蘭礁溪Villa可以民宿包棟★尋找澳洲住宿超過53940間飯店民宿找菲律賓住宿超過22183間飯店民宿寶寶用品【Pamps幫寶適】尿布特級棉柔紙尿褲L(68片X3串/箱)日本原裝一級幫紙尿褲/尿布(L)120片/箱日本原裝一級幫紙尿褲/尿布(L)42片x4包/箱嬰兒紙尿褲(L)86片x2包(彩盒)/箱衣物清潔清淨海健康呵護天然洗衣精清淨海小麥精華奶瓶食器清潔慕斯AirMax款式商品推薦喜歡文章就訂閱我喔EmailAddress立即訂閱熱門文章工作達人的留言政策-233,009views設定C和C++Code::Blocks編譯器的初學者教學指南-192,716viewsjQueryUI入門-48,071viewsCode::Blocks13.12繁體中文化-44,116viewsGTK+2.0教學-43,178views【金錢】信用卡國外刷卡手續費大比較-42,664viewsPython圖形使用者介面程式設計-41,715views推薦好用的部落格-37,899views歐姆龍氣動式噴霧治療器-30,368views程式語言教學–C、C++、OpenGL、STL-25,695views低頭族傷害救星__+Venture熱敷墊-25,511views資料庫正規化-24,714views近期文章受保護的內容:資金會不夠唷!與易借網金主借錢融資洽談都要仔細地驗證c++substr及c++常用七種字串函數【慶祝】託各位的福,工作達人即將突破千萬人氣!感謝大家平日的愛護♥免費獎品多多送受保護的內容:【御鮮品食堂】露營必備花雕雞組合包,露營的美味在這裡,山上吃美食、野餐餐點好有面子2021年18個用來找工作的任務發布外包平台推薦只有台灣人不知道的【布緯Organicvalley有機強化全脂牛奶】!濃醇健康的奶香在嘴裡整個化開!2天就知道是否成百萬點擊的寫作法則從大商之道一書看中興保全,擁有殖利率近5%的保全業龍頭是否值得入手呢即使露營沒有電,也可以用戶外行動電源Roommi小電寶滿足你每分每秒的用電需求!提升矚目度!讓女人的視線全盯在你身上的【TUK體育刻】QUICKBELL可調式啞鈴+多功能重訓椅之居家健身器具與我交誼!做我的粉絲!technoratiTwitter關於工作的連結Careerjet,找工作的搜尋引擎最推薦的訂房網站最多訂房優惠/住十晚送一晚全球最大訂房/機票網站最多網友住房評價~不怕踩雷!最新的回應「ㄚ琪」在〈【新科技快鍋】不是快鍋的快鍋,比壓力鍋安全且不沾鍋具的不鏽鋼鍋〉發佈留言「ALENKUO」在〈Aboutachi〉發佈留言「ㄚ琪」在〈設定C和C++Code::Blocks編譯器的初學者教學指南〉發佈留言「MicrocenHosting」在〈設定C和C++Code::Blocks編譯器的初學者教學指南〉發佈留言「香港植牙」在〈交換連結LinkExchange〉發佈留言歷史事件2013年4月一二三四五六日123456789101112131415161718192021222324252627282930 «3月 5月»MyDisclosurePolicyDesignedusingUnos.PoweredbyWordPress.



請為這篇文章評分?