0

データベース設計に不慣れで、オンラインで製品を販売し、顧客への繰り返し処方箋の注文も受け入れる薬局のERDを作成しようとしています。

これが私のERDへのリンクです：http： //i.imgur.com/aiKP0.png

両方の注文で「支払い」エンティティと「カード詳細」エンティティを1つだけ使用するにはどうすればよいのでしょうか。したがって、注文ごとに2つのエンティティがあります。ORDERTYPEエンティティと支払い/カード詳細エンティティの間に関係を作成できますか？

どんな助けでもいただければ幸いです。ありがとう

4

2 に答える 2

0

Prescription_Order私はとの両方を持っている正当な理由を見つけようとしていますProduct_Order。Orders（ORDERはどこでも予約語であるため複数形）テーブルが必要です。このテーブル（およびCustomer_Recurring_Orderへの参照の自然キーを含む）は、処方箋であるかどうかに関係なく、顧客の定期的な注文のルールを示します。 。あなたの薬の属性は、製品テーブルのレコードとして適切に属します。CustomerProduct

また、カードの詳細は機能的に顧客の存在に依存していると確信しているため、Card Detailsテーブルは1つ以上に適切にリンクされている必要があります。Customer

それらをクリーンアップしたら、必要なのは1つPaymentまたはCard Detailsエンティティのみです。覚えておくとよい設計原則は、2つのエンティティがすべて同じ属性を持っている場合、それらはおそらく2つの異なるエンティティではないということです。

配送情報を別のエンティティに分割しなかったのはなぜですかOrder_Shipment。すべての出荷には、常に顧客の注文のすべての部分が含まれますか？

于 2012-04-25T17:16:53.847 に答える
0

ただし、設計にはいくつかの欠陥があります。

  1. Product OrderおよびOrder Product。開発者と管理者は、どのテーブルが何に使用されているかを思い出すと夢中になります。
  2. なぜあなたが2を持っているのかは不明Card Detailsですか？列をPerscription_PaymentID追加する代わりに、逆の方法で実行します。両方のテーブルにフィールドを追加します。Product_PaymentIDCard DetailsCardID
  3. Customerと参加する意図は私にはわかりませんORDER TYPE。名前を変更することを検討してください。

また、この小さな応答を記述しても、スペース、アンダースコア、大文字と小文字が混在する名前、単数形/複数形のバリエーションを含むテーブル/列の名前を追跡することは非常に困難でした。

この回答を見て、リレーション、列、および制約に名前を付ける際に一般的なアプローチを使用することを検討してください。

于 2012-04-24T09:49:13.393 に答える