Стол "вечеринка" не выглядит правильно.Сравните с исходным кодом из этого другого SO вопроса .
В такой структуре номер идентификатора партии распространяется, так сказать, вниз.Обычно это должен быть либо первичный ключ, либо внешний ключ в таблицах, в которых хранятся данные о человеке.
В вашей таблице «отчетность», похоже, что первичный ключ не должен быть «partyid».Это позволило бы только одну строку на сотрудника, что, я думаю, вы не предполагали.(Я могу ошибаться.) Если я прав, вы можете рассмотреть ограничение NOT NULL UNIQUE для {partyid, date} и ограничение PRIMARY KEY для нового столбца 'reportid'.Таблицы "путешествия" и "производительность", вероятно, будут ссылаться на "репортировать"(Но продолжайте читать.)
На вашей диаграмме есть места, где организация получает дополнительный ключ: например, ваша компания присваивает уникальный номер сотрудника.Нет теоретической причины, по которой вы не можете использовать «Employid» вместо «Partyid» с этой точки зрения, чтобы ссылаться на сотрудников.Но есть практическая причина, по которой вы, возможно, не захотите этого делать.Это увеличивает количество соединений.
Например, если в таблицах «учетные данные», «инструмент», «сертификация», «академический» и «соответствие» ссылаются на employee.employid вместо employee.partyid, вы не можете просто присоединиться к «соответствию»"и" вечеринка ", чтобы получить имя человека.Вам также необходимо присоединиться к "employee".
Для других таблиц, таких как таблицы выставления счетов, отчетов, учетных данных и т. Д., Должны быть свои собственные идентификаторы, которые являются первичными ключами, например, billingidreportid, credentialid и т. д.?
У них должен быть первичный ключ;первичный ключ не обязательно должен быть идентификационным номером.Если существует существующий естественный ключ, вы должны его идентифицировать и объявить его УНИКАЛЬНЫМ в любом случае.
Таблица "orders", вероятно, должна иметь только "orderid" в качестве своего первичного ключа;используйте ссылку на внешний ключ для идентификации клиента.В некоторых случаях имеет смысл переименовать столбцы.В случае клиентов может иметь смысл называть его ключ «customerid» вместо «parytid».Я сам создал бы домен.
create domain PARTY_ID as integer not null;
Затем, везде, где требовался идентификационный номер участника, вместо этого я использовал бы домен.
create table customers (
customerid PARTY_ID primary key references parties (partyid),
...
Я бы предпочелсм. таблицу менеджеров тоже.Ссылка на него гарантировала бы, что manager.managerid будет преобразован в фактического менеджера, а не только в любого сотрудника.