2009-09-12 1 views
0

皆さん、こんにちは。私は大学のデータベースデザインクラスに取り組んでいます。私は下の質問とここの図で私の試みはhttp://tinypic.com/view.php?pic=httchc&s=3 ..誰も見て、提案を提供する気になるだろうか?助けてくれてありがとう!!データベースデザインでHWダブルチェックを探しています

QUESTION:

質問3 次のような状況では、情報システムを実装したい会社を説明します。同社は従業員、部署、およびプロジェクトを把握したいと考えています。企業のMIS部門が要件収集および分析フェーズを実行したとし、以下の説明で仕様レポートを提出したとします。

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

各部門は、それぞれ固有の名前、固有の番号、および単一の場所を持つ多数のプロジェクトを制御します。

各従業員の名前、社会保険番号、住所、給与、性別、生年月日が保存されています。各従業員は1つの部門にのみ割り当てられますが、必ずしも同じ部門によって管理されているわけではない複数のプロジェクトでも使用できます。会社は従業員が各プロジェクトで働く週数を追跡します。また、各従業員の直属の監督者を追跡しています。

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

この状況のEER図を描画します。

DEPARTMENTSテーブル

  • DEPARTMENT_ID(PK)
  • DEPARTMENT_NAME(英国)

:私はそれを描画するために、あなたや他の誰かにそれを残す - ここ

答えて

0

は、物理的なモデルですLOCATIONSテーブル

  • LOCATION_ID(PK)
  • LOCATION_NAME

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)、誰かが同じDEPT 2+回のマネージャーであるために複合キーがあればそのまま、可能 - 当同じ日付に開始されません。(nullでない)

PROJECTSテーブル

  • PROJECT_ID(PK)
  • DEPARTMENT_ID(FK)
  • PROJECT_NAME(英国)
  • LOCATION_ID(FK)
  • EXPIRY_DATE

    EMPLOYEESテーブル

    • EMPLOYEE_ID(PK)
    • DEPARTMENT_ID(FK)
    • FIRST_NAME
    • MIDDLE_NAME
    • LAST_NAME
    • SIN
    • SALARY
    • SEX
    • Birth_Dateの

    EMP_PROJECTS_XREFテーブル

    • EMPLOYEE_ID(PK、FK)
    • PROJECT_ID(PK、FK)

    DEPENDENT_RELATIONSHIP_CODESテーブル

    • DEPENDENT_RELATIONSHIP_CODE(PK)
    • DESCRIPTION

    DEPENDENTSテーブル

    • DEPENDENT_ID(PK)
    • EMPLOYEE_ID(FK)
    • FIRST_NAME
    • Birth_Dateの
    • SEX
    • DEPENDENT_RELATIONSHIP_CODE(FK)
  • 0

    多対多関係(多対多である 'Resides'表に似ています)には、 'Manages'表が必要です。各部門にはマネージャが1つしかないので、Departmentテーブルに単一のEmployeeIdOfManagerフィールド(およびDateStarted)を持つことができます。

    多対多リレーションシップをモデル化するテーブルのrexemの命名規則が好きです。 'EMP_PROJECTS_XREF'は「InvolvedWith」よりも優れています。

    [DirectSupervisor]フィールドは、(たとえば、上のボスの場合は)ヌル入力可能でなければなりません。

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

    複数の部署が同じ場所に存在できるかどうかを問い合わせる必要があります。そうであれば、LocationテーブルにDepartmentIdフィールドがあってはならず、そうでなければResidesテーブルは必要ありません。

    関連する問題