什麼規範化形式是餐廳菜單？

Question

這可能是題外話題，但我很好奇。

假設您有一個正常的餐館菜單，其中包含商品ID，用餐名稱和價格。它是什麼樣的正常形式？

我說這是BCNF，因爲朋友提出，它不在3NF，因爲傳遞依賴性價格 - >項目名稱 - >項目編號。你們有什麼感想？

Answer 1

餐廳菜單沒有任何常規形式。與其他任何要求一樣，菜單可以表示爲BCNF中的關係模式，也可以表示爲BCNF中沒有的其他模式。這是數據庫設計人員在創建模式時所做的選擇;而不是菜單信息本身隱含的內容。

您還沒有完全指定有問題的架構。假設關係：

Menu {ItemID, Name, Price} 

與兩個密鑰：{的ItemID}和{名稱}然後菜單是在BCNF相對於所述一組函數依賴的：

ItemID -> Name -> Price 
Name -> ItemID -> Price 

這些不是非關鍵傳遞因爲Name和ItemID都是候選鍵。由於Menu在BCNF中，它也在3NF中。

函數依賴關係總是以「行列式 - >從屬」的形式寫入。我沒有看到Price如何成爲決定因素（菜單上每個項目的獨特價格看起來極不可能），因此您提到的依賴關係：價格 - >項目名稱 - >項目編號沒有多大意義對我來說。如果由於某種原因價格確實是非關鍵因素，那麼上面的菜單關係當然會違反BCNF（和3NF）。

Answer 2

如果菜單隻有一種語言，那麼表中有兩個鍵（id和name），每個非鍵（價格）依賴於每個鍵，滿足3NF。 4NF也是滿意的，因爲只有一個非關鍵列。 5NF和6NF負責多桌關係;因爲只有一張桌子，他們也很滿意。

如果菜單是多種語言，菜單仍然滿足第一範式（如果我們將虛擬列「語言」視爲真正的列;否則菜單甚至不是1NF），但不能滿足第二範式：沒有非鍵屬性依賴於鍵的正確子集： 這裏的模式是：columns（language，id，name，price）;鍵（（語言，id），（名稱[，語言]）），但價格取決於膳食ID只，而不是它的訂購語言。

DB理論上，適當的分解將引入 表（ID，價格）鍵（ID） 。表（語言，ID，名稱）鍵（（語言，ID），當然，這對於一家真正的餐廳來說會很不方便（想象一下獲得兩個菜單 - 一個英文菜單和一個翻譯表），唯一的好處是語言價格的獨立性是強制性的而不是暗示性的。

名稱對價格沒有依賴性：價格並不決定名稱;這是相反的方式。