Владимир,

Я все-таки как-нибудь найду время и приведу примеры более сложных несбалансированных иерархий, которые не помещаются в 3 поля.
Когда же иерархия лежит в 3 полях, мне действительно приходится делать алиасы (как и в более сложных случаях) - но это все легкие клики мышки, это не сложно.
Что касается 1С, где видимо чаще используются именно простые, трехпольные иерархии, то насколько я знаю, там стараются не иметь глубокие ветвистые иерархии, так как сама 1С с ними работает со скрипом.

Что касается нашего примера - интересно бы конечно было сравнить мой куб с твоим. У Cognos куб разрастается, когда много категорий/members (35 тысяч это не так мало, поэтому и куб получился 10 Mb).

Для чистоты эксперимента попробуй сделать куб на основе моего XLS-файла - 30 измерений без иерархии (1 колонка - 1 измерение). Далее открой куб, и сделай отчет, когда в боковике 1000 элементов, каждый из которых раскрывается в элементы другого измерения (итого 1 миллион строк), а в шапке - 1000 элементов. В итоге получим в отчете 1 миллиард ячеек (большинство из них будут пустыми. Интересно, за сколько секунд у тебя откроется такой отчет (у меня за 16 секунд :)

А кубы (MOLAP) с 30 измерениями по 300 тыс. листьев в каждом делать нужно на очень серьезных компьютерах, у меня под рукой таких нет...

To Birkhoff:

Насчет примера со схлопыванием пустых уровней- это интерсено.
А что происходит если в каком то месте происходит появление нового уровня?
Видима надо перестраивать измерение и куб?

Нет, это делать не обязательно. Если куб подкачивается инкрементально - то просто появится еще один member/категория. Например, клиент Иванов, живя в Питере, купил товаров на 100 руб, а потом он переехал в Москву и купил в Москве товаров на 70 руб. То есть один и тот же Иванов встретится в 2 местах (в 2 ветвях классификатора). С помощью работы с подмножествами (сложные фильтры) в OLAP-клиенте Cognos PowerPlay можно будет увидеть всю историю Иванова.
Если же куб перегенерируется полностью - то тогда мы увидим, что Иванов купил товаров на 170 руб. в Москве.
Хорошо это или плохо - зависит от ситуации, нужно не забывать и о принципах из теории хранилищ данных...

Владимир,

Я сейчас слепил из 1С базы пример, где скопировал Parent-Child Номенклатуру 30 раз. В справочнике 15 тыс. позиций. Отчет по продажам с "30 Номенклатурами" хорошо работает. Тест не чистый, но по порядку величины правильный. Хотя, сознаюсь, немного пошаманил с настройками MS AS.

Мне кажется что в этом случае не происходит реальной проверки работоспособности MS AS в многомерном пространстве, поскольку как я понимаю к Вашей таблице фактов, имеющей поле КодТовара все эти 30 копий одного и того же измерения привязываются одинаково. Попробуйте все-таки мой пример, когда в каждом из 30 измерений - независимые, разные члены (если по одному из них наложить фильтр - это сразу отражается на OLAP-отчете, а если они все были бы одинаковые - то потерялась бы многомерность).

To Birkhoff:

Что будет если у нас было 3 уровня вложенности: например, Город-Магазин-Товар, а потом кто-то решил добавить еще одну градацию типа Город-Магазин-Отдел-Товар.

По правде говоря, эта ситуация похожа не на несбалансированную иерархию, а на случай, когда иерархия сбалансирована и собирается на основе полей из разных таблиц измерений.
Однако, если Вы поместили ее в 3 поля, то тогда в Cognos нужно во-первых гарантировать, чтобы заранее имелись лишние алиасы (и тогда при схлопывании уровней иерархии схлопнется на один нулловый уровень меньше, а если алиасов недостаточно - нужно один добавить, иначе потеряется детальный уровень иерархии), а во-вторых нужно будет все же перегенерировать куб, иначе получится, что в прошлые месяцы магазины раскрываются в товары, а свежеподкачиваемые данные с другой классификацией будут сгруппированы по-другому - Магазин-Отдел-Товар).

Владимир,

Юрий, вы нас не разводите, чай мы не небо коптим. :)
Пример возьмем другой. Самый нижний уровень вашей иерархии скажем злобный пользователь Иванов решил разбить на 2 группы в одной из подветок. При этом утыкаемся в нехватку заготовленных уровней.

Пользователь Иванов - не злобный, а любознательный, даже через чур :) А такие люди редко работают в серьезных компаниях, у которых большие БД с глубокими иерархиями.
Глубокая иерархия - это не только измерение для куба, но и базис для планирования, учета и контроля в компании. Поэтому просто так иерархии никто не углубляет, а если и углубляет - то это процесс не быстрый.
Ну а если даже и встретится такой случай - углубление иерархии на 5 уровней, хотя зарезервировано всего 3 - то тогда в куб не закачаются самые детальные 2 уровня. Пользователи это заметят, позвонят админу аналитической системы, он быстренько добавит еще 2 алиаса, и перегенерирует куб.

Можно тогда уж встречный вопрос: что происходит, когда в учетной системе (например в 1С) происходит углубление несбалансированной иерархии? Когда эти изменения попадут в куб MS AS, и что для этого нужно сделать?

P.S.

Мне как-то сразу в голову не пришло, что у Cognos есть еще один интересный способ работать с несбалансированными иерархиями (а также и со сбалансированными иерархиями).
Например, аналитик заходит в модель куба, открывает дерево категорий (members, иерархия), видит что там целый ряд городов. Далее он создает мышкой новый уровень иерархии, создает новые категории (типа "крупные города" и "мелкие города"), и мышкой подтаскивает Москву и Питер в категорию крупных, а более мелкие города - в категорию мелких городов.
Далее он нажимает на кнопку перегенерации куба, и в кубе отразится изменение в иерархии. Тут уже никакие алиасы не нужны.

To Birkhoff:

Если взять например какую нибудь оргштаную структуру очень большого предприятия

Для крупных внедрений обычно проводятся обследования, и если имеется 15-уровневая иерархия, важная для отчетов и анализа, под нее сразу можно следать большой запас - например 25 колонок, 10 из которых пока будут незаполнены.

Но даже и в более простых случаях углубления иерархий происходят. Например маркетолог или аналитик рынка может легко собрать...

Методология внедрения ПО Cognos состоит в том чтобы обучать не только технических специалистов, но и опытных пользователей/аналитиков, благо продвинутые визуальные средства позволяют за 1-2 дня научить создавать кубы даже человека, имеющего минимальный опыт общения с компьютером. После обучения маркетолог сможет пользоваться как общими кубами, так и играться, создавая свои кубы.

To Birkhoff & Дядя Федор:

Это правильно. И чем хорош Express, так тем? что там можно написать один скрипт, который всегда отреагирует на появление новых групп. Т.к. измерения parent-child.
Если они реализованы как Папик-Чайлд - сами попадут. делать ничего не надо

А агрегаты в кубе при изменении иерархии в учетной системе пересчитываются автоматически в фоновом режиме? Или для parent-child агрегаты не создаются и все считается налету?
И еще интересный вопрос: в средних и крупных компаниях, имеющих мощные глубокие несбалансированные иерархии (десятки/сотни тысяч позиций номенклатуры или сотрудников) при создании кубов в Cognos PowerPlay партиции создаются именно на основе таких измерений (одна подгруппа товара - в одну партицию, две подподгруппы другой подгруппы - еще 2 партиции и т.п.). Оптимизация партиций позволяет поддерживать производительность на высоком уровне. А измерения parent-child в OE и MS AS могут служить основой для разбиения куба на партиции?

To olegK:

1. Можно ли агрегировать по одним иерархиям в кубе, а на отчетах отображать другие ?

В Cognos PowerPlay создатель куба не может указать, что эту иерархию - агрегировать, а другую - нет (OLAP-движок позволяет проводить агрегацию по всем измерениям и показателям). Можно управлять лишь процессом создания партиций (что тоже немаловажно для производительности, когда большие кубы крутятся на слабых железках). Подобный подход исключает проблемы с торможением при раскрытии ветвей иерархий до листьев в OLAP-клиенте. Как показал пример с 30 измерениями, пользователь куба Cognos может не задумываться (с технической, а не с содержательной точки зрения), какие иерархии он выводит в отчет.

2. Если не секрет, как вы укладывате балансы и ПУ (со всеми их далеко идущими расшифровкми) в сбалансированные иерархии ?
P.S. При условии, что иерархии могут менятся каждый месяц - пользователь справится ?

Я специализируюсь на создании кубов на основе первичных документов и управленческих отчетов (бух. отчеты я не делаю, перекладываю это на пользователей, если им это потребуется).
Управленческие BS, P&L и CF - это отчеты, структура которых меняется довольно редко. Поэтому с ними проблем нет. К тому же, зачастую статьи управленческого отчета - это одна колонка (боковик отчета) в Excel, без иерархии.
Повторюсь, что если зарезервировать достаточно много пустых полей для несбалансированной иерархии, то и пользователь, и разработчик куба не должны будут менять структуру куба при изменении глубины иерархии - нужно будет только перегенерировать куб.

To Birkhoff:

модели анализа и группировки меняются постоянно и некоторые аналитики меняли бы иерархии каждый день, если бы технологии позволяли.

Технология Cognos, в силу того что не требуется лезть в БД учетной системы, писать там вьюшки, и писать MDX-выражения, позволяет аналитикам разрабатывать кубы и изменять их сколь угодно часто.

Кстати, кто нибудь сталкивался с отслеживанием изменения иерархии и если сталкивался, то как это решалось?

Для этого в учетной системе или в ХД должна поддерживаться темпоральность. В MRP/ERP системах это есть. Если кто хочет поиграться с темпоральностью или посмотреть, как она может быть реализована - напишите запрос на адрес Cognos@narod.ru - и я предоставлю демо-версию небольшой производственной подсистемы с элементами MRP/ERP, которую я как-то спроектировал и сейчас внедряю для одного из клиентов.
А вот как это реализовать в кубе - это вопрос для обсуждения, есть несколько вариантов реализации. Самый сложный - чтобы при выборе произвольной даты внутри OLAP-клиента перестраивалась иерархия.

To Birkhoff:

И как отразится на производительности существование 25 уровней иерархии?

Если у нас в учетной системе хранится иерархия с 15 уровнями, никакой разницы нет, сделаем ли мы измерение с 15 уровнями, или с 25 (10 из которых будут пустыми) - схлопывание пустых уровней - это простая операция для Cognos.

Может быть вам везло с клиентами, но по моим наблюдениям таких маркетологов, которые могут подняться в своем сознании до степеней абстракции, позволяющих создавать свои кубы, где то 1 на каждые 10.

Думаю те участники форума, которые с моей помощью познакомились с Cognos, согласятся, что создать куб в PowerPlay не намного сложнее чем научиться в Excel пользоваться автофильтром. Cognos не заставляет разработчиков своих кубов мыслить многомерно (в отличие от того же OE и возможно от MS AS). Рекомендую Вам хотя бы скачать с моего сайта презентацию по Cognos PowerPlay - там 2 слайда посвящены проектированию куба - увидев их, Вы поймете, что там нет ничего сложного даже для неопытного пользователя.

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

Понятно. Видимо в этом и есть обратная сторона медали. То есть в простых случаях при не очень глубоких иерархиях, MS AS и OE более удобно позволяют с ними работать, чем Cognos, но на больших объемах кубы MS AS и OE при изменении иерархии будут менее стабильны и тяжело будет управлять процессом закачки иерархии в куб (как я упоминал, Cognos может для старых данных хранить старую версию иерархии, а для новых - новую, измененную).

Не знаю как в MS AS, а в Express нет понятия партиций. Оно есть в RDBMS ORACLE. В экспрессе можно осуществить партиционирование руками. То есть создать две базы, хранящиеся на разных дисках, а потом виртуально их объединить формулой.

Согласен, реляционная БД Oracle - это круто, но партиции РСУБД не помогут улучшить производительность MOLAP. Хотя скажем так, что вопрос партиций актуален только для больших кубов, от 10-20 миллионов записей в таблице фактов и выше.

А как быть с неаддитивными данными? Они все равно будут суммироваться?

А вот это более сложный вопрос. К сожалению мои знакомые программисты из компании Cognos не могут мне рассказать о подходах Cognos к агрегированию, это коммерческая тайна Cognos.
Как то я обсуждал с Владимиром Ивановым вопрос по поводу показателей Distinct Count - такие показатели в некоторых ситуациях могут притормаживать, их не всегда можно агрегировать. Что касается таких вопросов как остатки, сальдо, дебиторка/кредиторка и т.п. - то Cognos эффективно работает с оборотными агрегатами и тормозов не наблюдается как на вершине иерархии, так и при раскрытии до листьев.

Владимир,

parent-child - это один из важных аспектов, по которому интересно сравнивать OLAP-сервера, но он не единственный.
Разные OLAP-сервера работают с parent-child по-разному, и где-то выигрывает один подход (в простых случаях), а где-то - другой (в сложных случаях и/или при больших объемах данных).

В противном случае это была бы тяжелая ручная работа, как сейчас в Cognos

Иногда у моих клиентов вообще нет parent-child, иногда есть - но с небольшим кол-вом уровней (или когда уровней много, но таких иерархий всего 1-2). Более сложные случаи мне не встречались, но если встретятся - их можно решать либо так же, с помощью алиасов визуальными средствами (это я не считаю тяжелой работой), либо написать универсальную функцию для СУБД, в которую передавать такие параметры как прогнозируемое кол-во уровней иерархии с запасом, ID товара (или контрагента, филиала и т.п.) и номер колонки, и эта функция сделает мне нужное количество колонок, часть из которых будут пустыми, а часть - заполненными.

Еще стоит упомянуть, что некоторые мои клиенты не придерживаются моей методологии а используют свою, создавая в Cognos PowerPlay иерархические измерения не визуальными средствами, а с помощью программы на VB, использующей результаты рекурсивного запроса к реляционной БД их учетной системы.