Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Introduction

There are many ways to design, configure and operate your Data Mart. Since different approaches are valid in context, it is not possible to define best practices for every task. However, there are some useful lessons from the experience of Eagle and its clients with Data Mart. This document assumes that you are familiar with how to use Data Mart. The information in this section does not cover basic concepts, but instead recommends specific choices of tools and techniques which lead to better results.

Developing a Data Mart Strategy

Converting Active Reports to Data Mart

You may have built your presentation-quality reports using PACE Active reports. Now that Data Mart is available as an information delivery tool, should you consider converting existing reports to source data against the Mart? This is a complex question, and involves several considerations discussed in the following sections.

Field Standardization

Each Advanced report built with underlying OLAP reports has a list of field attributes associated with it. Advanced reports often involve one or more individual field rules for each underlying OLAP report. Standardization and re-use of field attributes and field rules is possible, but many organizations find that it is all too easy to duplicate fields. Data Mart, by contrast, encourages business definition standardization and sharing of field attributes since duplication of data fields is much more easily recognizable in the Mart and thus avoidable.

Preserving Advanced Report Functionality

You will not lose the benefits of using Advanced reports under a conversion to Data Mart. You can still schedule Active reports built against the Mart to send to Portal, and still develop them as a Client reporting batch. Report ordering functionality and passing of parameters is the same as when actual OLAP reports underly the Advanced report.

If you implement Data Mart to adopt a reporting tool not supported by Advanced reports, you forego the benefits of Advanced reports related to Portal and Client Reporting.

Data Retrieval Staging versus Data Processing

When you run an Advanced report with underlying OLAPs, all of the underlying processing is done on the fly. Some calculations, especially performance calculations, can be time consuming and lead to long rendering times for reports. With Data Mart as the data source, all computations are completed before reports are run, so that reports simply retrieve field values from one or more tables.

However, if reporting in the organization is a matter of running reports in the overnight cycle and not during normal business hours rather than running reports during the day, Data Mart does not offer as much of a total production time savings.

You can create multiple snapshots allowing you to build and save your data more than once per day and use more than one source rule in the build process. Creating multiple snapshots means an organization could maintain a custodian source and a manager source for the same accounting data. By saving multiple snapshots, you could report on intra-day comparisons of data values.

Potential for Sharing Fields

Your reports share many common fields. Data Mart provides the efficiency of computing each one of them just once rather than once per report. Mart data is meant to be shared among reports. For this reason it is critical to make a careful plan of the data fields in the mart to assure that all reporting needs are covered by a minimum of fields.

Report Conversion

There is no utility that automates report conversion. It is difficult to design such a capability that would be useful in a large number of cases.

An Active reports report sources data from PACE field attributes. Data Mart can store data for the same field attributes with the exception of a short list of field types that Data Mart does not support. Refer to the Data Mart User Guide for additional information. The SQL code used by an Advanced report must be reworked in terms of tables accessed and joins used which changes in a Mart conversion.

However, Eagle Mart, which sources from Data Mart, comes with a set of standard reports including report source code for the non-performance set. These reports provide examples of building Advanced reports against the Mart that may be useful to you during report conversion.

Report Development

The Mart offers efficiencies in report development:

Data Mart simplifies the process of building SQL code for bringing your data together in a report. Data Mart places data fields of multiple types, such as position, performance, and transaction on the same line of a data source table at the group and fund levels of aggregation. This saves you the effort of creating multiple OLAP report rules and profiles and then joining their results in SQL that you must develop.

If you report data using time series, you can do so for some performance fields using the Performance Query Tool. For other types of data, OLAP processes are limiting. Through regular daily or monthly builds, Data Mart establishes a history of all data, making time series reporting easy.

Data Mart encourages standardization of field definitions and helps reduce unintended duplication of field attributes that sometimes accompanies OLAP report development. See “Field Standardization” for additional information.

Supporting Non-OLAP Data in the Mart

...

  • Data in structures not supported by OLAPs. The Eagle data model is very flexible and supports a wide range of data structures. You can build custom tables and join them to core tables to permit access by the OLAPs. You can also create database views and build field attributes to report their contents. However, there may be instances where data is loaded to the Eagle warehouse for which OLAP access is not readily available and cannot easily be provided.

  • Report-ready, single-use data loaded in high volume. Even in the case of single use data, Eagle recommends as a best practice that all data is stored in the warehouse followed by Data Mart running the OLAP processes to move a set of values from one warehouse schema to the Data Mart schema. This is the best approach if you want to load data from an external source such as report-ready performance data.

  • Data Moved in Anticipation of a Future Release Enhancement. You may need to deliver a type of information that is supported in Data Mart only in a future release due to a product enhancement. Release upgrade may not be practical before the information is required. If the nature of the enhancement is to enable a new type of field to be built into existing Mart tables, a temporary workaround strategy may be available. Refer to “Direct Loads to Future Table Extensions” for additional information.

...

Direct Loads to Reserved Columns of Mart Tables

The Selective Fields enhancement in V9.0 Data Mart allows you to directly load fields to Data Mart tables as long as you can populate all rows of those tables by a regular Data Mart Submit. You could reserve some fields in the tables that need supplemental data from direct loads. To do this, create and select a set of dummy field attributes for the model to create columns in the table to receive the external load. Selective fields are then used to avoid populating those fields in the regular build, reserving them for the external load. Eagle recommends you create and populate an extension since the Mart does not delete data, but simply updates it.

...

When more than one type of data must be reported in more than one source hierarchy, the number of required source rules can proliferate and lead to several snapshots and heavy duplication of data. For this reason, you should make choices to limit the required list of snapshots. See Sharing of Security Details Among Snapshotsfor additional information.

...