Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
2 Kaniovski: насколько решение на основе OLAP будет работать быстрее решения через BO если будут выводиться одинаковые данные? Можно сказать, что среднее время генерации отчетов на основе OLAP - не более 5 секунд (если реально используется OLAP). А время генерации отчета на основе прямых запросов зависит от многих факторов - объемы данных, сложность запроса, индексированность БД и т.д. Если под каждый отчет BO делать таблицу с агрегатами - тогда скорость будет хорошая (тяжело правда под каждый отчет изменять структуру ХД). Если использовать MS AS - то тоже скорость хорошая, однако по мнению г-на AAron этот подход фактически нельзя использовать ( BO кривовато поддерживает его, и далеко не вся функциональность reporting'a работает правильно (если работает вообще). ) 2 ......... : Могу только присоединиться к AAron-у. И повторить, что ВО - это по большому счету только СПОСОБ получения данных. Да - мощный, да - продвинутый, да - масштабируемый, "относительно красивый внешне" и т.п., но всего лишь СПОСОБ. Он генерирует SQL запрос и получает данные. А уже скорость работы запроса будет определяться СУГУБО скоростью работы СУБД/архитектурой Юниверса/мощностью сервера/пропускной способностью сети.... И еще у ВО есть одно достоинство - он "user-friendly". Т.е. конечный пользователь может ничего не знать ни о базе, ни о SQL-е... - и при этом иметь возможность получать нужные ему данные :) Блин, сомнительно для меня что BO - user-friendly... Из реальных внедрений о которых мне известно - все отчеты на BO делают профессиональные ИТ-специалисты а пользователи запускают только стандартные отчеты. Сами посудите, у BO нет возможности вставлять в отчет строки, для этого надо делать юнион на уровне таблиц хранилища данных, непредсказуемо время отклика на запрос пользователя - если пользователь сделает сложный вычисляемый показатель, то результат будет не за 5 секунд, а неизвестно когда... А что касается стандартной отчетности, то в BO все более-менее OK, поэтому в мировых рейтингах он не так много проигрывает системе Cognos :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 14:27 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
ребята, а кто в курсе BO или Cognos способны выводить информацию из OLAP накладывая фильтрацию на первичные данные, то есть данные из самого хранилища? Например у меня есть желание получить отчет за год по месяцам за все продажи суммы каждой из которых находятся в нужном мне диапазоне. Эти диапазоны могут быть любыми для каждого отчета. И если такая возможность имеется, то насколько дольше он будет считаться? как вообще это будет происходить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 14:44 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Jurii А что касается стандартной отчетности, то в BO все более-менее OK, поэтому в мировых рейтингах он не так много проигрывает системе Cognos :) Ссылочку на независимый источник, если не трудно.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 14:47 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
JuriiБлин, сомнительно для меня что BO - user-friendly... Из реальных внедрений о которых мне известно - все отчеты на BO делают профессиональные ИТ-специалисты а пользователи запускают только стандартные отчеты. Сами посудите, у BO нет возможности вставлять в отчет строки, для этого надо делать юнион на уровне таблиц хранилища данных, непредсказуемо время отклика на запрос пользователя - если пользователь сделает сложный вычисляемый показатель, то результат будет не за 5 секунд, а неизвестно когда... А что касается стандартной отчетности, то в BO все более-менее OK, поэтому в мировых рейтингах он не так много проигрывает системе Cognos :) Если бы Вы только знали, насколько "профессиональные", насколько "ИТ" и насколько "специалисты" у нас эти отчеты ваяют!!!!! ;))))))))))))))) Иногда группа ученых обезьян умнее. Но самое удивительное, что даже несмотря на это нужные им данные они получают!!! Пусть иногда долго и временами криво, но получают. Профессиональные ИТ-специалисты должны разрабатывать базу, к которой БО обращается. И строить Юниверс в БО, через который это обращение идет. А сам продукт на уровне пользователя достаточно прост. Вставлять строку? не спорю.... вот только при обработке ста тысяч строк от одной "дополнительной" Вам толку скорее всего не будет... А вообще можете сохранить отчет в Excel - и уже форматировать там. Может, это не настолько удобно и "не красиво", но в конце концов работает... И ответа на сверсложное вычисление через 5 секунд и на терабайтной базе ждать глуповато, Вы не находите? ;) Если кому-то нужна ссылка и тестовая версия - поищите в Яндексе... ВО в России представляют несколько фирм (может, и на тестирование взять удастся), но не хочу давать их названий, дабы не засорять ветку постоянной рекламой (уж извините, но камень в огорот Когноса ;) ). Из описаний могу разве что своим мнением поделиться... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 15:04 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Поделитесь! Что именно в Cognos вас не устраивает? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 15:10 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
KaniovskiПоделитесь! Что именно в Cognos вас не устраивает? Вы уж извините, но про Когнос ВООБЩЕ сказать ничего не смогу - не работал с ним. (Конкретно на этом сайте меня слегка веселят постоянные попытки Когнос прорекламировать - хотя я и понимаю, что человек торгует продуктом, это его работа...) Могу поделиться только опытом работы с ВО. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 15:27 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Отлично!!! Поделитесь опятом работы с BO. Я еще не определился что лучше. Повторю свой вопрос... BO способны выводить информацию из OLAP накладывая фильтрацию на первичные данные, то есть данные из самого хранилища? Например у меня есть желание получить отчет за год по месяцам за все продажи суммы каждой из которых находятся в нужном мне диапазоне. Эти диапазоны могут быть любыми для каждого отчета. И если такая возможность имеется, то насколько дольше он будет считаться? как вообще это будет происходить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 15:32 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
KaniovskiОтлично!!! Поделитесь опятом работы с BO. Я еще не определился что лучше. Повторю свой вопрос... BO способны выводить информацию из OLAP накладывая фильтрацию на первичные данные, то есть данные из самого хранилища? Например у меня есть желание получить отчет за год по месяцам за все продажи суммы каждой из которых находятся в нужном мне диапазоне. Эти диапазоны могут быть любыми для каждого отчета. И если такая возможность имеется, то насколько дольше он будет считаться? как вообще это будет происходить? В почте ответ поищите. Извините, но почту я просматриваю чаще, чем сайт - поэтому отвечу быстрее, если что.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 15:53 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
2 Kaniovski: ребята, а кто в курсе BO или Cognos способны выводить информацию из OLAP накладывая фильтрацию на первичные данные, то есть данные из самого хранилища? Например у меня есть желание получить отчет за год по месяцам за все продажи суммы каждой из которых находятся в нужном мне диапазоне. Эти диапазоны могут быть любыми для каждого отчета. И если такая возможность имеется, то насколько дольше он будет считаться? как вообще это будет происходить? Как я понимаю, на практике BO не выводит информацию из OLAP (если верить г-ну AAron). Что касается Cognos, то есть следующий подход: при проектировании OLAP-куба сделать вычисляемое измерение, элементы которого будут отображать Ваши диапазоны, причем надо сделать много маленьких диапазончиков (с шагом 1 доллар). Тогда в отчете Cognos Вы легко сможете отфильтровать данные по любому диапазону, сложив его из маленьких диапазончиков. Понятна ли идея? В этом подходе плюсом является то, что не пострадает производительность, так как фундаментом служит OLAP. 2 Bormoglot: А что касается стандартной отчетности, то в BO все более-менее OK, поэтому в мировых рейтингах он не так много проигрывает системе Cognos :) Ссылочку на независимый источник, если не трудно.... Вот например ссылка на отчет Gartner, где Cognos признан лучшей в мире аналитической платформой: http://mediaproducts.gartner.com/reprints/cognos/vol2/article2/article2.html 2 ......... : Если бы Вы только знали, насколько "профессиональные", насколько "ИТ" и насколько "специалисты" у нас эти отчеты ваяют!!!!! Можете ли привести название Вашей компании? Например если Вы из компании Терн и Ваши маркетологи анализируют Вашу клиентскую базу, то это не терабайтные, и даже не гигабайтные объемы данных... Вставлять строку? не спорю.... вот только при обработке ста тысяч строк от одной "дополнительной" Вам толку скорее всего не будет... При чем тут 100 тысяч строк? Обрабатывать можно хоть миллиард строк, но в отчете все зачастую помещается на 1 лист. Например, смотрим мы кто из крупных клиентов прошлого года стал хуже покупать в этом году. Увидели что кто-то стал покупать в 2 раза меньше, хотим эту строку раскрыть в товары и услуги, чтобы увидеть, что именно из ходовых товаров этого года этот клиент стал покупать меньше. Это типичный аналитический вопрос с двумя подзапросами, требующий гибкости от OLAP-клиента. В BO такие вещи сделать сложно, а фактически для пользователей - невозможно. А вообще можете сохранить отчет в Excel - и уже форматировать там. Может, это не настолько удобно и "не красиво", но в конце концов работает... Ну никто и не спорит, просто придется довольно много времени тратить на постоянные выгрузки в Excel и на переформатирования... И ответа на сверсложное вычисление через 5 секунд и на терабайтной базе ждать глуповато, Вы не находите? ;) Терабайтную базу можно залить в компактный OLAP-куб, и в среднем 5-секундный отклик там останется. дабы не засорять ветку постоянной рекламой (уж извините, но камень в огорот Когноса Интересно, какая связь между рекламой и Когносом? На этом сайте рекламируется Microsoft, это понятно, но рекламных предложений или рекламных банеров по Когносу - никогда не было. Поделитесь! Что именно в Cognos вас не устраивает? Вы уж извините, но про Когнос ВООБЩЕ сказать ничего не смогу - не работал с ним. Честный, хотя и немного уклончивый ответ... :) на этом сайте меня слегка веселят постоянные попытки Когнос прорекламировать Было бы интересно узнать где же на этом сайте такая реклама... :) А я вот в свою очередь понять не могу, почему еще кто-то интересуется и обсуждает BO, когда по стоимости он дороже чем Cognos, а по функциональности - проигрывает Когносу не имея OLAP (при этом репортинговая функциональность BO и Cognos примерно сопоставима)... Вот тех кто сравнивает MS SQL Server и Oracle понять можно - у каждой из этих СУБД есть свои плюсы и минусы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 16:54 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
согласен с Jurii по поводу того что на сайте действительно нет навязчивой рекламы Cognos. Вообще тема была открыта не для того чтобы прорекламировать то или иное решение, а для того чтобы разобраться в основах проблемы. Лично я получил много полезной информации по заданным вопросам. Всем отвечавшим большое спасибо! когда будут еще вопросы, буду задавать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 17:09 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Jurii2 ......... : Если бы Вы только знали, насколько "профессиональные", насколько "ИТ" и насколько "специалисты" у нас эти отчеты ваяют!!!!! Можете ли привести название Вашей компании? Например если Вы из компании Терн и Ваши маркетологи анализируют Вашу клиентскую базу, то это не терабайтные, и даже не гигабайтные объемы данных... Вставлять строку? не спорю.... вот только при обработке ста тысяч строк от одной "дополнительной" Вам толку скорее всего не будет... При чем тут 100 тысяч строк? Обрабатывать можно хоть миллиард строк, но в отчете все зачастую помещается на 1 лист. Например, смотрим мы кто из крупных клиентов прошлого года стал хуже покупать в этом году. Увидели что кто-то стал покупать в 2 раза меньше, хотим эту строку раскрыть в товары и услуги, чтобы увидеть, что именно из ходовых товаров этого года этот клиент стал покупать меньше. Это типичный аналитический вопрос с двумя подзапросами, требующий гибкости от OLAP-клиента. В BO такие вещи сделать сложно, а фактически для пользователей - невозможно. А вообще можете сохранить отчет в Excel - и уже форматировать там. Может, это не настолько удобно и "не красиво", но в конце концов работает... Ну никто и не спорит, просто придется довольно много времени тратить на постоянные выгрузки в Excel и на переформатирования... И ответа на сверсложное вычисление через 5 секунд и на терабайтной базе ждать глуповато, Вы не находите? ;) Терабайтную базу можно залить в компактный OLAP-куб, и в среднем 5-секундный отклик там останется. дабы не засорять ветку постоянной рекламой (уж извините, но камень в огорот Когноса Интересно, какая связь между рекламой и Когносом? На этом сайте рекламируется Microsoft, это понятно, но рекламных предложений или рекламных банеров по Когносу - никогда не было. Поделитесь! Что именно в Cognos вас не устраивает? Вы уж извините, но про Когнос ВООБЩЕ сказать ничего не смогу - не работал с ним. Честный, хотя и немного уклончивый ответ... :) 1. Я не думаю, что мне стоит тут приводить название своей компании. Но не Терн, честное слово. Смысл фразы про "непрофессионалов" был в том, что у нас ВО вполне нормально используют люди, зачастую просто фантастически далекие от каких-либо информационных технологий... 2. По добавлению строк - я только сказал, что это возможно, и привел способ. Не более того. 3. Ну если провести достаточно хорошую предварительную подготовку данных - то и 5 секунд будет много! Вопрос в том, до какой степени данные удастся в этот куб "ужать". Собственно, именно это и определит скорость работы. 4. Ну не будем спорить. Приношу свои извинения. Просто я несколько раз заглядывал в эту ветку - и почти всегда натыкался на то, что Вы сводите разговор к тому, какая хорошая система Когнос. Это Ваше право, повторюсь еще раз. Особенно если мнение искренне. Может, это я просто так неудачно попадал, что у меня неверное мнение сложилось. В общем еще раз скажу, что не хотел лично Вас обидеть. 5. Я правда никогда не работал с Когносом - потому и не стал отвечать. Хоть уклончиво это, хоть нет. Но еще более неправильно было бы давать какие-либо отклики о системе, которую "вживую" ни разу не пробовал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 18:13 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
......4. Ну не будем спорить. Приношу свои извинения. Просто я несколько раз заглядывал в эту ветку - и почти всегда натыкался на то, что Вы сводите разговор к тому, какая хорошая система Когнос. Это Ваше право, повторюсь еще раз. Особенно если мнение искренне. Может, это я просто так неудачно попадал, что у меня неверное мнение сложилось. В общем еще раз скажу, что не хотел лично Вас обидеть. Под "этой веткой" я подразумевал сам раздел сайта OLAP и DWH, а не данную тему. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 18:15 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
авторКак я понимаю, на практике BO не выводит информацию из OLAP (если верить г-ну AAron). Возможно, я не удачно выразился. BO умеет работать с кубами MS AS2000. Для этого существует специальный инструмент. Называется BO OLAP intelligence. Там можно создавать отчеты, аналитик может крутить кубы, дриллить, создавать калькуляции, строить графики и т.п. OLAPi работает непосредственно с кубов в BO есть другие модули, например, Performance Manager, которые работают поверх универсов. И вот в этом случае - есть проблемы. В остальных - нет. Ладно, позже могу еще написать, сейчас времени нет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 18:53 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Есть опыт работы с Jurii'ем и с Cognos'ом но нет опыта работы с BO :( система действительно позволяет делать достаточно многие вещи, единственный минус, что сейчас замечен - большие требования к ресурсам машины и не 5-секундная скорость формирования отчетов с серьезной детализацией и не определенной заранее в модели OLAP-куба иерархией. Правда скорее это статистические отчеты, для которых олап системы не предназначены, но у нас пока нет другого инструмента, говорят в Cognos 8 такой инструмент появился. P.S. почти все было сделано своими руками с минимальным привлечением консультантов и внедренцев, т.е. я имею ввиду, что если б внедрять еще прямыми ручками-вероятно было б совсем неплохо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 12:25 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
GuestzЕсть опыт работы с Jurii'ем и с Cognos'ом но нет опыта работы с BO :( система действительно позволяет делать достаточно многие вещи, единственный минус, что сейчас замечен - большие требования к ресурсам машины и не 5-секундная скорость формирования отчетов с серьезной детализацией и не определенной заранее в модели OLAP-куба иерархией. Правда скорее это статистические отчеты, для которых олап системы не предназначены, но у нас пока нет другого инструмента, говорят в Cognos 8 такой инструмент появился. P.S. почти все было сделано своими руками с минимальным привлечением консультантов и внедренцев, т.е. я имею ввиду, что если б внедрять еще прямыми ручками-вероятно было б совсем неплохо. Так как у меня наоброт - есть опыт с ВО, но не с Когносом, то можно вопрос? Если не секрет - НАСКОЛЬКО большие требования к ресурсам? И к ресурсам чего - сервера БД или клиентского места, где отчет выводится? Это на любом отчете, или только на сложных? Про "5 секунд" вообще говорить не стоит, думаю... Если у тебя ЗАРАНЕЕ и ЧЕТКО определен набор данных для отображения - тогда да, его можно поместить в компактный куб и т.п. (хотя в такой ситуации можно зачастую и excel-ем обойтись...). Но если у этого куба потенциально может быть измерений двести (например, продажи с немеряно подробным справочником товаров/клиентов/..., в котором куча полей), то тогда работа с ним в некоторых случаях просто отвратительна... P.S. К сожалению, далеко не факт, что "внешние" консультанты и внедренцы имели бы прямые ручки :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 12:58 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
2 Глеб: система действительно позволяет делать достаточно многие вещи, единственный минус, что сейчас замечен - большие требования к ресурсам машины и не 5-секундная скорость формирования отчетов с серьезной детализацией и не определенной заранее в модели OLAP-куба иерархией. Правда скорее это статистические отчеты, для которых олап системы не предназначены, но у нас пока нет другого инструмента, говорят в Cognos 8 такой инструмент появился. Если в боковик отчета вывести несколько заводов, под заводы - несколько тысяч клиентов, под клиентов подтащить несколько тысяч товаров, то получится наиинтереснейший аналитический отчет :) Только потребуется вагон бумаги чтобы его распечатать... Такие отчеты визуализируют миллиарды ячеек, это большая и неоправданная нагрузка на OLAP-сервер. Глеб, такие отчеты нужно делать не в Cognos PowerPlay/Analysis Studio, а в Cognos Query/Report Studio. Эти отчеты не аналитические, и хорошо строятся обычным SQL с использованием индексов. P.S. И не вводи народ в заблуждение :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 13:27 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
2 Юрий Guest_3212 Глеб: система действительно позволяет делать достаточно многие вещи, единственный минус, что сейчас замечен - большие требования к ресурсам машины и не 5-секундная скорость формирования отчетов с серьезной детализацией и не определенной заранее в модели OLAP-куба иерархией. Правда скорее это статистические отчеты, для которых олап системы не предназначены, но у нас пока нет другого инструмента, говорят в Cognos 8 такой инструмент появился. Если в боковик отчета вывести несколько заводов, под заводы - несколько тысяч клиентов, под клиентов подтащить несколько тысяч товаров, то получится наиинтереснейший аналитический отчет :) Только потребуется вагон бумаги чтобы его распечатать... Такие отчеты визуализируют миллиарды ячеек, это большая и неоправданная нагрузка на OLAP-сервер. Глеб, такие отчеты нужно делать не в Cognos PowerPlay/Analysis Studio, а в Cognos Query/Report Studio. Эти отчеты не аналитические, и хорошо строятся обычным SQL с использованием индексов. P.S. И не вводи народ в заблуждение :) прошу прощения но это не Глеб :) согласен что вероятно так оно и должно быть (о чем и был написан PS, мы этот инструмент использовать не научились по понятным причинам), к сожалению наши юзеры очень любят именно такие отчеты (правда покупателей и номенклатуры с фактически ненулевыми значениями там несколько меньше и саму номенклатуру мы используем в кубах не всегда-общая же база - да такого порядка). ввиду того что каждому юзеру, как правило требуется своя иерархия и группировки вложенностей в отчетах - OLAP более удобен для их формирования чем использование просто SQL (возможно Cognos Query/Report Studio облегчает эту задачу но..... см. выше)... 2 ......... имеются ввиду требования к ресурсам машины где крутится сам куб. у нас стоит P4-3Ггц, 2Гб оперативки - на нем OLAP сервер. В случае, если начинается массовое юзанье кубов система может отказаться формировать отчеты. здесь я рассматриваю конечно же формирование таких отчетов как говорит Guest_321 :) на меньших объемах система крутится достаточно шустро. Общее количество измерений порядка 30, показателей так же, количество значений измерений (позиций контрагентов или номенклатуры)-порядка несколька тысяч, когда мы их перемножаем между собой и еще с заводами и др признаками-получается действительно внушительная картина:) В принципе я согласен что нужно юзать и др. функционал, т.к. ОЛАП не совсем подходит для таких задач. если честно я слабо представляю себе ОЛАП куб с двумя сотнями измерений... зачем он такой нужен, под какие задачи, можно пример??? продажа это в простом случае 3 показателя: количество, цена, сумма. Клиент и номенклатура - это 2 измерения, а где 200?? по поводу внешних консультантов совершенно откровенно могу сказать что ручки у них прямее чем у нас, знаний и опыта тоже больше :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 14:12 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Guestzесли честно я слабо представляю себе ОЛАП куб с двумя сотнями измерений... зачем он такой нужен, под какие задачи, можно пример??? продажа это в простом случае 3 показателя: количество, цена, сумма. Клиент и номенклатура - это 2 измерения, а где 200?? а если у клиента есть еще десяток параметров, то Вы просто делаете связь куба (продаж, например) со справочником клиентов, а не добавляете эти параметры в куб? Ну даже при таком подходе могу добавить навскидку еще пару измерений: где продано, кто продал... Кстати, при таком подходе полученный "куб" будет очень мало отличаться просто от куска таблицы продаж за период (разве что только у вас клиенты ненормальные и закупаются в день по 10 раз, требуя в каждом счете одной строкой выбивать по одной единице товара - тогда продажи удастся "свернуть"). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 14:55 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
2 ......... нет, конечно же мы все измерения вытягиваем в куб но у клиентов у нас на текущий момент, к сожалению только один параметр - Группа, у номенклатуры больше, но основных в пределах 10 (производитель, несколько вариантов групп, модель, вид и др.), неосновные как правило мы закладываем в иерархии внутри, если они необходимы. так же у продаж есть доп параметры-каналы сбыта, склад, центр ответственности, менеджер и др. сейчас у нас по причине разнородности исходных данных нет ряда измерений, которые хотелось бы иметь, но даже если взять их всеравно мне трудно представить 200... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 15:10 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Guestz2 ......... нет, конечно же мы все измерения вытягиваем в куб но у клиентов у нас на текущий момент, к сожалению только один параметр - Группа, у номенклатуры больше, но основных в пределах 10 (производитель, несколько вариантов групп, модель, вид и др.), неосновные как правило мы закладываем в иерархии внутри, если они необходимы. так же у продаж есть доп параметры-каналы сбыта, склад, центр ответственности, менеджер и др. сейчас у нас по причине разнородности исходных данных нет ряда измерений, которые хотелось бы иметь, но даже если взять их всеравно мне трудно представить 200... "К сожалению"?! Да это к Вашему счастью!!!! )))) А теперь представьте, скажем, какую-либо торговую сеть. В которой клиенты формально прикреплены к одному региону, но могут закупаться в другом (а зарегистрированы, например, в третьем)... При этом клиент закреплен за каким-либо сотрудником (своего региона), но обслуживал его сделку другой сотрудник (другого региона). А если еще и менеджер проводит только предварительную подготовку, а непосредственно счет выписывает оператор, то это еще один параметр. Теперь по товарам... Пусть у Вас есть товар. У него наверняка есть товарная группа. Плюс еще какая-нибудь ассортиментная группа. Может, еще целевая аудитория. Плюс, возможно, товар составной (ну предположим, та же шоколадка может попадать и в категорию "белый шоколад", и в категорию "темный шоколад", если она "полосатая"... А если она "полосатая", да еще и с орехами?! А если и с фундуком, и с арахисом?! ;) Кстати - это просто был "отвлеченный пример" - не надо придираться, ок?). И прочая фигня. Итого получаем, что анализировать продажи газа - это одно, но анализировать продажи какой-либо "мелочевки" - совсем другое... В общем, итого может набежать как раз измерений под пару сотен. И прикол в том, что реально в 90% отчетов из них используется наверное половина, но остальные 10% МОГУТ потребовать и остальные параметры. Вот и получается, что куб придется строить полный. А если еще и неизвестно заранее, по какому периоду будут построены те же отчеты... Итого получим, что "якобы свернутый" куб будет мало отличаться от исходной таблицы, только полей там будет до .... Кстати, удобство ВО в том, что он вытянет не все 200 измерений, а только те, которые выбраны в отчете :) Вот из-за такой фигни лично у меня и сделано так, что ВО обращается не к кубам, а непосредственно к базе... Был бы очень рад, если бы мне удалось это дело сворачивать в кубы, но, видно, пока не судьба... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 15:36 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
2 ............ Да... я понял Вас :-) полагаю в таком случае это действительно возможно... а наше счастье может быть и счастье но до поры до времени, т.к. периодически со стороны пользователей появляются заявления о малом количестве измерений, спасают же нас от этого наши доблестные коллеги которые вот уже как год "не могут" дать нам данные с той аналитикой которая необходима - в учетных системах есть и менеджеры и операторы и пункт назначения и многое остальное, просто к нам они не попадают - и вскоре боюсь это может стать "к сожалению".... а что касается 90% отчетов использующих 50% параметров могу предложить сделать второй куб и третий и 4-й если нужно... у нас их порядка 6-7: 2 полных с различной степенью детализации, а остальные рассчитаны на определенные специализированные отчеты - так мы распределяем нагрузку и ускоряем формирование ряда специализированных отчетов, т.к. часто определенная группа юзеров пользуется лишь 2-3 отчетами ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 17:57 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Guestz2 ............ Да... я понял Вас :-) полагаю в таком случае это действительно возможно... а наше счастье может быть и счастье но до поры до времени, т.к. периодически со стороны пользователей появляются заявления о малом количестве измерений, спасают же нас от этого наши доблестные коллеги которые вот уже как год "не могут" дать нам данные с той аналитикой которая необходима - в учетных системах есть и менеджеры и операторы и пункт назначения и многое остальное, просто к нам они не попадают - и вскоре боюсь это может стать "к сожалению".... а что касается 90% отчетов использующих 50% параметров могу предложить сделать второй куб и третий и 4-й если нужно... у нас их порядка 6-7: 2 полных с различной степенью детализации, а остальные рассчитаны на определенные специализированные отчеты - так мы распределяем нагрузку и ускоряем формирование ряда специализированных отчетов, т.к. часто определенная группа юзеров пользуется лишь 2-3 отчетами Ну, глядишь, когда Ваши коллеги "смогут" дать Вам данные, уже или Вас там не будет, или пользователям это не понадобится (как в сказке о Ходже Насреддине: "За 10 лет уж или ишак, или султан, или я точно сдохнем...") ;) Иметь 10 кубов - это хорошо, конечно... Но сложности начнутся, если пользователи вдруг построят отчет в одном кубе, а потом захотят его "расширить", добавив туда же поле, но из другого куба. :) Особенно если им это поле будет то нужно, то не нужно... К тому же при таком подходе от пользователей придется требовать "степень интеллекта выше среднего", то есть как минимум понимание того, что есть кубы, какие там данные, что мы за рамки кубов в отчете вышли, т.е. надо куб сменить и т.п.... Да и место на диске все-таки кубы требуют - боюсь, при десяти кубах лично нам придется диски как минимум удваивать :)) Поэтому пока что ВО и устраивает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 19:29 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
прошу прошения тороплюсь-поэтому кратко: у нас объем среднего куба 200-250Мб - не так и много (все конечно от кол-ва измерений зависит:) и вероятно при 200-это будет совсем другой вариант Cognos кстати позволяет частично решить вопрос методом дрилл-дауна из одного куба в другой (этой технологией правда мы тоже не пользовались, а уже наверное пора кстати - хорошо - вспомнил о том что такое есть! а по поводу интеллекта-это да... временами такая проблема возникает) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 19:48 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
2 Guestz: 2 Юрий прошу прощения но это не Глеб :) Вот как... Не узнал, богатым будете :) У меня есть предположения, но не хотелось бы гадать. Если хотите чтобы эффективность использования Cognos у вас повысилась - предлагаю пообщаться вне форума, обсудить ваши задачи. у нас стоит P4-3Ггц, 2Гб оперативки - на нем OLAP сервер. В случае, если начинается массовое юзанье кубов система может отказаться формировать отчеты. Если OLAP-куб сделать из файла Excel, в котором 100 строк и 10 колонок, то при желании можно убить и 32-процессорный сервер с 64 гигабайтами оперативной памяти (если сделать сто миллиардов строчек и скрыть нулевые строки)... Чтобы такого не происходило - нужно вести соответствующую работу с пользователями, повышать их квалификацию. сейчас у нас по причине разнородности исходных данных нет ряда измерений, которые хотелось бы иметь, но даже если взять их всеравно мне трудно представить 200... 200 измерений в кубе можно представить легко. Например проводите Вы анкетирование Ваших клиентов - каждый вопрос в анкете - это отдельное измерение, эти измерения позволят проводить очень интересные аналитические исследования, сегментацию. Кроме этого по-хорошему надо делать вычисляемые измерения (лояльный клиент или нет, долго он существует или новый клиент, покупает ли он дешевые товары или дорогие, и т.д.) - эти измерения опять таки ценны для выявления скрытых тенденций и зависимостей... Cognos позволяет делать вычисляемые измерения без необходимости программирования на SQL. 2 ............ : Кстати, удобство ВО в том, что он вытянет не все 200 измерений, а только те, которые выбраны в отчете :) У Cognos вообще то есть тоже самое, на основе такого же семантического слоя метаданных. Вот из-за такой фигни лично у меня и сделано так, что ВО обращается не к кубам, а непосредственно к базе... Был бы очень рад, если бы мне удалось это дело сворачивать в кубы, но, видно, пока не судьба... Я думаю это и есть главная слабая сторона BO. По-хорошему, нужно чтобы семантический слой частично состоял из обращения к кубам, а частично - из обращения к реляционным таблицам. Пользователи могут не задумываться над архитектурой решения, когда они будут делать отчеты по анализу продаж - будут задействоваться кубы, когда будут делать многостраничные отчеты - будет несильно нагружаться реляционный сервер. Но можно и все закачивать в кубы. Куб с 200 измерений - это вполне реально. Да и место на диске все-таки кубы требуют - боюсь, при десяти кубах лично нам придется диски как минимум удваивать :)) Поэтому пока что ВО и устраивает. Кубы занимают места на диске всяко меньше, чем распухающее реляционное хранилище данных, в котором под BO надо делать много таблиц с агрегатами. А уж про размер бэкапов и про скорость поднятия их в случае выхода из строя основного сервера я не говорю - мои знакомые из розничной сети как-то поднимали реляционное ХД 2 недели... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 21:41 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Jurii У Cognos вообще то есть тоже самое, на основе такого же семантического слоя метаданных. Я думаю это и есть главная слабая сторона BO. По-хорошему, нужно чтобы семантический слой частично состоял из обращения к кубам, а частично - из обращения к реляционным таблицам. Пользователи могут не задумываться над архитектурой решения, когда они будут делать отчеты по анализу продаж - будут задействоваться кубы, когда будут делать многостраничные отчеты - будет несильно нагружаться реляционный сервер. Но можно и все закачивать в кубы. Куб с 200 измерений - это вполне реально. Как называется программный продукт у Cognos все это реализующий, и где можно достать демо-версию продукта? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2006, 08:54 |
|
||
|
|

start [/forum/topic.php?fid=49&msg=33633410&tid=1870303]: |
0ms |
get settings: |
10ms |
get forum list: |
21ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
61ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
95ms |
get tp. blocked users: |
2ms |
| others: | 245ms |
| total: | 458ms |

| 0 / 0 |
