Database Reference
In-Depth Information
moreover, dimension maintenance of some but not all dimensions is often manual.
What happens when part of a data source does not match dimensionality or an admin-
istrator erroneously renames a member? We both know the answer: kABoom! Insert
the mental image of a bad data mushroom cloud rising ominously over your Essbase
database.
A process that reverses out the dimensions to a SQL table so that constraints in the
form of InnEr JoIns can occur is the first step in guaranteeing that the fact data can
be successfully loaded into the database.
2.4.1.1 Extracting Dimensions
While this step could be done through one of the sev-
eral freeware outline extractors (Applied olap's outlineExtractor and Sebastién roux's
outlinereader are the two most common) or via Essbase 11.1.2.x's maxL “export outline”
command, oDI was used for this part because it can write directly to a SQL table. The
freeware products only write to flat files and maxL outputs only to xmL.
Before ASosamp's dimensions are extracted to the Dimensions table through a series
of dimension-specific Interfaces, Data models for Essbase and the Dimensions table
target and their concomitant Physical and Logical schemas must be defined first in
topology manager. your environment will dictate the specific schema and other defini-
tions. After you reverse the objects, the Essbase ASosamp and SQL table Dimension
Data models will look like table 2.3.
The Dimensions Data model contains some fields that are for the dimension tagged
as “Accounts” only, e.g., timeBalance, varreporting, etc. These properties are ignored
for non-Accounts dimensions on reversal and are set to nuLL. oDI will automatically
map Essbase and SQL field names in Interfaces if the names are identical. The Essbase
Data model names are defined by oDI so it is up to you to define your SQL target fields
in the same way. The alternative is to manually map fields, but why would anyone want
to create manual, error-prone Interface mapping requirements?
Table 2.3
