В хранилище данных у нас есть концепция медленно меняющихся измерений. Мне просто интересно, почему нет жаргона для «медленно/быстро меняющихся ФАКТ», потому что одни и те же меры типа 1, тип 2 могут использоваться для отслеживания изменений в таблице ФАКТ.Существует ли концепция медленного изменения ФАКТ в хранилище данных
По богам DW есть 3 тип FACT таблиц
Из них мы имеем по крайней мере 2 вариант, которые приведут к чему-то очень похожему на медленно меняющейся действительность таблицы. Все зависит от того, как настроена ваша исходная система.
Вариант 1: транзакционный на основе исходного кода системы
Если исходная система отслеживает изменения измерений через ряд сделок (т.е., начальное значение + изменение стоимости + изменение значения и т.д.), то каждая из этих операций концами в транзакционном факте. Затем это используется в таблице периодических фактов, чтобы отразить меры «как периода».
Например, если ваша исходная система отслеживает деньги в учетной записи и выходит из нее, у вас, вероятно, будет таблица фактов транзакции, которая в значительной степени отражает исходную таблицу денег в/из таблицы. У вас также будет периодическая таблица фактов, которая будет обновляться каждый период (в этом случае месяц), чтобы отразить общую стоимость счета за этот период.
Периодическая таблица фактов - это ваша таблица замедленного изменения.
Source DW_Tansaction_Fact DW_Periodic_Fact
--------------- -> ------------------- -> --------------------
Acnt1 Jan +10$ Acnt1 Jan +10$ Acnt1 Jan 10$
Acnt1 Feb -1 $ Acnt1 Feb -1 $ Acnt1 Feb 9$
Acnt1 Apr +2 $ Acnt1 Apr +2 $ Acnt1 Mar 9$
Acnt1 Apr 11$
Вариант 2: CRUD/перезапись Источник Система
Его, скорее всего у вас есть система источника, которая позволяет пользователям напрямую обновить/заменить бизнес-измерений. В любой момент времени, согласно исходной системе, для каждого измерения было и остается только одно значение. Вы можете совершить эту транзакцию с помощью какой-то хитроумной хитрости в своем процессе ETL, но только когда-либо вы получите окно транзакции, ограниченное вашим графиком ETL.
В этом случае вы можете пойти либо с периодической таблицей фактов, либо с таблицей Аккумуляции фактов.
Давайте рассмотрим пример нашей учетной записи, но вместо транзакций таблица просто хранит значение суммы против каждой учетной записи. Это обновляется по мере необходимости в исходной системе, так что для Acnt1 в январе это было 10 $, 9 февраля и 11 апреля. $
Придерживаясь таблиц фактов транзакции и периода, мы получим эти данные (как на конец апреля). Опять же, периодическая таблица фактов - это ваша таблица замещающих фактов.
DW_Tansaction_Fact DW_Periodic_Fact
------------------- -> --------------------
Acnt1 11$ Acnt1-Jan-10$
Acnt1-Feb-09$
Acnt1-Mar-09$
Acnt1-Apr-11$
Но мы также можем использовать таблицу Accumulating Fact, которая может содержать все месячные значения за данный год.
DW_Accumlative_Fact_CrossTab Year Acnt Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2001 Acnt1 10 9 9 11 - - - - - - - -
Или более 3тип иш версия
DW_Accumlative_Fact_CrossTab Acnt Year YearStartVal CurrentVal Acnt1 2001 10 9
Kindof отношение
В моем опыте такого рода возникает вопрос, когда этот общий сценарий бизнеса:
Обратите внимание, что вы имеете дело с четырьмя наборами времени (начальный период отчета, измерение на дату начального периода, текущий отчетный период, измерение в текущий период), который будет достаточно сложным, чтобы вы могли объяснить, не говоря уже о ваших конечных пользователей понять.
Постарайтесь отступить, объясните конечным пользователям, какие бизнес-меры меняются со временем, прислушиваются к тем, какие результаты они хотят, и соответствующим образом формируют ваши факты. Обратите внимание, что вы можете получить несколько таблиц фактов для одной и той же меры, это нормально и хорошо.
Ссылка:
Я не думаю, что эта концепция будет иметь смысл. Факт всегда меняется, являются результатом некоторых измерений, какого-то результата. Мы автоматически отслеживаем изменение фактов. Не так в измерениях, то есть (грубо говоря) ярлык, который идентифицирует факты. Поэтому изменение смысла метки может быть проблемой, поэтому нам может понадобиться отслеживать эти «изменяющиеся измерения». – momobo
@momobo Что относительно поправок? Скажите обновленные количества заказов и аналогичные – Ronnis
Исправление может быть обработано, обновив факт, когда это простая коррекция ошибки (может быть высокой производительности). Или добавление корректирующего фактора. Сохранять истории коррекции также возможно (я вижу вашу точку зрения сейчас), но я этого никогда не делал. Я думаю, что еще один момент времени со временем исправления должен быть способом. – momobo