Сбор данных в объектной БД

[Сергей С.]

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

Не могу написать Генератор Отчетов (а-ля Мастер отчетности в MS Access) для объектной базы, такой чтобы был прост в использовании. То бишь для конечного пользователя, а не для эксперта по SQL и реляционной алгебре. Может, подскажете, какие есть способы поиска информации по объектным базам данным?

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

Заранее благодарен.

[x77]

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

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

[Сергей С.]

Спасибо за ответ.
Была такая мысля, но, и пользователи неопытные, и заказ важный, и потребности у пользователей шибко растущие.
Хотя, сейчас почти реализован подобный вариант:
В коде системы отчетности на уровне подключаемых компонент реализованы шаблоны отношений между классами, которые определяют как и через какие  свойства классы связаны. Пользователь выбирая шаблон, по сути определяет группу отчетов - остается только определить выводимые свойства (из уже ограниченного множества) и прочие параметры типа фильтров, сортировки, группировки, функции и т.д.,  типа как в Акцессе, если схема отношений определена, то в дизайнере просто можно выбирать какие поля нужно включить в отчет и с какими ограничениями, объединения таблиц в Акцессе беруться из схемы.
Трудоемко, только оказалось спроектировать продукт, чтобы расширяемым остался. У меня уже была реализация - но изменился набор классов в ОБД и требования пользователей,и оказалось, что имеющаяся реализация никак не растянется под новые требования, хотя она при первом рассмотрении покрывала 50% отчетов.

[x77]

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

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

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

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

[Сергей С.]

И такая идея была. Для реляционных и файловых бд (через ODBC) есть даже компонент такой - ContourCube, который как раз генерацией локального куба занимается и UI по всем OLAP операциям предоставляет гибкий. Баловался, понравилось, но в другом проекте.
Текущий проект  на ZODB базе. Сама база есть дерево (физически только 1 родитель у объекта). Из программных инструментов по поиску данных, так называемый ZCatalog - который индексирует объекты выбранного подмножества классов по указанным свойствам,  по которым в последствии можно выбирать данные. Пользовательский интерфейс продукта - HTML (под Zope разработка).
И проблема, скорее, изобретения велосипеда..