Хочу поддержать backfire - необходим WB не только в специальную таблицу, но и напрямую в таблицу фактов

backfireГоспода, никто не собирается ломать OLTP или DWH. Только не надо держать нас за детей малых, которым спички не игрушка. Существует и без этого 1000+1 возможность наломать дров.


Я вижу проблемы WB еще и в необходимости некой бизнес-логики. Именно без такой логики можно "наломать дров". Отчасти проблема решается через введение разрешений на доступ к тем или иным ячейкам.
Но как эти разрешения обработает UPDATE CUBE при расчете весовых коэффицентов ???

Можно конечно эту бизнес-логику реализовать в клиентском приложении, однако уверен что если бы ее сервер поддерживал - было бы гораздо лучше


Владислав Беляев

Коллеги, давайте все-таки смотреть в корень проблемы. У backfire проблема потому что он не пользуется стандартным WB, а пытается его обойти через ROLAP. И я не пользуюсь стандартным WB по причинам
1 Медленно
2 Нет обработки бизнес правил
3 Проблемы при изменении структуры куба
4 Изменения вносятся во writebacktable а не в таблицу фактов

Теперь как я считаю должно быть

1 В Юконе, по крайней мере с weighted allocation все должно быть хорошо. equal allocation для больших объемов данных..., считаю практически нет таких задач
2 Должны отрабатываться все связи между dimensions, т.е. если в AS2K есть dimension и virtual dimension, то при update cube между ними не должно быть crossjoin, в идеале и значение virtual dimension вообще не должно во writeback table попадать. Кроме того есть и другие связи между dimensions (в AS2K5 их можно прописать) - они тоже должны в "UPDATE CUBE" обрабатываться.
В AS2K5 есть скрипты, надеюсь что их можно использовать для описания сложного Update. Еще проблема с UpdateCube - это Non leaf hidden data и custom rollup.

Я сейчас выкручиваюсь так: создаю set, где прописаны все возможные (разрешенные) взаимосвязи между dimensions, потом делаю Extract dimension из Intersect этого сета c уже выбранными members на других dimensions и получаю доступные для выбора members этого dimension. Значение с интерфейса передаю в sql stored procedure, где собственно и прописана логика update факт table.

Год назад backfire говорил, что при таком варианте update есть минус в том что не задействуется логика update cube. Так вот ее можно задействовать, правда с потерей производительности. Делается "Update Cube", затем NECJ из Descendants members of tuple members и эти значения ложаться в факт table

3 Надо чтобы WB table не изменялась (требуется ее пересоздание) при добавлении уровня в dimension или при добавлении virtual dimension. Вообще структура WB table в этом случае была бы гораздо ближе к таблице фактов (не содержались бы промежуточные уровни)

4 Опционально, надо чтобы изменения можно было вносить непосредственно в таблицу фактов без Writeback table

Без решения этих проблем приходится исхитряться, тогда и возникают проблемы наподобии описанной backfire

Заметьте, производительность UPDATE CUBE AS2K (см 2) во многом еще тормозится созданием совсем ненужных crossjoin, c virtual dimension например.

Владислав Беляев