The Results Area consists of a set of star schemas with conformed dimensions and common fact tables. Integration of results from multiple application use cases is achieved by having common fact tables for customer and account level measures. The design of the results area allows for drill-down and drill-across BI reporting, which should be preserved after customization.
Following are the Results Area Design Guidelines:
· Ensure that the naming convention for results tables and columns detailed in Appendix A, page A-1 section is followed.
· Dimensional conformance should be maintained: The same dimensional information should not be represented in different forms. In addition, dimension table design should be compatible with the slowly changing dimension process design and so should have the required columns.
· The common accounts summary fact table.
· (FCT_COMMON_POLICY_SUMMARY) consolidates measures at an account level granularity for all applications. Account level attributes captured from source systems in staging and those attributes that do not vary between runs should be part of the common accounts summary table. This enables integrated reporting of account information.
NOTE |
Any account level application specific attributes and measures that are computed by applications should be part of the application specific account summary entities. |
· The common customer summary fact table.
· (FCT_COMMON_CUSTOMER_SUMMARY) consolidates measures at a customer level granularity for all applications. Customer level attributes captured from source systems in staging and those attributes that do not vary between runs should be part of the common customer summary table. This enables integrated reporting of customer information.
NOTE |
Any customer level application specific attributes and measures that are computed by applications should be part of the application specific customer summary entities. |
· Aggregate Entities: Depending on performance requirements for each application, information can be reported out of aggregate entities. However, a drill through to the base entity from the aggregate entity is mandatory.
· Reporting and local currency support: Include additional attributes in the fact tables to store reporting and local currency equivalent of base measures. These attributes need to be computed by looking into the exchange rates.
· Support for full history: Any new tables in the Results area should be designed to support maintenance of full history.