5

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

これは私が思いついた図で、派生したスキーマは次のとおりです。

Part エンティティを削除すると、Circuit エンティティが任意の数の任意のパーツを「使用」し、各パーツをおそらく任意の回路に関連付けるには、各コンポーネントから個別の M 対 N の関係が必要になります。回路に入力します。これらの関係ごとに、新しいテーブルが生成されます。これは、プロジェクトで許可されているテーブルの厳密な最大数を確実に超えてしまいます。

教授が部分が不要であると具体的に述べた場合、それを削除してより単純なER図とスキーマにする方法があるに違いありませんが、それが何であるかはわかりません。

たぶん、あなたたちはそれが何であるかを見て、私にヒントを与えることができますか?

編集: ダン W は素晴らしい提案をしました。各パーツ タイプ (コンデンサ、抵抗器など) に独自のキーを与えることで、パーツを削除できます。次に、uses 部分の内部に、それらのコンポーネントへの外部キーを含めます。テーブルの各エントリは 1 つの部分にのみ関連付けられ、残りは null であると想定する必要があります。結果のスキーマは次のとおりです。このスキーマはうまく機能するはずです。しかし今、ER図のどの変更がこのスキーマに対応するかを正確に把握する必要があります。

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

4

1 に答える 1

1

テーブルの厳密な最大数 (物理設計) がありますが、ER 図でその数のエンティティ (論理設計) に制限されていますか? パーツのすべてのエンティティ (抵抗器、トランジスター、コンデンサー、および一般的な IC) は、パーツ、抵抗器、トランジスター、コンデンサー、および一般的な IC のすべての属性を null 可能な列として 1 つのパーツ テーブルに格納できます。属性がすべての型で有効な場合、その属性は null 許容ではありません。部品のタイプ (抵抗、トランジスタ、コンデンサ、または IC) を識別する部品テーブルに別の列を含めますが、これにも役立つ可能性があるすべてのエンティティに既にタイプ列があります。

スキーマの Parts テーブルは次のようになります。

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

Resistor、Capacitor、Transistor、および General IC テーブルをスキーマにドロップします。これらのエンティティを ER ダイアグラムに残します。これにより、パーツ テーブルのどの属性が各パーツ タイプに必要である (null であってはならない) かがわかるためです。

于 2012-02-20T15:16:41.360 に答える