Как моделировать динамические отношения в реляционной базе данных

Question

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

У меня есть две таблицы

Отделы = [DepID, Имя отдела, ...]

Сотрудники = [EmplID, Имя, Адрес, ...]

EmployeesAtDepartment = [EmplID, DepID]

Здесь таблица EmployeesAtDepartment должна создавать отношения между каждым сотрудником и отделом (отделами), в котором она работает (в основном только один, но может быть возможно принадлежать более чем одному отделу).

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

Теперь возникает мой вопрос: какие концепции доступны для моделирования этих «изменяющихся во времени отношений» в реляционной базе данных?

Мое первое предположение - добавить еще два столбца даты к EmployeesAtDepartment , например, [StartedAtDate, QuitAtDate], где последний равен NULL, если сотрудник в настоящее время работает в отделе. В этом случае в базе данных сохраняются только изменения.

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

Можете ли вы порекомендовать какие-либо ресурсы о плюсах и минусах вышеупомянутых подходов или есть еще лучшие способы?

Спасибо!

Answer 1

В комментарии phillipxy я нашел концепцию «медленно меняющегося измерения» https://en.wikipedia.org/wiki/Slowly_changing_dimension, который описывает несколько решений проблемы в реляционной модели.

Кроме того, существуют «временные базы данных» https://en.wikipedia.org/wiki/Temporal_database,, которые способны хранить историю всех изменений.

Answer 2

Стоит продумать различные варианты использования.

Ваша первая модель инстинктивно права - она ​​не дублирует данные. Это также упрощает ответы на такие вопросы, как «в какую дату человек X перешел из отдела y?», «Сколько человек изменили отдел между датами a и b», «сколько людей было в отделе x в дату y» "Какой самый длинный период, когда кто-либо оставался в отделе".

Он также позволяет вам прикреплять дополнительные детали к изменениям отдела - коды причин, комментарии и т. Д.

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

Ваш второй вариант имеет то преимущество, что вы можете забыть ни одного предложения where из одного из ваших запросов (который находился в отделе x на дату y). Я не думаю, что это стоит компромисса - особенно потому, что выяснить некоторые из вопросов выше становится довольно сложно