いくつかのデータベース設計テクニックを学習するための練習として、私は架空の小さなコンピュータショップ用のデータベースを設計しています。ショップが複数のサプライヤからいくつかのコンポーネントを入手し、それらをコンピュータシステムに組み立てて顧客に販売するという考え方です。 Image小規模なコンピュータショップのためのデータベースデザイン、提案を探してください
いくつかの説明：
このモデルの中央エンティティがアイテムである
は、ここで私は、これまでに作ってみたモデルの画像です。これは、ショップが所有または販売している単一の品目、例えば正確なi7 920プロセッサーを表します。このアイテムは、カテゴリ（「プロセッサ」）に属する製品（この場合は「Intel i7 920」）に属します。
これらの商品は注文により店舗に入ります。サプライヤからコンポーネントが注文されると、Ordersテーブルの新しいエントリが作成されます。オーダーされた各Itemに対して、Itemテーブルの新しいエントリーが作成され、OrderItemに対応するエントリーがあります（このテーブルのより良い名前...）。
OrderItemエントリには、基本的に、ショップが請求書に受け取った商品コスト、同じ説明などが含まれています。注文フィールドは、注文を表示または印刷する必要がある場合にアイテムが表示される順序を決定します。
お客様が何かを購入すると、請求書が作成されます。購入した各アイテムは、InvoiceItemが作成されます。これは基本的にOrderItemと同じ方法で動作します。価格フィールドは、顧客が支払う価格です（価格は製品ごとではなく、各請求書ごとにカスタマイズされていますが、商品ごとの価格を把握して価格の変化を追跡できる優雅な方法は見つけられません） 。 descriptionがNULLの場合、対応する商品の説明が請求書に表示されます。そうでない場合、その請求書のカスタム説明を入力できます。
ここで、手の込んだ部分は「アセンブリ」テーブルです。店舗が「PC 1」というPCシステムを販売している場合、「PC」カテゴリーに属する「製品」には「PC 1」項目があります。 「PC 1」システムが組み立てられるたびに、（ProductIDが「PC 1」の）新しいItemが作成され、このシステムの各コンポーネントに対して、Assemblyにエントリが追加されます。assemblyIDは新しいItemのitemIDになります、componentIDはコンポーネントのitemIDです。
私は、Assembliesテーブルなしでこれを管理する別の方法を考えました。ショップは架空の顧客に0 $（実際には0 CHF）のコンポーネントを「売る」ことができ、架空のサプライヤ（再び、無料で）。コンポーネントは在庫から消えるため、これは簡単なことですが、「売れた」コンポーネントを「買った」コンピュータにリンクする簡単な方法がありますか？
今、私はその形を学んだことにとても満足しています。しかし、確かに私が考えることができないものを表現するいくつかの誤りやいくつかのより良い方法があります。私は何か提案や批判を受けてうれしいです。前もって感謝します！
PS：テキストがちょっと長いと申し訳ありません...また、悪い英語のケースでご迷惑をおかけします（私の主な言語ではありません。 ）