Database Reference
In-Depth Information
If you do not have a data warehouse or mart for fact data or a corporate metadata
manager (you really do live under an unlucky star, do not you?), you must build the
hierarchy yourself. In some ways, metadata is trickier than fact data because that is
at the leaf level while the hierarchies must be constructed from a supporting struc-
ture that may not exist. With luck, most of your hierarchies can be lifted straight from
the source application. The tricky bit is what to do when the hierarchy Essbase needs
are nowhere to be found. Do not build and maintain that hierarchy in Essbase alone.
Essbase databases can become corrupt. They can get deleted (with intention or some-
times without). They can get modified by someone who should not have administra-
tor rights to Essbase. you need a good hierarchy source outside of Essbase—parent/
child SQL tables often work well. The additional effort to build that metadata store
will be worthwhile in the end. many customers have invested in oracle's Drm (Data
relationship management) product to alleviate the burden of metadata management.
Depending on the size of your organization, number of dimensions and members, fre-
quency of updates and complexity, purchasing a metadata management tool you should
explore within your organization. These tools require significant financial resources to
implement, but once in place, they can be a lifesaver.
Data validation against a source system is the same process as when going against a
proven data warehouse or data mart. Extract subtotals where applicable from the source
and compare them to Essbase. If the data is right, their variance will be zero. If there is
a variance, start back tracking. Again, Chapter 2 will give you the technique to do this
technical validation.
Ensuring data quality all comes back to you, the Essbase administrator. Data that
mathematically agrees with its source is valid as far as Essbase and the source are con-
cerned, but that technical approach does not address all data quality issues. If the source
definition is bad, even within a warehouse, then Essbase will reflect bad data that devi-
ates even farther from the truth because of its aggregated nature.
11.3.5 You Are Super Glue
The only comprehensive and ultimately correct way to solve issues, be they data quality,
calculations, or reports is to have a detailed understanding of the business processes,
learn and document how data is compiled, and then translate that combination of busi-
ness and technology to Essbase. This is too low level and technical for the project sponsor
and external consultants do not know your business well enough. It is only interested in
the nuts and bolts of the system, and the SmEs understand the business but not It. The
end users are not involved, interested, or available to help resolve data issues. That leaves
you: the Essbase administrator. you are the glue that joins your company's business to
the analytic functionality of Essbase. no other player in your organization will have this
combination of skills and perspective. See, you are special. you knew it all along; you
just did not know how very special and unique you really are.
11.3.6 Training Thyself
now that you know how special you are, you need to retain that uniqueness by ensur-
ing that your Essbase skills are keeping pace with the needs of your organization. yes,
even though Essbase constantly has new releases that are supposed to be really great, for
the average client-based Essbase team member, the two new calculation functions for
BSo (block storage option) and the latest and greatest enhancements to ASo (aggregate
storage option) do not exactly have us doing cartwheels. What is the practical difference