Идея создания удобного / нетехнического инструмента RAD для выполнения запросов и отчетов в базе данных

Question

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

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

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

Answer 1

Для вдохновения существует пять известных мне подходов:

• Список атрибутов . Для данной таблицы вы (дизайнер) предоставляете список всех атрибутов, для которых пользователь указывает значение атрибута запроса. Иногда пользователь также указывает операторы (например, Like, <,> и т. Д.); в противном случае он устанавливается вами в зависимости от типа данных (строки используют Like, числовые атрибуты и атрибуты даты используют диапазоны). Все критерии между атрибутами объединяются логическим И. Если вы разрешите пользователю перечислять значения для одного атрибута, они объединяются логическим ИЛИ. Пользователи обычно предполагают, что пустое значение атрибута подразумевает, что этот атрибут не включен в критерии. Как правило, вы указываете таблицы, которые, вероятно, будут представлять основной интерес для пользователей, и жестко соединяете соединения. Поскольку таблицы, объединения и логические возможности являются фиксированными, это имеет ограниченную гибкость ad hoc, но в большинстве случаев этого более чем достаточно. Это самый распространенный подход.

• Запрос по примеру . Пользователи выбирают таблицы, которые они хотят запросить, и вы предоставляете пустую форму с несколькими записями (например, сетка), которая включает в себя все атрибуты соединенных таблиц; то есть пустой результат запроса (в некоторых случаях пользователь также выбирает атрибуты для отображения). Пользователь завершает значения атрибута, как если бы они были примерами записей, где предполагается, что пустой атрибут может изменяться. Таким образом, если значения Приоритета и Состояние вводятся для одной и той же записи, их атрибуты объединяются логическим И. Если они введены в разные записи, они объединяются логическим ИЛИ. В некоторых случаях пользователь может также указать операторы для каждого атрибута (например, чтобы указать диапазоны значений). Это обеспечивает очень высокий уровень гибкости и кажется относительно интуитивно понятным для пользователей.

• Диаграммный запрос . Подход Tiziana Cararci к Query by Diagram позволяет пользователям определять сложные соединения и логические выражения, графически манипулируя диаграммой отношения сущностей. Для более подробной информации, Google для:

  • Catarci T & Santucci G (1995). Diagrammatic vs Textual Query Languages: Сравнительный эксперимент. Труды рабочей группы ИФИП. 2.6 Рабочая конференция по визуальным базам данных, (март).

  • Catarci T, Costabile MF, Levialdi S & Batini C. (1997). Системы визуальных запросов: анализ и сравнение. Журнал визуальных языков и вычислений, 8 (2), 215-260, (июнь).

• Запрос графического фильтра . Подход Бена Шнейдермана к фильтру позволяет пользователям определять сложные логические выражения, создавая визуальные сети операторов и критериев, используя метафору сантехники или электричества. Google для:

  • Шнейдерман Б. (1991). Визуальные пользовательские интерфейсы для исследования информации. Материалы 54-го ежегодного собрания Американского общества информационных наук, 28 (Вашингтон, округ Колумбия, октябрь).

  • Мюррей Н.С., Патон Н.В., Гобл С.А., Брайс Дж. (2000). Kaleidoquery: основанный на потоке визуальный язык и его оценка. Журнал визуальных языков и вычислений, 11 (2), 151-189 (апрель).

• Запрос на естественный язык Было предпринято много попыток разобрать естественный или полунатуральный язык в структурированный запрос, но он не имел большого успеха, отчасти из-за Неоднозначность естественного языка (например, в «Комиссионном доходе всех продавцов, назначенных в Великобританию и Ирландию», «и» можно интерпретировать как логическое ИЛИ или И). Вы можете попытаться вернуть несколько результатов (по одному для каждой интерпретации) для выбора пользователем (вроде как Google). Этот подход может быть адекватным для неквалифицированных пользователей и для случаев, когда достаточно, а не совершенно правильный результат достаточен.

Answer 2

«удобный для пользователя» и «нетехнический способ» звучит как специальная отчетность. В этом случае вы можете взглянуть на это Ad-Hoc отчет о демонстрации . Но есть много других специальных инструментов отчетности.

Answer 3

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

Я лично видел Linq2SQL для asp и Ruby на рельсах, делающих это. Есть еще много