Владимир Иванов Тут нужна опытная и светлая голова внедренца, которая этот DWH спроектирует в виде самых тривиальных табличек SQL-сервера, но с нетривиальными задачами. А OLAP-тут только вершинка над этим DWH и простейший элемент BI-решения. Выбрать можно потом OLAP любой и даже несколько сразу. :)

я того же мнения:

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

- OLAP действительно можно выбрать любой, собственно, как я и говорил, это вообще не наше дело, это бизнес наших заказчиков.. Наше дело - поставить им по-максимуму olap-friendly solution. А это, в моем теперешнем понимании означает "с возможностью выгрузки наших данных, предварительно приведенных к некоторой канонической olap-форме в указанное место (DWH)"

олапист
- соглашения по именованию полей без которого визарды во многих продуктах становятся бесполезны
- схема parent-child которую многие продукты недолюбливают
- MS:длинющий список ограничений на real-time ROLAP
- всякие фенечки типа Unary Operators, Custom Members, etc (MS), Transformations (MSTR) реализуемые непосредственно в DWH
- соглашения которые необходимы для поддержки многоязычности (например в CRN)
- особенности работы с NULL (MS)
- ...

Можно конечно сказать что это не DWH, а уже некая дополнительная витрина на основе DWH, но сути это не меняет
Хотя если в слово "грамотно" вкладывать знание особенностей конкретных продуктов, тогда согласен

Вот было бы очень интересно, если бы специалисты по тем или иным OLAP-системам перечислили основные моменты, которым должен удовлетворять грамотно спроектированный DWH, чтобы эти OLAP-системы себя комфортно чувствовали. Будем очень благода!

Добрый ЭхВы хотите получить ТЗ на проект? Книга лучший друг человека - The Data Wharehouse Toolkit. Practical Techniques for Building Dimentional Data Warehouses. Ralph Kimball. Там ответы на все Ваши вопросы.

я как раз его читаю. Но там, как ни странно, нет ни слова о влиянии имен полей на работу визардов в cognos и на особенности обработки NULL в MS AS... Из постов коллег я сделал вывод, что они что-то знают о таких нюансах, вот и хотелось бы, так сказать, приобщиться к. Кимбол прекрасен с т.з. общих подходов, но частности не менее важны, если требуется получить действительно юзабельную систему. Увы, пока специалисты упорно хранят молчание :)

ingaспециалисты хранят молчание потому что именно за знания которыми вы просите поделиться они получают деньги.

я подозревал что-то в этом роде :)

не понимаю, однако, чего здесь опасаться, деньги-то они получают от конкретных кастомеров olap-system, а не от разработчиков вроде меня. Вряд ли ведь можно всерьез опасаться, что сотрудники какого-н. банка подсмотрят в форуме на sql.ru какой-н. нюанс работы с cognos и на том основании решат, что они теперь в специалистах по cognos не нуждаются, а будут все делать сами? Скорее уж наоборот, увидев тут толкового специалиста, они именно его и пригласят...

Впрочем, довольно провокаций :) В дальнейшем буду благодарен за ответы по существу вопроса.

No PasaranМы тут как-то уже подзабыли а в чем собственно вопрос? Поставьте задачу, постараемся помочь.

нет ничего проще:

1) было бы очень интересно, если бы специалисты по тем или иным OLAP-системам перечислили основные моменты, которым должен удовлетворять грамотно спроектированный DWH, чтобы эти OLAP-системы себя комфортно чувствовали. В данном случае интересует скорее специфика того же cognosa, MS AS, BO, чем общие подходы, описанные у того же Кимбола (хотя всякий практический совет будет ценен)

2) рекомендуемая механика кормления DWH из оперативной системы: scheduled service? разовые запуски.. что-то еще? У нас пользователи оперативной системы как правило сегрегируют данные между собой (Петя работает только со счетом 1, Вася - только со счетом 2 и т.п.; хуже того, Петя - только с транзакциями из банка 1, Вася- только с транзакциями из банка 2, при этом и те и другие транзакции могут ложится на один и тот же счет 3) - имеются ли прецеденты скармливания в DWH не целиком данных предприятия а некоторых вертикальных подмножеств?

3) представим, что у нас есть некоторые изменяющиеся факты (прогнозируемый баланс, к примеру); технически как лучше отслеживать необходимость изменения и отрабатывать это изменение? Первое, что приходит в голову - повесить триггер, регистрирующий изменения прогнозов, затем, при запуске etl-подсистемы перебирать изменения, вносить их в DWH, помечать как отработанные.. Имеет это смысл или есть какие-то более правильные способы? А если у меня несколько DWH будет поддерживаться одновременно, как организовать гарантированную синхронизацию всех DWH ?

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

- меня смущает то, что в случае, когда Петя работает только с банком 1, а Вася только с банком 2, при этом те и другие транзакции ложатся на счет Х, при сегрегированном кормлении DWH (т.е. если за сеанс etl будут синхронизироваться только Петины или только Васины изменения) может произойти так, что результирующие данные по счету Х неверны, т.к. чьи-то изменения туда не попали.. С одной стороны - это проблема пользователя, он же сам это настроил.. С другой стороны - вопрос, имеет ли смысл предоставлять пользователю такую "возможность ошибаться"? С третьей стороны - сейчас пользователи привыкли к возможности сегрегирования данных во всех имеющихся ф-циях системы, т.е. при отсутствии такой возможности у них может возникнуть синдром лишения.. Короче, аргументы "против" понятны. Приведите, если можно, аргументы "за" ... "раздельное питание" DWH ...

- а где можно прочитать про партишенинг?

No Pasaran
Если напишете бизнес-задачу, то постараюсь написать что-то более подробное.

Фокус в том, что конкретной бизнес-задачи я не знаю. Я - разработчик некоторой финансово-аналитической системы. У этой системы есть на сегодняшний день несколько сотен заказчиков на нескольких континентах.. Все они занимаются финансовым анализом но в разных, естественно, вертикальных сегментах индустрии. Большинство этих заказчиков помимо нашей узко-финансовой системы используют другие системы, в т.ч. BI -системы типа того же cognos, BO и иже с ними. И большинство хочет данные из нашей системы поиметь в своих BI-системах. Просто так взять нашу БД и перегружать из нее данные - не катит, т.к. огромного к-ва интересующих пользователей данных в БД вообще не хранится, а расчитывается (прогнозируемые балансы, оперативный контроль контрактов, комиссионные) - и показывается в соотв. отчетах/гридах в самой системе. Т.е. для того, чтобы наши заказчики стали еще более счастливы, чем они есть сейчас, наша система должна стать olap-frienly, т.е. иметь возможность результаты своей работы выгружать в некоторое внешнее хранилище DWH. А дальше уже наши заказчики будут натравливать на это DWH свои BI-tools... Потому наша задача - грамотно спроектировать DWH, чтобы большинство распространенных BI tools с ним хорошо дружило; и второе - реализовать etl-сервисы для аккуратного кормления этого DWH на основании данных и логики, имеющихся в оперативной системе... Такие дела..

No Pasaran автор А если у меня несколько DWH будет поддерживаться одновременно, как организовать гарантированную синхронизацию всех DWH
Это вас куда-то нетуда потянуло.

туда.. у любимого клиента стоит наша система в Лондоне, а филиалы у них по всей Европе, в Штатах и в Южной Америке... Каждый филиал, естественно, совершенно самостоятельная организация со своей инфраструктурой, IT и т.п. Вот и получается, что, вероятнее всего, из одной и той же системы бразильцы захотят кормить свой cognos, а французы - свои BO...