Xpoint
   [напомнить пароль]

Интерфейс построителя отчетов

Метки: [без меток]
2007-10-29 13:00:16 [обр] Thirteensmay(0/157)[досье]

Требуется разработать понятный неспециалисту, удобный интерфейс построителя отчетов. Т.е. есть БД, сущьности, таблички, связи, все как обычно, по этой БД необходимо строить отчеты типа "Список клиентов за последний месяц, и т.п.". С технической точки зрения вопросов нет, определен набор таблиц с формализованными исходными данными для построения SQL запросов, модуль сборки запросов из этих исходных данных, их выполнение и построение по результатам самих отчетов. Теперь требуется ввод этих "исходных данных", т.е. пользовательский интерфейс заполняющий по соответствующим правилам определенные выше таблицы.

Понятное дело что с интерфейсом может работать не специалист по БД, т.е. оперирование понятиями LEFT JOIN и т.п. тут не прокатит. Ды, как бы оно как раз и делается для того чтобы уйти от SQL. Трансляцию пользовательской логики во внутреннее представление я как нибудь сам выполню, основной вопрос в определении этой самой пользовательской логики, т.е. организации работы с интерфейсом и его возможностей. Опыта работы с построителями запросов (отчетов) не имею, требуются рекомендации "независимых экспертов" т.е. с точки зрения пользователей.

Предполагается что на нижнем уровне система будет более менее универсальной, т.е. с адаптацией под различные БД, на уровне пользователя же эта универсальность будет подрезаться/настраиваться во имя удобства и простоты работы пользователя с конкретной БД. Хотелось бы услышать рекомендации по организации пользовательского интерфейса, так чтобы он был максимально близок к логике обычного пользователя. Возможно какие то отдельные соображения, статьи, обзоры, опыт работы с существующими построителями, пожелания, и т.п. Буду рад любой информации.

спустя 2 часа 23 минуты [обр] GRAy(0/259)[досье]
Thirteensmay[досье] А что есть отчёт в самом общем виде?
спустя 1 час 38 минут [обр] Thirteensmay(0/157)[досье]

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

На самом деле сейчас есть 2 системы, одна универсальная - фактически формализованный ввод SQL запроса, гибко конечно, но пользовать тяжко, практически пользователю надо знать SQL и структуру, специалисту получается проще SQL ручками написать, пользователя же выражения типа "Определите тип связи/группировки" ставят в тупик. Вторая система проще, но жестко заточена под специфику родного проекта. Требуется нечто среднее.

Насколько я понимаю интерфейс должен обеспечивать пользователю наборы полей которыми он сможет оперировать, выбирать какие именно он хочет видеть в отчете, в каком виде (форматирование), задавать условия выборки (imho самое сложное), применять встроенные функции (сортировка, итоги, и т.п.). Но все это не должно быть черезчур. От жесткой привязки к конкретной структуре БД я на нижнем уровне отвязался за счет отдельной формализации SQL запроса, вопрос как отвязаться от жесткости пользовательского интерфейса при этом не сделав из него монстра, фактически понятно как - определить наиболее типичную функциональность в абстрактном виде (выборка полей, возможно взаимосвязь между ними, определение условий, использование функций), остальное реализовывать по требованию.

Т.е. в результате надо ответить на вопрос какую именно абстрактную функциональность надо реализовать, и в каком для пользователя виде ? Тут возможно требуется социальное исследование, но может быть есть какието готовые материалы/идеи ? Или может тупо содрать из MS Access, вроде там визуальный построитель запросов был... ;) Однако просто так некашерно... Наверное есть опыт использования и какие то свежие идеи.

спустя 54 минуты [обр] GRAy(0/259)[досье]

Thirteensmay[досье] Реализация "абстрактной функциональности" скорее всего пользователей как раз и не устроит. MSAccess тоже не эталон т.к., фактически, представляет собой визуальный построитель запросов и от необходимости знать структуру пользователя не освобождает ну никак. Вот вы пишете:

... определен набор таблиц с формализованными исходными данными для построения SQL запросов, модуль сборки запросов из этих исходных данных, их выполнение и построение по результатам самих отчетов...

Т.е. всё-то у вас уже есть, но вот структура этих самых "исходных данных", судя по всему, не очень подходит для представления простым пользователям - а это значит, скорее всего, что вы просто сделали враппер для sql`я ценность которого... ну, скажем так, неочевидна. Реляционная структура сама по себе достаточно самоописательна (если не злоупотреблять ;)) и главная проблема как раз не в том чтобы динамически построить нужный селект и подставить человекочитаемые имена - а в выделении из множества всех возможных запросов к вашей структуре наиболее полезных и наиболее часто используемых. Это можно сделать как минимум двумя способами:
эмпирическим - т.е. реализовывать отчёты по мере поступления заявок от пользователей и постоянно их классифицировать и "уплотнять" (т.е. параметризировать, находить общее и т.п.)
объектным - попытаться в предметной области выделить ключевые интересующие пользователя объекты и построить метамодель позволяющую строить запросы к этим объектам очевидным для пользователя способом (хорошая реляционная структура может обладать этим свойством сама по себе).
Есть отраслевые стандарты ведения бизнеса (банковские например) из них можно почерпнуть как описания типовых объектов данной предметной области, так и некоторые типовые запросы к информации порождаемой тем или иным бизнесом - это можно и нужно использовать в качестве отправной точки подобных систем. Остаётся понять к какой отрасли относятся ваши задачи ;)
Впрочем, может я напрасно разоряюсь ;) и задача проще чем мне кажется - но в такой абстрактной формулировке, на мой взгляд, решения нет.

спустя 1 час 4 минуты [обр] Евгений Петров(0/1055)[досье]

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

максимально близок к логике обычного пользователя

Кто это такой? Что он будет делать в вашей системе? Какие ошибки и пристрастия ему присущи? И т.д. и т.п.

спустя 23 часа [обр] Thirteensmay(0/157)[досье]

GRAy[досье] Не напрасно, коечто почерпывается ;)

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

Теперь собственно говоря цели: Их 2, первая очевидна - поиметь такой функционал в проектах. Естественно сложные отчетные формы типа табелей рабочего времени и реестров предоставленных услуг в медстрахкомпании делаются отдельно, однако этому сопутствует и куча мелочевки, типа вытяните нам кто вчера из студентов-практикантов перед обедом в столовую заходил ато памперс в кастрюлю с супом засунули. Парить таким разработчиков мягко говоря неэффективно, и хорошо когда такое по телефону решается, оторвать задницу программера и послать его с кавминвод за урал сложно, а когда он возвращается вообще страшно. Это я конечно крайний случай описываю, и решать такое можно по разному, однако линия надеюсь очевидна. Итак, первая цель - обеспечить пользователю возможность решить проблему самому, разгрузить разработчиков/поддержку, облегчить процесс создания отчетов, есть и другие бонусы, это к вопросу почему выбрано именно такое решение. Вторая цель - чисто наша с вами профессиональная специфика - стандартизация подходов к разработке, повышение ее эффективности за счет повторного использования кода, облегчение поддержки, обеспечение преемственности/взаимозаменяемости в условиях текучки кадров. Тут надеюсь понятно и так, посему особо комментировать не буду. Очевидно что работать с одним универсальным модулем легче чем с кучей разнокалиберных велосипедов.

Евгений Петров[досье] Обычным пользователем предполагается считать некоего не совсем тупого перца, не знающего SQL и реляционных подходов, однако способного понять что такое набор записей (таблица), что есть понятие строки столбца и поля, типа данных, а также то что он может применять к такому чуду нехитрые функции типа сортировки, арифметических действий, логические функции и т.п. Т.е. фактически это хорошист по информатике и уверенный пользователь Excel. Обиженные головой и пр. не рассматриваются. Помоему это вменяемые требования для оператора.

А теперь о текущих идеях к реализации: Сутра удалось поговорить с разработчиком предыдущей версии, увязывая его соображения с предложенным GRAy[досье] объектным способом организации (эмпирический тут не пойдет, от него какраз уйти и пытаемся), с соображением реляционная структура не злоупотребляя сама по себе достаточно..., а также со сформулированной идеей абстрактной функциональности и враппера SQL (их роль снижается/изменяется но польза остается) получаем следующее:

Основным объектом с точки зрения пользователя является Представление. Практически оно точь в точь является представлением (вьюсом) в терминологии БД. Пользователь заранее обеспечивается (разработчиками) набором представлений отражающих основные объекты конкретной предметной области (например представление "Проходная" или "Регистратура" или "Процедурный кабинет"). Представление содержит набор записей характеризующих соответствующий объект, т.е. практически это обычная таблица, например представление Проходная содержит поля: Кто, когда, куда, как. Представление может быть параметризованным, например у "Опоздавшие" настраивается чувствительность и т.п. Также придется както оформить фильтрацию. Для создания отчета пользователь должен "войти в представление" определить его параметры, указать необходимые столбцы, возможно применить встроенные функции. Фактически с точки зрения пользователя отчет будет состоять из столбцов, т.е. пользователь должен перечислить их, но столбец может быть как реальным столбцом из представления, так и функцией, функция в свою очередь либо результат применения встроенной функции к реальному столбцу, либо синтез новой информации на основе других столбцов и встроенных функций. В результате получится Запрос, этот запрос можно использовать повторно.

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

Теперь мы приходим к идее Враппера SQL, точнее это будет назвать Системным хранилищем, фактически это семейство таблиц БД которые содержат исходные данные для построения запроса. Само построение запроса по этим исходным данным, его выполнение и преобразование в конечный формат реализуется отдельными модулями и здесь не рассматривается. Итак, системное хранилище содержит исходные данные и наполняется интерфейсом с которым работает пользователь. Т.е. интерфейс обеспечивает трансляцию описанных выше возможностей пользователя в их формальное представление в виде исходных данных для дальнейшей работы. Что же должен "транслировать" интерфейс и во что ? Смотрим выше, это как минимум определения используемых Представлений, перечни столбцов, определения функций, параметров и пр. Соответствующая структура БД (семейство таблиц) уже есть, досталось в наследство, правда похоже придется подрихтовать, посмотрим, там я еще толком не разбирался, пока пытаюсь определить основу логики и свести все требования воедино.

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

Так, значит все что было выше элементарно, теперь выходим на третий уровень мрака ;) Дело в том что задача разгрузки разработчиков решена не доконца, ведь пользователю необходимо обеспечивать Представления. Ряд основных Представлений включается в комплект поставки, но что если пользователю потребуется нечто оригинальное ? Для небольших заказчиков это не проблема - на них просто кладут. В остальных случаях остается только снова дергать основных разработчиков, а у них и так дел по горло. Значит предлагают такое решение: Обеспечить возможность перекладывания заботы об организации Представлений с плеч основных разработчиков на отдел техподдержки, либо даже на местных админов если те в состоянии, также при этом формально решается проблема с мелкими заказчиками - типа вот вам инструмент, разбирайтесь сами.

Как же обеспечивается такая возможность ? Предполагается разработка интерфейса администратора, с помощью которого возможно создание Представлений. Да, это уже должен быть более менее квалифицированный специалист, это нормально. В качестве помощи предполагается представлять ему т.н. карты БД, т.е. фрагменты реальной структуры с указанием связей и отношений с различных точек зрения (различные карты). Организация сущьностей в иерархии и путешествия от одних сущностей по первичным/внешним ключам к другим, т.е. своеобразный проводник по БД. Впрочем идея сия далеко не первоочередная хотя и реализована в одном из проектов, и боюсь ее отсутствие может стать камнем предкновения при внедрении.

Вот такие как говорится пироги, тут еще надо оговорится что проект коммерческий со всеми вытекающими в области лицензий, сокрытия кода и т.п. это надо учитывать. Теперь в Вашем распоряжении пактически полная информация что к чему, может что еще посоветуете ? Вполне возможно можно использовать какие-то готовые модули, ведь реализации и построителей отчетов, и визуальных дизайнеров БД есть, может быть чтото удастся удачно использовать в описанном контексте ? Уж не знаю кто осилит дочитать сей пост доконца, но по крайней мере я сам впервые за 3 дня таки полностью собрал до кучи и осознал задачу, уже хорошо ;)

спустя 1 час 31 минуту [обр] GRAy(0/259)[досье]
Что-то вы опять черезчур углубились в реализацию. Попробуйте построить типовые use cas`ы для вашего приложения в контексте двух-трёх предметных областей. Вы утверждаете, что пытаетесь уйти от "эмпирической" организации - значит у вас уже должно было накопиться достаточно таких use cas`ов.
Какие действия будет совершать пользователь в процессе создания отчёта? Какие из них чаще нужны, какие реже, какие в крайних случаях - возможно для вас это очевидно, может поделитесь.
спустя 2 дня 16 часов [обр] Thirteensmay(0/157)[досье]
Хм... Задачка оказалась сложнее чем может показаться. Выделил общую линию, часть вариантов использования,, и тут срочная работа... Если не мешает то пусть тема полежит пока, думаю вернуться позже. Вообще ее наверное надо было сначала в Анализ и проектирование, а уж только потом в Usability.
спустя 2 месяца 16 дней [обр] Thirteensmay(0/157)[досье]
Можно сносить, времени на нормальное проектирование нет, будем делать как обычно...
Powered by POEM™ Engine Copyright © 2002-2005