Коллеги, столкнулся со следующей проблемой.
Создаю хранилище данных. В качестве ключа почти везде будет выступать сотрудник (employee), который генерирует определнную активность. У сотрудника есть следующие поля, которые могут идентифицировать его (причем в разных базах данных эти поля разные): имя, имя аккаунта, номер телефона, менеджер. Каждый из этих аттрибутов важен и нужно отслеживать его изменение.
Например, у человека был менеджер A, а в момент времени T изменился на B. Если мы захотим посмотреть историю работы относительно сотрудника, то кто является менеджером нас не волнует. Но если менеджер B будет смотреть исторические показатели своей команды, то до момента времени T рассматриваемый сотрудник не должен попасть в выборку, а после T должен. Ну и аналогично по все остальным параметрам (у человека может смениться номер телефона, но это все тот же человек; у человека может смениться фамилия ну и т.д.).
Я не могу сообразить каким образом мне спроектировать соответствующую таблицу. Пока что пришел к следующему варианту:
Identity (id PK) - это просто фиктивная таблица с одним, ключом по которому мы будем связывать исторические данные.
Employees (id PK; identity_id FK REF Identity.id; name; username; phone; manager_id FK REF Employees.id, start_date DATETIME; end_date DATETIME).
Теперь пример двух записей из таблицы Employees:

201 | 3 | Ivanova, Irina | SPBIVANOI | 1111111 | 51 | 27.01.2005 | 31.05.2006
... проходит много времени ...
943 | 3 | Petrova, Irina | MONPETROI | 2222222 | 42 | 01.10.2010 | NULL

То есть за 4 года у Ирины:
1) Поменялась фамилия с Ivanova на Petrova
2) Поменялся аккаунт c SPBIVANOI на MONPEROI (он не просто генерируется из фамилия + имя, правило другое)
3) Поменялся телефон с 1111111 на 2222222
4) Поменялся менеджер с 51 на 42
В общем поменялось все.
Однако Employees ранит всю историю этих изменений и при необходимсоти мы можем проследить историю изменений через identity_id (второй столбец, знаение = 3).

Подскажите пожалуйста имеет ли такая идея право на существование? Есть ли более правильные/оптимальные способы хранения высоковолатильной мастер даты в хранилище?

Спасибо.

Особенно интерисует ваше мнение по поводу таблицы Identity, в которой будет только одно поле - ключ, так как другой постоянной информации у сотрудника просто напросто нет.

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

Приходилось ли еще кому-нибудь решать подобные задачи?

Ответ на мой вопрос - SCD (slowly-changed dimensions). Тема закрыта.