Focal Point
DMC and STAR SCHEMAS

This topic can be found at:
https://forums.informationbuilders.com/eve/forums/a/tpc/f/1381057331/m/127102381

July 17, 2009, 08:45 AM
bcook278
DMC and STAR SCHEMAS
I am looking for some feedback from folks that have been using DMC to build out traditional star schemas (aka kimball dimensional design). We have been loading to star schema for about 8 years using a custom ETL process coded in RPG on an iSeries Platform. We are in the process of moving of iSeries to Linux servers running MySQL and are re-writing our ETL using DMC and noticing a few challenges trying to get this to work the way our old process did. I'd be interested in hearing from anyone that has either faced similar challenges or anyone that thinks this tool works very well with regard to the Star Schema. I see that in the upcoming version 7.7 they are touting some enhancements for star schema loads which makes me think this functionality is still maturing. Any feedback related to this would be appreciated.


WebFOCUS 7.6.8
WebFOCUS Client and Server running on RedHat Linux, Developer Studio on Windows XP
All output formats
July 17, 2009, 12:09 PM
Marina
Some of the improvements, to provide faster loading of slowly changing dimensions, planned for 7.7 have been retrofitted into 7.6.10. Also, DataMigrator allows now overriding the default dates; such as for the end date for active rows, instead of NULL using a day far in the future

This message has been edited. Last edited by: Marina,
July 19, 2009, 11:26 AM
Endre
bcook278 ,

We are using DMC for years with true star schemas. Both Type I and Type II dimensions.

One of the most important thing, and it is for any rdbms, that you should remove indexes before loading and recreate them after load. You can issue SQL level commands with DM, so it is pretty easy to do. (leave logical/natural key indexes on dimensions, but regenerate them after load)

Also, when loading SCD, you should join the target dimension with the source table on the left side of the SQL icon. Join on the logical/natural key. Than in the SQL, filter for columns that are not EQ between the source and the dimension. This cuts down the number of row going over for update/insert on the target dimension. If you have a large dimension, this should give you a big improvement. Remember that every column of every row has to be checked for equality when dealing with SCD.

If you specify specific challenges you run into, I might be able to help.

Endre
"Kimball forever - Inmon never..."


WebFocus 7.6.8
iWay Data Migrator 7.6.8
PMF 5.1