As of December 1, 2020, Focal Point is retired and repurposed as a reference repository. We value the wealth of knowledge that's been shared here over the years. You'll continue to have access to this treasure trove of knowledge, for search purposes only. Moving forward, myibi is our community platform to learn, share, and collaborate. We have the same Focal Point forum categories in myibi, so you can continue to have all new conversations there. If you need access to myibi, contact us at email@example.com and provide your corporate email address, company, and name.
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
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 futureThis message has been edited. Last edited by: Marina,
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.