dhis2-devs team mailing list archive

[Lars Helge Øverland <larshelge@xxxxxxxxx>]

Thanks a lot for contributing to docs :-)

On Mon, Nov 16, 2009 at 1:09 AM, <noreply@xxxxxxxxxxxxx> wrote:

> ------------------------------------------------------------
> revno: 40
> committer: knutst_adm <knutst_adm@knutst2-l>
> branch nick: dhis2-docbook-docs
> timestamp: Mon 2009-11-16 01:06:42 +0100
> message:
>  Report docs
> modified:
>  src/docbkx/en/dhis2_user_man_mod9.xml
>
>
> --
> lp:~dhis2-documenters/dhis2/dhis2-docbook-docs
> https://code.launchpad.net/~dhis2-documenters/dhis2/dhis2-docbook-docs<https://code.launchpad.net/%7Edhis2-documenters/dhis2/dhis2-docbook-docs>
>
> Your team DHIS 2 developers is subscribed to branch
> lp:~dhis2-documenters/dhis2/dhis2-docbook-docs.
> To unsubscribe from this branch go to
> https://code.launchpad.net/~dhis2-documenters/dhis2/dhis2-docbook-docs/+edit-subscription<https://code.launchpad.net/%7Edhis2-documenters/dhis2/dhis2-docbook-docs/+edit-subscription>
> .
>
> === modified file 'src/docbkx/en/dhis2_user_man_mod9.xml'
> --- src/docbkx/en/dhis2_user_man_mod9.xml       2009-11-15 23:30:57 +0000
> +++ src/docbkx/en/dhis2_user_man_mod9.xml       2009-11-16 00:06:42 +0000
> @@ -104,5 +104,42 @@
>  <para>This is controlled through something called aggregation levels and
> at the end of the edit data element screen there is a tick-box called
> Aggregation Levels. If you tick that one you will see a list of aggregation
> levels, available and selected. Default is to have no aggregation levels
> defined, then all raw data in the hierarchy will be added together. To
> specify the rule described above, and given a hierarchy of Country,
> Province, District, Facility: select Facility and District as your
> aggregation levels. Basically you select where you have data. Selecting
> Facility means that Facilities will use data from facilities (given since
> this is the lowest level). Selecting District means that the District level
> raw data will be used when aggregating data for District level (hence no
> aggregation will take place at that level), and the facility data will not
> be part of the aggregated District values. When aggregating data at Province
> level the District level raw data will be used since this is the highest
> available aggregation level selected. Also for Country level aggregates the
> District raw data will be used. Just to repeat, if we had not specified that
> District level was an aggregation level, then the facility data and district
> data would have been added together and caused duplicate (double) population
> data for districts and all levels above.</para>
>  </sect3>
>  </sect2>
> -  </sect1>
> +</sect1>
> +<sect1>
> +<title>Reports</title>
> +<sect2>
> +<title>Report tables</title>
> +<para>
> +Report tables are meant to be database tables fulfilling the specific data
> needs of a report, chart, pivot table or other output format. It can be
> understood as a mini datamart that contains only the data needed for its
> purpose (the report). The rationale behind this concept is to automatically
> provide the data sources for reports without bothering the users every time,
> like a normal datamart, and to speed up the data processing and aggregation
> (small targeted datamarts are obviously faster than big ones).
> +</para>
> +<para>
> +When created and generated a report table will appear in the DHIS 2
> database as a normal table, but always with the prefix _report. This table
> should not be altered manually as it is controlled by the system. These
> tables are constantly being deleted and recreated as the user wants new
> updated data within the same table structure. These tables can then be
> access and used from any third party tool for displaying data. In DHIS 2 we
> have integrated with the BIRT report designer from the Eclipse platform and
> made it especially easy to link BIRT reports to report tables and to run
> these reports from within DHIS 2. However, we see report tables as a much
> broader tool and concept than to just support BIRT reports. It can and
> should (for performance gain and automation) be used for as many data output
> purposes as possible. e.g. as data sources for the database views used for
> Excel pivot tables.
> +</para><para>
> +Report tables are meant to be defined once and then run automatically in
> the background each time a report that depends on it is generated. Reports
> (BIRT, the default report in DHIS 2) is directly linked to one or more
> report tables and these are automatically processed in the background when
> the report is run. To make the report tables reusable over time and across
> orgunits they can have parameters. Three types of parameters are allowed;
> orgunit, parent orgunit (for listing of orgunits in one area) and reporting
> month. As a side note I can mention that we are looking into expanding this
> to include reporting quarter and year, or to make that period parameter more
> generic with regard to period type somehow. Be able to use period as a
> parameter makes the report table reusable over time and as such fits nicely
> with report needs such as monthly, quarterly or annual reports. When a
> report is run by the user in the DHIS 2 the user must specify the values for
> the report tables that are linked to the report, and first the report table
> is re-generated (deleted and re-created with updated data) and then the
> report is run (in BIRT report engine).
> +</para><para>
> +Report tables can consist of either values related to data elements or
> indicators, and not a mix of the two. A third report table type is data
> completeness, which is related to completeness of reporting across orgunits
> for a given month. Completeness reports will be covered in a separate
> section. The reason for not mixing data elements and indicators in one
> report table is due to the cross tab functionality that would be very
> complex and less useful with yet another dimension. Since two or more report
> tables can easily be linked to one report this limitation should not have
> much effect on report design possibilities.
> +</para><para>
> +There are three dimensions in a report table that identify the data;
> indicators or data elements, orgunits and periods. For each of these
> dimensions the user can select which metadata values to include in the
> report. The user must select one or more data elements or indicators to
> appear in the report. The orgunit selection can be substituted with a
> parameter, wither one specific orgunit or an orgunit parent (making all its
> children appear in the report). If one or more orgunits are selected and no
> orgunit parameter is used then the report is static with regard to which
> orgunits to include, which in most cases is an unnecessary restriction to a
> report. The period selection is more advanced as it can in addition to
> specific periods like Jan-09, Q1-08, 2007 also contain what is called
> relative periods. As report usually is run routinely over time a specific
> period like Jan-09 is not very useful in a report. In stead, if you want to
> design a monthly report you could use the relative period called Reporting
> Month. Then you must also include Reporting Month as one of your report
> parameters to let the system know what exactly is the Reporting Month on the
> time of report generation. There are many other relative periods available
> and they all relate to the report parameter Reporting Month. E.g. the
> relative period called So far this year refers to the accumulative value for
> the year incl. the Reporting Month. If you want a trend report with multiple
> periods in stead of one aggregated period you can select e.g. Individual
> Months this year which would give you values for each month so far in the
> year, and you can do a similar report with quarters. The idea is to support
> as many generic report types as possible using relative periods, so if you
> have other report needs please suggest new relative periods on the mailing
> list and they will be added to the report table options.
> +</para><para>
> +Cross tabbing is a very powerful functionality in report design as the
> typical DHIS data table with references to period, data element/indicator
> and orgunit makes more advanced report design very difficult as you cannot
> put e.g. specific indicators, periods or orgunits on specific columns. E.g.
> by cross-tabbing on the indicator dimension in an indicator report table you
> will get the indicator names on the column headers in you report, in
> addition to a column referencing orgunit, and another column referencing
> period. With such a table design you could drag and drop indicator names to
> specific columns or chart positions in the BIRT report design. Similarly you
> can cross tab on orgunits or periods to make their names specifically
> available to report design. E.g. by cross-tabbing on periods and selecting
> the two relative periods, reporting month and so far this year you can
> design reports with both the last month and the accumulative annual value
> for given month as they will be available as column headers in your report
> table. It is also possible to combine two dimensions in cross-tabbing, e.g.
> period and indicator, which makes it possible to e.g. look at three selected
> indicators for two specific relative periods. This would e.g. make it
> possible to make a table or chart based report with BCG, DPT3 and Measles
> coverage, both for the last month and the accumulative coverage so far in
> the year.
> +</para><para>
> +All in all, by combining the functionality of cross tabbing, relative
> periods and report table parameters you should have a tool to support most
> report scenarios. If not we would be very happy to receive suggestions to
> further improvements to report tables. As already mentioned we have started
> to look at more fine-grained parameters for the period dimension as the
> Reporting Month does not cover or at least is not intuitive enough when it
> comes to e.g. quarterly reports.
> +</para>
> +</sect2>
> + <sect2>
> +<title>BIRT reports</title>
> + <sect3>
> +<title>Create a report table in DHIS 2</title>
> +<para>- create a report table in DHIS 2 is to create so-called report
> tables in DHIS, found under Reports module, which will serve as the data
> table for your report. Normally one table per report, but multiple tables
> for one report is also possible. A report table can be a cross tabulated
> table on any of the dimensions period/indicator/data element / orgunit, and
> also in combination, like “BCG &lt; 1 coverage + last 3 months” and “BCG
> coverage &lt; 1 year+ last month”. This cross-tabulation makes it a lot
> easier to control the design of the report which is then done with dragging
> and dropping column headings onto the report. The report table can also have
> report parameters like reporting month, organisation unit and organisation
> unit parent (if you are e.g. listing all sub-districts in a given
> district).</para>
> +</sect3>
> + <sect3>
> +<title>Design the report in BIRT</title>
> +<para>Then you design the report in the stand-alone BIRT designer (based
> on the Eclipse platform) and access the report table in the DHIS 2 database
> using a jdbc connection and an sql query (all using the BIRT user
> interface). When you have connected to the table and selected which columns
> to use they will be available as fields that you can drag and drop onto your
> report design. In BIRT you can preview the report at any point, and when
> you're done you can save the report as an xml file (.rptdesign). More
> instructions here:
> http://208.76.222.114/confluence/display/HISP/Birt+designer%27s+notes
> </para>
> +</sect3>
> + <sect3>
> +<title>Define and run the report in DHIS</title>
> +<para>(the very first time you need to configure where the BIRT report
> viewer is installed, go to Reports→Report→Configure report) In DHIS 2 you
> can define a report in the Reports module that you link to a report table
> and provide with a name. Then the report is ready to be generated and
> displayed, and this can be done in two ways, 1) run report with new data or
> run report with existing data. This all depends on whether your report table
> is populated already or not. Most likely you will have to run it with new
> data and then you are asked to provide values for the report parameters (if
> defined in the report table) and then the table will be populated in teh
> background and a new window will show the report as soon as it is ready. The
> new window will actually be generated by the BIRT report viewer, which is a
> separate web application running on the same tomcat instance.</para>
> +</sect3>
> +</sect2>
> +</sect1>
>  </article>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
> More help   : https://help.launchpad.net/ListHelp
>
>