多くの属性を持つDBテーブルの設計

Question

この場合、dbデザインがどのように見えるかを知りたいと思います。私の心に来る何

のようなすべてのエンティティのためのテーブルです：

Engine 
EngineDesign 
ElectricalSystem 
Drivetrain 
etc. 

しかし、それはテーブルの多くとして私には見えます。私の考えは大丈夫ですか？

ドライブトレインはどうですか？今日我々は8つのギアを持っていますが、製造元に別のものがあればいつでも変更することができます。 （行）

DrivetrainId | Gears 
1   | 1st 
2   | 2nd 
3   | 3rd 
etc. 

Answer 1

テーブルを数えることで、データベース設計の健全性を判断することはできません。 「あまりにも多くのテーブル」の通常のフォームや「十分でないテーブル」のようなものはありません。また、「あまりにも多くの列」の通常の書式、または「十分でない列」の通常書式のようなものはありません。

今日のように、トランスミッションギア比ごとに1つの列があると5NFになります。これは、同じドメインの値が問題となる複数の列を持たないためです。複数の列を持ち、その値は同じドメインから来ており、同じ意味を持つという問題があります。

明らかに、第8ギアと第1ギアは異なる意味を持っています。実際には、それらを異なるドメインから引き出すことが考えられます。私の推測では、0.67は第1速の有効な値ではなく、4.85は第8の有効な値ではないということです。

これらは

• 、異なる列に格納されている場合、それはすべての行が8変速比のそれぞれの値を持っている制約を強制するのは簡単だし、有効な値の範囲に
• 制約各ギア比は本当に簡単です。 （しかし、あなたは唯一の5または6のギアを持つ以降のデザインのため、NULL値に対応するために持っている、そしてそれは、正規化の問題を提起する。）
それらは行として格納されている

、

• が、それは難しいです - 不可能かもしれません - 各車両が8つの変速比のそれぞれの値を有するという制約を実施するためには、各変速比に対する有効値の範囲に対する制約がより複雑である。 （特に後でギアが5または6つしかないデザインに適応する場合。）

Answer 2

私の最初の本能は、属性で何かをするだろう
表（列）

DrivetrainId | 1st | 2nd | 3rd | etc. 

それとも

表：

それは、このようにする必要がありますテーブルと車のテーブル（私は車を想定していますか？）

Attributes 
AttributeId | AttributeCategory | AttributeDesc 

Cars  
CarId | AttributeId | AttributeValue