Database Reference
In-Depth Information
as you become more adept with oDI. In any case, we will follow the all-important four
steps. I am sure you remember them, but just in case:
1. Extract dimension metadata to a table.
2. Identify and load missing dimension metadata.
3. Load the fact data.
4. validate the data in Essbase to the fact data.
A Note about ODI Project Organization
SubfFolders
A folder hierarchy within an ODI Project is not mandatory, but it can help logically organize code modules. Numbering the
folders, as in Figure 2.2, will sort them in logical process order and, yes, these are the four steps to data quality realized in ODI.
Location of Objects
To get around ODI's default unorganized lists of objects, I match the location of objects with their scope, such as
Procedures that are local to a subfolder within that folder. Project global objects are stored in the default location in the
Project's First Folder. As an example, the Procedure PROC_DataNotInMetaData is only used in the Packages within the
subfolder 2—LoadMissing, and consequently is stored there per Figure 2.3.
Naming Conventions
Although categorizing objects through subfolders aids organization, it is easy (at least for me) in an even moderately
complex project to get very confused as to what a given object does. Looking at Figure 2.4, is it obvious what each
object does?
Figure 2.2
Designer folders.
Figure 2.3
Object organization.
