多值依賴 模式分解 (學習感想)

2021-10-08 01:23:46 字數 2414 閱讀 2693

模式分解,是關係規範化的手段,而關係規範化的實質就是概念的單一化,一事一地,(這裡書上講得挺好的),從而避免或減少增刪改的異常/繁瑣(以下統稱異常)。

對於乙個只有函式依賴的模式而言,我們把它分解到bcnf這個層次,那就徹底解決了增刪改的異常,如(學生s,系sd,宿舍d)有s→sd,sd→d,當我們把它分解為(學生s,系sd)和(系sd,宿舍d),就不用再考慮語義上的啥啥函式依賴了,增刪學生或系,都不會造成異常,修改系主任名字也不用那麼繁瑣,當然了你要是修改系名,兩個表都得改一下,畢竟你要滿足參照完整性。至於如何把乙個只含函式依賴的模式分解到bcnf,我在此就不多贅述了。

而對於含有非平凡非函式依賴的多值依賴的模式而言,如何分解到bcnf,如何分解到4nf呢?

我們先講策略:在我們對乙個含有函式依賴和非平凡非函式依賴的多值依賴的模式進行分解到bcnf時,不用考慮那個非平凡非函式依賴的多值依賴,直接忽略,就觀察它的函式依賴,把它分解到bcnf即可。而要分解到4nf,同前面步驟一樣,在bcnf的基礎上,觀察分解得到的各個bcnf關係,看是否仍存在非平凡非函式依賴的多值依賴,如果不存在那就是4nf,不用變了,如果有bcnf表仍存在雙非多值依賴,那麼按照書上定理,將雙非多值依賴分解為平凡的非函式依賴的多值依賴即可,那麼按照定理,它就是4nf。

回過頭來說,對於乙個只有函式依賴的模式而言,在分解它時,我們要考慮它的函式依賴和無損鏈結。無損鏈結是為了避免資料的丟失,而函式依賴是為了避免增刪改的異常。這就是我們一般用到的模式分解的準則。

對於函式依賴而言,bcnf就已經到終極了。但對於雙非多值(越寫越短,下次非多)而言,這貌似才剛剛開始。但開始的晚並不意味它還能活很久,至少對於我們而言,到下一步的4nf就over了。

對於雙,不對,非…,害算了,就叫雙非多值叭,對於雙非多值而言,其實書上,你們觀察下書上的說法,存在雙非多值依賴,增刪改很不方便,資料冗餘也很明顯。然後提出利用4nf來消除雙非,但4nf怎麼就減少冗餘了,4nf怎麼就避免或減少增刪改的異常了,emmm,它沒有說。但,很明顯的,減少儲存冗餘,那是顯而易見的。

我舉個很常見的多值依賴的例子,(課程c,老師t,參考書b)(全碼,bcnf),分解為(課程c,老師t)和(課程c,參考書b)(都是4nf),這是書上的例子,很直觀的,它減少了資料的儲存冗餘,這確實。但避免了增刪改的異常了嗎?就單這個例子而言,它確實也很直觀的避免或減少了。如課程c1,有t1,t2兩位老師,b1b2b3三本書,在原表中我要給c1加一位老師t3,那我就得新增3個元組,而在分解後的(課程c,老師t)和(課程c,參考書b)中只要加乙個元組即可。

但你要說4nf對雙非多值而言就像bcnf對於函式依賴而言那樣,徹底解決它帶來的增刪改異常,這是不準確的。

對於簡單的多值依賴,乙個模式(x,y,z),只有x→→y,你分解為4nf後確實徹底解決了增改異常(我也不知道有沒有徹底解決,但我覺得挺徹底的),但你拿0129問的那道題:r(a,b,c,d),有a→→c和c→→bd。分解為(ac)和(cbd),它的增刪改仍是會異常,你在cbd中若只新增乙個元組,就有可能破壞a→→c這一關係,所以還是很複雜的,你在原表中在不破壞它多值依賴的基礎上對它增刪改,其本身就是乙個很複雜的事,而在4nf中仍然很複雜,不像bcnf中的函式依賴那樣徹底解決。所以4nf對於多值依賴增刪改的優化是有限的,越複雜的多值依賴,增刪改越複雜。

題目中,要求的是把模式分解到4nf,那就按4nf定義,按分解定理分解到4nf就可以了,就像題目要求分解到3nf一樣,3nf雖然沒有徹底擺脫函式依賴帶來的異常,但它是3nf呀,4nf雖然可能沒有徹底解決雙非多值帶來的異常,但它是4nf。

我之所以會想這麼多,就是步入誤區了,我感覺0129發的那道題,答案不對呀,我在cbd中插入乙個元組,並沒有保持它原本的雙非多值呀。這個思維是錯的,當我們判斷一種分解方式,如將模式分解為3nf,bcnf,是否正確,不是看我插入乙個或刪除乙個元組,原本函式依賴是否不被破壞,而是根據定義bcnf、3nf各自的定義去判斷的。又如我們在進行分解為3nf,bcnf時,都是要始終考慮原模式的函式依賴和無損連線的,只要跟著策略始終關注,那麼求出的就是bcnf,就是3nf。

舉個書上的例子,(學生s,教師t,課程j),它是3nf,那我在3nf種插入個元組,這個元組和已在的乙個元組有點聯絡,s不一樣,j不一樣,但t一樣(畢竟依賴時是一種語義,這樣插入時也沒破壞什麼完整性,當然可能是我沒接觸到),這樣插入後原本的函式依賴t→s就被破壞了呀,但你就就此否定它是3nf啦?這和我一開始步入的誤區是一樣的。你要說它不是3nf,你得給我什麼證據,你得告訴我存在某個非主屬性函式確定某個非主屬性或者某個非主屬性部分依賴候選碼,要類似於違背3nf定義的證據。

而分解為4nf的話,就是要在bcnf基礎上再考慮雙非多值,按照策略分解出的就是4nf,而0129發的那題的答案就是按照策略求解出來的,我要說它不是4nf,我就得找到,這其中存在的雙非多值。

最後補充一句,無損鏈結是基礎要求,不管分解成什麼,你都要無損連線。判斷是否保持函式依賴,判斷是否有無損連線性,判斷是否分解成了3nf,各自的要求是不一樣的,前兩者出問題,那整個模式分解就是錯的,而分解沒問題還要看看是否達到3nf的標準。有功夫判斷是否無損,說不定一看就看出哪哪哪不滿足3nf定義了。

保持函式依賴的模式分解

一 轉換成3nf的保持函式依賴的分解 演算法 是關係模式r的乙個分解,u f 並設f是乙個最小依賴集,記fdi為xi alj,其步驟如下 對r的函式依賴集f進行極小化處理 處理後的結果仍記為f 找出不在f中出現的屬性,將這樣的屬性構成乙個關係模式。把這些屬性從u中去掉,剩餘的屬性仍記為u 若有x a...

設計模式學習之依賴倒置原則

依賴倒置原則,即抽象不應該依賴細節,細節應該依賴於抽象。其實就是要針對介面程式設計,不要對實現程式設計。為什麼是依賴倒置?在物件導向開發時,為了使常用的 可以復用,通常會把這些常用的 封裝成函式庫,這樣就可以在不同的業務 中呼叫這些庫,使得 得到復用。但是,如果在設計的時候不合理,高層的業務模組直接...

設計模式學習之開放封閉原則與依賴倒置原則

1.開放封閉原則是說對軟體實體 類啊 模組啊 函式啊等等 應該可以擴充套件,但是不可以修改。也就是對擴充套件開放 對更改封閉。2.依賴倒置原則高層模組或者底層模組都依賴於抽象,抽象不應該依賴於細節。針對介面程式設計,而不是針對實現程式設計。程式中所有的依賴關係都終止於抽象類或者介面。3.黎克特制代換...