0

皆さん、こんにちは...大学のデータベース設計クラスに取り組んでいます。以下に質問があります。ここで図を試してみましたhttp://tinypic.com/view.php?pic=httchc&s=3 .. 誰か見て、提案をしてくれませんか? 助けてくれてありがとう！！

質問：

質問 3 次の状況は、情報システムを導入したいと考えている会社を表しています。会社は、従業員、部門、およびプロジェクトを追跡したいと考えています。会社の MIS 部門が要件の収集と分析のフェーズを行い、次の説明を含む仕様レポートをあなたに渡したとします。

会社は、複数の場所を持つことができる部門に編成されています。各部門には、固有の名前、固有の番号、およびマネージャーがいます。会社は、各従業員が部門の管理を開始した日付を追跡します。

各部門は多数のプロジェクトを管理しており、各プロジェクトには固有の名前、固有の番号、および単一の場所があります。

会社は、各従業員の名前、社会保険番号、住所、給与、性別、生年月日を保存します。各従業員は 1 つの部門にのみ割り当てられますが、必ずしも同じ部門によって管理されるとは限らない複数のプロジェクトに取り組む場合があります。会社は、従業員が各プロジェクトで週に何時間働いたかを追跡します。会社はまた、各従業員の直属の上司を追跡します。

保険の目的で、会社は各従業員の扶養家族も追跡したいと考えています。会社は、各扶養家族の名、性別、生年月日、従業員との関係を記録したいと考えています。

この状況の EER ダイアグラムを描画します。

4

2 に答える 2

0

これが物理モデルです - 描画はあなたか他の誰かに任せます:

DEPARTMENTSテーブル

  • DEPARTMENT_ID (pk)
  • DEPARTMENT_NAME (英国)

LOCATIONSテーブル

  • LOCATION_ID (pk)
  • 場所の名前

DEPT_LOCATIONS_XREFテーブル

  • DEPARTMENT_ID (pk、fk)
  • LOCATION_ID (pk、fk)

DEPT_MANAGER_XREFテーブル

  • DEPARTMENT_ID (pk、fk)
  • EMPLOYEE_ID (pk、fk)
  • EFFECTIVE_DATE (pk) -- この複合キーにより、開始日が同じではない限り、誰かが同じ部門のマネージャーになることが 2 回以上可能になります。
  • EXPIRY_DATE (非ヌル)

PROJECTSテーブル

  • PROJECT_ID (pk)
  • DEPARTMENT_ID (fk)
  • PROJECT_NAME (英国)
  • LOCATION_ID (fk)

EMPLOYEESテーブル

  • EMPLOYEE_ID (pk)
  • DEPARTMENT_ID (fk)
  • ファーストネーム
  • ミドルネーム
  • 苗字
  • 罪
  • 給料
  • セックス
  • 生年月日

EMP_PROJECTS_XREFテーブル

  • EMPLOYEE_ID (pk、fk)
  • PROJECT_ID (pk、fk)

DEPENDENT_RELATIONSHIP_CODESテーブル

  • DEPENDENT_RELATIONSHIP_CODE(ピーク)
  • 説明

DEPENDENTSテーブル

  • DEPENDENT_ID (パック)
  • EMPLOYEE_ID (fk)
  • ファーストネーム
  • 生年月日
  • セックス
  • DEPENDENT_RELATIONSHIP_CODE(fk)
于 2009-09-13T00:01:39.307 に答える
0

多対多の関係には「Manages」テーブルが必要です (多対多の「Resides」テーブルと同様)。各部門にはマネージャーが 1 人しかいないため、代わりに Department テーブルに 1 つの EmployeeIdOfManager フィールド (および DateStarted) を含めることができます。

私は、多対多の関係をモデル化するテーブルに対する rexem の命名規則が気に入っています。たとえば、' EMP_PROJECTS_XREF' は 'InvolvedWith' よりも優れています。

DirectSupervisor フィールドは NULL 可能でなければなりません (トップ ボスの場合など)。

InvolvedWith テーブルに DepartmentId フィールドがあってはならないと思います。

複数の部門が同じ場所に存在できるかどうかを照会する必要があります。その場合、Location テーブルに DepartmentId フィールドはありません。そうでない場合は、Resides テーブルは必要ありません。

于 2009-09-13T01:00:24.717 に答える