sql - レストランメニューとはどのような正規化形式ですか？

Question

これはおそらく話題から外れていますが、私は興味があります。

itemID、食事の名前、価格が記載された通常のレストランメニューがあるとします。それはどのような正規形ですか？

BCNFだと言いますが、推移的な依存価格->アイテム名->アイテム番号のために3NFにはないという友人が持ち出しました。皆さんはどう思いますか？

Answer 1

レストランのメニューは通常の形式ではありません。他の一連の要件と同様に、メニューはBCNFのリレーションスキーマとして、またはBCNFにない他のスキーマとして表すことができます。これは、データベース設計者がスキーマを作成するときに行う選択です。メニュー情報自体に暗黙的なものではありません。

問題のスキーマを正確に指定していません。関係を仮定すると：

Menu {ItemID, Name, Price}

{ItemID}と{Name}の2つのキーを使用すると、機能依存性のセットに関してMenuがBCNFになります。

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

NameとItemIDの両方が候補キーであるため、これらは非キーの推移的な依存関係ではありません。メニューはBCNFにあるので、3NFにもあります。

関数従属性は、常に行列式->依存性の形式で記述されます。価格が決定要因になる可能性がどのようにあるかわかりません（メニューのすべてのアイテムに固有の価格は非常にありそうにないようです）ので、あなたが言及した依存関係：価格->アイテム名->アイテム番号はあまり意味がありません私に。価格が何らかの理由で重要でない決定要因であった場合、上記のメニュー関係はもちろんBCNF（および3NF）に違反します。

Answer 2

メニューが1つの言語のみの場合、テーブルには2つのキー（idとname）があり、すべての非キー（価格）はすべてのキーに依存しており、3NFを満たしています。非キー列が1つしかないため、4NFも満たされます。5NFと6NFはマルチテーブル関係を処理します。テーブルが1つしかないので、彼らも満足しています。

メニューが多言語の場合でも、メニューは第1正規形を満たしますが（仮想列「言語」を真の列と見なす場合、それ以外の場合、メニューは1NFでもありません）、第2正規形を満たしません。キー属性は、キーの適切なサブセットに依存します。ここでのスキーマは次のとおりです。columns（language、id、name、price）; keys（（language、id）、（name [、language]））ただし、価格は食事IDのみに依存し、注文された言語には依存しません。

DB-理論的には、適切な分解は、テーブルのペアtable（language、id、name）keys（（language、id）、（name [、language]））table（id、price）keys（id）を導入することです。もちろん、これは実際のレストランでは不便であり（英語のメニューと翻訳テーブルの2つのメニューを取得することを想像してください）、唯一の利点は、暗黙ではなく、言語に対する価格の独立性が強制されることです。

名前が価格に依存することはありません。価格によって名前が決まるわけではありません。それは反対の方法です。