データベースの簡略化ER図/スキーマ

Question

学校プロジェクトでは、独自のデータベースを作成する必要があります。電子部品の在庫を管理するためのデータベースを作成することにしました。必要条件として、ER図を作成し、その図からデータベーススキーマを導出する必要がありました。私にとって不幸なことに、教授は私が作成したダイアグラムを単純化することができ、「パート」エンティティは不要だと考えています。

This私が思い描いた図であり、hereは派生したスキーマです。

Circuitエンティティを削除すると、Circuitエンティティが任意の数のパーツを「使用」し、各パーツに任意の回路が関連付けられるようにするには、別々のM対N各コンポーネントタイプからCircuitへの関係。それらのリレーションシップのそれぞれが新しいテーブルを生成します。これは間違いなく、プロジェクトに許可されているテーブルの厳密な最大数を超えます。

教授がPartに特に言及していない場合は、それを削除する方法が必要であり、その結果、より簡単なER図とスキーマが得られますが、その内容はわかりません。

多分あなたはそれが何であるかを見て、私にヒントを与えることができますか？

EDIT： Dan Wは素晴らしい提案をしました。私は、各部品のタイプ（コンデンサ、抵抗器など）に独自のキーを与えることによって、部品を排除することができました。使用部分の内部には、これらのコンポーネントへの外部キーが含まれます。私は、テーブルの各エントリは、単一の部分にのみ関連し、残りはnullであると仮定しなければならないだろう。結果のスキーマHere'sこのスキーマはうまくいくはずです。しかし今、ER図の修正がこのスキーマに対応するかどうかを正確に把握しなければなりません。

EDIT2： 私は、私が探している関係がn-aryであるという結論に達しました。いくつかの情報源によると、n-aryをスキーマに変換するには、参加するエンティティタイプの関係の主キーを外部キーとして含めます。次に、単純な属性を追加します。私が思いついたのはThisです。

Answer 1

テーブルの物理的な最大数はありますが、ER図でそのエンティティ数（論理設計）に制限されていますか？パーツ、レジスタ、トランジスタ、コンデンサ、および汎用ICのすべての属性をnull許容列として1つのパーツテーブルに格納することができます。属性がすべての型に対して有効である場合、その属性はNULL可能ではありません。パーツテーブルには、パーツのタイプ（抵抗、トランジスタ、コンデンサまたはIC）を識別するための別の列を含めてください。ただし、これに対応するすべてのエンティティにすでにタイプの列があります。

スキーマ内の部品表は以下のようになります。

PartID (PK) 
Quantity 
Drawer 
Part Type 
Value 
Tolerance 
Subtype 
Power Rating 
Voltage 
Term_Style 
Diam 
Height 
Lead_Space 
Name 
Case 
Polarity 
Use 
V_CE 
P_D 
I_C 
H_FE 
Package 
Pins 
Description 

、あなたのスキーマに抵抗、コンデンサ、トランジスタおよび一般的なICのテーブルをドロップします。これらのエンティティはER図に残しておきます。これは、各パーツタイプに対して、どのパーツテーブルが必要であるか（nullであってはならない）を示しているためです。