Всем привет!

To ura:

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

На мой взгляд, то что у Вас есть - это по определению - хранилище данных (выделенная денормализованная БД).
Это типа есть у меня телевизор, коробка, когда включаю - на телевизоре загружается Windows, далее могу запускать MS Excel. Так вот, могу ли я работать в этом MS Excel, или для работы в Excel надо купить компьютер?

To backfire:

DWH надо, без него - только идеологи Когнос проповедуют :-)

:) Эксперты по Cognos (правда не все) стремятся к тому, чтобы ROI от внедрения Cognos было высоким. А если без причины предлагать делать хранилище данных - то и проект затянется, и стоимость его повысится, а трудоемкость повысится еще больше.
В то же время хочу отметить, что я не противник хранилищ данных - сейчас у меня идет несколько проектов, в которых первый этап -это создание DWH...

А что касается проблем с низкой производительностью при создании куба на основе OLTP - то видимо это актуально для MS AS, а для Cognos - не актуально. В Cognos делаются простые запросы к OLTP и есть мощный вычислительный инструментарий конструкторов выражений, которые нагружают OLAP-сервер. А если приходится переносить вычисления на уровень реляционного сервера - то используется инкременталка, и делается это по возможности ночью.

Так что видимо, г-н ura, у Вас 2 альтернативы - либо читать труды классиков по DWH, либо выбрать более гибкий OLAP-сервер (например Cognos PowerPlay :)

To ura:

Данные то как раз нормализованы, но не совсем в том виде, который подходит для DWH. Один пример - цены хранятся в разных валютах, а в документе имеется ссылка на таблицу курсов. Для этих преобразований и нужны вьюхи.

Эта типичная задача в Cognos решается через создание виртуальных вьюшек (выбрать таблицу продаж и курсов, сделать связь по идентификатору валюты и по дате - дата документа >= дата курса, ну и наложить фильтр агрегирования для отбора записей из справочников курсов валют с ближайшей меньшей датой) - то есть всего несколько кликов мышкой в конструкторе выражений. У MS AS нет модуля для создания виртуальных вьюшек, и поэтому приходится лезть в базу и создавать там объект - вьюшку...

Не думаю, что Cognos сможет преобразовать данные, полученные из MS SQL сервера, главным образом построить таблицу фактов, быстрее чем это сделает сам SQL сервер при помощи грамотного механизма, написанного грамотным разработчиком.

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

Дмитрий,

Юр, дело не в Когносе и не в МСе. Дело в том, что запросы при процессинге будут тормозить в СУБД. Одна из причин, почему стоит делать денормализованное хранилище.

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

To DmitryS:

Мы оба знаем, что инкременталка возможна не всегда

И также мы знаем, что инкременталка сложна при маленьких объемах данных (тогда можно хоть каждый час куб перепроцессить), а при больших объемах (например в рознице, телекоме и т.п.) она делается легко, так как там нет исправлений задним числом.

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

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

Не надо приписывать ASу недостатки, которых у него нет

OK, пусть у MS AS не будет недостатков :) Только вот функциональности для решения типичных задач в нем тоже маловато, о чем свидетельствуют многочисленные постинги на этом форуме...

По моим оценкам, разработка хранилища и ETL требует примерно в 4-5 раз больше времени, чем навешивание сверху самых навороченных кубов:-)

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

Дмитрий,

Юр, в оперативных системах практически всегда присутствуют удаления. Причём физические. Как ты их решишь инкременталкой?

Всегда есть какой-то закрытый период, в котором ничего не удаляют и не изменяют. Я делаю куб на конец этого закрытого периода и каждый раз подкачиваю инкрементально данные до текущей даты.

Согласись, что PowerPlay (как и AS) преимущественно предназначен не для оперативного репортинга.

Ну наверное, это все-таки OLAP-продукты, ведь есть еще и продукты класса Query & Reporting (Cognos Impromptu, ReportNet, BusinessObjects, Crystal, Actuate, Oracle Discoverer и т.п.), и они думаю лучше заточены на оперативность. Но супер-оперативность до минуты нужна не руководителям и менеджерам, а рядовым сотрудникам, для которых Business Intelligence внедряется редко. А оперативность до часа - это несложно для OLAP, хотя реально и это мало кому нужно - обычно хватает свежести данных по состоянию на конец вчерашнего дня.

И потому, если есть возможность и потребность делать качественную аналитику, то надо её делать

Я считаю, что не надо стремиться к 100-процентной максимизации качества аналитики - это и трудоемко, и дорого, и малореально. Пусть будет качество на уровне 99.9% :)