0

私は初心者のデータベース管理者で、ハードウェア インベントリ スプレッドシートを取得して SQL サーバーに移行するプロジェクトに取り組んでいます。現在、データは 1 つの大きな非正規化ビューとして存在します。3NFを実現しようとしているのですが、なんとなくうまく設計できていない気がします。

状況の概要を簡単に説明します。

  • 学区には複数の建物があり、複数の部屋があります。学校は拡張期を迎えているため、新しい部屋が常に「構築」されているため、「部屋番号」を主キーとして使用できないため、代理キーを使用するようになりました。
  • 教師は部屋に割り当てられますが、部屋には必ずしも教師がいる必要はありません (つまり、ラボ)。先生も部屋を変えることができます。
  • ハードウェアを購入すると、バーコード番号が付与されます (PO の項目番号と考えてください)。実際のハードウェアは、シリアル番号で識別されます。
  • ハードウェアは部屋に割り当てられ、ワークステーション番号と IP アドレスが割り当てられます。

デザインはしっかりしているように見えますか、それとも欠陥がありますか? また、1 対多の関係の間でジャンクション テーブルを作成しても問題ありませんか (特定のハードウェアが部屋に割り当てられ、部屋には多くのハードウェアがある場合があります)。

以下のリンクを見つけてください。

論理データベース設計

4

2 に答える 2

1

各エンティティの機能分解から始めて、それが「何であるか」とどのように使用されるかを定義します。3NF とは、重複を避け、適切なレベルの参照を維持することです。

この問題では、建物をモデル化します (PK: 自動 ID、名前など)。次に、外部キーを使用して ROOM (PK: 自動 ID、番号など) を BUILDING プライマリ キーにモデル化します。次に、外部キーなしで TEACHER (PK: 自動 ID、名前など) をモデル化します。

教師と部屋の割り当ての関係については、結合テーブルを使用します。

TEACHER_ROOM

これには、次の複合主キーがあります: TEACHER_ID ROOM_ID

したがって、教師を部屋に割り当てることができますが、部屋は教師を必要としません。このモデルでは、教師を多くの部屋に割り当てることができます (1 対多のカーディナリティ)。

ハードウェアでも同じこと - SERIAL_NUMBER などでそれ自体を定義します。次に、どのハードウェアがどの部屋にあるか、HARDWARE ID に一意のキーを持つ ROOM_HARDWARE テーブルを用意します。多くのハードウェアがあります。

于 2013-05-28T18:23:29.023 に答える
0

私が唯一気になったのは、ハードウェア テーブルです。カテゴリとメーカーは別のテーブルにある必要があります。

于 2013-05-28T18:19:15.960 に答える