Константин,

Ну, я же всё-таки правильно сказал, что проблема SCD для Вас была вновинку?
Я же не упрекаю Вас за это. Ну, не знал человек, что тут такого? Он и признался в этом сам.

Тот факт что я мало читал классиков по ХД (и сейчас не тороплюсь этого делать) не говорит о том, что я не сталкивался с медленно меняющимися измерениями на практике :) Я сталкивался с такими вещами при проектировании кубов на основе данных из ERP-систем и MRP-модулей (где имеет место вариативность структуры номенклатурных позиций во времени), при анализе выполнения заказов, когда статус заказа меняется во времени, и т.п. В каждом случае я не брался за книжки, а сам придумывал решение.

P.S. Видимо это старая привычка - когда я активно занимался шахматами, я мало читал теорию дебютов, и все придумывал прямо за шахматной доской...

Александр,

Я был на 99% уверен, что в PowerPlay нельзя решить задачу медленно меняющегося измерения

А сейчас Вы - на 100% уверены, что в PowerPlay нельзя решить эту задачу, или по прежнему - на 99%, или Вы поняли, что кое-какие способы в PowerPlay есть?


А для меня остался неясным вот какой вопрос:

По-моему, хранилище с помощью MOLAP создать нельзя, и лучшее его применение - это витрина поверх реляционного ХД

Если в учетной системе (OLTP) хранится в каком-либо виде история, что клиент Петров сначала жил в Москве, потом в Питере, потом в Магадане - то все хорошо - можно либо создать реляционное ХД и на него навесить MOLAP, либо навешивать MOLAP сразу на OLTP. Если же учетная система не хранит историю перемещений Петрова - то никакое реляционное ХД и никакой MOLAP не помогут. Вы согласны с этим?

Константин,

Достаточно постоянно делать "снимки" статусных атрибутов (таких как город клиента, например), тогда появляется возможность нормально захватывать исторические данные. Это называется CDC (changed data capture) и является одной из дисциплин построения хранилищ данных.

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

На мой взгляд, инкрементальное обновление MOLAP-куба - это нечто похожее на CDC, не так ли? В реляционном ХД хранить данные конечно надежнее, но я полагаю, что спроектировать и поддерживать такое ХД - трудоемко. Не знаете, есть ли в России реальные проекты по разработке ХД с учетом всех правил знаменитых теоретиков по ХД?

Константин,

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

Да, действительно, я предпочитаю делать проекты в более сжатые сроки и без необходимости программирования/рахработок ХД и т.п., для того чтобы аналитическая система была гарантированно высокого качества. Проблема грязных данных, с которыми я борюсь с помощью виртуальных вьюшек - имеет место, не все можно отловить. Но меня успокаивает, что степень скрытой загрязненности данных - обычно невысока, и по той причине, что пользователи проводят сверки своих старых отчетов с новыми отчетами из аналитической системы, нет риска, что аналитическая система увеличит степень загрязненности данных...
Так что наши пользователи принимают управленческие решения в условиях несколько недостаточной информации, и ROI этих проектов очень высок (так как в знаменателе не такая большая сумма затрат на проект). А на западе данные лучше очищают, но затраты на проект резко увеличиваются, и поэтому у них ROI не такой высокий.
Мне кажется, что наши пользователи лучше понимают, что такое правило Парето :)

Александр,

Для сравнения - более 50 атрибутов с справочнике продукции. Вам бы, Юрий, пришлось создавать 50 измерений.

Можно создать 5 измерений, в каждом из которых будет по 10 альтернативных Дрилл-Даунов. Да даже если делать 50 измерений - это тоже будет неплохо работать, куб от этого не распухнет, хотя в оси фильтра в OLAP-клиенте будет несколько строк...

И предупреждая Ваш ответ на счет использования Impromptu по OLTP системе, скажу, что в OLTP системе их как раз и нет. Большая их часть берется из внешних источников.

В Impromptu можно внешние источники подключать в виде хот-файлов, это будет выглядеть как будто в основной базе данных появились новые таблицы.
Но более интересный вариант - использовать возможность OLAP-сервера создавать многомерные кубы на основе нескольких источников данных разного формата. Например, часть атрибутов брать из основного источника данных, а часть - из внешних источников.

По-моему, в русском языке есть более четкое определение такого гарантированного качества данных - дешево и сердито :)

Дешево и сердито - это когда качество получаемых услуг и приобретаемых товаров невысокое. Я считаю, что качество подходов "без ХД" и "с ХД" соотносится не как "среднее и дешевое" и "высокое и дорогое", а как "высокое и дешевое" и "очень высокое и дорогое".

попробуйте организвать MLM сеть по продаже Cognos, у Вас должно получиться :)

Сети MLM - это когда основная цель - "впарить" товар. Что касается продвижения Cognos, то тут более уместен термин "развитие партнерской сети", поскольку продукты Cognos надо не только продавать, но и качественно внедрять.
У меня есть ряд партнеров, я продолжаю развивать партнерскую сеть, даже раздел отдельный имеется для этого на сайте http://cognos.narod.ru ... Так что спасибо за идею, но Ваша квалификация в области маркетинга примерно такая же, как и у меня, поэтому мы и мыслим примерно одинаково :)

To backfire:

Cto to trudno naiti logiku v vashem utverzhdenii. Visokoe kachestvo soverschenno ne sleduet iz szhatih srokov i otkaza ot DWH.

Я имею в виду, что когда аналитические модели/OLAP-кубы проектируются визуальными средствами - то качество будет высоким. Если же надо писать ручками MDX-выражения, SQL-запросы, создавать новую реляционную БД (ХД), и т.п. - то вступает в силу человеческий фактор, и качество из-за этого страдает.

Проблема грязных данных, с которыми я борюсь с помощью виртуальных вьюшек
Esli vi reshaete takei problemi na view, to u vas libo hardware nemeryannoe ili ob'emi DB malenkie.

Виртуальные вьюшки - это не объекты базы данных (не реальные вьюшки). Виртуальные вьюшки - это фактически SQL-запросы, создаваемые визуальными средствами в модуле Cognos Impromptu. В тех случаях когда данные очищать не нужно, виртуальная вьюшка создается путем простого выбора полей и создания производных вычисляемых полей на основе связанных таблиц. Когда же данные надо очищать - вычисления усложняются, в них включаются правила, в соответствии с которыми надо проводить очистку.
Я приводил примеры своих проектов - объемы там очень даже приличные, а железо - довольно скромное. Мощное железо не требуется, поскольку подкачка через виртуальные вьюшки в MOLAP-кубы PowerPlay производится малыми порциями (инкрементально). А в кубах, как известно, пользователи проводят многомерный интерактивный анализ и строят отчеты, не нагружая при этом реляционный сервер SQL-запросами.

Esli OLTP, sluzhaschaya istochnikom dannih, takaya zha ne namniogo starshe vashego OLAP-resheniya, to mozhet vi i pravi.
Esli zhe OLTP rodilas ranshe, chem upala Berlinskaya Stena (da, ne udivlyaetes, na Zapade eto ne islklyuchenie, a surovaya pravda zhizni), to vash podhod bez DWH voobsche ne proidet.

Я помню лето 1990 года, когда от Берлинской Стены остались последние камни (жаль правда что не догадался тогда взять себе один на память :)
Но все же это было давно... На территории бывшего СССР мало кто пользовался компьюьерными учетными системами, и еще меньшее их количество сохранилось до сих пор. Думаю не вызывает сомнений, что подавляющее большинство учетных систем в России и СНГ появились либо в начале/середине 90-х годов, либо позже - они работают либо на файл-серверных, либо на клиент-серверных реляционных базах данных, таких форматов как DBF, Paradox, FoxPro/VFP, MS SQL, Interbase, Oracle, DB2, Informix, Sybase, Progress. Ко всем этим источникам данных можно легко приконнектиться (либо через прямой драйвер, либо через ODBC) и спроектировать на их основе аналитические модели - перекачивать данные из них в отдетьную БД (ХД) вовсе не обязательно...

To Tulenev:

Это хорошо в том случае, если визуальные средства функционально эквивалентны выражениям языков MDX и SQL, в чем я сомневаюсь. Делая инструмент более доступным для бизнес-пользователя связываем руки профессиональным разработчикам - известная дилемма... А потеря качества из-за нехватки в визуальных средствах возможностей оптимизации производительности вас не смущает?

Если почитать множество задач, которые выносятся на этот форум пользователями MS AS, то практически все они легко решаются в PowerPlay визуальными средствами (хотя в PowerPlay нет языка MDX). О чем это может говорить? Я думаю дело в том, что Cognos выпустил этот OLAP-сервер примерно 14 лет назад, и за эти годы, прислушиваясь к требованиям миллионов конечных пользователей, в PowerPlay был заложен широчайший спектр функциональности для решения типичных задач. Это называется термином Completeness of Vision в отчетах компании Gartner, по которому Cognos - явный лидер ( http://mediaproducts.gartner.com/reprints/cognos/116968.html ).

Что касается "нехватки визуальных средств для оптимизации": например, задача по вычислению остатков на основе данных по приходам и расходам. Эта задача в PowerPlay решается легко и все летает (оптимизировать ничего не надо, так как визуальные средства оптимально используют агрегаты). А вот на MDX эту задачу можно решать по-разному, и надо долго оптимизировать, чтобы производительность достигла приличного уровня...

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

Разница между подходами Cognos и Microsoft в следующем: Cognos выпустил очень навороченный OLAP-сервер и заточил на него свои стандартные клиентские интерфейсы из среды Windows, Web и Excel. Microsoft сделал "универсальную" аналитическую платформу (что не менее трудоемко, чем сделать навороченные визуальные средства), чтобы партнеры Microsoft могли с нуля писать под нее клиентские приложения (что приводит к распылению ресурсов).

To backfire:

A kak vi postupaete v teh sluchayah, kogda OLTP sistema archiviruetsya (usekaetsya, obrezaetsya).
V OLTP sistemah vryad li kto hranit dannie o tranzakciyah bolee chem za 1-2 goda. V to vremya kak dlya analiza neredko ispolzuetsya glubina do 10 let.
Kak vi postupaete v teh sluchayah, esli vashu analiticheskuyu model nado modificirovat (dobavit dlya analiza novie fakti, atributi, ili izmereniya).
Chto vi delaete v takom sluchae, kogda v kube imeyutsya dannie po transakziyam, kotorih uzhe net v OLTP?

Такие ситуации встречались в моей практике. Иногда некое хранилище данных уже существовало, и к нему прикручивался инструментарий Cognos напрямую. Бывали случаи, когда в это хранилище закачивались уже несколько агрегированные данные, и не было желания хранить там данные с атомарным уровнем детализации (или хранилища вообще не было). Соответственно приходилось брать стриммерные ленточки, копировать с них на жесткий диск несколько кусков базы данных, настраивать виртуальную вьюшку, и несколько раз выполнять операцию инкрементальной подкачки данных в куб. Но все же, в большинстве случаев в учетной системе (в OLTP) хранились данные за всю историю, и такой проблемы просто не возникало.