Коллеги, добрый день.

Хочу попросить совета у мудрых, коим удалось на практике реализовать концепцию витрин данных (Data Mart), т.к. сейчас передо мной встала именно эта задача. А опыт решения напрочь отсутствует.
Инструментарий в моем распоряжении пока такой: SQL-Server (включая Analysis Services) и MS Office. На SQL-Server находится корпоративная БД, есть несколько кубиков, и тьма представлений и хранимых процедур, собирающих отчеты для конечных пользователей. Визуализаций отчетов – в Экселе.

Хочется придти к известной 3х-уровневой схеме:
1. Реляционная база данных (нормализованная)
2. Витрины данных (денормализованные)
3. Отчеты конкретных пользователей

При помощи витрин хочется решить следующие задачи:
1. Дать определения основным бизнес-терминам (что такое продажи, клиенты, каналы сбыта и т.д.).
2. Ограничить тяжелый SQL-кодинг уровнем витрин, в идеальном варианте – чтобы «аналитик» мог формировать отчеты из витрин вообще не прибегая к SQL.

Это теория. На практике появляются проблемы…
Физически я понимаю витрины как набор тематических представлений, например, «продажи», «работа с клиентами» (звонки, встречи и т.д.), «персонал» и так далее. Не возникает проблем собрать на их основе одноименные кубики и отдать их «аналитикам» на растерзание…
Однако любой управленческий отчет есть синтез плохо совместимых данных. Например, руководителю наверняка захочется в одном отчете увидеть в разрезе по филиалам показатели по продажам, по работе с клиентами, по персоналу и т.д. И вот тут я уже не представляю себе инструментарий, при помощи которого «аналитик» (не знающий SQL) может скрестить данные из нескольких представлений (кубов). Есть несколько идей, как организовать связку "Витрины-Отчеты", например:
1. Подключать кубы к Экселю и в нем формулами (либо кат-энд-пейстом) собирать нужные отчеты. При этом отчеты получатся очень громоздкими и тяжело поддерживаемыми (например, формулы в Экселе будут постоянно съезжать), зато в качестве «аналитика» можно использовать достаточно дешевого специалиста по экселю.
2. Подключать кубы к Аксесу и конструктором запросов собирать нужные отчеты. Тут уже требуется специалист понимающий принципы БД.
3. Собирать отчеты в SQL на уровне SQL Server’а. Самый быстрый и простой для меня способ, однако в перспективе означает армию SQL-программистов на поддержке отчетов

Как на практике выглядит цепочка БД-Витрины-Отчеты? Какие специалисты и с каким набором компетенций должны обслуживать связку «Витрины-Отчеты»? И какой оптимальный для этого инструментарий?

Заранее бесконечно благодарен за ответы =)

strizhДля поддержки этого хозяйства работает 1 аналитик со
знанием SQL (юзать MS RS я ее научил)

1 аналитик это отрадно. Если не секрет, какой объем отчетности она поддерживает?
(Витрины, рискну пердположить, поддерживает все же не аналитик)

MS Reporting Services в скором времени появится, буду изучать.

strizhОна поддерживает 3 десятка отчетов.
Впечатляет.
Спасибо за то что поделились опытом, будущее окрашивается в светлые тона.

За последние несколько дней прихожу к выводу, что знание SQL для аналитика - это, по всей видимости, нормально и не следует этого пугаться. Главное не давать его SQL-творчеству опускаться ниже уровня витрин и, я полагаю, получится приемлемый уровень управляемости системы.

Petro123Можно вообще по простому - в виде слоя доступа к данным (типа витрина) - пакеты с VIEW и хранимками.
Сейчас так и делаю. И буду продолжать до появления Reporting Services.
В принципе ничего страшного в этом нет, Витрины это ведь концепция, а представления, хранимки, Reporting Services это частные случаи реализации.