Re: Business Objects with DB2 data

In the 1980s, I worked for a software company that developed end-user reporting tools for IBM mainframes. We found that most end-users had difficulty with joining multiple tables or files, so we recommended customers have an "administrator" to create views of the data -- that took care of (hiding the details of) how to join one or more tables, to present to the end user the appearance of a "flat file". Then, they could write their own query logic to select (a subset of) records from that view, and they could then select (a subset of) fields from that view to include in their reports, and of course, they could specify how they wanted the reports to be formated (control breaks, layout, etc.)

I suggest your company designate one or more members of your IT staff to act as "database administrators" (DBAs) to support end-user reporting requirements by creating "views" of the data for those end-users. You can do this with DDS based logical files, or,use SQL DDL to create SQL VIEWs. One benefit of DDS Logical Files is that an "index" can be automatically created as part of the LF, while with SQL, you create a VIEW over the data, and you must still create one or more SQL INDEXes over the base table(s) to improve performance. Whenever a request comes to IT for a "mew report", a DBA determines if an existing view can be used and notifies the users, or fi needed, they create a new view and then inform the users. This way, gradually, over time, you build up a set of customized views for reporting purposes that are tailored to the needs of your end users.

Once these views are created, end-users can use Query/400, or Query Manager/400, or SEQUEL, or pretty much any reporting tools, such as Microsoft Access or other PC-based reporting tools, to go against those logical views -- whatever tools the users are familiar with, and that allows them to "get the job done" with a minimum of fuss and re-training.

Another important benefit of using "views" of the data is that you can use security and authorization to restrict direct access to the actual database (PFs & LFs or TABLEs and VIEWs) of the applications so that the end-users cannot directly access the "raw" data. Then you grant authority to the end users to use only those "reporting views" created specifically to support end-user reporting requirements. Such access is normally "read-only".