Person -> Подробная структура базы данных

Question

У меня есть модель домена:
Сотрудник: Id, FirstName, LastName, Sex, BirthDate.
Офис: сотрудник, рабочая станция, имя офиса и т. Д.
Контакты: сотрудник, мобильный телефон, электронная почта и т. Д ...

Но я не уверен насчет моей текущей структуры базы данных. Как правильно: таблица «Сотрудники» имеет PK EmployeeID, а таблицы «Офисы и контакты» имеют свои собственные идентификаторы и ссылку на таблицу «Сотрудники», или «Таблица сотрудников» имеет свой EmployeeID, а также содержит ссылки на офисы и контракты, имеющие OfficeID и ContactID?

Answer 1

Если данные в таблице Office и Contact просто улучшают информацию о Employee, я бы использовал EmployeeID в качестве первичного и внешнего ключа для Employee. Это моделирует отношение 1 к 0..1.

Сотрудник: EmployeeID в качестве первичного ключа

Офис и контакты: EmployeeID в качестве первичного и внешнего ключа для Employee

Answer 2

Чтобы быть в разумной нормальной форме, ваши сотрудники должны обратиться в офис.

При условии, что отношения контактов - это когда у сотрудников есть набор контактов, и ни один другой сотрудник не разделяет эти контакты, правильные отношения должны быть контактами, относящимися к сотруднику.

Сотрудник: empid, officeid

Офис: officeid

Контакты: empid, контакт

Answer 3

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