Пользовательские пользовательские отчеты по известной схеме - PullRequest
3 голосов
/ 21 июня 2011

В разработке находится предстоящий проект, удовлетворяющий требованию конечных пользователей создавать собственные отчеты на основе своих данных в нашей реляционной базе данных с фиксированной / известной схемой.

Интерфейс должен быть очень удобным для пользователя, и поэтому перенести все языковые концепции t-sql в графическую парадигму слишком сложно как для команды проекта, так и для конечного пользователя.

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

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

Мозговой штурм - поддержка функций в порядке сложности: фильтры SELECT, WHERE, FULL JOIN, LEFT JOIN, сортировка, разбиение по страницам, группировка, агрегация, фильтр HAVING.

Мой план резервного копирования состоит в том, чтобы просто перевести его к предварительно написанным представлениям SQL (со встроенными JOIN) с возможностью отображения доступных столбцов с настраиваемой построчной фильтрацией. Пейджинг и сортировка выполнима. Само по себе это не позволяет группировать, агрегировать функции, HAVING-фильтры или выполнять другой анализ строк.

Ответы [ 2 ]

2 голосов
/ 21 июня 2011

Как продолжение поста @Dems (поле для комментариев было недостаточно) :) ..

Согласовано по большинству пунктов .. Если ваши данные в основном аналитические, то вы можете посмотретьв инструмент, такой как PowerPivot .В этом случае вы можете написать общий запрос, а затем разрешить пользователям получать отчеты на основе результирующего набора в знакомом инструменте (Excel).

В основе каждого механизма специальных отчетов вы найдетеНесколько общих тем:

Метаданные
Будет несколько способов описания схемы, так что модель может быть легко использована пользователем.Sql Server Reporting Services (SSRS) требует, чтобы вы построили модель метаданных, чтобы использовать построитель отчетов.При использовании PowerPivot вы можете использовать псевдонимы столбцов, чтобы сделать их более удобочитаемыми, но, в конце концов, вы просто предоставляете плоский набор данных и позволяете пользователю создавать объединения / отношения.

Построитель запросов
После того, как пользователь манипулирует метаданными, должна быть создана промежуточная система для преобразования концептуального отчета в фактический запрос.Многие инструменты измеряются на основе сложности Sql, которую они производят, поскольку это может сильно повлиять на производительность.Один из способов обойти это - создать представления, против которых механизм отчетов может создавать запросы.Один из лучших примеров этого с открытым исходным кодом, который я видел, - это движок, поддерживающий Hibernate / NHibernate (посмотрите, как различные Dialects используются при построении запросов).

Механизм рендеринга
По моему опыту, создание механизма рендеринга - это не та дорога, по которой ты хочешь идти.Существует множество проблем, связанных с устройством, а также проблемы с внешним видом (например, как вы планируете представлять каскадные объединения / отношения?).У каждого движка рендеринга есть свои особенности (PowerPivot использует Excel, у SSRS есть служба, которая создает необработанный результат и возвращает его приложению-потребителю), который необходимо учитывать, поэтому будьте внимательны при выборе.

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

Выясните, что устраивает ваших пользователей, и постарайтесь приспособить ваше решение к этому домену.Я часто обнаруживал, что для опытных бизнес-пользователей что-то вроде PowerPivot идеально подходит.Для большего числа повседневных конечных пользователей более полезно иметь «готовые» отчеты, которые могут быть изменены конечным пользователем через простой пользовательский интерфейс, который позволяет им изменять ограничения / группировки / сортировку.

2 голосов
/ 21 июня 2011

Существует много вариантов, но лучшие из них стоят денег.

Мне очень нравится QlikView, как простой в использовании отчет, предназначенный для техников.Если ваша пользовательская база более технически настроена, это может быть немного ограничительным, но если ваша пользовательская база не имеет логических возможностей мышления, это слишком сложно.Это самая большая ловушка, в которую я попадаю ...
- Нет, я хочу большего!
- Нет, это слишком сложно для меня!
- В то же время ...

Если бы вы собирали свой собственный набор инструментов внутри, вам, вероятно, лучше всего придерживаться кубов OLAP.Пусть люди нарезают и обрезают данные так, как им нравится, но со всеми предварительно определенными отношениями.Сделайте это правильно, и вы можете просто указать сводную таблицу Excel на куб OLAP и позволить им играть ...

Следующим шагом, как говорит Бобби Д., могут быть службы отчетов SQL Server или что-то подобное.

Но если ваши пользователи хотят абсолютной гибкости, им нужен сам инструмент SQL.К сожалению, все инструменты следуют одной и той же тенденции: чем гибче и мощнее, тем больше времени вам нужно потратить на обучение / тренировку.

...