_модБор_ИСЕсть множество систем. Порядка 20
Решение зависит от используемых СУБД.

Решение зависит от очень многих факторов. Объемы данных не так влияют, как их качество, аналитики, размерности. Раз решили использовать XML, то подозреваю, что там вполне типичный зоопарк систем. Типовой набор задач : интеграция, транзакционное хранилище, логика агрегации, олап-хранилище, система отчетности. Все должно работать в одних терминах, значит метаданные в той или иной форме, справочники. Это только основные технические проблемы. Их решение зависит от существующей инфраструктуры, организационных и финансовых проблем, текущего состояния, отношения к IT руководства, общего положения на предприятии, географии, перспектив развития, взаимоотношений с конкретными вендорами, наличием нужных специалистов и т.д. и т.п.

Бор_ИСЕсть множество систем. Порядка 20, руководство предприятия требует отчёты, данные для которых берутся из всех этих систем т.е. сидит несколько человек делает выгрузку из одной системы, затем из другой, потом это всё слепляет, снова обрабатывает. И потом этот отчёт подаётся руководителю. Отчёты разные, иногда меняются. Есть отчёты которые нужно делать каждый день, есть которые каждый месяц. Данных несколько терабайт.
Есть идея выгружать данные из всех систем в xml, затем запихивать это всё в одну СУБД и потом уже просто остаётся правильно написать запрос.
Есть ещё как-нибудь идеи как это можно делать быстро?

Насчет сделать быстро и отностительно малой кровью.
1. Опишите и зафиксируйте интерфейс выгрузки (формат XML, csv, web-service... - по вашему усмотрению).
2. Выгружайте только агрегаты. В аналитических отчетах терабайты не нужны. Они могут понадобится для статистических и итсторических отчетов, но тогда надо строить полноценное транзакционное хранилище.
3. Заведите справочники для всех аналитик, желательно с историчностью, но это гораздо сложнее. Приводите данные измерений к этим справочникам в момент выгрузки.
4. Разработайте аналитическое хранилище.
5. Разрабатывайте отчеты на промышленной платформе (MS Reports, BusinessObjects, Crystal, Oracle Reports... ). Если что-то уже не используете, конечно, стоит купить...

Делайте все, ориентируясь на план развития ИТ в компании.

iscrafmShoora5. Разрабатывайте отчеты на промышленной платформе (MS Reports, BusinessObjects, Crystal, Oracle Reports... ). Если что-то уже не используете, конечно, стоит купить...

промышленная это та которая промышляет? А если для формирования отчетности не используется MS Reports, то отчетность получается некорректная? А если не купить Oracle Reports, то о какой интеграции вообще может идти речь.
Иногда такие советы прочитаешь...

Вот именно, совет. Следовать ему или нет - личное дело каждого. Я высказал свое мнение, которое основано на личном опыте работы в одной очень немаленькой корпорации, где количество интегрированных систем несколько больше 20. А написал криво - признаю. Читать так:

5. Разрабатывайте отчеты на промышленной платформе (MS Reports, BusinessObjects, Crystal, Oracle Reports... ). Если что-то уже не используете, конечно. На мой взгляд, стоит купить...

Нормальная система аналитической отчетности экономит кучу времени всем участникам процесса.

iscrafmShoora,
мой вопрос состоял в том, что такое промышленная платформа. Это платформа которая промышляет, платформа для промышленности или что?

Это устоявшийся термин, означающий стабильный продукт с заявленной стратегией развития, большой историей внедрений, обычно от известного производителя. Создан занять определенную нишу в IT-инфраструктуре предприятия. Обычно к нему прилагается сложившийся рынок специалистов.

iscrafmТитов АлександрПродукты из списка вполне живы и развиваются в известных направлениях.
шикарная характеристика :)
p.s. Вы перелогинились?

Про характеристики - ну не скажешь в двух словах о нежных отошениях SAP, Oracle, IBM, Microsoft и их поглощения. Хотите поговорить про преимущества той или иной BI платформы? Я не хочу - слишком обширная тема, к тому же оффтопик. В компании, где я работаю основным средством аналитической отчетности давно был выбран BO (до покупки САПом). Поскольку основной платформой приложений является SAP, можно сказать, что наши стратеги не зря получают зарплату - угадали.

p.s.->p.s. Ну, так получилось :)

ГликогенВсе правильно сказано насчет хранилища и "промышленных систем отчетности".
Забыли 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 в конце концов. Но и на этом процесс не заканчивается. Заложить грамотные основы корпоративной архитектуры, выстроить процесс (с документированием и всем прочим) - и не стыдно будет передать систему последователям.