データベース設計テクニックを学ぶための演習として、架空の小さなコンピューター ショップ用のデータベースを設計しています。アイデアは、ショップが複数のサプライヤーからいくつかのコンポーネントを入手し、それらをコンピューター システムに組み立てて、顧客に販売するというものです。
これまでに思いついたモデルの画像は次のとおりです 。
いくつかの説明:
このモデルの中心となるエンティティはアイテムです。これは、ショップが所有または販売した 1 つのアイテムを表します。たとえば、1 つの正確な i7 920 プロセッサです。このアイテムは、カテゴリ (「プロセッサ」) に属する製品 (この場合は「Intel i7 920」) に属します。
これらのアイテムは注文を介してショップに入ります。コンポーネントがサプライヤから注文されると、Orders テーブルに新しいエントリが作成されます。注文された Item ごとに、Items テーブルに新しいエントリが作成され、それに対応する OrderItem のエントリが作成されます (このテーブルにこれ以上の名前は思いつきませんでした...)。
OrderItem エントリには、基本的に、ショップがサプライヤから請求書で受け取ったものが含まれます: 商品の価格、同じ説明など。注文フィールドは、注文を表示または印刷する必要がある場合に、商品がどの順序で表示されるかを決定します。
一方、顧客が何かを購入すると、請求書が作成されます。購入するアイテムごとに、InvoiceItem が作成されます。基本的には OrderItem と同じように機能します。価格フィールドは、顧客が支払う価格です（価格は製品ごとではなく、請求書ごとにカスタマイズされていると仮定しましょう。製品ごとの価格を設定し、価格の変化を追跡できるエレガントな方法を見つけることができませんでした） . description が NULL の場合、対応する製品の説明が請求書に表示されます。それ以外の場合は、その請求書のカスタム説明を入力できます。
ここで注意が必要なのは、Assemblies テーブルです。ショップが「PC 1」という PC システムを販売している場合、たとえば「PC」カテゴリに属する「PC 1」エントリが製品に表示されます。「PC 1」システムが組み立てられるたびに、新しいアイテムが作成され (「PC 1」の productID を持つ)、このシステムの各コンポーネントに対して、エントリがアセンブリに追加されます。assemblyID は、新しいアイテムの itemID になります。 、 componentID はコンポーネントの itemID です。
Assemblies テーブルを使用せずにこれを管理する別の方法を考えました: ショップはコンポーネントを 0 $ (実際には 0 CHF) で架空の顧客に「販売」し、組み立てられたコンピューターを架空のサプライヤーから「購入」することができます (ここでも、自由）。コンポーネントが在庫から消えるため、これは簡単に実行できるように思えますが、「販売された」コンポーネントを「購入された」コンピュータにリンクする簡単な方法はありますか?
今、私はそこから学んだことにとても満足しています。しかし、私が考えられなかったものを表現するためのいくつかのエラーやより良い方法が確かにあります. 提案や批判をいただければ幸いです。前もって感謝します！
PS: テキストが少し長い場合は申し訳ありません... また、いくつかの悪い英語のケースについては申し訳ありません (それは私の主な言語ではありません (それはまた、選択が不十分なフィールド/テーブル名を説明することにもなります (私は喜んで取得します)提案）））