To Александр & Константин:

По правде говоря, я не эксперт-теоретик по теории SCD/медленно меняющихся измерений, и думаю большинство посетителей форума - тоже не эксперты в этой области. Поэтому было бы хорошо, если бы вы дали определение каждому из 3 типов SCD и привели бы примеры для каждого из типов.

Юрий, можно поподробнее, какие у PowerPlay есть возможности для организации медленно меняющихся измерений?

Я не говорю, что PowerPlay может помочь в любых ситуациях с SCD, поскольку не все они мне попадались на практике. На практике я встречаюсь с разными учетными (OLTP) системами, которые по-разному хранят информацию об изменениях. Обычно мне помогает либо создание виртуальной вьюшки в Impromptu, которая позволяет вытащить в кубы из базы OLTP данные по нужным правилам, либо я использую параметры, которыми можно играться на первой закладке свойств уровня иерархии измерения в модели куба в PowerPlay Transformer (уникальность, перемещение категории в другую ветвь иерархии, обновление названия категории, обновление описания категории и т.п.).

Я думаю, в том, что PowerPlay сможет поддерживать SCD 1 сомнений ни у кго нету? :)

Приведу пример. Есть справочник клиентов, в котором поверх старого названия клиента ввели новое. Идентификатор клиента не изменился. При этом в кубе PowerPlay пока хранится этот идентификатор и старое название. Я могу запустить процесс генерации категорий, в ходе которого старое название обновится на новое, и потом я обновлю куб (без необходимости перегенерации куба). Это приведет к тому что в кубе название клиента изменится на новое. Если же мы не хотим терять старое название, то думаю есть несколько вариантов - например сделать в кубе в этом измерении иерархию, и один и тот же идентификатор будет раскрываться в старое и новое название (это типа когда мы делаем уровень иерархии КОРПОРАЦИЯ, внутри которой могут быть компании Альфа и Бета, но мы знаем, что это одна и та же организация).

Если речь идёт об изменении не названия, а перепривязке к новому родителю
Однако, не очень понятно, как это связать со временем
Ну, и вопрос к Юрию (как стороннику решений без создания хранилищ и витрин данных) - как это реализовать без витрины данных?

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

По поводу SCD 2 вопрос к Юрию - как Вы считаете, можно ли сделать поддержку SCD 2 средствами PowerPlay или нет?
Если да, то как её реализовать в случае отсутствия хранилища или витрины данных?

Также прошу Вас привести пример исходных данных и результата, которого Вы хотите достичь.

To Константин:

Вот такая задачка. Как решать на PowerPlay?
Я примерно представляю, как решать её с помощью MOLAP, но, backfire прав в том, что задача требует предварительной работы с данными (создание хранилища или витрины данных).

Для начала приведу пример из жизни на тему анализа продаж через дистрибьюторов. В учетной системе (Аксапта) каждый документ по продажам содержит ссылку на стравичник дистрибьюторов (на тех кто продает). Кроме этого в документе есть ссылка на справочник клиентов (те кто покупают товары), и для каждого из клиентов задан один единственный дистрибьютор, который работает с этим клиентом. В идеале клиенты должны покупать только у "своих" дистрибьюторов, но реально бывают случаи, когда какой-либо дистрибьютор продает что-либо чужому клиенту.
Для анализа этих данных в PowerPlay было создано 2 измерения для дистрибьюторов - "Дистрибьютор по клиенту" и "Дистрибьютор фактический". Если вывести оба этих измерения в отчет (одно в строки, а другое в столбцы), мы увидим, какие дистрибьюторы продавали товары клиентам других дистрибьюторов.

Что касается Вашей задачки, то ее надо решать исходя из потребностей пользователей. Я бы предложил делать закачку в куб PowerPlay таким образом, чтобы наш клиент Петров встречался внутри кадждого из городов. То есть если в каждом городе он сделал лишь по одной покупке, то в куб закачаем 4 записи:

Год, Город, Клиент, Сумма
2000, Москва, Петров, 100
2001, Санкт-Петербург, Петров, 120
2002, Пермь, Петров, 30
2003, Воркута, Петров, 75

Другой вопрос, хранится ли в учетной системе информация, что Петров в такое-то время жил в таком-то городе (надеюсь хранится)...
В итоге Сумма для каждого города вычислится корректно.

To Константин:

Не понимаю, какое отношение это имеет к проблеме SCD. Мы обсуждаем только одно измерение.

Иногда бывает правильным включить клиентов внутрь их дистрибьюторов, и несмотря на то что SCD приведет к тому что связь будет многие ко многим - сумма по дистрибьюторам распределится правильно. При этом подсчет клиентов и ранжирование их по общей сумме закупок надо делать на основе отдельного измерения КЛИЕНТЫ.

А структура измерений какая при этом будет? ГОРОД-КЛИЕНТ?

Да, я именно это имел в виду.

Если даже хранится, то при переезде Петрова может потеряться информация о том, где он жил до переезда.
Так что, без хранилища будет сложно решить эту задачу.

Некоторые учетные системы поддерживают темпоральность (например в них можно при указании связи указать начальную и конечную дату действия связи), такие системы можно назвать хранилищами данных... Если же система не поддерживает темпоральность, то может помочь то, что в документах есть ссылки напрямую на клиентов и на города (то есть схема звезда).

Константин,

Похоже, Юрий, Вы плохо понимаете, что такое хранилище данных

Я и не скрываю того, что не являюсь экспертом в этом вопросе. На практике я решаю аналитические задачи с помощью виртуальных вьюшек Impromptu.

Давайте закроем эту дискуссию. Уже всё понятно.

Закрыть - дело не хитрое. Только вот каждый участник понял для себя что-то свое... Вы бы как эксперт по ХД и SCD хотя бы прокомментировали, поняли ли Вы, что PowerPlay позволяет решить проблемы SCD, или наоборот Вы поняли, что MOLAP такие задачи решать не умеет...

To Alexander Stoulov:

Вы бы тоже поделились бы своими мыслями, удалось ли Вам получить ответы на свой вопрос...

Константин,

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

Вот это уже интересно. Не забывайте, мы находимся на сайте www.sql.ru , и тут много профессионалов в области SQL.
Не могли бы Вы привести пример записей из одной или нескольких таблиц, и объяснить, что надо связывать неравенством. Может быть коллективный разум позволит найти решение хотя бы для не очень больших объемов данных? Кстати, Вы говорите что производительность снижается с ростом количества записей - это записи таблицы фактов или таблицы справочника/измерения?

Константин,

Я это решение уже знаю. Зачем мне здесь коллективный разум

Коллективный разум может помочь усовершенствовать это решение, чтобы его можно было использовать и на больших объемах данных. Хотя если это Ваше ноу-хау - можете оставить это в тайне.

Могу лишь порекомендовать почитать Кимбала - он эти вопросы уже неоднократно разжёвывал.
Ссылку выложить?

У Кимбала много информации на сайте. Если не трудно - выложите ссылочку на его статью, которая относится к обсуждаемому нами вопросу.

Константин,

С одной стороны:

(это то, что предложил Юрий). На деле в SCD2 это так и происходит.

С другой стороны:

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

Где же логика в Вашем суждении? Я довольно много полезного рассказал в этой дискуссии на тему MOLAP и SCD...

Я конечно не эксперт в области хранилищ данных, но и не ламер :) Хотя может я просто случайно угадал

Константин,

Ну, я же всё-таки правильно сказал, что проблема 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) хранились данные за всю историю, и такой проблемы просто не возникало.