鑑於下面的函數依賴關係,對我來說有點令人困惑,因爲第三範式表示R的非主素屬性並不依賴於主關鍵字。因此,我從表中刪除了函數依賴關係 C - > DE,並將其置於新的關係中,但所有這些屬性也可以由關係的主鍵確定。我想,我不能從該表中刪除d和Ë或者我應該刪除,因爲進一步BCNF也刪除這些attributes.Question沒有幫助的是當我刪除第一功能依賴我也應該刪除d和E從第一個表? enter image description here規範化與第三範式的關係
-1
A
回答
0
要將關係放入給定的NF(正常形式),您應該遵循一個已被建議用於該NF的算法。 (例如,給定一些FD,根據阿姆斯特朗的公理,還有許多其他的FD;你也需要處理它們,例如,在可能的情況下「保留」FD有一定的好處,並且保留FD的分解爲3NF分量總是可能的;但是如果我們分解使得某些FD屬性在組件之間被分割,我們可能無法保留FD)。
請注意,這些算法不涉及首先歸一化到較低的NF。 (這可以阻止「好的」更高NF設計從最終結果。)
當你分解以從與屬性R的關係中去除FD X→Y時,如果組件具有屬性集XUY和R-Y,則會丟失/不加入。通過重複分解,所有組件將最終在您想要的NF中(如果它是BCNF或更低)。但是你的整體分解不一定會像建議的算法會給你的那樣「好」。
相關問題
- 1. 規範化和關係
- 2. SQL表規範化與非規範化
- 3. 關係數據庫規範化問題
- 4. 規範化傳遞依賴關係
- 5. 規範化一對一布爾關係
- 6. 非規範化關係數據lucene/solr
- 7. 正常化,直到第三範式
- 8. 將模式規範化爲第四範式
- 9. 第三範式的DBMS
- 10. 規範模式與規範在BDD
- 11. 是第三範式的這種關係嗎?
- 12. EF關係和規範模式
- 13. MySQL - 文件系統規範化還是非規範化?
- 14. MySQL - 從第一範式移動到第二和第三範式
- 15. mongo中的規範化與非規範化數據
- 16. 歸到第三範式
- 17. 數據庫第三範式
- 18. 是規範化還是非規範化形式的事實表?
- 19. 規範化表的模式
- 20. 規範化或反規範化?
- 21. 關係數據庫設計 - 規範化和關係
- 22. 報告非規範化與規範化數據庫
- 23. ES6 String.prototype.normalize與W3C規範化
- 24. RDBMS規範化與性能
- 25. 非規範化JSON與JQ
- 26. 規範化使範圍[0,1]
- 27. 規範化scipy.ndimage.filters.correlate
- 28. 規範化sklearn
- 29. 規範化表
- 30. RDBMS - 規範化
是的,你應該刪除這些屬性。考慮到從ABC關係中給定AB的一定值,對於C有一個(唯一的)值。通過該值,在第二個關係中,可以找到由AB確定的D和E的值。 – Renzo
請儘可能使用文字而不是圖片。部分圖像無法搜索或剪切和粘貼。 – philipxy
轉到您提供的用於定義「傳遞性FD」的*參考*以及分解爲3NF/BCNF的算法。那麼,如果「所有這些屬性也可以由關係的主鍵確定」呢? PK *總是*確定所有屬性。做「關係」和「這種關係」是指原來還是「新關係」?而且,PKs並不重要,CK也可以。這與傳導型FD和BCNF有什麼關係?爲什麼BCNF如果你想要3NF?請編輯您的問題以清楚。說明你正在談論的所有這些事情,並確保它總是清楚你指的是什麼。 – philipxy