Организация хренния мастер-данных в хранилище
От: sVenom Россия  
Дата: 01.10.10 08:07
Оценка:
Коллеги, столкнулся со следующей проблемой.

Создаю хранилище данных. В качестве ключа почти везде будет выступать сотрудник (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).

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

Спасибо.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.