Несколько советов по дизайну модели отчета:
1. Построить витрину данных
Существует несколько инструментов, таких как построитель отчетов: бизнес-объекты, Oracle Discoverer, чтобы назвать пару. Все они имеют слои метаданных, которые дают вам некоторый путь к инструменту создания отчетов для конечных пользователей, однако им все еще действительно необходимо получать данные в подходящем формате, чтобы получить эффективное решение. Это означает, что вам действительно нужно мыслить с точки зрения построения своего рода витрины данных.
Без чистых данных инструменты будут отображать все ошибки в производственной базе данных, поэтому пользователям придется понимать их, чтобы получить правильные результаты. Это означает, что отчетность действительно должна исходить из чистого источника данных.
Вы имеете практически нулевой контроль над SQL, который генерируют эти инструменты, поэтому они вполне способны генерировать запросы, которые будут влиять на вашу производственную базу данных. Это означает, что ваши отчеты должны размещаться на отдельном сервере. Схема, удобная для специальных инструментов (например, схема типа «звезда»), устранит наихудшие из потенциальных проблем с производительностью.
2. Очистить данные
В цикле нет разработчика со специальными инструментами, поэтому пользователи будут наивно использовать инструмент, не зная, какие проблемы с данными. Неточные результаты запроса всегда будут рассматриваться как ошибка инструмента . Для правдоподобия эти ловушки должны быть устранены из набора данных перед инструментом.
3. Сделайте навигацию надежной и защищенной от идиотов
Построитель отчетов может устанавливать ограничения при переходе от одного объекта к другому. Без них можно объединить несколько таблиц в отношения m: m. Это называется Fan Trap и возвращает неверные итоги. Необходимо настроить модель таким образом, чтобы отдельные таблицы фактов агрегировались по общим измерениям, т. Е. Сворачивались до их объединения. Получение этого права устраняет класс ошибок. У большинства инструментов есть некоторый механизм для предотвращения этого.
4. Сделайте агрегирование данных
Вы получаете это бесплатно от Business Objects, но вам нужно будет явно указать агрегированную меру для каждой базовой меры в построителе отчетов. Скрыть основные меры и выставить совокупности. Это означает, что система свернет данные до размеров измерений, выбранных пользователем.
Заключение
Размещение специального инструмента непосредственно над рабочей базой данных вряд ли будет работать хорошо. У данных будет слишком много подводных камней, и схема не будет пригодна для отчетов. Это означает, что вы готовы к некоторой работе по созданию витрины данных, чтобы очистить данные и подготовить их для инструмента. Если вы тратите значительное время на создание специальных отрывков, возможно, вы найдете экономическое обоснование просто во времени разработчика, что впоследствии сэкономит.
РЕДАКТИРОВАТЬ: Мастер моделей отчетов (как и большинство таких вещей) создает беспорядок при работе. Вам придется настроить параметры, такие как ограничение генерации нерелевантных агрегатов. В прошлом я получал довольно хорошие результаты, генерируя суммы, скрывая все базовые показатели и выставляя совокупности, как если бы они были базовыми показателями. Это дало поведение, очень похожее на Business Objects. В определенных случаях вы также можете указать количество, мин / макс или среднее значение.
Конкретным примером, о котором я думаю, была довольно большая модель отчета с приблизительно 1500 полями в ней, поэтому агрегат-фест, сгенерированный мастером, был неуправляемым с общим числом полей более 10 000. Вы также можете настроить структуры папок немного как службы Analysis Services и использовать их для организации полей. Наконец, если введено описание, поле будет отображаться как всплывающая подсказка, если вы наведете курсор мыши на инструмент конечного пользователя.