Чтение многих советов по проектированию Kimball относительно таблиц фактов (транзакции, накопление, периодические) и т. Д. Я все еще не уверен, что мне следует делать с моим случаем обновления таблицы фактов, что, как я считаю, не является чем-то необычным. К делу.
Мы обрабатываем жалобы от клиентов, и мы хотим иметь возможность отражать текущий статус жалобы в хранилище данных. Наши жалобы имеют рабочий статус статусов, через которые они проходят, разные сотрудники, которые имеют дело с ними вовремя, но для нашего анализа это не имеет значения на данный момент. Мы хотели бы рассмотреть текущую ситуацию с жалобой.
Насколько я понимаю, зерно таблицы фактов было бы единственной жалобой с колонками (не имеет значения для этого вопроса, должно ли это быть мусорным размером, вырожденным и т. Д.), Таких как:
- Номер жалобы
- Текущий статус
- Текущий статус Дата
- Текущий уполномоченный
- Тип жалобы
Насколько я понимаю, поскольку мы не хотим просматривать историю процесса, а вместо этого видим текущее состояние процесса, хранение нескольких строк для каждой жалобы, представляющей его состояние, является излишним, поэтому вместо этого мы сохраняем только одна строка на жалобу и обновить ее .
Теперь, мои рассуждения верны, чтобы сделать это? В приведенном выше случае номер жалобы и тип хранилища жалоб не изменяются, в то время как столбцы «Текущий» изменяются, и нам нужно обновить строку, чтобы мы могли реализовать механизм изменения сбора данных (как мы это делаем для измерений прямо сейчас) сравнить поступающие строки из исходной системы для этого факта с сохраненными в данный момент строками фактов, чтобы уменьшить временные затраты на такую операцию.
Честно говоря, для меня это выглядит как таблица измерений со смешанным типом 0 и 1 SCD, но в ней хранятся факты получения жалоб.
SO Опубликовать для справки: Таблица фактов с информацией, которая регулярно обновляется в исходной системе
Редактировать
Мне известно, что я мог бы использовать накопительную таблицу фактов с метками времени, которая в некотором роде похожа на SCD 2-го типа, но конечному пользователю на самом деле не важна история процесса. Позже в анализ будет включено больше фактов, поэтому отделение этой потребности от хранилища данных в данном случае не очень помогает.