このデータ構造の何が悪いのか、そしてどのように改善するのかを説明するように求められました。
データ構造は次のとおりです。
これが私がこれまでに持っているものです：
車の価格は、車がショールームにある場合にのみ設定されます。車の価格を車のテーブルに置く方が理にかなっています。
車のテーブルにNULLデータを格納することは意味がありません。次のようなレイアウトを使用することをお勧めします。
一部のショールームには同じ車が複数あるため、ショールームにある特定の車の数を示すには、数量の見出しが必要です。
私が作成した新しいテーブルにはまだ繰り返しデータがありますが、データ構造を作成するときはノーノーだと漠然と覚えているので、3番目のテーブルを作成する必要があると思いますか？よくわかりません。。。
現在のデータ構造の何が問題になっているのかについて少し助けが必要です。それを改善する方法があれば、助けていただければ幸いです。
1つの問題は、Carテーブルが2つの異なるものを格納することです。それはmakeを格納し、モデルを格納します。
したがって、次のように分割する必要があります。
作成：列makename、makecode
モデル：列makecode（makesの外部キー）、modelname、modelcode
そして今、ショールームのテーブルはモデルにのみ関連しているので、誤ってメーカーを参照することはできません。
1つのモデルに関連する多くのショールームテーブル行を含めることができるため、2つのテーブルを意味のある形でマージすることはできません。したがって、それらを分離して、そこから移動します。
車の構造には、車種と車種の両方が格納されているようです。それは少なくともいくつかの警報を発するはずです。フォード、VW、プジョーのような車は独自のものを持っていMakeCodeます。フィエスタやゴルフのような車種には独自のものがありModelCodeます。
元の構造では、車のモデルは、を介してメーカーを参照し、ParentCarIdを複製しMakeCodeます。ModelCode車のメーカーは特定のモデルではなく、およびにnullが割り当てられていParentCarIdます。
意味がありません。ParentCarId車が別の車の子になるとはどういう意味ですか？代わりに、車は別のテーブルで表される別のエンティティであるメーカーに属しています。MakeCodeまた、これは所属するメーカーの属性であるため、車にはを含めるべきではありません。明らかに、メーカーとモデルは非常に異なっており、異なるテーブルで表す必要があります。
そのテーブルを2つに分割することは理にかなっています。1つはメーカー用、もう1つはモデル用です。Makesには、、、IDおよびNameがありMakeCodeます。モデルには、、、、IDおよびa Name（の外部キー）があります。ModelCodeMakeIdIDMake
繰り返しのデータは冗長であるというのは正しいです。
モデルにはさまざまなサブカテゴリが存在する可能性があるため、「ショールーム」を「モデル」に変更します。IEゴルフTDI対GTIなど。...そして基本価格（MSRP）がモデルに適用されます。ショールームのステータスは価格設定には意味がありません-宣伝されているがショールームやロットにはないロットがあります。
データがサポートしているのであれば、NULL可能列があることに問題はないと思います。どちらでも問題ありません。適切な量のデータが得られたらベンチマークを実行して、何が最も役立つかを確認できます。ただし、前ではなく、後で最適化してください。