Ищете HW двойную проверку на дизайн базы данных - PullRequest
Новая
       18

Ищете HW двойную проверку на дизайн базы данных

0 голосов
/ 13 сентября 2009

Привет всем ... так что я работаю над классом дизайна базы данных для университета. У меня есть вопрос ниже, и моя попытка на диаграмме здесь http://tinypic.com/view.php?pic=httchc&s=3.. кто-нибудь возражал бы взглянуть и предложить предложения? спасибо за помощь !!

ВОПРОС:

Вопрос 3 Следующая ситуация описывает компанию, которая хотела бы внедрить информационную систему. Компания хотела бы отслеживать своих сотрудников, отделы и проекты. Предположим, что отдел MIS компании прошел этап сбора и анализа требований и предоставил вам отчет о спецификации со следующими описаниями.

Компания организована в отделы, которые могут иметь несколько отделений. У каждого отдела есть уникальное имя, уникальный номер и менеджер. Компания отслеживает дату, когда каждый сотрудник начал управлять отделом.

Каждый отдел контролирует ряд проектов, каждый из которых имеет уникальное имя, уникальный номер и одно местоположение.

Компания хранит имя каждого сотрудника, номер социального страхования, адрес, зарплату, пол и дату рождения. Каждый сотрудник назначен только в один отдел, но может работать над несколькими проектами, которые не обязательно контролируются одним и тем же отделом. Компания отслеживает количество часов в неделю, которое сотрудник работает над каждым проектом. Компания также следит за непосредственным руководителем каждого сотрудника.

В целях страхования компания также хотела бы отслеживать иждивенцев каждого сотрудника. Компания хочет записать имя, пол, дату рождения и отношения каждого сотрудника с зависимостью.

Нарисуйте EER-диаграмму для этой ситуации.

Ответы [ 2 ]

0 голосов
/ 13 сентября 2009

Наличие таблицы «Управляет» было бы необходимо для отношения «многие ко многим» (аналогично таблице «Резиденты», то есть ко многим). Поскольку в каждом отделе есть только 1 менеджер, вместо этого вы можете иметь одно поле EmployeeIdOfManager (и DateStarted) в таблице Department.

Мне нравится соглашение об именах для rexem для таблиц, которые моделируют отношение многие ко многим, например, «EMP_PROJECTS_XREF» лучше для меня, чем «InvolvedWith».

Поле DirectSupervisor должно быть обнуляемым (например, для главного босса).

Я считаю, что в таблице InvolvedWith не должно быть поля DepartmentId.

Вам следует выяснить, может ли в одном месте существовать более одного отдела. Если это так, тогда в таблице Location не должно быть поля DepartmentId, а если нет, то вам не нужна таблица Resides.

0 голосов
/ 13 сентября 2009

Вот физическая модель - я оставляю это вам или кому-то еще, чтобы нарисовать:

DEPARTMENTS стол

  • DEPARTMENT_ID (pk)
  • DEPARTMENT_NAME (Великобритания)

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) - этот составной ключ позволяет кому-либо быть менеджером в течение одного и того же отдела 2+ раза, если он не запускается в ту же дату.
  • EXPIRY_DATE (не ноль)

PROJECTS стол

  • PROJECT_ID (pk)
  • DEPARTMENT_ID (fk)
  • PROJECT_NAME (Великобритания)
  • LOCATION_ID (fk)

EMPLOYEES стол

  • EMPLOYEE_ID (pk)
  • DEPARTMENT_ID (fk)
  • FIRST_NAME
  • MIDDLE_NAME
  • LAST_NAME
  • SIN
  • ЗАРПЛАТА
  • SEX
  • BIRTH_DATE

EMP_PROJECTS_XREF стол

  • EMPLOYEE_ID (pk, fk)
  • PROJECT_ID (pk, fk)

DEPENDENT_RELATIONSHIP_CODES стол

  • DEPENDENT_RELATIONSHIP_CODE (шт.)
  • ОПИСАНИЕ * * 1 095

DEPENDENTS стол

  • DEPENDENT_ID (pk)
  • EMPLOYEE_ID (fk)
  • FIRST_NAME
  • BIRTH_DATE
  • SEX
  • DEPENDENT_RELATIONSHIP_CODE (фк)
...