Понимание медленно меняющегося размера, тип 2

Мне трудно понять, как использовать в моем сценарии медленно меняющееся измерение типа 2. Я просмотрел разные обучающие сайты, но они не подходят.

У меня есть таблица размеров сотрудников, содержащая:

+-----+---------------+------------+------------+
| id  | employee      | designation| Location   |
+-----+---------------+------------+------------+
| 1   | Ola           |   CEO      | Newyork    |
| 2   | Ahmed         | DEVELOPER  | California |
| 3   | Ola           | Manager    | California |
+----------+----------+------------+------------+

У меня есть таблица фактов по аккаунту

+-------+----------+
|emp_id | Amount   | 
+-------+-----------
| 1     | 2000000  |  
| 2     | 300000   | 
+----------+-------+

Теперь мы видим, что размер изменился, и, таким образом, был присвоен новый идентификатор тому же сотруднику Ola. Как бы мы справились с таблицей фактов?

  • Новый ID Олы не будет найден в Таблице фактов.

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

  • Как бы мы отметили, что этот сотрудник не является новым сотрудником, и на самом деле его местонахождение / должность были изменены.


data-warehouse dimensional-modeling fact star-schema scd
person Miru    schedule 21.10.2016    source источник
comment
Я нашел это чрезвычайно полезным: datawarehouse4u.info/SCD-Slowly-Changing-Dimensions.html Особенно та часть, где описывается модель данных для SCD 2. Это также отвечает на различие. В таблице фактов отсутствует дата, описывающая, что в мае Ола был в Нью-Йорке, но в июне он приехал в Калифорнию. Возможно, вам придется добавить таблицу снежинок, чтобы описать уникальных сотрудников.   -  person tobi6    schedule 21.10.2016

Ответы (1)


arrow_upward
4
arrow_downward

Я уверен, что есть много способов сделать это, вот один из них - иметь "employee_Key" в вашей таблице измерений, которая уникальна для сотрудника. Итак, ваша таблица размеров будет выглядеть так -

 id  | emp_key | employee   | designation| Location   |Valid From| Valid To |
-----|---------|------------|------------|------------|----------|----------|
 1   | EMP1    | Ola        |   CEO      | Newyork    |1/1/1900  |1/1/2016  |
 2   | EMP2    | Ahmed      | DEVELOPER  | California |1/1/1900  |NULL      |
 3   | EMP1    | Ola        | Manager    | California |1/2/2016  |NULL      |

Вы можете продолжить загрузку таблицы фактов с «Новым» идентификатором сотрудника. В этом случае у вас будет 2 разных набора ключей для этого сотрудника.

+-------+----------+
|emp_id | Amount   | 
| 1     | 2000000  |  
| 2     | 300000   | 
| 3     | 100000   |
+----------+-------+

Если вы хотите объединить (например, сумму сумм) для сотрудника с самого начала, вы должны объединить факт и измерение, используя ключ идентификатора, и сгруппировать по emp_key. Так,

select emp_key, sum(amount) from employee dim, account fact where dim.ID = fact.ID group by emp_key.

Если вы хотите узнать сумму с тех пор, как он стал менеджером, вам просто нужно сделать свертку в поле идентификатора.

select dim.ID, sum(amount) from employee dim, account fact where dim.ID = fact.ID group by dim.ID.

или так -

select fact.ID, sum(amount) from account fact group by fact.ID.
person Ashwin    schedule 22.10.2016
comment
Спасибо. Если я возьму ненужное измерение для таких изменяющихся атрибутов, не будет ли это намного лучше? Какой подход вы порекомендуете? - person Miru; 23.10.2016