Размеры отдельной записи в хранилище данных SQL, кажется неподходящим, как еще я могу обеспечить эти потребности? - PullRequest
0 голосов
/ 06 марта 2019

Бизнес нуждается в некоторых измерениях с одним значением:

DIM_BuildDate - store datetime of the DW build, with latest inventory date
DIM_CurrentAccountingPeriod - what is the accounting period now (at build date)
DIM_CurrentExchangeRate - what is the currency exchange rate now

Возможно, все они могут объединиться в одно измерение с атрибутами для каждого значения, но это не мое дело.

Это кажется неправильным.Значения меняются ежедневно или периодически, делая их медленно меняющимися размерами, в лучшем случае.Тем не менее, есть некоторая подлинная полезность для хранения этих значений с помощью DW.

  • Если транзакционное задание не удалось, сборка DW может иметь данные инвентаризации, которые имеют двухдневную давность, и это важно.Поэтому я сохраняю его в DIM_BuildDate.
  • Часто календарная дата не совпадает с отчетным периодом, особенно в начале и в конце месяца.Поэтому я сохраняю это как DIM_CurrentAccountingPeriod.
  • Существует FACT_ExchangeRate, который хранит значения обменного курса с течением времени, но деловые люди хотят получить простой способ доступа к «Текущему обменному курсу».

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

Как еще можно представить эти требования в DW?

1 Ответ

1 голос
/ 10 марта 2019

Конечно, неправильно создавать измерение с отдельными записями для каждой метрики - ваша звездная схема будет раздуваться.

Дата сборки должна быть добавлена, ее никак нельзя обойти (это уникальная часть данных, которой у вас нет в вашей звездообразной схеме).

Текущий обменный курс может быть легко добавлен к вашей табличной модели в качестве вычисленной меры DAX (просто выберите курс, где дата = дата построения). Не нужно хранить его в отдельном измерении. В качестве меры было бы гораздо проще использовать в расчетах.

Фискальные даты можно смоделировать как отдельную (фискальную) календарную таблицу, или вы можете просто добавить фискальные даты в качестве атрибутов в вашу календарную таблицу (т. Е. «Фискальная дата», «Фискальный год» и т. Д.).

Аналогичным образом, вы можете пометить «текущий» период в таблице календаря (то есть добавить поле «Тип периода» со значениями «Текущий период», «Прошлый период» («Будущий период», если вам нужно)). Его можно использовать в качестве слайсера или фильтра DAX. То же самое относится и к «текущему» финансовому периоду - это просто еще один атрибут в календарной таблице.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...