Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
может быть у кого-то есть опыт использования OLAP в Axapta, подскажите. 1. что нужно сделать, чтобы увидеть ОПРЕДЕЛЕННУЮ сводную таблицу при нажатии на ОПРЕДЕЛЕННОЙ форме кнопки Запросы/Сводная таблица. то есть как сопоставить экземпляк куба и форму, на которой его можно будет отобразить? каждому кубу можно поставить в соответствие модуль системы - то ли это, что мне нужно? потому что так не получается. imho 2. в моей Axapta какие-то убогие PivotTables - у них нет скрола. и если площадь ячеек сводной таблицы занимает места больше, чем размер окна и экрана, то все данные уходят в никуда, mtp какой-либо возможности их увидеть. PivotTables в Excel я не видела, но там есть свой скрол. как быть в Axapte? может, хотя бы в 3.0 этого нет? MSSQL Server 7.0 Axapta 2.5 заранее благодарность ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2003, 18:16 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
По отзывам моих знакомых могу сказать, что в системе Axapta довольно слабо реализован OLAP. Так что обычно OLAP к Аксапте прикручивают "сбоку", а не пользуются имеющейся функциональностью. Мне дважды приходилось прикручивать Cognos PowerPlay, слышал также о попытках прикрутить к Аксапте и другие OLAP-продукты... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2003, 18:23 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
да, наверное так и есть, НО .. 1. передо мной стоит задача реализовать OLAP в Axapta по возможности 2. а если нет, что использовать в качестве OLAP-клиент от Microsoft? Excel я не считаю хорошим решением :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2003, 18:27 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
Excel и MS BI Portal лучшее решение, если вы хотите дать к статистике массовый доступ, а не собрать 1но рабочее место для одного "гуру". Для внедрения на десятки рабочих место такие слова как "easy-to-use" становятся очень конкретными. У людей есть масса других проблем помимо изучения OLAP-клиентов, а с Excel как правило знакомы все. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2003, 18:44 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
2. а если нет, что использовать в качестве OLAP-клиент от Microsoft? Excel я не считаю хорошим решением :( Excel мне тоже не очень нравится в качестве OLAP-клиента :) Все зависит от задач, которые ставит перед Вами Ваше руководство. Я бы порекомендовал взять MS AS, попробовать подключиться к БД Аксапты, натаскать табличек (благо структура БД Аксапты довольно простая) и попробовать создать 1-2 кубика. Для сравнения - посмотреть ознакомительную версию Cognos PowerPlay. Показать оба варианта руководству, и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2003, 18:49 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
:) мне нужно обеспечить массовы доступ к статистике. и конечно же попроще. уже есть решение на базе Oracle Express но руководство хочет перевести всю автоматизацию на Microsoft. можно где-нибудь узнать поподробнее, что такое MS BI Portal. на этом сайте встречаю не в первый раз, но только на этом. а MS AS я уже пробовала, и табличек из аксапты и кубики строятся, не совсем так как хотелось бы, но все же ... но в качестве клиента это достаточно сложный вариант imho. пользователю нужны голое отчеты. и все. предлагать cognos можно даже и не пытаться :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2003, 19:05 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
http://www.1bi.ru/bip.html ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2003, 19:06 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
Оригиналы всегда лучше http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnowc/html/odc_bip.asp В Москве и Питере можно посмотреть/обсудить развернутый MS BI Portal в действии прямо у клиентов. Причем в Питере развернутый над Real-Time OLAP. Мыло в профайле. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2003, 19:30 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
пользователю нужны голое отчеты. и все. предлагать cognos можно даже и не пытаться :( Тогда не понимаю, чем Вам не подходит Excel? У Cognos более продвинутые инструменты для создания отчетов. Можно, обладая навыками программирования на VB, написать свой интерфейс для ввода параметров отчета (для неопытных пользователей можно сделать простой интерфейс), передавать это в Cognos, и получать обратно отчет в любом формате. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2003, 19:32 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
Excel как массовый OLAP-клиент плох и хорош в основном одним. Пользователи работают с локальным Excel файлом. Обновить настройки Excel-отчетов централизованно это проблема, особенно если пользователи уже поменяли "шаблон". В MS BI Portal это делается с сервера. Там даже сброс сводной таблицы в Excel делается через IE. Пользователи могут иметь свои "приватные" отчеты, но настройки "для всех" обновляются централизованно. Также централизованное управление условным форматированием данных это большой плюс: "подсветим красным вредных клиентов!". :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2003, 19:46 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
BIP - это здорово, и я рассматриваю его как перспективный вариант. сколько хочет за него Microsoft? НО ! Вы забываете, что пока у нас SQL 7.0 и Axapta 2.6. Я так поняла, что в такой конфигурации, возможно использовать только MS AS для построения кубов на данных из Axapta и Excel (если ограничиваться MS) как клиенита. OLAP в Axapta не достойный. или стороннего производителя, в частности Cognos. имеет ли смысл на табличках Axapt'ы строить DW? у меня создается такое впечатление, что они там изначально построены по удобной для OLAP схеме. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.07.2003, 13:48 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
Вл.Иванов открыл для себя BI-порталы У ProClarity, Panorama, BO, MSI и других BI-поставщиков все это давно есть. Только покупали это исключительно солидные клиенты - цены от штуки за пользователя. ОК, появился "бесплатный" аналог от MS. Никто не против. Поставьте его, как Excel, рядом с остальными предложениями, и сравнивайте. Без профанации, что это нечто радикально новое. Окажется, что единственное преимущество - бесплатность. Да и то, бесплатность мнимая, т.к. лицензии на MS Office для работы OWC никто не отменял. Ну-ка ну-ка, сколько он там стоит по прайсу MS? Кто-нибудь помнит? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.07.2003, 14:22 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
бесплатность - это солидное преимущество. а какие у него недостатки - по сравнению с вышеперечисленными клиентами? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.07.2003, 15:16 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
2 Schumelka посмотрите http://www.erponline.ru/read/press_release/74 у них должно быть готовое решение по интеграции OLAP и Axapta. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.07.2003, 15:45 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
У Cognos, ProClarity и Panorama нет серверно управляемого Web-решения с такой низкой стоимостью Delpoy как BI Portal и очевидно не будет. Я действительно не считаю очень важным наличие на внедрении проф. OLAP-клиентов. Точне не считаю приоритетным. Просто я не собираю внедрения в стиле "1но раб. место для 1го гуру". Все внедрения у меня это десятки рабочих мест под OLAP. Информация в OLAP системе может помочь все команде сотруников принимать верные решения, просто нужно разделить доступ. MS AS тут очень силен. Если внедрение массовое, нужен в первую очередь массовый OLAP-клиент. Это Excel и теперь BI Portal. Очень важное качество "easy-to-use", которого нет у проф. OLAP-клиентов. Да и "проф" штука относительная, я заметил, что даже фин. директора имеющие опыт 2-3 года работы с двумя разными OLAP-системами не освоили всех возможностей Excel. На самом деле напомню историю перед самым крахом "Активных Торговых Технологий" (сейчас это отдельно Любимов и Adelite). Я же звонил вам перед развалом и спрашивал, что вы будете делать, когда Digital Design послал всех вас в сад и забрал свой OLAP-клиент обратно. Мне и другим звонившим, вы и ваши коллеги из Adelite откровенно признавались, что вся эта возня вокруг OLAP-клиентов это чистое маркетинговое фуфло, чтобы выделиться на общем фоне и круче Excel 2000 (замечу 2000!) ничего нет. Как быстро меняется точка зрения профессионалов. :) Из проф. клиентов я считаю лучшим продукт Cognos. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.07.2003, 16:02 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
Using the Office Web Components on a client computer requires a valid Office XP license only if you want to access the components with interactive functionality. If you do not have an Office XP license installed, you will experience the components in a view-only mode, with features such as "Export to Excel" disabled. This enables developers to distribute the client-side components without worry that they will work—the component will automatically check for a license on the client computer and react accordingly. The Office Web Components are shipped as part of Office XP Professional, Office XP Developer, Office XP Standard, Microsoft Access version 2002, Microsoft Excel version 2002, and Microsoft FrontPage® version 2002. Any of these products will include a valid Office XP license to enable interactive functionality. Иными словами WOC бесплатен в режиме view only, который и использует BI Portal. Те у кого есть MS Office могут использовать интерактивные фичи. Самая дешевая лицензия на Office стоит около $180 (SBP). Начиная с 5 лицензий идет большая объемная скидка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.07.2003, 16:14 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
Владимир, я с вами личных разговоров не имел. Это раз. Если вы цитируете кого-то из третьих компаний, то делайте это дословно и с упоминанием Ф.И.О. и даты разговора. Это два. А ваша маниакальная манера приплетать меня, АТТ и Аделит к совершенно посторонним темам, общая манера ведения дискуссий - просто некорректны. В англосаксонском юризме есть термин "диффамация", который ближе всего описывает ваше неприличное в обществе поведение. Я уже устал тыкать вас носом в это. Жаль, что у нас юризм не англосаксонский :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.07.2003, 18:22 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
коллеги, еще раз, скажите pls где можно почитать про add in от microsoft? ps imho стоит завести отдельную тему: Иванов vs Любимов. ничего личного :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.07.2003, 11:33 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
add in это расширения MS BI Portal. Сам Portal позволяет дописывать свои Add In и внедрять доп. функциональность в отчеты. Разработка Add In документированна и лежит в доках к MS BI Portal. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.07.2003, 14:03 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
для schumelk'и: только что вернулся из отпуска... не успел ответить сразу мне по долгу службы пришлось работать с Axapta и, в частности, связывать ее с OLAP, имея только AS в распоряжении. результатом работы было хранилище данных, в которое заносились данные из таблиц Аксапты (с помощью построенных мною правил закачки), и на основе которого были построены OLAP кубы. При этом БД Аксапты использовалась в качестве оперативного источника, и вдобавок получили хранилище данных и кубы. Все это не покидая AS. в качестве клиента могут использоваться, решения от ProClarity, Panorama, Cognos, например, у ProClarity есть свой собственный Analytics Server, который в рамках intranet организации (или за пределами) может рассматриваться как портальное решение. Если есть интерес, то eval-версию ProClarity можно посмотреть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2003, 21:02 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
о, наконец-то, хоть один живой человек, который занимался совмещением OLAP и Axapt'ы. я уж думала, что это чрезвычайно редкая задача. спасибо. я так понимаю, что использовать в качестве клиентов PivotTables Axapt'ы или Excel'я не лучшее решение. Но боюсь, мне все же придется это делать. Как вы думаете, это реально - построить на их основе olap-отчетность? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2003, 10:52 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
девочка наверняка зарплату поболее большинства здесь получает - а как же - OLAP, ERP, все дела... а ведь сама-практически нуль - выежжает на спине доброхотов-помощничков... и на сертификатики сдает наверняка... и откуда такие берутся? sorry ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2003, 11:51 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
2 анонимус: а откуда берутся такие любители считать деньги в чужом кармане? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2003, 13:38 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
конечно, все верно, действительно так =) и зарплата огромная(белая) и сертификаты и автомобиль иностранный и шофер личный - выкокий красавец блондин - и квартира и дача ... что еще ... только вот в башке ни бум-бум - но это мелочи. зачем, если есть доброхоты? а есть ли? а ведь, действительно - коммерциализованность форума - вот она. и критика справедлива, НО в других местах не отказываются помочь начинающим. а здесь - раз уж за это (вроде) должны много платить - то и карабкайся ты сам (а еще лучше - сама :)). ну что ж, логично, и не придерешься - конкуренция. спасибо всем, кто мне помогал. ps: to аноним: а почему не подписаться? не готовы отвечать за свою позицию? странно ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2003, 13:41 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
to schumelka: Нового шофера не надо? Правда не блондин. (шутка) А по поводу коммерциализованности форума и крабкаться самому, то никто никому ничего не должен. Вся помощь - исключительно дар. Требовать дара, так же как и благодарности за него нельзя. Да и возмущаться по этому поводу тоже не стоит. Помогли ведь. P.S. Злых анонимусов тоже не люблю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2003, 15:14 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
эй, я не возмущаюсь, что не помогают - наоборот, очень даже помогают - и за это спасибо :) только ведь и просить дара не возбраняется, или как? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2003, 16:25 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
просить подарки - это попрошайничество/вымогательство ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2003, 16:57 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
для schumelka: построить отчетность на PivotTables можно, все зависит от того, что хочется получить: функциональность, возможность фильтрации... есть такое предложение, что стоит опубликовать более подробные вопросы на форуме или по почте. удачи Андрей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2003, 18:37 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
2 shumelka А чем тебя Oracle Discoverer не устраивает? Пробывала? 1) относительно недорого (дешевле решений от MS, руководству твоему должно понравится :) 2) Работает с ODBC-источниками (под MS SQL 7 гарантированно), хотя Oracle роднее 3) в свободном доступе по бесплатной developer licence (см. http://otn.oracle.com) 4) гришь, в Аксапте таблички настроены прям под кубы. Хм. Не знаю, но раз так, "натрави" Discoverer прям на них. Тогда даже не надо ETL, и все такое.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2003, 15:27 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
2 oracle9idba >А чем тебя Oracle Discoverer не устраивает? Пробывала? >2) Работает с ODBC-источниками (под MS SQL 7 гарантированно), хотя Oracle >роднее Discoverer все-таки ROLAP, а не МOLAP сервер. И я чего-то не нашел каким образом он работает с ODBC источниками. Если можно расскажите. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2003, 15:48 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
Упс. А можно поподробнее про то, что он дешевле бесплатного MS AS? Речь то про решение к SQL Server'у идёт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2003, 15:54 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
To oracle9idba: относительно недорого (дешевле решений от MS, руководству твоему должно понравится :) Насколько я знаю, у Microsoft вообще нет решений класса Query & Reporting (по крайней мере пока). Так что я бы сравнивал Discoverer с Cognos Impromptu... Правда ли, что Discoverer заточен на анализ, но при этом не является профессиональным генератором отчетов? И есть ли в Oracle Discoverer интеллектуальный конструктор выражений? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2003, 15:58 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
ага, я уже сам посмотрел как он с ODBC работает - через гетерогенные сервисы. Т.е. как минимум Oracle Standard Edition к нему купить придется (да и EUL кажется только там и может храниться). А это еще лишние $1.500 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2003, 16:01 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
На самом деле наверное лезть Discoverer-ом через ODBC не самый лучший вариант. Лучше перекачать данные в ORACLE и там крутить. Это оправдано в случае создания хранилища данных, т.е. когда нам данные нужно смотреть не только из Аксапты, а еще из чего нибудь. Насчет того, что Discoverer не является профессиональным генератором отчетов - правда. У Oracle генератор отчетов - Oracle Reports, в который можно сбросить из Discoverer шаблон. Но конечно кое какое форматирование можно сделать и в самом Discoverer. Консруктор выражений там есть и наверное работает гораздо умнее, чем у других, т.к. умеет использовать всякие хитрые расширения ораклового SQL. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2003, 16:14 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
Действительно, если есть БД на MS SQL + несколько других источников можно создать ХД в Oracle, подцепить к нему Discoverer, Oracle Reports, навесить Oracle Express... Правда стоимость и трудоемкость реализации такого решения будет немалая. Помнится на форуме (то ли на этом, то ли на www.olap.ru ) обсуждался вопрос, что если есть БД Oracle, почему бы к ней не прикрутить MS AS - а хранилище в MS SQL Server будет бесплатным подарком :) Интересно, бывают ли в жизни такие случаи с одновременной поддержкой двух СУБД - Oracle и MS SQL? То что к Oracle прикупают MS SQL - я слышал, а вот обратные случаи - не слышал... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2003, 16:39 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
>И есть ли в Oracle Discoverer интеллектуальный конструктор выражений? Юра, про этот "интеллектуальный конструктор выражений" вы упоминаете в каждом втором постинге (когда речь идет о сравнении продуктов). Насколько я понимаю это тот асистент (или окошко), который используется для определения column calculation или mesure calculation? Если так, то должен вас огорчить :-) в Discoverer тоже такой есть причем с возможностью использовать широкий спектр оракловских аналитических ф-й (очень интересная штука кстате - позволяет совмещать группированный и не группированный результат в одном sql запросе). Меня вот мучает другой вопрос относительно PP (вер. 6.61). При проектировании куба в Трансформере - неужели если я хочу затянуть из базы негруппированный рез-тат например некую shipment_date я должен обязательно использовать count(shipment_date) в исходном sql запросе, а вот определить mesure (или column) calculation как count(shipment_date) не могу, т.к. групповые функции там уже недоступны? Или это делается в принципе по другому? Насколько я изучил ваши постинги - вы в таком случае затягиваете в куб уже группированный (в sql запросе) результат. Но вот например в MS AS в свойствах mesure/"source column" можно указать count. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2003, 16:54 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
2 Jurii Часто в форуме проходят обсуждения цены создания BI системы. При этом забывается, что кроме стоимости лицензий на софт есть еще и оплата труда людей, задействованных в проекте и всякие прочие накладные расходы. Нормальная Enterprise система будет стоить не один десяток, а то и сотню тысяч долларов, даже у нас в стране. В этой сумме, стоимость лицензий в общем-то теряется, вернее теряется разница в стоимости лицензий между конкурирующими продуктами. Если же говорить не об Enterprise системах, а о "Сделай сам" системах, то действительно, на первый план выходит стоимость лицензий и количество готового функционала, который предоставляет тот или иной коробочный продукт. Oracle, в общем то, ориентируется на Enterprise решения и для них дает целую линейку мощных продуктов, с помощью которых можно сделать практически все, что угодно при наличии грамотных спецов и достаточного финансирования. Все наверное предатавляют в каких случаях можно обойтись MySQL, а в каких все таки лучше купить Oracle или MS SQLServer. Почему то до сих пор на всех больших предприятиях существует куча самописных систем, так как готовыми все аспекты деятельности предприятия покрыть невозможно. А с аналитикой все еще сложнее. Системы класса Business Objects и других предполагают что ты купил за 2-5 тысяч коробку и можешь с помощью нее что то сделать, устроит это тебя или нет - неизвестно. Но настоящее Enterprise решение не построишь на таком софте. Более того, даже используя линейку Microsoft не так то просто построить нормальную систему. :) Поэтому подсчет стоимости лицензий, начиная с некоторого уровня практически теряет смысл. Надеюсь, моя мысль понятна. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2003, 18:43 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
to Jurii порядок цен такой (см ниже). цены на Discoverer Admin Edition ("рабочее место администратора", включая Warehouse builder) http://oraclestore.oracle.com/OA_HTML/ibeCCtpItmDspRte.jsp?a=b&item=353269 .. на Discoverer User Edition ("рабочее место пользователя") http://oraclestore.oracle.com/OA_HTML/ibeCCtpItmDspRte.jsp?a=b&item=353271 .. на Oracle Database standard Edition http://oraclestore.oracle.com/ Короче, один разработчик и 5 пользователей (на обязательно только Discoverer - но еще всего, что разработчик реализует в Developer Suite (см. его возможности)) около 3000 euro (без НДС). Если же приобрести вместо Standard Edition Enterprise Edition, то можно использовать поставляемые java-компоненты для Business Intelligence. А уже совсем другой уровень системы! Но поскольку аналитические функции (вроде SUM() OVER (PARTITION BY ... ORDER BY ...) ) лицензируются и в Standard Edition, то для многих этого окажется вполне достаточным: покупать дорогой enterprise и не надо :) Замечу, что никаких дополнительных вложений в software (кроме OS) более не требуется (если ничего не забыл :) про "профессиональность" конструктора и генератор выражений уже ответили другие участники форума. Добавлю лишь, что клиента редко интересует "профессиональность" конструктора, MOLAP или ROLAP - главное, чтобы система решала его задачи. А для задач построения нерегламентированных аналитических (top10, ratio to total, lag/lead и др.) отчетов Discoverer в паре с Oracle9i SE подходит великолепно. А что касается выражений: механизм вычисляемых полей в Discoverer достаточно мощный и определяется он возможностями сервера БД. Если же необходимы вычисления, которые невозможно сделать в программе, всегда можно вынести их на уровень хранилища данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2003, 10:54 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
всем здравствуйте :) у нас как раз и было такое смешаное решение. базы в MS SQL под Axapt'ой + отдельное синхронизируемое хранилище на Oracle + Discoverer в качестве клиента. почему не устраивает: 1. действительно, слишком громоздкая и запутанная структура 2. хотелось бы иметь информационную структуру по возможности в рамках продуктов одной фирмы (здесь наличие Axapta и MSSQL первичны, переход на Oracle не рассматривается даже как вариант) 3. опять же, не MOLAP 4. сложности с поддержкой. особенно, если решение создавалось спонтанно и не документировалось - как это было у нас. разработчик ушел. теперь система отчетов и хранилище на Oracle - тайна, покрытая мраком. субъективно, MS AS + Client намного прозрачнее 5. и конечно, стоимость OLAP-решения на MS - нулевая, при условии, что есть MS SQL Server и Office. Oracle - дополнительные траты. что касается структуры данных Axapta - она во многом денормализована, как и всегда, для увеличения скорости запросов, но по-хорошему, отдельное хранилище строить все-таки нужно, потому что таких понятий как "таблица фактов" и "таблицы измерений" в чистом виде не существует, хотя в некоторых случаях - почти то, что надо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2003, 12:37 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
>Короче, один разработчик и 5 пользователей (на обязательно только >Discoverer - но еще всего, что разработчик реализует в Developer Suite (см. >его возможности)) около 3000 euro (без НДС). странная у вас арифметика получается. Судя по ссылкам, которые вы привели вы считаете стоимость годичных лицензий (т.е. ограниченных на 1 год). Если считать нормальные (неограниченные) лицензии, то стоимость будет следующая: 6 лицензий Discoverer Desktop = 856*6 = € 5136 5 (сервер с 1-им cpu) лицензий Oracle SE = 257*5 = € 1285 Итого: € 6424 >клиента редко интересует "профессиональность" конструктора, MOLAP или >ROLAP - главное, чтобы система решала его задачи. А для задач построения >нерегламентированных аналитических (top10, ratio to total, lag/lead и др.) >отчетов Discoverer в паре с Oracle9i SE подходит великолепно. клиента интересует в первую очередь время отклика, а оно не гарантировано при работе с ROLAP. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2003, 12:48 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
клиента интересует в первую очередь время отклика, а оно не гарантировано при работе с ROLAP. Никакая модель ничего гарантировать не может. Ни MOLAP ни ROLAP. К тому же сейчас границы между ними настолько стираются, что уже и чистым ROLAP-ом назвать решение на Discoverer нельзя. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2003, 13:00 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
>Никакая модель ничего гарантировать не может. Ни MOLAP ни ROLAP. Такое впечетление, что вы никогда не работали ни с MOLAP ни с ROLAP системой. Иначе видели бы, что даже на маленьких объемах разница во времени отклика значительная. >К тому >же сейчас границы между ними настолько стираются, что уже и чистым >ROLAP-ом назвать решение на Discoverer нельзя. Да, вот это интересно. Где же хранятся данные Discoverer'а как не в реляционных таблицах? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2003, 13:08 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
2 .dba Что значит "маленькие объемы" в применении к MOLAP? Это термин как раз ближе к реляционным базам. 1000 записей - маленький объем, 100 миллионов - большой, приницпиально ничего не меняется. В многомерных базах играет еще количество измерений, структура этих измерений и проч. Легко можно устроить ситуацию, когда даже на 1000 исходных записей MOLAP сервер умрет из-за объема просчитываемых данных, а вот для ROLAP это будет совершенно не в напряг. Ну и обратный пример тоже можно придумать. Так что истина где-то посередине, как обычно. Таблицы-то таблицами, но есть еще материализованные View с Query Rewrite, которые непосредственно к реляционной модели имеют опосредованное отношение. Кстати говоря, есть такая компания SAS Institute, котороую все однозначно считают поставщиком MOLAP решений, но этот самый MOLAP построен там точно по такому же принципу - куча табличек с частично агрегированными данными и Query Rewrite движок, который все это разруливает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2003, 13:38 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
2 .dba Насчет цен - согласен с вами: конечно, правильнее рассматривать цены на лицензии без ограничения срока действия. + вы не учли Oracle Internet Developer Suite. А это еще 4280 евро. Итого выходит около 11000 евро (без НДС) за 6 лицензий пользователя Discoverer и Oracle Standard Edition и одну лицензию разработчика. Тем не менее, это информация к размышлению при выборе платформы для построения аналитической системы? Видел прайс того же Business Objects - там все гораздо грустнее в плане цен, хотя судя по презентации Business Objects возможности Oracle Discoverer + Oracle Database + Oracle IDS как минимум не уступают возможностям BO + some Database. Интересно узнать мнение специалистов по BO по этому вопросу. 2 All: а в каких случаях оправданы лицензии на 1, 2 или 4 года? В случаях, если компания планирует прекращать свою деятельность через это время или планирует менять vendora системы? Какие еще варианты? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2003, 14:15 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
To .dba Юра, про этот "интеллектуальный конструктор выражений" вы упоминаете в каждом втором постинге, используется для определения column calculation или mesure calculation. Я называю его (конструктор Impromptu) интеллектуальным потому, что он помогает пользователю создавать сложные выражения с легкостью (это очень важно при создании произвольных сложных запросов и отчетов). В зависимости от положения курсора в выражении предлагается выбрать функции и поля соответствующих типов (а не все из огромных списков), уместные в данном контексте ключевые слова, операторы и т.п. в Discoverer тоже такой есть причем с возможностью использовать широкий спектр оракловских аналитических ф-й (очень интересная штука кстате - позволяет совмещать группированный и не группированный результат в одном sql запросе). А вот в Discoverer - насколько я помню, конструктор не является контекстно-ориенторованным. Что касается функций - то Cognos Impromptu позволяет увидеть и использовать оракловские функции. Хранимые функции оракла тоже можно подключить в общий список функций. Impromptu также позволяет совмещать группированный и негруппированный результат в одном запросе. Например, если в БД - 1 миллион строк по 10 тысячам клиентов, 50 тысячам товаров и по 10 филиалам - мы можем получить 1 миллион строк результата - в одном поле будет детальный показатель, а в соседних полях мы увидим итог по клиентам, товарам и филиалам. Таким образом я часто провожу разбиение клиентов на крупных, средних и мелких, используя поверх итога функцию квантиль. неужели если я хочу затянуть из базы негруппированный рез-тат например некую shipment_date я должен обязательно использовать count(shipment_date) в исходном sql запросе, а вот определить mesure (или column) calculation как count(shipment_date) не могу, т.к. групповые функции там уже недоступны? Насколько я изучил ваши постинги - вы в таком случае затягиваете в куб уже группированный (в sql запросе) результат. Но вот например в MS AS в свойствах mesure/"source column" можно указать count. В Cognos PowerPlay тоже можно указать Count в свойствах Measure. Не очень понятен Ваш пример. Если например есть таблица фактов - строки документов, но мне детальный куб не нужен, я обычно в виртуальном view использую другую таблицу фактов - шапки документов. Видимо либо Ваш пример очень сложен - тогда я прошу сформулировать его подробнее, либо Вам просто стоит пройти небольшой тренинг по Cognos, чтобы изучить базовую функциональность и прочувствовать, как работает связка Powerplay + Impromptu при решении различных классических задач... To Birkhoff: Нормальная Enterprise система будет стоить не один десяток, а то и сотню тысяч долларов, даже у нас в стране. Согласен, аналитическая система для крупной компании не может стоить копейки. Однако здесь на форуме есть представители из разных регионов, и не только из крупных компаний. Для массового рынка хорошо, если для начала нужно заплатить немного, и можно быстро получить первые результаты, покрывающие 60-70% потребностей. Такие продукты сушествуют (Cognos, MS AS). Oracle, в общем то, ориентируется на Enterprise решения и для них дает целую линейку мощных продуктов, с помощью которых можно сделать практически все, что угодно при наличии грамотных спецов и достаточного финансирования С моей точки зрения, у Oracle - хорошая РСУБД, но все остальные продукты - не являются лидерами в своих нишах. Лидирующие аналитические продукты не хуже дружат с РСУБД Oracle, чем оракловые аналитические продукты. А то что например Oracle Express или Discoverer мощнее тех же PowerPlay и Impromptu - верится с трудом. Просто Oracle лучше раскручен с маркетинговой точки зрения. Системы класса Business Objects и других предполагают что ты купил за 2-5 тысяч коробку и можешь с помощью нее что то сделать, устроит это тебя или нет - неизвестно. Но настоящее Enterprise решение не построишь на таком софте. Более того, даже используя линейку Microsoft не так то просто построить нормальную систему. :) Ну положим BO - стоит не 2-5 тыс., а подороже. За 2 тыс. можно купить Cognos PowerPlay + Impromptu. С помощью этих продуктов можно решать сложные задачи в пределах локальной сети компании (если не рассматривать кривое, но имеющее право на существование терминальное решение). Если нужно создать единый портал для всех филиалов - придется докупить портальное решение (либо простое и дешевое, либо навороченное и дорогое), но ядром аналитической системы будут все равно недорогие Windows-версии этих продуктов. И я бы не сказал, что нормальную корпоративную аналитическую систему можно создать только с помошью продуктов Oracle. Поэтому подсчет стоимости лицензий, начиная с некоторого уровня практически теряет смысл. А вот с этим я согласен. Если даже не брать Москву и Питер, где годовая зарплата IT-специалиста не так мала, а рассмотреть например Новосибирскую область, где зарплата 200-300$ в месяц, то за год эта зарплата перекроет стоимость лицензий навороченнейших аналитических продуктов :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2003, 14:22 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
Я не спорю с тем, что здесь присутсвуют представители компаний различных уровней, с разными потребностями. И я бы не сказал, что нормальную корпоративную аналитическую систему можно создать только с помошью продуктов Oracle. Так и я этого не говорю :) Все что я хочу сказать, так это то, что имея большую линейку интегрированных продуктов можно наращивать систему практически беспредельно. Нужен только OLAP - используйте Discoverer или Express, не хватает возможностей репортинга - Reports, захотелось написать приложение заточенное под компанию - Jdeveloper с или без BiBeans, нужно портальное решение - берете Application Server ну и так далее. Легче увязать межд собой продукты одной компании, чем зоопарк от разных. Ну, а то, что систму можно построить не только на Oracle - я с этим не спорю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2003, 14:32 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
2 shumelka >> 1. действительно, слишком громоздкая и запутанная структура Вы о чем? Если о дизайне системы, то некорректно привязывать "громозкость и запутанность" к Oracle, MS или т.п. IMHO, эти факторы зависят от квалификации того "кто писал" и/или того, "кто читает". >> 3. опять же, не MOLAP интересно, зачем вам именно многомерный OLAP? "Крутить" и Drill-ить кубы и в ROLAP можно. Уж не цену ли себе "набиваете" :) ? >> 4. сложности с поддержкой. особенно, если решение создавалось спонтанно и не документировалось - как это было у нас. разработчик ушел. теперь система отчетов и хранилище на Oracle - тайна, покрытая мраком. субъективно, MS AS + Client намного прозрачнее Да, спонтанность разработки никогда не шла на пользу качеству. Вам повезло, если руководство предоставляет достаточно времени на перевод системы на MS и качественную проработку всех аспектов новой системы. Ушедшему разработчику скорее всего, ставили жесткие временные рамки (или он работать не умеет :)). Если новый разработчик (Вы?) ранее хоть немного работал Oracle, то проблем с "прозрачностью" меньше будет >> 5. и конечно, стоимость OLAP-решения на MS - нулевая, при условии, что >> есть MS SQL Server и Office. Oracle - дополнительные траты. Флаг вам в руки, если ВСЕ необходимое для MS OLAP уже официально закуплено. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2003, 14:33 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
To Birkhoff: Легко можно устроить ситуацию, когда даже на 1000 исходных записей MOLAP сервер умрет из-за объема просчитываемых данных, а вот для ROLAP это будет совершенно не в напряг. Не могли бы Вы привести такой пример. Ни разу не видел, как MOLAP умирает... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2003, 19:37 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
2 Jurii Вы же сами постоянно пишете о слабостях других MOLAP серверов по сравнению с Cognos, что, дескать, они не могут ворочать большие объемы. Как же тогда вы говорите, что не видели как умирает MOLAP? Так что, видимо вы лукавите, задавая этот вопрос. А если серьезно - постройте кубик например из 30 parent-child измерений, глубиной например по пять уровней и общим числом листьев в районе нескольких сотен. А потом попробуйте его сагрегировать. Даже если на нижнем уровне будет 1000 записей, для MOLAP сервера это будет очень тяжело. Не знаю выдержит ли MS AS такое? А в Cognos наверное такой эксперимент вообще поставить нельзя. А для ROLAP практически любой SQL запрос по 1000 записей будет обсчитываться моментально. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2003, 11:01 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
А если серьезно - постройте кубик например из 30 parent-child Незнаю как в других, но в 9i ROLAP не работает с несбалансироваными иерархиями. В то время как Express обрабатывает отлично (ну и наверное 9i AW). Так что же в этом случае, ну и вообще раскажите как другие работают с такими иерархиями? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2003, 13:44 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
2 DimaR В Discoverer можно эмулировать несбалансированные (unbalanced tree hierarchies) иерархии. Например, если структура департамента продаж образует несбалансированную иерархию, то в отчете по реализации в разрезе менеджеров и отделов можно видеть агрегированные показатели реализации по отделам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2003, 14:14 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
2 DimaR Express работает с несбалансированными иерархиями, но не с таким их количеством. То есть 30 измерений собрать и сделать Rollup по всем не получится. Иногда в ROLAP не нужно присутствие именно несбалансированных иерархий, запрос можно построить другим способом. Иногда нельзя :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2003, 14:25 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
2 Birkhoff >Таблицы-то таблицами, но есть еще материализованные View с Query Rewrite, >которые непосредственно к реляционной модели имеют опосредованное >отношение. Почему опосредованное? MV в которых хранятся агрегированные результаты соединения нескольких таблиц по сути являются такими же реляционными таблицами только уже не с детальными, а агреггированными фактами. Кроме того для обновления их необходимо полностью пересоздать. Я уже не говорю о том что создание и обновление MV всегда связано с дополнительными накладными расходами для OLTP базы (если они создаются в ней). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2003, 14:55 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
2 .dba Как раз насчет полностью это вы не правы. Существуют разные способы пересоздания. Но иногда, конечно, необходимо полностью. В MOLAP данные тоже надо сначала загрузить и проагрегировать, что тоже является таким же пересозданием как и в случае MV. А то что MV - таблицы базы, конечно, но QR не связан с реляционной моделью,это уже надстройка, которая и позволяет достичь повышения производительности. И еще один момент, аналитические базы данных обычно предполагают отставание во времени от боевых, хотя в последнее время придумываются штуки вроде Real-Time OLAP, чтобы это победить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2003, 15:04 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
Real-Time OLAP пользователи очень любят, особенно если с оперативными отчетами в OLTP-системе не очень... Только вот для реализации Real-Time OLAP приходится модифицировать таблицы источников данных, чтобы те содержали дату-время последней модификации записи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2003, 15:20 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
>Как раз насчет полностью это вы не правы. Существуют разные способы >пересоздания. Но иногда, конечно, необходимо полностью. Я говорил о конкретном типе MV - " в которых хранятся агрегированные результаты соединения нескольких таблиц ". Именно этот тип в Оракле обновляется путем полного пересоздания. Если не верите могу привести ссылки. Я говорю именно об этом типе MV т.к. он чаще всего необходим для представления многомерных данных. >И еще один момент, аналитические базы данных обычно предполагают >отставание во времени от боевых, хотя в последнее время придумываются >штуки вроде Real-Time OLAP, чтобы это победить. Я уже писал, что обновление агрегированного MV на боевой базе является серьезной проблемой с точки зрения производительности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2003, 15:21 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
>А то что MV - таблицы базы, конечно, но QR не связан с реляционной >моделью,это уже надстройка, которая и позволяет достичь повышения >производительности. QR (query rewrite) не более чем механизм изменения запроса направленного на таблицу в запрос перенаправленный к MV и к хранению данных никакого отношения не имеет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2003, 15:26 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
To Birkhoff: А если серьезно - постройте кубик например из 30 parent-child измерений, глубиной например по пять уровней и общим числом листьев в районе нескольких сотен. А потом попробуйте его сагрегировать. Даже если на нижнем уровне будет 1000 записей, для MOLAP сервера это будет очень тяжело. Не знаю выдержит ли MS AS такое? А в Cognos наверное такой эксперимент вообще поставить нельзя. Спасибо, интересный пример. Я как то делал куб в Cognos PowerPlay с 50 измерениями и 50 показателями, но не все измерения были иерархическими. Тогда я закачал в куб 50 тысяч записей, и проблем с производительностью не наблюдал. Думаю Ваш пример хорош для проверки качества OLAP-движка. Обязательно потестирую Cognos PowerPlay. Было бы интересно провести такой же эксперимент на MS AS, Oracle Express и Hyperion Essbase - и провести сравнительный анализ (каков получится размер куба, сколько времени он будет процесситься, сколько времени потребуется на проектирование куба). Кстати, в чем с Вашей точки зрения сложность этого примера для MOLAP - в том, что в кубе будет очень много ячеек? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2003, 15:47 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
2 .dba QR (query rewrite) не более чем механизм изменения запроса направленного на таблицу в запрос перенаправленный к MV и к хранению данных никакого отношения не имеет. Вот и я говорю, что к храненению данных QR никакого отношения не имеет, поэтому и не относится ни к MOLAP ни к ROLAP. И вообще термины были придуманы давно и сейчас граница между ними расплывается. В общем этот вопрос скорее философский. :) Я уже писал, что обновление агрегированного MV на боевой базе является серьезной проблемой с точки зрения производительности. Конечно, но для этого существуют выделенные сервера - хранилища данных, чтобы не нагружать боевой сервер. Я говорил о конкретном типе MV - "в которых хранятся агрегированные результаты соединения нескольких таблиц". Именно этот тип в Оракле обновляется путем полного пересоздания. А я говорил о MV вообще. Я не помню того, что этот тип MV требует полного пересоздания, но вполне возможно, лень проверять :). А насчет того, что этот тип в основном и используется - тут уж зависит от архитектуры хранилища. У кого-то да, у кого-то нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2003, 15:56 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
2 Jurii Кстати, в чем с Вашей точки зрения сложность этого примера для MOLAP - в том, что в кубе будет очень много ячеек? Да, конечно, в том что слишком много ячеек, но не только. Любой нормальный MOLAP сервер умеет работать с пустыми пространствами в кубе, иначе никаких терабайтов не хватит для того, чтобы записать все ячейки на диск. У каждого производителя механизм работы с пустотами свой. Смысл сводится к тому, что часть данных заранее агрегируется и записывается на диск, а часть вычисляется на лету. Тот же QR работает в общем-то по тому же принципу. Пример, про который говорилось, я пробовал делать на Express. Важно именно соблюсти условия, про которые я сказал - большое количество именно иерархических измерений, так как неиерархические обсчитываются гораздо легче и требуют меньше места. Я выскажу свое личное предположение: у более современных MOLAP движков преимущество в том, что они создавались в условиях, когда например 256MB RAM на рабочей станции не экзотика. А старые движки вроде Express делались в то время, когда и на сервере 4 мегабайта было много. Поэтому приходилось извращаться и не замахиваться на такие большие объемы, перелопатить 7-8 измерений на медленных дисках и 4мб RAM было круто. А тот же MS AS сейчас может занять 256МБ под кэш куба и вычислять на лету огромные объемы. Но все равно, мне интересно вытянет ли тот же MS AS такой объем? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2003, 16:13 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
2Birkhoff Вытянет, но "как" это зависит от целого ряда факторов. Parent-Child агрегируется на уровне All и Soft. Если Parent-Child содержит до 50.000 элементов особых проблем не будет. Если станет больше тогда лучше синтезировать Parent-Child как Regular. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2003, 17:03 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
2 Владимир Тут ведь еще ситуация осложняется тем, что там не одно parnet-child измерение, а их несколько десятков. Поэтому все еще сложнее. На каждом конкретном измерении листьев может быть немного, но зато много уровней и большое количество самих измерений. Кстати задача реальная, мне такую пришлось решать. А в regular часто не переложишь, если иерархия несбалансированная - как это сделаешь? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2003, 17:45 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
2Birkhoff И я решал. Вопрос что за отчет будут стоить. Если всегда будут выбирать по 1-2 Parent-Child из 40 имеющихся, все будет быстро, т.к. не выбранные измерения скроются за All-агрегатом. Если комбинации более 2х Parent-Child предварительная агрегация тут мало помогает. По законам комбинаторики мы попадаем скорее всего в "MOLAP-дырки" даже при плотности 80%. Выход тут в создании синтетических измерений, еслу вдруг начинаются тормоза. В Express это как-то не так? Измерение близкое к несбалансированному можно сделать через Ragged Hierarchies. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/olapdmad/agdimensions_8jzn.asp ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2003, 17:58 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
2 Владимир В Express это примерно так же, проблема в другом, - он для такого количества измерений не может преднасчитать ALL агрегацию, видимо потому что по законам той же комбинаторики и ALL агрегатов получается очень много. А если все обсчитывать на лету - тоже не проходит. MS AS лучше считает агрегаты. Может кому то и удавалось на Expresse такое поднять, но я не встречал пока. А запросы какие будут - ну ясное дело произвольные :) И действительно, в любой момент времени нужен срез не более чем по 5-6 измерениям, но какой именно срез понадобится в следующий момент - никто не знает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2003, 18:19 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
Всем привет! Приведу описание примера по созданию куба с 30 измерениями в OLAP-сервере Cognos PowerPlay: 1) Создал в Excel 1 колонку с числами от 10001 до 11000. Далее создал 30 колонок с заголовками "izm01" ... "izm30". Далее заполнил эти колонки значениями типа "member_izm1610388" (для каждой колонки свой набор из 1000 уникальных значений). Итого - 31 колонка. Размер файла XLS - 2.1 Mb. 2) Создал в модуле PowerPlay Transformer модель куба. В источнике данных (таблица фактов) - 31 колонка из Excel + 4 вычисляемые колонки (соответственно 1, 2, 3 и 4 первых символа от первой пятисимвольной колонки). Эти 4 колонки я использовал как 4 уровня измерения для каждого из 30 измерений. 5-й, нижний уровень брался из следующих 30 колонок. Показателем сделал первую колонку. 3) Сгенерировал куб. Время генерации - 49 секунд. Размер куба - 10 Mb (в сжатом виде - 1.3 Mb). Количество категорий (members) - примерно 35 тысяч (в каждом из 30 измерений по 1000 листьев + узлы иерархии). 4) При тестировании работы куба в OLAP-клиенте PowerPlay User замедления не наблюдалось, даже когда делал глубокую вложенность (10 уровней в боковике и 3 уровня в шапке) и накладывал фильтры по другим измерениям. Такой подход я избрал, поскольку подготовить данные - это долгий процесс, а свободного времени немного. Понятно, что пример получился несколько упрощенный, иерархии сбалансированные. Как думаете, интересен ли такой эксперимент? Хочет ли кто-нибудь его повторить на своем инструментарии? Если будут желающие - могу выложить на сайт http://cognos.narod.ru исходный XLS-файл для скачивания. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2003, 11:52 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
2 Jurii Эксперимент, безусловно, интересный. Вот только я не совсем понял, как вы строили уровни по каждому из измерений? Можно пояснить на примере? Получилось ли при этом 30 пятиуровненых измерений? И выложить файл было бы полезно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2003, 12:15 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
To Birkhoff: Исходные данные можно скачать с http://cognos.narod.ru/Xls30izm.zip . В модели куба у меня именно 30 измерений, в каждом из которых по 5 уровней иерархии. По-хорошему, нужно было сделать в Excel для 30 измерений не 30, а 150 колонок, но это потребует долгой рутинной работы. Если есть на форуме волонтеры - сделайте для каждой из 30 колонок еще 4 колонки: в первой будет взят первый символ из пяти правых крайних, во второй - два первых символа из пяти правых крайних, и т.д. (три первых и четыре первых символа). Это и будут колонки для формирования уровней иерархии с первого по четвертый (искуственная классификация). Я пошел по альтернативному пути. Создал в модели куба 4 вычисляемые колонки с помощью формулы Substring (izm01, 13, N), где N - это число от 1 до 4 (то есть были вычислены подстроки от строки из колонки izm01, начиная с 13 символа, длиной N символов. Поскольку крайние правые 5 символов у всех 30 колонок для каждой строки одинаковы, я перетащил эти 4 вычисляемые колонки друг под друга в каждое из 30 измерений. А пятый нижний уровень для первого измерения взял из колонки izm1, для второго измерения - из колонки izm2, ..., для тридцатого измерения - из колонки izm30. Понятно ли мое объяснение? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2003, 12:46 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
Разясните новичку, предыдущий пример, а то я ничего не пойму. Может у меня с арифметикой плохо. Возьмем без иерархий 1000^30=1.e+90 значений Возьмем теперь какой либо процент заполнения куба , пусть даже милионные доли процента, Всетаки я могу представить порядок цифр и объем данных, а с иерархиями (тем более несбалансироваными) еще сложнее. Где у меня ошибка??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2003, 13:10 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
To DimaR: Разясните новичку, предыдущий пример, а то я ничего не пойму. Вы не понимаете, почему куб получился довольно небольшим при таком большом количестве измерений? Возьмем без иерархий 1000^30=1.e+90 значений Пока все правильно, Вы вычислили число ячеек куба. Возьмем теперь какой либо процент заполнения куба , пусть даже милионные доли процента, Всетаки я могу представить порядок цифр и объем данных, а с иерархиями (тем более несбалансироваными) еще сложнее. А вот здесь Вы ошибаетесь. Почему Вы думаете, что процент заполнения куба - миллионные доли процента? Ведь закачали то мы всего 1000 записей, в кубе заполнено всего 1000 ячеек, ну и в каком-то количестве ячеек созданы агрегаты (у каждого OLAP-сервера свой метод создания агрегатов). Не исключено, что реальный процент заполнения куба - не 1.e-8, а 1.е-85. Как показывает этот пример, OLAP-движок Cognos имеет высокое качество и не подвержен проблеме лавинообразного роста размера куба. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2003, 13:40 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
Ведь закачали то мы всего 1000 записей На кой черт мне OLAP сервер для анализа 1000 записей? Как правило реальный объемы совсем другие, то что я пробовал на Express по 2 измерениям Иерархия Год-Месяц-День 365 дней Иерархия Товары (несбалансированая по группам товаров от 1 до 7 уровней в ветке) 40000 товаров 400 груп (все в иерархии). Анализ нужен до самых нижних уровней, то есть и по конкретным товарам и по дням. было более 2000000 записей, так это просто тесты. Я думаю у Expreess, и у 9i ROLAP, и у Discoverer на 30 иерархиях на 1000 записей тоже не возникнет никаких проблем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2003, 16:00 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
To DimaR: На кой черт мне OLAP сервер для анализа 1000 записей? Вы прочитайте эту дискуссию :) В ходе нее возник вопрос, как можно умертвить MOLAP. Поступило предложение - сделать куб с 30 измерениями и закачать в него всего 1000 записей. Это было сделано с помощью Cognos PowerPlay и теперь все знают, что MOLAP - это не такая слабая штука. Теперь правда надо проверить, все-ли MOLAP-продукты могут решать такие задачи... Как правило реальный объемы совсем другие, то что я пробовал на Express по 2 измерениям Иерархия Год-Месяц-День 365 дней Иерархия Товары (несбалансированая по группам товаров от 1 до 7 уровней в ветке) 40000 товаров 400 груп (все в иерархии). Ну правильно, раз Вы работаете с Express - то Вы знаете его слабые стороны и стараетесь избегать ситуаций, когда в кубе более 5 измерений. А теперь представьте, что аналитик поработал с Вашим кубом, увидел, что по какому-то товару прибыль маленькая, отфильтровал 1000 фактов продаж конкретно этого товара и решил провести исследование, какие факторы влияют на прибыльность по данному товару. Аналитик определился с потенциальными факторами (их предположим примерно 30 :) , подключил к таблице фактов эти несколько десятков классификаторов и захотел повертеть в кубе этот маленький, но широкий массив данных - вот мы и пришли к нашему примеру :) Я думаю у Expreess, и у 9i ROLAP, и у Discoverer на 30 иерархиях на 1000 записей тоже не возникнет никаких проблем Вот и сделайте доброе дело - проведите тесты на основе выложенных мною для скачивания данных ( http://cognos.narod.ru/Xls30izm.zip ), опубликуйте их результаты. В первую очередь посетителей форума интересует MOLAP-продукт Express (в нем более удобно проводить многомерный анализ с Drill-down/up по иерархиям). Лично мне очень интересно узнать, какой размер будет у куба, сколько по времени он будет процесситься, сможете ли Вы в течение 20-30 минут спроектировать куб, или у Вас уйдет больше времени, и т.п. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2003, 16:52 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
2 DimaR Ну не все же задачи сводятся к анализу продаж. Существует еще анализ, колторый называется многофакторный. Когда самих записей может быть и немного, но за то параметров. Измерений, отношений - сколько угодно. 2 Jurii Это хорошая новость, что MOLAP Cognos может это ворочать, жаль экперимент не чистый, т.к. уровневая иерархия она и есть уровневая - алгоритм обсчета агрегатов очень прозрачный. Собственно и ROLAPа хватит. А в Express все измерения parent-child, что и хорошо и плохо одновременно. Интересно, сможет ли кто-то это сделать именнно на 30 несбалансированных иерархиях? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2003, 17:11 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
К слову, я провел данный тест в MS AS. Ни каких проблем, причем создание 100 агрегатов для данного примера заняло несколько секунд. Хотя я думаю тут Cognos как раз тормозил, агрегация у MS быстрее. Размер OLAP-базы составил всего 300kb. Следует отметить, что данный тест не совсем то что предлагал Birkhoff. В его примере речь шла о несбалансированном Parent-Child. Такое измерение OLAP-серверу трудно агрегировать, а Cognos вообще такие измерения строить не умеет. В примере, где Parent-Child транслирован в аналог регулярного измерения MS AS и Cognos очень сильны своими MOLAP агрегатами. Я строил схожий пример причем для реальной системы в Сатурне, где были Parent-Child до 50 тыс. в таком измерении все Ok, т.к. MS AS сделает All-агрегации. В принципе ok если 2 большие Parent-Child и остальные регулярные, но не всегда. К слову, подобные фокусы не для чайников. Если измерения вырастут до нескольких сотен тысяч элементов можно врезаться в неправильную обработку транзации базы MS AS. Как результат... сервер гибнет со всем содержимым. Дело в том, что даже если нажать Reset при старте MS AS снова начнется бесконечная работа транзактора. Так что осторожнее с тестами, тут все работает в MS AS, но нужен опыт. Хотя я думаю что при 30 измерениях по 300 тыс. элементов Cognos тоже начнет творить чудеса. Юр, попробуй, любопытно что будет. PS. А то что Express ляжет даже на примере из 1000 записей это к доктору не ходи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2003, 17:21 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
To Birkhoff: уровневая иерархия она и есть уровневая - алгоритм обсчета агрегатов очень прозрачный. Собственно и ROLAPа хватит. Я думаю на выбор между MOLAP и ROLAP влияет не только наличие или отсутствие несбалансированной иерархии, но и масса других факторов, которые довольно часто обсуждаются на OLAP-форумах... Интересно, сможет ли кто-то это сделать именнно на 30 несбалансированных иерархиях? Давайте уточним, что такое несбалансированная иерархия. Например: Id, Name, Parent_Id 1, Товары, 0 2, Услуги, 0 11, Товары продовольственные, 1 12, Товары непродовольственные, 1 111, Пиво, 11 112, Водка, 11 Эта иерархия является несбалансированной? Если да - то у того же Cognos нет стандартных средств для подобных табличек с 3 полями, а используются более универсальные методы работы с иерархиями (далеко не всегда иерархия лежит в 3 полях одной таблицы). В конечном итоге с помощью создания алиасов для таблицы с иерархией все сводится к следующему виду: Колонка1, Колонка2, Колонка3, Колонка4 Группа1, Подгруппа11, NULL, Товар15 Группа1, Подгруппа12, Подгруппа121, Товар17 Группа2, NULL, NULL, Товар24 Другими словами получаем определенное количество колонок (это число больше или равно числу уровней иерархии по самой глубокой ветви, если иерархия часто изменяется - делают лишние алиасы и добавляются несколько пустых колонок, содержащих NULL, чтобы был запас). Далее колонки подтаскивают одну под другую и получается иерархическое измерение куба, в каждом уровне которого проставляется свойство схлопывания пустых уровней. В итоге при Дрилл-дауне в кубе по одной ветви можно углубиться более глубоко, по другой - менее глубоко. Если бы у меня было лишнее свободное время - я мог бы сделать и такой пример, но уж очень муторно генерить 30 иерархических несбалансированных категорий. Может у кого-нибудь исходные данные уже подготовлены? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2003, 17:44 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
Юра, пример найти из жизни элементарно. Возьми у своего большого клиента на 1С справочники Номенклатура и Контрагентов. Типичный Parent-Child У некоторых моих клиентов они достигают размеров в 100 тыс. элементов и 12 уровней вложенности. Что-то не радует раскрывать самому подобные деревья в регулярное измерение. И что противно, юзер все равно рано или поздно сделает 13й уровень. :) Если я в MS AS с таким измерением расправлюсь за 10 секунд мастером, то тебе тут такие ритуальные танцы делать. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2003, 17:57 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
2 Владимир Иванов Дело как раз не в 1000 записях. Я и завел этот разговор для того, чтобы показать, что количество записей в MOLAP - это еще не все. Мне в Expresse доводилось строить 12 мерный кубик с несбалансированными иерархиями, причем объем загружаемых записей был порядка десяти миллионов. Так что то, что Express может поднять 12 таких измерений характеризует его с хорошей стороны. Другое дело, что там нет регулярных иерархий и это плохо. А в вашем примере с Сатурном сколько было в кубике измерений parent-child? 2 Jurii Я думаю на выбор между MOLAP и ROLAP влияет не только наличие или отсутствие несбалансированной иерархии, но и масса других факторов. Не вопрос :) Насчет примера со схлопыванием пустых уровней- это интерсено. А что происходит если в каком то месте происходит появление нового уровня? Видима надо перестраивать измерение и куб? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2003, 18:03 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
Владимир, Я все-таки как-нибудь найду время и приведу примеры более сложных несбалансированных иерархий, которые не помещаются в 3 поля. Когда же иерархия лежит в 3 полях, мне действительно приходится делать алиасы (как и в более сложных случаях) - но это все легкие клики мышки, это не сложно. Что касается 1С, где видимо чаще используются именно простые, трехпольные иерархии, то насколько я знаю, там стараются не иметь глубокие ветвистые иерархии, так как сама 1С с ними работает со скрипом. Что касается нашего примера - интересно бы конечно было сравнить мой куб с твоим. У Cognos куб разрастается, когда много категорий/members (35 тысяч это не так мало, поэтому и куб получился 10 Mb). Для чистоты эксперимента попробуй сделать куб на основе моего XLS-файла - 30 измерений без иерархии (1 колонка - 1 измерение). Далее открой куб, и сделай отчет, когда в боковике 1000 элементов, каждый из которых раскрывается в элементы другого измерения (итого 1 миллион строк), а в шапке - 1000 элементов. В итоге получим в отчете 1 миллиард ячеек (большинство из них будут пустыми. Интересно, за сколько секунд у тебя откроется такой отчет (у меня за 16 секунд :) А кубы (MOLAP) с 30 измерениями по 300 тыс. листьев в каждом делать нужно на очень серьезных компьютерах, у меня под рукой таких нет... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2003, 18:12 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
To Birkhoff: Насчет примера со схлопыванием пустых уровней- это интерсено. А что происходит если в каком то месте происходит появление нового уровня? Видима надо перестраивать измерение и куб? Нет, это делать не обязательно. Если куб подкачивается инкрементально - то просто появится еще один member/категория. Например, клиент Иванов, живя в Питере, купил товаров на 100 руб, а потом он переехал в Москву и купил в Москве товаров на 70 руб. То есть один и тот же Иванов встретится в 2 местах (в 2 ветвях классификатора). С помощью работы с подмножествами (сложные фильтры) в OLAP-клиенте Cognos PowerPlay можно будет увидеть всю историю Иванова. Если же куб перегенерируется полностью - то тогда мы увидим, что Иванов купил товаров на 170 руб. в Москве. Хорошо это или плохо - зависит от ситуации, нужно не забывать и о принципах из теории хранилищ данных... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2003, 18:31 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
2Birkhoff В Сатурне сейчас 3 больших Parent-Child и более 40 регулярных измерений. Раньше P-C было больше, но я их побил. OLAP-база стремительно растет вместе с компанией - уже 10 млн. фактов. Я сейчас слепил из 1С базы пример, где скопировал Parent-Child Номенклатуру 30 раз. В справочнике 15 тыс. позиций. Отчет по продажам с "30 Номенклатурами" хорошо работает. Тест не чистый, но по порядку величины правильный. Хотя, сознаюсь, немного пошаманил с настройками MS AS. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2003, 18:39 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
2 Jurii Это тоже интересно, но я спросил немного о другом. Что будет если у нас было 3 уровня вложенности: например, Город-Магазин-Товар, а потом кто-то решил добавить еще одну градацию типа Город-Магазин-Отдел-Товар. Причем характерно это только для крупного магазина, а для других не важно. и на них не должно отражаться. Это и есть несбалансированная иерархия. Как в Cognos работать с такими ситуациями? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2003, 18:39 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
2 Владимир. Здорово. А какое количество уровней в иерархии номенклатуры в среднем? И является ли она несбалансированной? В приниципе в движке MS AS я меньше всего сомневался :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2003, 18:44 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
2Jurii Юрий, вы нас не разводите, чай мы не небо коптим. :) Пример возьмем другой. Самый нижний уровень вашей иерархии скажем злобный пользователь Иванов решил разбить на 2 группы в одной из подветок. При этом утыкаемся в нехватку заготовленных уровней. 2 Birkhoff Самое большое несбалансированное P-C измерение это совсем не Номеклатура, а некоторое синтетическое измерение нужное для анализа ряда факторов. Как подможество оно содержит Номенклатуру и еще много чего. Номеклатура Сатурна это гигант, как и сама компания имеющая 30% оптового рынка стройматериалов России. Одни болты и гайки несколько десятков тысяч позиций. Сколько всего сейчас сказать не берусь, наверное около 500 тыс. Просто все работает на автопилоте я там несколько месяцев не был. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2003, 18:59 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
Владимир, Я сейчас слепил из 1С базы пример, где скопировал Parent-Child Номенклатуру 30 раз. В справочнике 15 тыс. позиций. Отчет по продажам с "30 Номенклатурами" хорошо работает. Тест не чистый, но по порядку величины правильный. Хотя, сознаюсь, немного пошаманил с настройками MS AS. Мне кажется что в этом случае не происходит реальной проверки работоспособности MS AS в многомерном пространстве, поскольку как я понимаю к Вашей таблице фактов, имеющей поле КодТовара все эти 30 копий одного и того же измерения привязываются одинаково. Попробуйте все-таки мой пример, когда в каждом из 30 измерений - независимые, разные члены (если по одному из них наложить фильтр - это сразу отражается на OLAP-отчете, а если они все были бы одинаковые - то потерялась бы многомерность). To Birkhoff: Что будет если у нас было 3 уровня вложенности: например, Город-Магазин-Товар, а потом кто-то решил добавить еще одну градацию типа Город-Магазин-Отдел-Товар. По правде говоря, эта ситуация похожа не на несбалансированную иерархию, а на случай, когда иерархия сбалансирована и собирается на основе полей из разных таблиц измерений. Однако, если Вы поместили ее в 3 поля, то тогда в Cognos нужно во-первых гарантировать, чтобы заранее имелись лишние алиасы (и тогда при схлопывании уровней иерархии схлопнется на один нулловый уровень меньше, а если алиасов недостаточно - нужно один добавить, иначе потеряется детальный уровень иерархии), а во-вторых нужно будет все же перегенерировать куб, иначе получится, что в прошлые месяцы магазины раскрываются в товары, а свежеподкачиваемые данные с другой классификацией будут сгруппированы по-другому - Магазин-Отдел-Товар). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2003, 19:04 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
Владимир, Юрий, вы нас не разводите, чай мы не небо коптим. :) Пример возьмем другой. Самый нижний уровень вашей иерархии скажем злобный пользователь Иванов решил разбить на 2 группы в одной из подветок. При этом утыкаемся в нехватку заготовленных уровней. Пользователь Иванов - не злобный, а любознательный, даже через чур :) А такие люди редко работают в серьезных компаниях, у которых большие БД с глубокими иерархиями. Глубокая иерархия - это не только измерение для куба, но и базис для планирования, учета и контроля в компании. Поэтому просто так иерархии никто не углубляет, а если и углубляет - то это процесс не быстрый. Ну а если даже и встретится такой случай - углубление иерархии на 5 уровней, хотя зарезервировано всего 3 - то тогда в куб не закачаются самые детальные 2 уровня. Пользователи это заметят, позвонят админу аналитической системы, он быстренько добавит еще 2 алиаса, и перегенерирует куб. Можно тогда уж встречный вопрос: что происходит, когда в учетной системе (например в 1С) происходит углубление несбалансированной иерархии? Когда эти изменения попадут в куб MS AS, и что для этого нужно сделать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2003, 19:18 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
P.S. Мне как-то сразу в голову не пришло, что у Cognos есть еще один интересный способ работать с несбалансированными иерархиями (а также и со сбалансированными иерархиями). Например, аналитик заходит в модель куба, открывает дерево категорий (members, иерархия), видит что там целый ряд городов. Далее он создает мышкой новый уровень иерархии, создает новые категории (типа "крупные города" и "мелкие города"), и мышкой подтаскивает Москву и Питер в категорию крупных, а более мелкие города - в категорию мелких городов. Далее он нажимает на кнопку перегенерации куба, и в кубе отразится изменение в иерархии. Тут уже никакие алиасы не нужны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2003, 19:24 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
to Jurii Глубокая иерархия - это не только измерение для куба, но и базис для планирования, учета и контроля в компании. Поэтому просто так иерархии никто не углубляет, а если и углубляет - то это процесс не быстрый. Не знаю как у вас, но в моих тестах иерархии брались из таблиц в базе, и я исходил из предположения, что иерархию групп товаров могут поменять в любой момент, например одну группу разбить на несколько более мелких, и т.д., ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2003, 19:26 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
2 Jurii Ну в общем я об этом и спрашивал. Если меняется количество уровней - нужно менять струкутру и перегенерять весь куб. В том то и проблема, что заранее неизвестно сколько там полей будет три или пять. А насчет того что в реальности не бывает что углубляются уровни иерархии - еще как бывает. Если взять например какую нибудь оргштаную структуру очень большого предприятия - там всегда есть простор для появление отделов, подотделов, филиалов, лабораторий, цехов - черт ногу сломит как называть уровни иерархии, в кажой ветке названия будут свои. Но даже и в более простых случаях углубления иерархий происходят. Например маркетолог или аналитик рынка может легко собрать несколько товаров в одну группу, чтобы наблюдать за группой в целом, а внутри этой группы могут быть еще группировки по одному ему известному закону. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2003, 19:39 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
2 DimaR Это правильно. И чем хорош Express, так тем? что там можно написать один скрипт, который всегда отреагирует на появление новых групп. Т.к. измерения parent-child. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2003, 19:41 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
Можно тогда уж встречный вопрос: что происходит, когда в учетной системе (например в 1С) происходит углубление несбалансированной иерархии? Когда эти изменения попадут в куб MS AS, и что для этого нужно сделать? Если они реализованы как Папик-Чайлд - сами попадут. делать ничего не надо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2003, 10:47 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
To Birkhoff Конечно изменения в структуре иерархий бывают, но если говорить о больших компаниях с большими базами, то подобные изменения это довольно серьезный процесс. Трудно представить себе крупную компанию у которой каждый месяц меняется орг структура или иерархия справочника номенклатура. И тут нельзя не согласиться с Юрием Глубокая иерархия - это не только измерение для куба, но и базис для планирования, учета и контроля в компании. Поэтому просто так иерархии никто не углубляет, а если и углубляет - то это процесс не быстрый. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2003, 12:21 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
To LNekhimchuk: Таких компаний - 9 из каждых 10. To Jurii: Два вопроса: 1. Можно ли агрегировать по одним иерархиям в кубе, а на отчетах отображать другие ? 2. Если не секрет, как вы укладывате балансы и ПУ (со всеми их далеко идущими расшифровкми) в сбалансированные иерархии ? P.S. При условии, что иерархии могут менятся каждый месяц - пользователь справится ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2003, 12:43 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
2 LNekhimchuk К сожалению вынужден согласиться с olegk. Не надо привязыаться к номенклатуре, номенклатура может и не часто меняются, но модели анализа и группировки меняются постоянно и некоторые аналитики меняли бы иерархии каждый день, если бы технологии позволяли. А есть еще вопрос остлеживания истории изменения иерархий и пересчет в зависимости от прошлого состояния иерархии и текущего. К примеру, переместили мы товар из одной группы в другую, а потом стало интересно, какие были бы прибыли по группе, если бы этот товар остался в старой группе? Или как изменилась бы каритна прибыли по группам в прошлом году, если бы этот товар еще в прошлом году стоял в этой новой группе? В общем, вопросов от аналитиков больше, чем могут дать ответов технологии. Кстати, кто нибудь сталкивался с отслеживанием изменения иерархии и если сталкивался, то как это решалось? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2003, 13:52 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
To Birkhoff: Если взять например какую нибудь оргштаную структуру очень большого предприятия Для крупных внедрений обычно проводятся обследования, и если имеется 15-уровневая иерархия, важная для отчетов и анализа, под нее сразу можно следать большой запас - например 25 колонок, 10 из которых пока будут незаполнены. Но даже и в более простых случаях углубления иерархий происходят. Например маркетолог или аналитик рынка может легко собрать... Методология внедрения ПО Cognos состоит в том чтобы обучать не только технических специалистов, но и опытных пользователей/аналитиков, благо продвинутые визуальные средства позволяют за 1-2 дня научить создавать кубы даже человека, имеющего минимальный опыт общения с компьютером. После обучения маркетолог сможет пользоваться как общими кубами, так и играться, создавая свои кубы. To Birkhoff & Дядя Федор: Это правильно. И чем хорош Express, так тем? что там можно написать один скрипт, который всегда отреагирует на появление новых групп. Т.к. измерения parent-child. Если они реализованы как Папик-Чайлд - сами попадут. делать ничего не надо А агрегаты в кубе при изменении иерархии в учетной системе пересчитываются автоматически в фоновом режиме? Или для parent-child агрегаты не создаются и все считается налету? И еще интересный вопрос: в средних и крупных компаниях, имеющих мощные глубокие несбалансированные иерархии (десятки/сотни тысяч позиций номенклатуры или сотрудников) при создании кубов в Cognos PowerPlay партиции создаются именно на основе таких измерений (одна подгруппа товара - в одну партицию, две подподгруппы другой подгруппы - еще 2 партиции и т.п.). Оптимизация партиций позволяет поддерживать производительность на высоком уровне. А измерения parent-child в OE и MS AS могут служить основой для разбиения куба на партиции? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2003, 14:30 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
2 Jurii Для крупных внедрений обычно проводятся обследования, и если имеется 15-уровневая иерархия, важная для отчетов и анализа, под нее сразу можно следать большой запас - например 25 колонок, 10 из которых пока будут незаполнены. Интересный подход, может быть он и работает, жаль только что ограничения все равно есть. И как отразится на производительности существование 25 уровней иерархии? После обучения маркетолог сможет пользоваться как общими кубами, так и играться, создавая свои кубы. Может быть вам везло с клиентами, но по моим наблюдениям таких маркетологов, которые могут подняться в своем сознании до степеней абстракции, позволяющих создавать свои кубы, где то 1 на каждые 10. Иными словами, большая часть - просто потребители готовых отчетов, в лучшем случае способные поменять фильтр. А те, которые готовы строить свои кубы обычно и SQL написать могут. Не всегда конечно, но часто. А агрегаты в кубе при изменении иерархии в учетной системе пересчитываются автоматически в фоновом режиме? Или для parent-child агрегаты не создаются и все считается налету После изменения структуры иерархии нужно перезапустить процедуру агрегации, но обычно это происходит сразу после загрузки новой порции данных, поэтому для пользователей незаметно. Но сразу получить результат изменения иерархии нельзя. А измерения parent-child в OE и MS AS могут служить основой для разбиения куба на партиции? Не знаю как в MS AS, а в Express нет понятия партиций. Оно есть в RDBMS ORACLE. В экспрессе можно осуществить партиционирование руками. То есть создать две базы, хранящиеся на разных дисках, а потом виртуально их объединить формулой. Правда я сам этого не делал именно в таком виде. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2003, 14:58 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
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-клиента перестраивалась иерархия. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2003, 15:03 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
2 Jurii В Cognos PowerPlay создатель куба не может указать, что эту иерархию - агрегировать, а другую - нет (OLAP-движок позволяет проводить агрегацию по всем измерениям и показателям А как быть с неаддитивными данными? Они все равно будут суммироваться? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2003, 15:11 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
2Юра Юра я никогда не соглашусь с доводом типа "моя система не умеет поддерживать функцию X, значит функция X неправильная для использования в бизнесе". Это бизнес решает нужна ему функция X или нет, а инструментарий должен быть просто богат функционалом и достаточно универсален. Parent-Child очень даже запросто менятся в весьма формальных организациях. Работая с MS Project Pro я постоянно имею дело иерархиями (RBS, WBS, PBS,SBS и др.). Так вот, формально обычно определяется регламентом только верхние уровни всех Breakdown Structure, в самом низу менеджеры могут использовать свои группировки. Это нормально и очень полезно. В некоторых случаях, например для оптимизаций графиков работ на скилам людей и оборудования это просто необходимо. Замечу, MS Project Pro умеет с такими уровнями работать и без Parent-Child, но для этого Microsoft пришлось купить продукт Project Vision, который автоматически переделывает структуры DWH и OLAP-кубов в случае изменений в структурах BS и Outlines. В противном случае это была бы тяжелая ручная работа, как сейчас в Cognos. В EPM-системах нормально иметь по 20-30 уровней иерархической детализации задач, ресурсов и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2003, 15:45 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
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 эффективно работает с оборотными агрегатами и тормозов не наблюдается как на вершине иерархии, так и при раскрытии до листьев. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2003, 16:06 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
Владимир, parent-child - это один из важных аспектов, по которому интересно сравнивать OLAP-сервера, но он не единственный. Разные OLAP-сервера работают с parent-child по-разному, и где-то выигрывает один подход (в простых случаях), а где-то - другой (в сложных случаях и/или при больших объемах данных). В противном случае это была бы тяжелая ручная работа, как сейчас в Cognos Иногда у моих клиентов вообще нет parent-child, иногда есть - но с небольшим кол-вом уровней (или когда уровней много, но таких иерархий всего 1-2). Более сложные случаи мне не встречались, но если встретятся - их можно решать либо так же, с помощью алиасов визуальными средствами (это я не считаю тяжелой работой), либо написать универсальную функцию для СУБД, в которую передавать такие параметры как прогнозируемое кол-во уровней иерархии с запасом, ID товара (или контрагента, филиала и т.п.) и номер колонки, и эта функция сделает мне нужное количество колонок, часть из которых будут пустыми, а часть - заполненными. Еще стоит упомянуть, что некоторые мои клиенты не придерживаются моей методологии а используют свою, создавая в Cognos PowerPlay иерархические измерения не визуальными средствами, а с помощью программы на VB, использующей результаты рекурсивного запроса к реляционной БД их учетной системы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2003, 16:23 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
2 Jurii Я спросил о том, можно ли вообще заставить Cognos не обсчитывать суммы по неаддитивным измерениям? Например не суммировать остатки разных товаров по номенклатуре? Или суммирование всегда происходит принудительно и пользователь сам должен отдавать себе отчет в том, что аддитивно, а что нет? Еще стоит упомянуть, что некоторые мои клиенты не придерживаются моей методологии а используют свою Вот гады! :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2003, 16:39 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
2Юра. Вопрос в том, что MS AS поддерживает и эмуляцию P-C как в Cognos и сам P-C + несбалансир. иеррахии в натуральном виде. Для задач в области управления проектами MS имеет специальное автоматическое средство для генерации эмуляции P-C через регулярное измерение. К слову, ты так и не заметил основной недостаток P-C в MS AS и Oracle. Это усложнение создания MOLAP-агрегатов. Oracle вообще их не создает, а MS AS создает только в вершине и после SP2 еще умеет делать soft-агрегаты. Реально это работает с хорошей производительностью только P-C измерениях с небольшим количество членов (20 тыс - 50 тыс, полностью гарантированно до 5 тыс.). Microsoft сам отказался от P-C в MS Project Pro в виду более сильной схемы агрегации регулярных измерений. Такие портфели проектов на MS Project как в Merrill-Lynch (2000 проектов, 8000 сотрудников, 1 млн. задач и т.д.) просядут в OLAP-отчетах на P-C. Вот за этим и применяется подход с автогенератором структуры P-C в регулярные измерения (Project Vision). Таких генераторов ни у Cognos ни у Oracle нет. Мораль такова. Для P-C решение MS самое сильное, это без рекламы. Просто факт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2003, 16:39 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
2 Владимир К слову, ты так и не заметил основной недостаток P-C в MS AS и Oracle. Это усложнение создания MOLAP-агрегатов. Oracle вообще их не создает, Это с чего это вы взяли? Если из моего пример с 30 измерениями, то проблема в том, что он просто подвисает на этапе создания агрегатов, а не не создает в принципе. А если измерений немного - то прекрасно создает, куда же без агрегатов? Причем легко работает например на иерархиях из 300000 членов. Мораль такова. Для P-C решение MS самое сильное, это без рекламы. Просто факт. Движок в чем-то мощнее. Конкретно в этом аспекте. Но движок это еще не решение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2003, 16:44 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
Движок в чем-то мощнее. Конкретно в этом аспекте. Но движок это еще не решение. См. например про движек MS AS в соседнем топике про ускорение MDX :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2003, 17:11 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
Владимир, Вопрос в том, что MS AS поддерживает и эмуляцию P-C как в Cognos А умеет ли при этом MS AS схлопывать пустые уровни иерархии, чтобы по одной ветви группа сразу раскрывалась в товар, а по другой - в подгруппу и лишь затем - в товар? К слову, ты так и не заметил основной недостаток P-C в MS AS и Oracle. Это усложнение создания MOLAP-агрегатов. Oracle вообще их не создает, а MS AS создает только в вершине и после SP2 еще умеет делать soft-агрегаты. Я не могу себя назвать экспертом по MS AS и OE. Но в моих постингах такое предположение высказывалось (что parent-child MS AS и OE негативно сказываются на их производительности). Об основных недостатках продукта должен говорить эксперт по этому продукту. Если же кто-нибудь из клиентов будет введен в заблуждение и обнаружит слабые стороны продукта эмпирическим путем - то это негативно скажется на репутации экспертов... Реально это работает с хорошей производительностью только P-C измерениях с небольшим количество членов (20 тыс - 50 тыс, полностью гарантированно до 5 тыс.). Ну тогда понятно, почему некоторые участники форума жалуются на производительность при раскрытии дерева иерархии в MS AS. Теперь они по крайней мере увидят альтернативу parent-child - в переходе к эмулированному parent-child. Таким образом нужно отфильтровать базар в тех постингах, где упомянуты крупные компании, имеющие глубокие иерархии - там то побольше 5000 листьев :) Для них и Cognos и MS AS будут решать задачу создания иерархического измерения одинаково. Вот за этим и применяется подход с автогенератором структуры P-C в регулярные измерения (Project Vision). Не мог бы ты привести примерчик, как из таблицы с 3 колонками (ID, NAME, PARENT_ID) получается регулярное измерение. Создаются ли несколько колонок как в Cognos, или из таблицы сразу создаются уровни иерархии куба? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2003, 18:56 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
А умеет ли при этом MS AS схлопывать пустые уровни иерархии, чтобы по одной ветви группа сразу раскрывалась в товар, а по другой - в подгруппу и лишь затем - в товар? Ответ прост: умеет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2003, 20:14 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
2 DmitryS Вопрос был, по моему, но о настоящих P-C, а об эмулированных. На эмулированных тоже умеет? И вообще как эта эмуляция реализована? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2003, 20:20 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
Юра, ты все-таки не эксперт в Cognos, а сейл. Иначе бы ты спокойно признавал недостатки продукта, в том числе P-C. К слову, коллеги. Важное наблюдение. Создавая свои кубы для MS Project, я не обратил внимание на последнее развитие встроенной системы. Сейчас посмотрел и увидел, что они после SP все переделали. Поскольку после SP2 в MS AS измерения P-C во многом "залетали", Microsoft переделал практически все измерения в MS Project на P-C. Вот такъ. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.08.2003, 04:27 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
К слову, мои тесты показывают, что "транслятор в регулярные измерения" более быстр. Но это теперь библиотека на DSO, которая есть не у всех. :) Трансляция делается просто, P-C разворачивается в регулярное дерево с уровнями по P-C. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.08.2003, 04:31 |
|
||
|
OLAP в Axapta
|
|||
|---|---|---|---|
|
#18+
Владимир, Юра, ты все-таки не эксперт в Cognos, а сейл. Иначе бы ты спокойно признавал недостатки продукта, в том числе P-C. Думаю те, кто читают мои постинги, видят, что там больше интересной и содержательной информации, чем похожей на PR. Так что все-таки я в первую очередь - эксперт. Я упоминал, что в Cognos нет в чистом виде P-C, и говорил, что способ обхождения этой ситуации с моей точки зрения несложен (чем это не спокойное признание недостатка?). Кроме этого я делал вывод, что в некоторых простых ситуациях это можно назвать слабостью Cognos, а в более сложных ситуациях - это уже преимущество Cognos, его гибкость, по сравнению с конкурентами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.08.2003, 13:03 |
|
||
|
|

start [/forum/topic.php?all=1&fid=49&tid=1873200]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
179ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
115ms |
get tp. blocked users: |
1ms |
| others: | 12ms |
| total: | 349ms |

| 0 / 0 |
