Database Reference
In-Depth Information
3. “Load data” loads fact data to Essbase.
4. “validate” validates the fact data totals to Essbase totals.
Why Continue Using Packages if Load Plans Are So Great?
As previously noted, sometimes Load Plans are not a good replacement for Packages as in PKG_LoopAndLoad because of
missing Load Plan functionality.
Relevant Examples
If you examine the steps “Load data” and “Validate,” you will see that these are also Packages. I purposely did not con-
vert these to Load Plan steps because Load Plans are so new and the solutions I have provided are not the standard ODI
Interface approach. I wanted to reach the majority of ODI installations today that are using older versions of the product
as of the writing of this topic. However, the sequential steps in these Packages could easily be converted to a Load Plan
(another challenge to the reader).
2.5 ConClusion
And, so we come to the end of an epic data quality quest. Do your feet hurt? or maybe
your head? no matter, together we have Slain the Beast called Bad Data. may it never
stain your Essbase database's honor.
Was the journey worth the cost? What
you
need to decide is, was this chapter's long
trip to data quality worthwhile? of course I am ever so slightly biased, but consider this:
• The case for the dangers of bad data has been made by real world examples.
recall that these examples mostly ended in unemployment. If you do not have
this issue licked, begin trembling in terror.
• The where (and the where never) and how to ensure data quality is laid out in
a heavily annotated form over the four steps of metadata extraction, missing
metadata identification, metadata and data loading, and Essbase to source data
validation. you can use this approach and much of the code in your databases,
even if you never use oDI.
• Following on that last point, a slew of advanced oDI, maxL, and SQL tech-
niques are demonstrated and documented in this chapter's appendix. The con-
cepts behind the code can be used in nondata validation tasks.
Just as I channeled and then paraphrased President reagan about trusting, but ver-
ifying data, you must channel President kennedy and hold that: “Let every business
owner know that you shall pay any price, bear any burden, meet any hardship, sup-
port any friend, oppose any foe, in order to guarantee good data in Essbase and assure
continued employment.”
Bad data in Essbase means pain for all concerned, yet it occurs all the time. We
Essbase developers all know this and if we have any imagination about its impact on our
livelihoods, we fear it. That this evil persists when the tools to combat it fall readily to
hand makes its propagation all the more difficult to understand.
This chapter cannot explain why we Essbase practitioners tend to honor data qual-
ity more in the breach than in the observance, especially given the direct professional
and personal consequences. Perhaps this chapter
is
a kind of pop psychology guide
that will make you more strongly consider including a data quality step in your cur-
rent and upcoming Essbase projects. or, maybe you can use it as a lever on a tight-
fisted project sponsor who does not want to pony up the cash to get his data right
from the start.
