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

Question

Я разрабатываю пользовательское BI-приложение, используя SSAS с операциями обратной записи. По сути, пользователи хотят анализировать текущее состояние своих торговых представителей и территорий, настраивать границы территорий и назначения в сценарии "что если", а затем фиксировать изменения, если им нравится, как выглядит этот сценарий. У каждого пользователя может быть несколько различных сценариев, чтобы показать его / ее босса, и когда сценарий утвержден, он становится новым текущим состоянием сбытовой организации. Я буду активно использовать некоторую комбинацию ROLAP и HOLAP для достижения этой цели.

Мой босс и я не согласны с тем, как реализовать функцию сценария. Он имеет сводную информацию о том, как работает SSAS, и использует свой многолетний опыт создания приложений баз данных, пока я несколько недель экспериментировал с SSAS и читал библию Кимбалла, но я все еще относительно новичок в многомерном моделировании. Мне просто нужен кто-то, кто знает, что они делают, чтобы одобрить, отклонить или изменить мою идею, которая заключается в следующем.

У меня есть несколько таблиц SCD типа 2, которые выглядят примерно так:

Create Table SlowlyChangingDimension
(
    SurrogateId Int Identity(1,1) Not Null,
    NaturalId NVarChar(50) Not Null,
    BeginDate DateTime Not Null,
    EndDate DateTime Not Null,
    IsCurrent Bit Not Null,
    IsCommitted Bit Not Null,
    -- Data columns
    Constraint PK_SlowlyChangingDimension Primary Key Clustered (SurrogateId),
    Constraint Ck_SlowlyChangingDimension_DateRange Check (EndDate > BeginDate)
)

Я сохраняю исторические данные с помощью соответствующего использования столбцов BeginDate, EndDate и IsCurrent. Когда поступают новые данные, я заканчиваю текущую версию объекта и создаю новую текущую версию.

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

Теперь, когда сценарий создан и его начальное состояние идентично зафиксированному состоянию, пользователь может начать вносить изменения. Изменения будут сохранены в таблице SCD как дополнительные текущие строки, где IsCommitted = False. После внесения изменений таблица моста сценария будет обновлена ​​таким образом, что она удалит ссылку на зафиксированную версию объекта и теперь будет связана с новой альтернативной версией объекта. Когда сценарий фиксируется, старая подтвержденная версия заканчивается, альтернативная текущая версия фиксируется, и сценарий и все его ссылки на строки в таблице SCD удаляются.

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

Answer 1

Хотя теоретически возможно программно восстановить схему куба служб Analysis Services во время выполнения, вам все равно придется ждать обработки, что может быть очень быстрым для небольших наборов данных или очень длинным для большого количества данных. На практике, однако, службы Analysis Services должны иметь относительно статическую схему. Вы можете обрабатывать дополнительные сценарии, добавляя данные и повторно обрабатывая куб - даже через постепенные обновления, чтобы сделать его быстрым. Приложения для составления бюджета и прогнозирования обычно используют этот более поздний подход - добавление новых сценариев путем изменения данных, а не изменений схемы.