2 Виктор Сакович:

Если Cognos не имеет особого отношения к хранилищу данных, то тогда что Вы делаете в этом топике?

Я не говорю что Cognos нужно внедрять не делая при этом реляционного хранилища. Реляционное хранилище просто не является обязательным условием для успешного внедрения Cognos. И не стоит забывать, что OLAP-клиент работает поверх многомерной СУБД формата Cognos.

2 Глеб:

единственный конкурент у него это комплексное решение от компании Oracle.

Оригинальная оценка :) Представляю себе новый магический квадрант Gartner, в котором представлены только Cognos и Oracle...

если требуется только BI то подойдет и когнос.

Примечание редактора: Глеб имеет в виду, что если требуется еще и хранилище данных, то нужно использовать реляционную БД Oracle, что вполне логично.

пришел к однозначному выводу что надо брать все решение от одного поставщика, выбрал Оракл (особенно учитывая новые версии продуктов Оракл выходящих в 2007г.).

В рейтингах аналитическая функциональность Oracle не занимает высоких мест... Новые версии 2007 года ты уже видел, или только читал рекламу?
Ну ладно, пока это все слова, вот когда сделаешь прототип аналитической системы на Oracle BI - тогда посмотрим, стоящая это вещь или нет.

Цена сопровождения и развития конечного комплекса в составе BI, CPM и Portal будет на порядок меньше. Возврастает оперативность обработки и модификации комплекса, сужаются профили специалистов

Типа наймете студента-ораклиста, который за 300 долларов в месяц будет все поддерживать, и еще переведет вашу систему 1С на платформу Oracle :) На мой взгляд, РСУБД Oracle и Oracle BI - это разные технологии, задачи у них слишком разные, требуют даже разного уровня образования и опыта, и вряд ли хороший специалист по РСУБД будет одновременно хорошим специалистом по BI/CPM.

2 Андрей Прохоров:

Я считаю что в PowerPlay multiple write access is NOT needed. Закачка данных в OLAP-куб (в те или иные ячейки куба) не производится несколькими процессами одновременно.
Тогда какой смысл ссылаться на стандарт, которому Вы не считаете нужным следовать?

Стандарт FASMI не требует от OLAP-системы многопользовательского ввода данных в ячейки куба. Похоже Вы просто спутали термин OLAP с термином OLTP (в OLTP-системе действительно нужно поддерживать многопользовательский ввод данных).

2 pavelvp:

Не знаю как там и что делает Когнос, но исходные данные, характерные для таких задач, можно пожать раз в 10 (а то и больше) даже в "исходном" реляционном виде. Причём вместе с индексами. В экспериментах на реальных хранилищах (реляционных) мы получали 16-ти кратное сжатие.

У Cognos нет цели делать сжатие данных. Самое главное - гибкость и интерактивность при работе с отчетами, и высокая скорость отклика. При этом кубы получаются компактными, и это приятно.

Просто хотел сказать, что запихнуть 700М в 50М вполне реально при некоторых условиях...

А может ли Ваша СУБД помочь тем, у кого компьютер без CD ROM? То есть ужать 700 мегабайт в 1.3 мегабайт? (я имею в виду что размер 50 мегабайт - это не архивирование данных, а рабочее состояние с 5-секундным откликом на запрос, а 1.3 мегабайта - это архивированное состояние, из которого надо будет данные развернуть в рабочие 50 мегабайт).

2 Андрей Прохоров:

"SHARED means that the system implements all the security requirements for confidentiality (possibly down to cell level) and, if multiple write access is needed, concurrent update locking at an appropriate level."
После утверждения, что:
Cognos имеет функциональность OLAP и соответствует стандарту FASMI
Попытки аппелирования к тому, что авторы "стандарта" чего-то не понимают выглядят просто жалко.

Спасибо за цитату стандарта FASMI. Я не говорил, что авторы этого стандарта что-то не понимают, я говорил что Вы не понимаете разницу между OLAP и OLTP.
Cognos позволяет настраивать права доступа к ячейкам OLAP-куба (cell level). Далее в стандарте говорится, что "если требуется multiple write access и т.д.", но мы ведь понимаем что в OLAP/BI не требуется "multiple write access". В случае если бы авторы стандарта хотели обязать настоящие OLAP-сервера поддерживать "multiple write access", они бы написали, что "multiple write access is required".

2 MSTR_Fan:

Неужели узнали что Cognos имеет функциональность OLAP и соответствует стандарту FASMI ( http://www.olapreport.com/fasmi.htm )?
Серьезно? И как давно имеет и соответствует? Кстати, за какие заслуги OLAP Report были причислена к лику.. то есть к стандартизующим организациям?

Cognos соответствует стандарту FASMI как минимум с 1999 года, когда я впервые с ним познакомился... А что касается авторитета OLAPReport - если Вы их не уважаете - это Ваше право, но почему то их недешевые отчеты покупают...

По теме: Jurii, какое Вы решение предлагаете по вопросу в топике? Про OLAP я кажется понял, как строить хранилище?

Автор дискуссии говорил, что ему "Необходимо найти OLAP решение которое может бать основано на хранилищах или той или другой СУБД". На этот вопрос топика, по выбору OLAP-решения, я предлагаю посмотреть в сторону Cognos. А на Ваш вопрос по поводу того, как строить хранилище, могу сказать, что на это влияет выбор BI-инструментария. Если инструментарий является OLAP-продуктом, то за прототип хранилища можно взять хоть базу данных 1С, если не является - то надо строить хранилище по схеме звезда.

2 pavelvp:

Честно говоря, не совсем понял вопроса... Но пожать данные без потерь в 500 раз, в общем случае ИМХО невозможно :-)

Возможно что в общем случае - невозможно, но вот в частных случаях, как показывает практика, это вполне реально...

2 pavelvp:

У меня есть серьёзные сомнения насчёт "без потерь". Из этих 1.3М можно восстановить в полном объёме исходные 700?

Да, можно. Реально в моем примере это были 7 миллионов записей по 700 тысячам юр. лиц, и в архивном файле размером 1.3M помещался куб размером 50M, в котором без потери детализации хранились все 7 миллионов записей (700M).