Проектирование базы данных PK-FK для записей о дате вступления в силу в будущем?

Question

В конечном итоге я собираюсь преобразовать это в дизайн Hibernate / JPA.Но я хотел начать с точки зрения базы данных.У нас есть различные таблицы, содержащие данные, которые датируются будущим.Возьмите таблицу сотрудников со следующим псевдоопределением:

сотрудник

• id INT AUTO_INCREMENT
• ... поля данных ...
• действует с ДАТЫ
• действует до ДАТЫ

Сотрудник_обзоры

• id INT AUTO_INCREMENT
• employee_id INT FK employee.id

Очень упрощенно.Но допустим, что у сотрудника А есть id = 1 ,ffectiveFrom = 01.01.2011 ,ffectiveTo = 01.01.2099.Этот сотрудник будет менять работу в будущем, что теоретически создаст новую строку, id = 2 сffectiveFrom = 01.07.2011 ,ffectiveTo = 1/1/2099 и id = 1ffectiveTo обновлено до 6 /30/2011.Но теперь моя программа должна будет проходить каждую таблицу, которая имеет отношение FK к сотруднику каждую ночь, и обновлять эти FK, чтобы ссылаться на недавно вступившую в силу запись сотрудника.

Я видел различные публикации как в чистом SQLи на форумах Hibernate у меня должна быть отдельная таблица employee_versions, в которой я буду хранить все данные с эффективными датами, что приведет к обновленному псевдо-определению ниже:

employee

• id INT AUTO_INCREMENT

employee_versions

• id INT AUTO_INCREMENT
• employee_id INT FK employee.id
• ... поля данных ...
• действует от ДАТЫ
• действует до ДАТЫ

employee_reviews

• id INT AUTO_INCREMENT
• employee_id INT FK сотрудника.id

Затем, чтобы получить какие-либо фактические данные, нужно будет фактически выбрать из employee_versions с правильным employee_id и диапазоном дат.Кажется довольно неестественным иметь эту вторичную таблицу «версий» для каждой версионируемой сущности.

У кого-нибудь есть какие-либо мнения, предложения из вашей предыдущей работы и т. Д.?Как я уже сказал, я беру это чисто с точки зрения общего проектирования SQL, прежде чем наложить на Hibernate сверху.Спасибо!

Answer 1

Этот сотрудник будет менять работу в будущем, что теоретически создаст новую строку (сотрудник)

Почему? Какой в ​​этом смысл? Ваша employee сущность больше не представляет работника, теперь она представляет некоторую абстрактную концепцию «человек на должности».

Я полагаю, что было бы более разумно выделить сущность, которая меняется, когда сотрудник «меняет работу» - должность, - в отдельную таблицу, чтобы вы не столкнулись с какой-то грязной концепцией, когда один физический человек фактически является несколько employee строк.

Я не понимаю, почему вы думаете, что это кажется «неестественным» - выбирать из дополнительной таблицы - вы бы отделяли что-то, что имеет множественность (положение человека), от чего-то, что является единичным (работник).

Answer 2

Вам необходимо решить, разрабатываете ли вы базу данных для поддержки операций или хранилище данных для поддержки отчетов.Если это второй, ваш дизайн в начале очень похож на медленно изменяющееся измерение типа 2 Кимбала.Традиционно вы хотели бы, чтобы ваша оперативная база данных представляла самую последнюю версию вашего сотрудника и предоставляла для нее некоторый бизнес-ключ (employee #, SSN и т. Д.).Затем данные можно загрузить в хранилище данных, где каждая отдельная запись в измерении EMPLOYEE будет иметь суррогатный ключ и даты вступления в силу / окончания.Факты, например обзоры, будут связаны с записями в измерении EMPLOYEE на основе бизнес-ключа и даты / времени.Например, вы сможете отличить отзывы о сотруднике А, когда он занимал должность младшего техника, от его отзывов, когда он переходил на должность старшего инженера.

Answer 3

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

Answer 4

Существует сущность, которая соответствует уникальному человеку:

     EMPLOYEE
     eeid PK
     firstname
     surname
     dateofbirth
     dateofhire
     dateoftermination
     etc

, и существует сущность, которая соответствует должности (занимаемым) сотрудником:

     EMPLOYEEPOSITION
     id pk
     eeid FK references EMPLOYEE(eeid)
     title
     reportsto FK references EMPLOYEE(eeid)
     startdate not null usually
     enddate allows null

Вопрос о том, как обеспечить возможность перекрытия позиций EMPLOYEE, обычно не решается путем создания нескольких записей EMPLOYEE.Вставки / обновления в EMPLOYEEPOSITION обычно проверяют столбцы startdate / enddate для каждой позиции EE и, в зависимости от того, какое правило действует (например, перекрытие разрешено / запрещено), либо фиксируют, либо откатывают операцию.позиции EE можно найти с помощью eeid.

Обычно вы не ставите дату прекращения действия в записи EE, если и пока это не необходимо.Если EE является работником по контракту, я бы создал экземпляр условия контракта как EMPLOYEEPOSITION.

Здесь можно провести аналогию для любой сущности, которая существует в отношениях «многие к одному», обратно к EMPLOYEE.

Answer 5

Если продолжить с ответом Мэтта Б , ваше обсуждение проблемной области проясняет, что ваш дизайн требует таблицы «позиции». Отзывы сотрудника по-прежнему актуальны для этого сотрудника даже после перехода на новую должность. Кроме того, в каждой корпорации, с которой я сталкивался, концепция пребывания сотрудника связана со всей его историей в компании, а не только с текущим положением.

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

Answer 6

Для такого рода вещей у нас обычно есть единственное логическое поле, называемое Active, которое позволяет упростить запросы к последней применимой записи.