Создатель отчетов SSRS - проблемы с опытом?

Я изучаю идею развертывания веб-разработчика отчетов SSRS для наших конечных пользователей, чтобы они могли создавать свои собственные отчеты против наших баз данных производственных приложений. Из того, что я видел до сих пор, этот инструмент проще в использовании, чем дизайнер отчетов VS Biz Intel Studio, плюс его проще установить, а развертывание отчетов намного понятнее для конечного пользователя (плюс самое главное, что нет SQL Я думаю).

Есть ли у кого-нибудь какие-либо мысли или опыт о подводных камнях, дающих пользователям такую силу? В настоящее время мы получаем много запросов на экспорт данных в плоский файл, чтобы они могли его прочитать, а затем создавать отчеты в Access против него, поэтому я считаю, что SSRS будет лучше, чем Access...

Ответ 1

Некоторые советы по разработке модели отчета:

1. Создайте карту данных

Существует несколько таких инструментов, как построитель отчетов: бизнес-объекты, Oracle Discoverer, чтобы назвать пару. У всех из них есть слои метаданных, которые дают вам часть пути к инструменту отчетности конечных пользователей, однако им по-прежнему действительно нужны данные с ложкой в подходящем формате для создания эффективного решения. Это означает, что вам действительно нужно думать с точки зрения создания своего рода данных-мартов.

Без чистых данных инструменты будут раскрывать все полученные в производственной базе данных, поэтому пользователи должны будут понять их, чтобы получить правильные результаты. Это означает, что отчет должен действительно оторваться от чистого источника данных.

У вас почти нулевой контроль над SQL, который эти инструменты производят, поэтому они вполне способны создавать запросы, которые будут грызуна вашей производственной базой данных. Это означает, что ваши отчеты должны проводиться на отдельном сервере. Схема, дружественная к специальным инструментам (например, звездная схема), уменьшит наихудшие из возможных проблем с производительностью.

2. Очистка данных

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

3. Сделайте навигацию надежной и идиот-защищенной

Конструктор отчетов может устанавливать ограничения на переход от одного объекта к другому. Без них можно объединить несколько таблиц вместе в отношении m: m. Это называется Fan Trap и вернет неправильные итоги. Вам необходимо настроить модель так, чтобы отдельные таблицы фактов были объединены с общими размерами, то есть свернуты до их соединения. Получение этого права исключает класс ошибок. Большинство инструментов имеют механизм предотвращения этого.

4. Сделайте агрегацию данных

Вы получаете это бесплатно от бизнес-объектов, но вам нужно будет поместить агрегированную меру по каждой базовой мере с помощью Report Builder. Скрыть базовые меры и выставить агрегаты. Это означает, что система будет сворачивать данные в зерне размеров, выбранных пользователем.

Заключение

Размещение специального инструмента непосредственно над производственной базой данных вряд ли будет работать. Данные будут иметь слишком много подводных камней, и схема не будет предоставлять отчетность. Это означает, что вы работаете над созданием массива данных для очистки данных и подготовки к этому инструменту. Если вы тратите значительное время на создание специальных выписок, может быть бизнес-кейс просто во время разработки, это может сэкономить позже.

РЕДАКТИРОВАТЬ: Мастер модели отчетов (как и большинство таких вещей) при запуске создает беспорядок. Вам придется настроить настройки, такие как ограничение генерации нерелевантных агрегатов. Раньше у меня были неплохие результаты, генерируя суммы, скрывая все базовые меры и раскрывая агрегаты, как если бы они были базовыми. Это дало повод так же, как Business Objects. В определенных случаях вам также может понадобиться вывести счетчик, min/max или средние значения.

Конкретный экземпляр, о котором я думаю, был довольно большой моделью отчета с примерно 1500 полями в нем, поэтому совокупность-fest, созданная мастером, была не поддающейся управлению с 10 000 + полями в целом. Вы также можете настроить структуры папок, похожие на Analysis Services, и использовать их для организации полей. Наконец, если введенное описание в поле будет отображаться в виде всплывающей подсказки, если вы наведете его на инструмент конечного пользователя.

Ответ 2

Всего несколько комментариев по предыдущему ответу:
1. Модель семантического запроса, используемая SQL Server Reporting Services Report Builder, была разработана с явным намерением предотвращать ложные ловушки/неправильные итоговые значения для отношений m: m. Никаких дополнительных усилий для включения этой функции не требуется; он присущ структуре запросов, созданных Report Builder.
2. Мастер по умолчанию создает агрегированные меры по числовым полям по умолчанию, поэтому для экспонирования агрегатов не требуются дополнительные усилия. Вы можете настроить модель, добавив или удалив совокупные вычисления в зависимости от ситуации.

В целом, старая пословица "мусор в мусоре", безусловно, применяется. Если ваши данные не чистые, тогда построитель отчетов или другие специальные инструменты отчетности просто сделают это более очевидным.

Аарон Майерс
Инженер по разработке программного обеспечения, службы отчетов SQL Server