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...

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