Тип 2: медленно изменяющиеся размеры и запрос исторических данных в определенный момент времени - PullRequest
Новая
       88

Тип 2: медленно изменяющиеся размеры и запрос исторических данных в определенный момент времени

1 голос
/ 10 апреля 2020

У меня есть маленькая звездная схема, представляющая записи времени для проблем в Jira. У меня есть таблица измерений типа 2 IssueAttributes, а затем таблица фактов TimeEntry.

Упрощенное представление таблицы измерений: 

+----------+---------+-------------+-----------+-----------+------------+----------+
| IssueKey | IssueID | IssueNumber | IssueName | IsCurrent | ValidFrom  | ValidTo  |
+----------+---------+-------------+-----------+-----------+------------+----------+
| 1        | 123456  | PR-1000     | Original  |  0        | 2000-01-01 |2020-04-09|
+----------+---------+-------------+-----------+-----------+------------+----------+
| 2        | 123456  | PR-1000     | Changed   |  1        | 2020-04-10 |9999-1231 |
+----------+---------+-------------+-----------+-----------+------------+----------+

Упрощенное представление таблицы фактов: 

+--------------+---------+-----------+
| TimeEntryKey | IssueKey| TimeEntry |
+--------------+---------+-----------+
| 11111        | 1       | 1.25      |
+--------------+---------+-----------+
| 11112        | 2       | 1.5       |
+--------------+---------+-----------+

При вставке в таблицу фактов я использую каким бы ни был текущий IssueKey из таблицы измерений, что кажется правильным подходом. Но если я хочу получить СУММ записей времени и сгруппировать их по IssueName, это приведет к 2 строкам, так как имя изменилось между первой и второй строками. У меня сложилось впечатление, что лучше всего сохранять простые объединения и использовать ключи, но в этом случае кажется, что вам нужно сначала присоединиться к измерению на IssueKey, а затем снова присоединить это к измерению на IssueNumber и IsCurrent = 1, чтобы получить атрибуты для текущей версии данных. У меня нет проблем с этим, но я также понимаю, что объединения должны быть простыми в DW, чтобы конечному пользователю не приходилось задумываться о том, как эти объединения работают, и это, кажется, противоречит этому пониманию. Я правильно об этом думаю? Вы не должны go возвращаться и обновлять ФК в таблице фактов, верно? Нужно ли мне согласованное измерение или что-то еще, чтобы поддерживать определенные атрибуты во времени?

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

1 Ответ

1 голос
/ 14 апреля 2020

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

  • текущий флаг строки
  • дата начала (или «время начала даты», если вы хотите иметь более одного обновления в течение дня)
  • дата окончания (или «время окончания даты», если в течение дня требуется более одного обновления)

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

Это может решить вашу проблему.

...