2016-12-28 15 views
0

商品には異なるカテゴリがあります。顧客は同じカテゴリーの複数の商品のみを注文することができ、同じカテゴリーで異なるカテゴリーの商品を注文することはできません。彼らは、各カテゴリーごとに別々の注文を作成する必要があります。私の問題は、これを設定する方法を理解できないことです。スクリーンショットを参照してください。今設定されている方法でOrder_DetailsにProductIDがあるので、クライアントが異なるカテゴリから複数の製品を選択するのを止めることはありません。異なるカテゴリの製品を1つの注文で限定する

OrdersテーブルまたはOrders_ItemsテーブルにCategoryID FKを設定した場合、カテゴリは製品の属性であり、注文ではないため、正規化の2番目の形式に違反します。製品カテゴリーは2つの表になるため、冗長性も作成されます。

このために別のテーブルを作成する必要がありますか、何らかの制約によってこれを制限する方法はありますか? (はい、私は自分のアプリケーションでプログラム的にこれを制限することができますが、私はむしろそれがデータベースに正しく設定しています。

enter image description here

+1

個人的に私はこの種のものはあなたのコードで完結していると思います...特殊化をチェックして別のテーブルを追加することはできますが、データベース構造は問題ありません。あなたはあなたのデータベースに妥当性検査を依頼していますが、テーブル構造はあなたにそれを手助けしません。私の意見 – Veljko89

+0

あなたはこれを達成しようとしているコードを共有することができます... – Vikrant

+0

私はまだコードを使用していません。すべてのデザインは、GUIとペンとペーパーで行いました。 –

答えて

1

私はOrdersOrder_Itemsの両方でCategoryIDを追加し、コンポジットFK制約を使用します参照整合性を確保:

ALTER TABLE Order_Items 
ADD FOREIGN KEY (OrderID, CategoryID) 
REFERENCES Orders (OrderID, CategoryID); 

ALTER TABLE Order_Items 
ADD FOREIGN KEY (ProductID, CategoryID) 
REFERENCES Products (ProductID, CategoryID); 

は、これが作成される、適切なインデックスが必要になります

を追加します。 Ordersテーブルのは、OrderIDに依存しているため、2NFまたは3NFに違反しません。関数の依存性を記録または導出する他の方法がないため、これは冗長ではありませんOrderID -> CategoryID。それは推移関数従属性(OrderItemID -> OrderID -> CategoryIDOrderItemID -> ProductID -> CategoryID)を作成するため

Order_ItemsCategoryIDを追加する3NFに違反します。ただし、上記のFK制約を使用すると、データの異常が発生するリスクはありません。情報の観点から冗長性を導入していますが、管理された冗長性であり、参照整合性のために使用されるため正当です。

トリガーを使用すると冗長性なしで同じ目的を達成することができます(OrdersにはまだCategoryIDが必要です)が、私はFK制約の単純さを好みます。

+0

なぜこれを単純化しないのですか?このようにOrderテーブルにCategoryIDを入れるだけで、クライアントが新しい注文を出してカテゴリを選択すると、そのカテゴリの商品のみが表示されます。問題は解決した、いいえ? –

+1

UIとデータモデルは直交しています。関連するオプションのみをユーザーに提示することは良いことですが、DBレベルで注文と注文製品の一貫性を強制する方法がないと、無効なデータが記録され、修正が時間をかける可能性があります。バグが発生し、複数のアプリケーション機能や手動でデータが更新されます。単一の場所で完全性を強制することは、代替案よりも簡単で正確です。 – reaanb

関連する問題