Re: CalliGraph - альтернативный OLAP-генератор отчетов

Для CalliGraph'a все измерения равноценны, а потому работая с N измерениями можно построить любую из (N+1)! иерархий представления данных. Это теоретический предел и Calligraph его обеспечивает. М.б. кто-то знает другие продукты, которые обеспечивают этот предел и подобную гибкость?

> Re: kaumay
> Я не понял ответ. Дело не равноценности измерений и не в построении
> представления из N измерений. Вопрос в том, как я могу определить
> внутреннюю структуру измерений, насколько это удобно.

На мой взгляд, не просто удобно, но и максимально логично. Например, если речь идет о времени, то Вы просто указываете нужные даты или периоды в любых сочетаниях. (Мы называем эту внутреннюю разбивку граничными условиями анализа выбранного реквизита.) Если речь идет о бухг. проводках, то Вы перечисляете нужные для анализа счета, объединяя их под нужными Вам названиями "малоценка"(в нее входят счета NN...), "основные средства" (NN...), "ценные бумаги" (NN...). Если речь идет об обработке миграционных карт, то интересно посмотреть: прибыло, убыло, в т.ч. из городов, сельской местности, из-за границы и т.д. Если речь идет о диспансеризации больных, то Вы указываете интересующие Вас диагнозы, и т.д.

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

Нет, Вы не дочитали и не попробовали. После того, как Вами выбраны нужные градации (реквизиты, поля БД - назовите как Вам нравится) и определены для них граничные условия, работает автомат. (Кстати, в качестве градации м.б. и любая Ваша формула.) Вы можете получить один и тот же документ любым из (N+1)факториал существенных способов, где N - количество задействованных реквизитов. Вы только указываете мышкой "направление" - какой реквизит хочется видеть "вдоль", какой "поперек", а какой по "диагонали". Для автомата это все равно - размеры, форма, корректное взаимодействие подключенных функций - на то и железяка... Эргономика заложена в алгоритмы. А иерархии определяются тем порядком, в котором Вы их расположили в запросе.
Мой совет - когда повара наперебой хвалят свою стряпню, то лучше взять большую ложку и попробовать...

Уважаемые господа!
Когда же все-таки Вы перестанете обработку "кубов" называть OLAP-системами?
О какой же "On Line" обработке можно говорить, если создание т.н. "кубов" может занять часы, а то и сутки?
И второй вопрос: Когда же все-таки перестанут говорить (или скромно умалчивать) о равноценности измерений при "кубостроительстве"?
Если программист угадал какие измерения и с какой точность для "кубов" брать - хорошо, а если нет - делай новые "кубы". Смешно, когда делают вид, что кто-то может спрогнозировать вопросы действительно грамотного аналитика, который, порой, сам не знает куда его занесет в процессе анализа и от каких факторов ему придется "танцевать".
На мой взгляд, что бы ни говорили о критериях Е.Ф.Кодда - они классика для OLAP.
И оценивать продукты, декларируемые как OLAP, следует именно по этим критериям. (По крайней мере до тех пор, пока другие критерии не станут классическими.)
Все прочее - от лукавого. И еще от того, что сделать OLAP-систему работающую с OLTP-потоками очень трудно. Еще труднее сделать это за минимальное время, т.е. ЗА ОДИН ПРХОД ПО ИНФОРМАЦИИ (меньше-то не бывает!), а в идеале, с параллельной обработкой OLTP-потока. (При этом все расчеты уважаемого г-на MaD MaXX становятся просто забавной игрой в цифры.)
Надо говорить еще и о том, что следует сделать интерфейс, которому можно обучить End User'a за полчаса, и чтобы он просто указывал какой документ ему нужен, с какой разбивкой, с какими расчетами, какие измерения расположить "вдоль", какие "поперек", какие "по диагонали". А дальше уже забота программиста: научить работать автомат, которому без разницы размеры и сложность документа, вложенности, иерархии, корректное взаимодействие подключаемых функций (вне зависимости от сложности и размеров документа) и т.д.
(Конечно этот подход в корне отличается от того, что декларирует г-н Павел Ишенин: программист может все. Да, может! Но OLAP д.б. ориентирован на End User'a, а не на программиста! Не будет же он утверждать, что программист может создавать документы для аналитика в On Line!)
Как это ни печально, но именно этого требует ГРАМОТНЫЙ пользователь. А Е.Ф.Кодд просто четко сформулировал все эти требования пользователя - не больше и не меньше.
И пользователь прав уже даже только потому, что он платит деньги.
Лапшу на уши малограмотному End User'y навешать, конечно же, можно, но это ненадолго. Все равно он поймет, что ему нужно.
P.S. Заранее приношу извинения за то, что многим наступаю на любимую мозоль, но истина дороже.