Попутный вопрос.А другие средства OLAP это позволяют ?

В OLAP-сервере Cognos PowerPlay это делается через выбор опции Time-state Rollup (первый период, последний период, среднее за период и др.).

Вопрос к Виктору: действительно в MSTR есть понятие измерения Времени? Или оно ничем не отличается от других измерений?

2 Андрей Прохоров:

А что можно реализовать в измерении Время в Cognos, чего нельзя реализовать в любом другом?

Измерение времени имеет удобную опцию Time-State Rollup. Сделав пару кликов мышки можно получить суммирование по всем измерениям куба, кроме времени - по времени например можно корректно отображать полуаддитивные показатели (когда год равен декабрю, а декабрь - дате 31 декабря). Если измерения Времени в аналитической системе нет - то реализовать Time-State Rollup будет трудоемко. Также стоит отметить, что Cognos, получая на вход поле типа Дата, автоматически генерирует иерархию времени, это зачастую удобнее чем создавать отдельную таблицу с календарем.

2 Константин Лисянский:

ВРЕМЯ в Cognos PowerPlay может быть только одно. Что не очень удобно

В ОЛАП-кубе Cognos может быть сколько угодно измерений времени. Если используется Time-State Rollup - то тогда есть ограничение - может быть лишь одно реальное измерение времени, но при этом сколько угодно фиктивных измерений времени (на основе например текстовых полей, как в Вашем подходе с таблицей календаря).

Что касается поддержки именно времени, то, так же, как и с остальными измерениями, оно реализуется на уровне РСУБД соответствующими таблицами.

Никто не спорит, но для поддержки Time-State Rollup при работе с полуаддитивными показателями это будет неудобно.

2 Виктор Сакович:

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

Думаю этот постинг прояснил вопрос, зачем выделяют отдельно измерение времени (см. выше мой ответ Андрею Прохорову).

Времена ведь бывают разными. В задаче может быть множество времён: Время заказа, Время отгрузки, Время продажи, Время поставки и т.п. И для каждого может потребоваться иерархия с месяцами, кварталами и т.д.

Правильно, в тех ОЛАП-продуктах, где есть выделенное измерение времени - можно создать много измерений времени в одном кубе.

Если временная иерархия выстроена заранее, то что с ней можно сделать?

Надо заранее продумывать, как выстраивать иерархию времени. Я например часто делаю одновременно 2 измерения времени - Год-месяц-день и Год-неделя. Если заранее не определиться с иерархией - то это означает не использовать технологию многомерного OLAP. А без многомерного OLAP, если в OLAP-кубе не создавать заранее просчитанных агрегатов, не будет высокой производительности при анализе данных пользователем и при построении отчетов.

2 backfire:

Раз идет межконфесиональное обсуждение, то замечу, что в Юконе использование полуаддитивных мер не накладывает ограничений, о которых вы рассказали Константину относительно Когноса.

По правде говоря, первое мое впечатление от чтения функциональности Юкона - это то что она делалась с учетом функциональности OLAP-сервера Cognos PowerPlay... Что-то конечно должно быть в Юконе лучше, чем в PowerPlay. Хотя я слабо себе представляю, как Юкон разрулацию, когда в OLAP-отчете будет одно измерение времени в строках, а другое измерение времени - в столбцах, и по обоим будет задан Time-State Rollup - не будет ли конфликта, не упадет ли от этого сервер...

2 Константин Лисянский:

ОК. В Microstrategy тоже нет таких ограничений.

Приятно об этом слышать.

поскольку в Microstrategy все измерения равноправны, неаддитивность можно иметь на любом измерении, даже если это не измерение ВРЕМЯ.

То есть например мы смотрим отчет по географическому измерению, и значение показателя на уровне страны Россия у нас будет равно значению дочерней к России Ярославской области? А количество голосов поданное за всех кандидатов в президенты будет равно числу голосов, поданному за г-на Явлинского? :)
Я думаю что Cognos считает неактуальным использование Time-State Rollup для невременны'х измерений. А если например требуется подтасовать результаты выборов, чтобы например сумма голосов по кандидатам не была равна общему итогу - можно использовать External Rollup - эта функция Cognos позволяет заполнять нужные ячейки OLAP-куба PowerPlay произвольными значениями.

2 Mosha:

А еще в Юконе есть ByAccount aggregation function, которая позволяет разным членам измерения Account аггрегироваться по разному в зависимости от их типа (например Inventory как LastNonEmptyChild, а Income как Sum и т.д.).

В Cognos PowerPlay при проектировании OLAp-куба создаются иерархические показатели, и для каждого показателя можно задать индивидуальные правила агрегации (вместо измерения Account).

2 Виктор Сакович:

Это не очень интересно. Я имею в виду текстовые поля. Дело в том, что в жизни требуются не фиктивные, а настоящие измерения, которые можно использовать в анализе. Например, найти все заказы, время поставки по которым отличаются от времени размещения не больше, чем на 7 дней. Это задача нахождения просроченных заказов.

Тут важно не путать в разных подхода - OLAP и Query & Reporting. OLAP подразумевает создание агрегатов в OLAP-кубе. Для OLAP не свойственно выводить в качестве результатов отчета список заказов. Однако в OLAP часто делают измерение "Количество дней просрочки", устанавливая для него заранее фиксированные интервалы (от 1 до 7, от 7 до 14, и т.д.). Либо делают показатель Среднего времени просрочки, и в OLAP-отчете делают выборку контрагентов, имеющих средний уровень просрочки более N дней. И при всем этом не требуется, чтобы измерения времени были нормальными - даже текстовое измерение времени может служить базисом для расчета измерения Количества дней просрочки.
Если хочется вывести список документов, в которых количество дней просрочки определяется пользователем произвольно - это подход query & reporting, когда отчет делается не на основе многомерного, а на основе SQL-запроса, в онлайне, нагружая реляционный сервер. Для этой цели у Cognos есть либо ReportNet, либо Impromptu.

А потом как-то очень странно, что это свойство Cognos (Time-State Rollup) относится к измерению. На мой взгляд, это может относиться только к метрике. Например, тот же уровень складских запасов. А если у Вас в кубе ещё есть и аддитивные метрики, скажем продажи?

Вы правы, понятие Time-State Rollup указывается не для измерения, а для метрики (показателя). Но думаю те кто принимал участие в дискуссии и так все поняли.

2 Виктор Сакович:

Тут важно не путать в разных подхода - OLAP и Query & Reporting
Я понял. Но скучно это. Шаг вправо, шаг влево - и уже нужен другой продукт.

Не согласен. Я могу провести параллель с вопросом выбора оружия - иногда удобнее использовать пистолет, а иногда - винтовку с оптическим прицелом. В арсенале MSTR насколько я знаю есть только винтовка, а для оперативного OLAP-анализа, в ходе которого нужно ответить на множество взаимосвязанных вопросов, и для которого нужны заранее предрассчитанные агрегаты - средства нет :) У Cognos есть и то, и другое.

Вы правы, понятие Time-State Rollup указывается не для измерения, а для метрики (показателя). Но думаю те кто принимал участие в дискуссии и так все поняли
Я конечно знаю, как должно быть. Но Вы писали совсем другое. Смотрите цитату внизу
Измерение времени имеет удобную опцию Time-State Rollup

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

2 Константин Лисянский:

господа, перестаньте оппонировать Юрию
научитесь наконец фильтровать этот бред

Думаю за такие непарламентские выражения нужно перекрыть г-ну олаписту доступ в форум, по крайней мере пока он не станет Олапистом с большой буквы :)