| BIRT and structured data sources [message #27358] |
Mon, 18 April 2005 01:20  |
Eclipse User |
|
|
|
Originally posted by: bjoern.brauel.softwareag.com
I was just looking at the very impressive work that has been done with
BIRT so far, however from looking at the oda implementation I come to
the conclusion that the current data model for representing data-sources
is fairly relational, from my point of view it would be desireable to
have support for an XML-Schema type data model underneath the oda
implementation. While most use-cases today of BI and Reporting are based
on relational databases I do see a need both from the architectural as
well as the use-case side to base a reporting/BI tool on a document
centric data-model. Anyone from Actuate have a comment on this , or
should I start prototyping it right away :) ?
cheers .. Bjoern
|
|
|
| Re: BIRT and structured data sources [message #28915 is a reply to message #27358] |
Wed, 20 April 2005 02:13  |
| Eclipse User |
|
|
|
Bjoern,
You raise an excellent question, one that we've wrestled with quite a bit.
Tabular data is a no-brainer; reporting tools have handled it forever. It is
easy to see how to group, sort, summarize and display such data. For
example, a list of customers.
Handling data in the form of a simple hierarchy is also clear since a
hierarchy can simply be flattened into rows and processed as above. For
example, an XML document that lists customers, their orders, and the items
within orders can easily be flattened to produce a customer/orders/items
report, or a list of orders with back-ordered items, or the list of
customers who ordered certain items.
Reporting on non-tabular, multi-hierarchical data is a bit less clear. For
example, how does one report on data with multiple hierarchies (customers
and a list of orders followed by a list of support calls.) One can imagine
linkages between the report layout and the various hierarchies, but it seems
to get rather too complex fairly quickly. Or, perhaps people want to divide
this into three data sets? Customers, orders for a customer, calls for a
customer?
Finally, pure documents seem the most complex at all. How does one report on
an HTML page? On a BIRT report design? Where is the repetition that reports
present? This is where we, steeped in the world of reporting, get a bit
stuck.
The answers will come, we believe, from understanding actual use cases. What
kind of data does someone have and what kind of report do they want to
create? With enough cases, patterns will emerge, and we'll all slap our
foreheads and say "Aha! That's what we should do." Just haven't got there
yet.
Certainly, if you've got an application that will shed light on these
questions we're all ears. And if you can spare a bit of time to code up a
solution, so much the better!
Thanks,
- Paul
Paul Rogers
BIRT PMC
"Bjoern Brauel" <bjoern.brauel@softwareag.com> wrote in message
news:d3vghg$8ki$1@news.eclipse.org...
>I was just looking at the very impressive work that has been done with BIRT
>so far, however from looking at the oda implementation I come to the
>conclusion that the current data model for representing data-sources is
>fairly relational, from my point of view it would be desireable to have
>support for an XML-Schema type data model underneath the oda
>implementation. While most use-cases today of BI and Reporting are based on
>relational databases I do see a need both from the architectural as well as
>the use-case side to base a reporting/BI tool on a document centric
>data-model. Anyone from Actuate have a comment on this , or should I start
>prototyping it right away :) ?
>
> cheers .. Bjoern
|
|
|
Powered by
FUDForum. Page generated in 0.02364 seconds
Home