Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Unary operators- можно заставить данные аггрегироваться?
|
|||
|---|---|---|---|
|
#18+
Добрый день! Можно ли как-нибудь заставить MS AS аггрегировать данные при процессинге куба для измерения с unary operators (или custom rollup formula)? Иначе при большом количестве членов на нижнем уровне с unary operators, для самого верхнего уровня при запросе юзера расчет ведется в realtime, что есть очень долго... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2004, 13:57 |
|
||
|
Unary operators- можно заставить данные аггрегироваться?
|
|||
|---|---|---|---|
|
#18+
В версии Analysis Services 2000 невозможно преаггригировать результаты unary operators. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2004, 10:06 |
|
||
|
Unary operators- можно заставить данные аггрегироваться?
|
|||
|---|---|---|---|
|
#18+
А Mosha-то ненастоящий ! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2004, 10:10 |
|
||
|
Unary operators- можно заставить данные аггрегироваться?
|
|||
|---|---|---|---|
|
#18+
Тогда получается, что при наличии хотя бы пары больших измерений с custom rollup formula теряется одно из основных преимуществ OLAP - быстрота времени отклика. Ведь зачастую именно такие dimensions и используются. Можно, конечно, вместо этого написать Calculated Members на MDX, которые будут считаться как надо от предаггрегированных данных и работать это будет быстрее, но как-то это нерационально, имхо... А как с аналогичным аспектом обстоят дела у других производителей OLAP серверов? И не обещает ли Microsoft в новой версии AS улучшений в этом плане? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.03.2004, 15:55 |
|
||
|
Unary operators- можно заставить данные аггрегироваться?
|
|||
|---|---|---|---|
|
#18+
To ArtemL: А как с аналогичным аспектом обстоят дела у других производителей OLAP серверов? Не могли бы Вы привести пример задачи, в которой фигурируют унарные операторы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.03.2004, 17:25 |
|
||
|
Unary operators- можно заставить данные аггрегироваться?
|
|||
|---|---|---|---|
|
#18+
Я наверное не очень точно выразился в своем первом ответе. Я имел в виду что <b>результаты</b> вычислений unary operators невозможно преаггрерировать в Analysis Services 2000, но вычисляться они будут из преагррегированных данных используя оптимальные аггрегации. Кроме того, в глубоких dimensions, как правило начинаю с определенного уровня все unary operators это просто "+". Query Processor в Analysis Services умеет оптимизировать этот случай и сводит его к такому же query plan как если бы unary operators не было вообще. Вы правы, что если есть много unary operators или custom rollups по нескольким dimensions, то производительность не будет такой же как в случае когда их нет. Но производительность будет наверняка лучше чем если промоделировать те же вычисления с помощью calculated members. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.03.2004, 18:54 |
|
||
|
Unary operators- можно заставить данные аггрегироваться?
|
|||
|---|---|---|---|
|
#18+
Задача такая: Есть измерение География с 3 уровнями: - По всем отделениям -- Регион --- Отделение Регионы присылают сначала отчеты в целом по всему своему региону, а затем детальные отчеты по отделениям. В последствии для анализа требуется и то, и другое для сравнения в одном кубе. Сначала я включил сводные отчеты по регионам в уровень Отделение (родитель - соответствующий регион), и, чтобы не было двойной аггрегации, у сводных отчетов поставил unary operator ~, у остальных соответственно +. Начались тормоза для самого верхнего уровня из-за выполнения аггрегации в query time (более 2 минут, без unary практически мгновенно). С Custom Rollup Formula для уровня Регион лишь немного получше. Пришлось поднять сводные отчеты на уровень Регион и включить unary operators на нем. В этом случае предаггрегируются все уровни, кроме верхнего, что приемлимо по скорости выполнения запроса. Так что конретную проблему, вобщем-то, решил, но остался интерес в принципе как решать задачи, когда необходима нестандартная аггрегация нижних уровней больших измерений, если даже на таком относительно небольшом измерении замедление очень заметно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2004, 08:23 |
|
||
|
Unary operators- можно заставить данные аггрегироваться?
|
|||
|---|---|---|---|
|
#18+
PS: Забыл добавить, клиент - Excel 2002 sp2. В нем время выполнения запроса ощутимо больше, чем при обновлении того же среза данных в Analysis Manager ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2004, 08:31 |
|
||
|
Unary operators- можно заставить данные аггрегироваться?
|
|||
|---|---|---|---|
|
#18+
Артем В начале встречный вопрос: А разве можно определить unary operators на измерении которое не parent-child ? Я этого не знал... А вообще я бы решал эту задачу немножко по другому. Каждый раз когда данные могут вводиться на разных granularities (не знаю как это сказать по русски), то обычно надо применять virtual cubes которые построены из кубов с disabled levels. Типичный пример такой задачи - это бюджет против реальных данных (Budget vs. Actual). Бюджет как правило определяется на более бысокой granularity чем реальные данные, т.е. бюджет идет по месяцам, а реальные данные по дням и т.д. Тоже самое происходит и Вашем примере. Я бы сделал 2 куба, у одного из них уровень Отделение был бы disabled. В этот куб надо собирать данные по регионам, а во второй куб данные по отделениям. После чего оба куба обьединяются в виртуальный куб, в котором станет два measures - их можно сравнивать с друг другом и т.д. Производительность и маштабируемость такого решения должна быть очень хорошая. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2004, 10:42 |
|
||
|
Unary operators- можно заставить данные аггрегироваться?
|
|||
|---|---|---|---|
|
#18+
To ArtemL: Я согласен с г-ном Mosha. Я действительно много раз решал задачу объединения в одном кубе агрегированных и детальных данных. Например, некоторые мои клиенты - крупные производственные компании, торгующие по всей России, объединяли в кубах план с детализацией до федерального округа/области, группы товара и месяца, а факт брали из учетной системы с делализацией до дистрибьютора (их клиент), товара и даты отгрузки. Мне правда не надо было делать виртуальные кубы, поскольку OLAP-сервер, который использовался в этих проектах (Cognos PowerPlay) поддерживает в аналитической модели несколько таблиц фактов. Этот алгоритм наверняка можете использовать и Вы. Если интересуют подробности проектирования аналитических моделей - пишите мне на адрес cognos@narod.ru . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2004, 13:25 |
|
||
|
Unary operators- можно заставить данные аггрегироваться?
|
|||
|---|---|---|---|
|
#18+
В Cognos PowerPlay для сравнения величин с разными уровнями агрегации используется специальный механизм аллокации. Например, у вас есть данные продаж по регионам и данные продаж по отделениям. Оба источника данных подключаются в одну модель. Создается два показателя - ПродажиПоРегионам и ПродажиПоОтделениям. Устанавливается связь между уровнями измерений и полями источников. Затем можно указать, как должен вести себя показатель ПродажиПоРегионам, если пользователь анализирует его на уровне Отделений. Есть три варианта - 1. На уровне отделений выводить нули 2. На уровне отделений выводить сумму по региону 3. распределить сумму региона по отделениям пропорционально другому показателю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2004, 13:56 |
|
||
|
Unary operators- можно заставить данные аггрегироваться?
|
|||
|---|---|---|---|
|
#18+
Unary operators получилось определить на измерении типа star schema без проблем - просто добавил соответствующую колонку в низлежащую таблицу. А об ограничении только на parent-child я не слышал... Другой типичный пример применения unary operators - Активы и Пассивы в балансовой структуре. Подход с виртуальными кубами, несомненно, очень удобен. Я уже использую его как раз для сведения в виртуальный куб плана и факта, т.к. как раз такая задача и стоит. Если разбить существующие кубы еще и по степени детализации, то в основе виртуального получится 4 куба вместо 2. Есть 5 мер, которые надо смотреть одновременно (рубли, доллар, евро, итого по валюте и итого) в разрезе статей или времени. 5 умножаем на 2 (план/факт), еще на 2 (детализация) + еще для каждой пары мер план/факт вычисляется выполнение и получаем очень большое количество мер в каждой ячейке. Поэтому решил по степени детализации куб не делить, чтобы дополнительно не усложнять структуру конечного куба. Таким образом, тут задача получается немного посложнее, т.к. есть аггрегированные и детальные данные и по плану, и по факту. Хотя принцип, вобщем-то, не меняется. Спасибо всем за информацию! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2004, 15:22 |
|
||
|
Unary operators- можно заставить данные аггрегироваться?
|
|||
|---|---|---|---|
|
#18+
Предлагаю подробнее обсудить вопрос с разной гранулярностью. У меня задача стоит, насколько я понимаю, довольно общая, и поскольку вроде на форуме я не нашел рассуждений на эту тему - значит, все (кто пользуется MS AS) как-то это дело решают. Хотелось бы обменяться опытом - кто как. :-) Есть измерение Договор. У него есть на уровне "договор" есть значения обязательств (план) в мерах, и на этот же уровень поднимается агрегацией исполнение обязательств, по "документам" (накладные,платежки). Вопрос - как объединить это в один куб, чтоб и план был, и факт на уровне договора. У меня изначально был отдельный куб по плану и отдельные - по факту. Собиралось и один виртуальный; при этом элементарно в плановом кубе неправильные данные были (план договора умножался на число документов). Потом возникла мысль разделить измерения - сделать одно Договор, одно - фактическое с документами. Снова появился разного рода трудности. Последняя мысль - сделать одно измерение, со всем набором мер. При появлении договора бросать туда member "Обязательства" с планом и пустым - фактом. У документов соответственно там же будет факт, а план- пустым. Так вроде все должно сравниваться в пределах одного куба. Есть какие-нибудь мысли на этот счет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2004, 16:15 |
|
||
|
|

start [/forum/topic.php?fid=49&msg=32429001&tid=1872786]: |
0ms |
get settings: |
6ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
234ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
35ms |
get tp. blocked users: |
1ms |
| others: | 234ms |
| total: | 532ms |

| 0 / 0 |
