ГликогенВсе правильно сказано насчет хранилища и "промышленных систем отчетности".
Забыли 2 важнейших пункта -
1. Как будут согласовываться справочники (и вообще как будет управляться качество данных)
2. Каким инструментом ETL все это будет грузиться в хранилище.

Все это можно сделать на хардкодных спагетти-скриптах, но руководство и последующие поколения айтишников вам спасибо не скажут.
Поэтому в 8 из 10 таких проектов стратежно применяются промышленные же ETL-средства, и в половине - средства MDM.

2 cамых целостных на сегодня подхода - это
1. Обработка входящих справочников и фактов универсальными процедурами, основанными на правилах обработки + генерация хранилища на Generic-схеме, практически без кодинга (Kalido)
2. "Хранилище из коробки" (Oracle BIEE+BI Apps)

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

Скажем так, про ETL и MDM не забыли, а опустили :) Когда человек начинает разговор со слов "Есть идея выгружать данные из всех систем в xml, затем запихивать это всё в одну СУБД и потом уже просто остаётся правильно написать запрос.
Есть ещё как-нибудь идеи как это можно делать быстро?", делаем вывод, что он и его команда находятся на определенном этапе. Предлагать на этом этапе сделать все "как у больших", бессмысленно. Даже если лично он убедится, убедить руководство вряд ли удастся. На мой взгляд, на этом этапе важно соблюсти общий принцип и не пропускать важных этапов - потом любой "наколенный" компонент может быть относительно безболезненно заменен соответствующим продуктом. Предложение все-таки купить систему репортинга идет из этих соображений. Если этого не сделать, народ автоматом начинает писать логику отчетов на том, что ему ближе - либо на базе (куча скриптов на PL\SQL и зубодробительные вьюхи - типичная картина), либо пропускают все через супер-app-сервер, либо Excel и VBA - это реальность и с этим сталкиваешься постоянно... получается спагетти.

Petro123
если в первую очередь не рассматривать покупные решения...
- делать гетерогенный запросы на лету или делать хранилище данных
- по какому протоколу брать данные
- кто будет эксплуатировать систему
и т.д.
Даже решение класть всё в XML а потом лишь "осталось написать запросы" к этой байде.... - очень сомнительно.

ЗЫ. Лучше рассматривать не последовательность действий, а архитектуру решений в этой области.
Тот же DTS вместо TSQL всяко лучше при заполнении хранилищ данных (если у Вас сиквел)


iscrafmникогда никто не задумывался о том, что для того чтобы не было спагетти, достаточно банально документировать все?
...
К тому же, имхо конечно, несколько переоценивается техническая сложность ETL продуктов. Выбросьте из них графику, шедулеры.... и посмотрите что останется.

Все верно, но несколько поверхностно. Нельзя смотреть на создание такой системы, как OLAP только с точки зрения технологий и текущего состояния систем-источников. Это ПРОЦЕСС. Прыгать через этапы здесь так же опасно, как и городить спагетти. OLAP - вершина айсберга, она не является жизненно важной для предприятия (и для руководства!), в отличие от любой MES или ERP, но если грамотно начать ее внедрять, она может оказать связующее действие на другие системы - их новые версии будут создаваться с учетом корпоративных справочников, в них будут предусматриваться интерфейсы взаимодействия, дойдут и до MDM, ESB, SOA в конце концов. Но и на этом процесс не заканчивается. Заложить грамотные основы корпоративной архитектуры, выстроить процесс (с документированием и всем прочим) - и не стыдно будет передать систему последователям.