Может ли All прояснить в чем прелесть данного предложения Oracle?
Так как мы сами занимаемся написанием DWH для банков вот и интересно, в чем соль Builder
У нас например система состоит из:
- DWHAgent сбор данных с оперативных источников, выгрузка в текстовый файл, перекодировка, минимальная очистка данных, инкремент и т.п. при том встроен MSScript который разбавлен своими объектами, на скрипте вот и пишется гибкий алгоритм выгрузки
- DWHManager ядро. т.е. загружает плоские файлы, удаляет производные агрегаты, расчитывает агрегаты и т.п. при этом агрегаты могут формировать данные в таблицах, формировать физические объекты в ОС и т.п. алгоритмы формирования описываются: классы в BPL, пакеты в Oracle, скрипты в MSScript
- DWHMonitor контроль работы ядра, т.е. DWHManager - кто прислал данные, кто нет и т.п.
Все работает на Oracle.
Любой объект в хранилище автоматически имеет 3 измерения: время, издатель, сущность. Т.е. с помощью измерения Время формируются все варианты возможного хранения данных в разрезе времени, Издатель в разрезе структуры организации. Месяц можно настроить что будет зависеть от Дня, тогда при изменении данных дневного объекта, будут пересчитаны все зависимые от него объекты, как дневные так и месячные и т.п.
Объекты могут храниться в виде истории, т.е. С - ПО для минимизации объема.
В скриптовый язык, встроены объекты для оперирования данными с помощью экономических формул, т.е. не надо знать структуру хранилища.
Есть интеграция с Excel.

А чем лучше, хуже Warehouse Builder?
Что я вижу, так это использование Discover и Report

А что может сказать All?

BirkhoffDiscoverer и Reports никакого отношения к OWB не имеют.

А прелесть OWB в двух словах в том, чтобы не писать свою систему, а используя стандартный CASE автоматизировать процесс построения хранилища и ETL процессов.
Но раз вы уже свою систему написали, то, возможно OWB вам не нужен.

Вопросы по стандартному CASE OWB:
1. Использует механизм подписчик/издатель, для поиска изменений в данных. Или он этим не пользуется?
2. Что предлагается для доставания данных из других СУБД? Если данные в OLTP системе очень раскиданы, и одним запросом не решить задачу, что является "клеем" для формирования плоского файла? Где и как идет преобразование данных, если OLTP различны в разных подразделениях, но по факту в хранилище надо поставлять "правильные" данные?
3. Что выступает в качестве загрузчика плоских файлов? SQLLoader?
4. Какие механизмы используются для построения "расчетных" данных? Я так понимаю: материализованные представления. Которые надо обновлять после загрузки данных. Ну а если представлением не решить вопрос "расчетных" данных, а можно решить только хранимой процедурой с параметрами, кто отслеживает и дергает эти процедуры - по факту изменения первичной информации?
5. Есть ли в стандартном решении вариант хранения истории данных (для уменьшения объема, когда например строка меняется раз в год)?
6. Какие предлагаются средства для решения проблем изменения размерностей со временем?

Sintetik1. не пробовал, но можно использовать advanced queue
2. все что можно подключить к ораклу по HS/TG будет видется как обычные таблицы, есть глюки, но они решаются, совершенно необязательно формировать плоский файл
3. да, но можно подключить как external table
4. можно и хранимые процедуры и функции использовать, нахудой конец весь алгоритм в table function засунуть, а загрузка обычно регламентом определяется
5. slowly changed dimension, там их аж 3 вида кажется
6. это изменение модели, перепроектирование со всеми вытекающими, или вы что-то иное имели ввиду?

1. Можно ли согласиться что все это касается только СУБД Oracle, т.е. если из Oracle доставать данные? В других СУБД, если это не предусмотрено OLTP системой, имхо никак не обнаружить измененных данных. Окромя может фич этих СУБД, или полного слепка данных и сверки его со своим, а потом генерация изменений.
2. Вариант понятен и принимается. Но для этого скорее надо иметь устойчивые и широкие каналы связи, с источниками данных - в реальности это не всегда возможно.
3. Понятно. Но мы не перешли на 9-ку. Вместо SQLLoader используется массивный интерфейс OCI - что в принципе одно и тоже, просто не надо коннект делать к СУБД, иметь ctl,par файлы.
4. У нас загрузка и расчет, по мере поступления данных от источников. по поводу использовать хранимки и т.п. понятно. Но кто их должен дергать? Вот допустим есть отчет в НацБанк, расчет которого делается за банк раз в месяц. Т.е. для его построения надо целый месяц собирать ежедневные данные от филиалов, и потом один раз в конце месяца дернуть расчет. а если какой то филиал, заново пришлет данные (исправил ошибки в OLTP) - то данный отчет надо удалить, по загрузке этого филиала - опять расчитать. Что предлагает OWB для таких случаев?
5. А можете привести пример как физически в таблицах эти три варианта реализуются? интересно глянуть
6. Скажем такая проблема, с таблицами фактов и измерений бывает. Со временем надо добавить поля. Как это выполняется в OWB? Т.е. понятно что физически можно добавить тупо поля в таблицу, но может OWB предлагает чтото интересное?

Sintetikу меня складывается впечатление, что у вас не совсем хранилище, а простая консолидация данных в одном месте, в наших проектах считается что изменение данных в хранилище задним числом это не совсем штатное событие, а уж тем более изменение структуры. скорее всего owb вам не подойдет
Это смотря как смотреть что такое хранилище. Да есть такое свойство в определнии хранилища - как неизменность данных. У нас это есть. Но данное свойство наступает только когда данные будут завизированы ответственным человеком, в данном случае это может быть главбух банка, который согласен например с расчетным балансом, и с тем что нет ошибок в оперативных данных, т.е. в ОДБ. А ошибки случаются очень часто, как правило из-за низкой квалификации персонала на местах, в центре явно квалификация выше, да и некоторые ошибки можно обнаружить только в сводных данных.

Ну так раскажите если есть время о прелестях OWB.
А скорее всего чтобы я убедился что OWB для таких задач не подходит.

А вот изменение структуры иногда бывает.
Правда очень редко.....
Это может быть связано например с изменением правил устанавливаемых НацБанком... Могут вводиться в ОДБ новые параметры и т.п.
Или например изменяется ХП расчета какогото отчета, надо вести историю, что до такой даты расчет делается так, а после вот так - чтобы вернувшись назад и если понадобиться воспользоваться алгоритмом действовавшим на то время.

Да ничего хвалить не надо.
Просто хотел узнать возможности OWB.
А то может делали "велосипед"
Правда сам система была сделана в 98 году, это потом так уже - развитие по мере. На то время был Оракл 7.3.4 - и про OWB вообще не слыхали, только про Express. Так вот не пошли ли мы по неправильному пути, еще тогда?
Хотя на то время разработка обошлась меньше чем в 5000 у.е.
А также есть ли смысл развивать, если есть полуфабрикаты на рынке?