MihichА можно по подробнее с вытаскиванием данных?

Можно. Берете группу мер, одну, смотрите, с какими измерениями помимо измерения даты она связана, выписываете названия ключевых атрибутов. И пишете SQL запрос поверх openquery, внутри которого MDX запрос, вытягивающий с фильтром WHERE для одной даты (в цикле перебираете от минимальной даты из фактов до максимальной), со всеми физическими мерами и со всеми ключевыми атрибутами используемых измерений. Если помимо простых мер (агрегация SUM есть много last non emty/first child) - перебираете их отдельно, чтобы нули не записывать на каждую из дат внутри, например, приход есть в штуках на 1,2,3 января, ценник на 2, выдергиваете раздельно в 2 таблицы, затем подумаете, как соединить обратно в одну таблицу для новой группы мер, в которой есть новое измерение (которого раньше не было в кубе).

Ну и так одну группу мер за другой, каждую в плоскую таблицу SQL, затем подсоединяете столбец с ключом нового измерения - и обратно, в новый куб с таким же названием группы мер и такими же названиями мер. Чтобы упростить процесс.

Вопросы?

MihichУх. СПАСИБО БОЛЬШОЕ. Начинаю осваивать. Суть с простыми мерами понял. Дальше буду спрашивать по мере вытягивания данных
Почему полезно вытягивать в 2 разные таблицы меры из одной и той же группы мер, если агрегация разная.

Поясню. Допустим, у Вас есть строки с продажами и тут же последними ценниками себестоимости. 1 января 10 штук, розничная цена 10 шекелей, оборот 100 шекелей, на тот момент мера last-non-empty для ценника себестоимости была 7 шекелей, маржа на операции 10x(10-7)=30 шекелей, 2 января назначена новая цена себестоимости в 8 шекелей вместо 7, продаж не было, строка дает 0 штук и 0 розницы и 7 шекелей цены, 3 января ничего нет, 4 января снова 10 штук, снова розничная 10, оборот 100 шекелей, цена себестоимости не поменялась, поэтому 8 шекелей в отдельной мере.

И вот Вы начинаете выгрузку из OLAP куба в плоскую таблицу. Чтобы выгрузить - Вы берете non empty ограничение по мере в штуках и получаете строки от 1 и 3 января. Но не увидите строку от 2 января, когда поменялся ценник.

Затем у Вас появится новое измерение "дата изменения цены поставщика". Понятно, что для строки 3 января нужно привязать новое измерение ко 2 января, а для строки 1 января новое измерение к декабрю прошлого года. Но у Вас этой информации для такого расчета не будет.
А вот если есть отдельная таблица фактов продаж и отдельная таблица истории цен себестоимости - тогда да, таки можно будет правильно новое измерение привязать.

Понимаете, в чем цимес? Поэтому нужно сесть вместе с бизнесом и подумать, стоит ли игра свеч, какая информация может быть потеряна при таком или другом алгоритме выгрузки обратно из OLAP в SQL.

Andy_OLAP,

То есть для строки 4 января найти привязку к дате изменения 2 января, строк в 3 января никаких нет, опечатался.