Why use/sell OWB 9.0.4

Question

Can somebody tell me how I can convince customers to use OWB 9.0.4 when this tool isn't capable to create a simple data warehouse similar to the example that comes with the Oracle 9i database (SH schema).
To test the 9.0.4 version of OWB I have tried to import the data warehouse example into OWB, but the only objects I got were tables without the dimension information. Even the partition and tablespace information of the tables got lost.
So I tried to recreate the exact same dimensions as the example but OWB failed again. After 3 years listening to every promise made by Oracle, I had great hopes that OWB 9.0.4 finally would be capable to create dimensions that are physically stored in multiple tables. I was quite dissapointed to find out that the dimension modeller in OWB 9.0.4 hasn't changed a bit. Even primary and unique key constraints still can't be assigned to a specific index tablespace. So why should I use dimensions in OWB if Oracle still believes that every dimension is always one table? Even their own example proves otherwise.
It would be a lot easier when all the target objects are listed as tables and that you can use the dimension and cube objects to add some specific characteristics to these tables. Maybe that the OWB development team can take a look at how Oracle Enterprise Manager defines dimension objects. That is why I prefer to use Oracle Designer and if neccessary Oracle Enterprise Manager to create the physical database structure and only use OWB or a third party ETL tool to create the mappings and process flows.
My opinion after seeing OWB 9.0.4 still is that if the mapping builder, a decent dimension modeller and other OWB functionality had been added to Oracle Designer three years ago, Oracle would now have a far better data warehouse development tool than OWB will ever be. Even the GUI will be better off and more easy to use.
With kind regards,
Rob Nijland
Intelligence in Information BV
The Netherlands

Answer 1

Rob,
Let me address some of the issues below.
You state:
"Much to my regret I must say that I have already heard these kind of promises for the last three years."
Warehouse Builder's first release 2 became available in February 2000. I.e. the product exists 3 years now. I cannot comment about promises that have been made in the past, but we are definitely working on the feature to implement snow-flake modeling. I understand your frustration about the fact that it is not available today, but if you read Kimball he does state: unless you have a very good reason to create a snowflake implementation you should never do so.
Page 95 of Kimballs 'Data Warehousing toolkit' starts with: 'Resisting the Urge to Snowflake'. Page 97 states: 'Do not snowflake your dimensions, even if they are large. If you do snowflake your dimensions, be prepared to live with poor browsing performance.'
Irrespective of what Kimball states, I hope you can agree that OWB has moved forward in the last 3 years. OWB development has a limited number of resources and we can only address so many areas of the product in so much time. Please do understand that we do our utmost to create a product that suits our users' needs.
You state: "I have tried to import a converted OWB 9.0.2 project into OWB 9.0.4. The import went well, but the problems started when I tried to validate and generate the mappings. I received a lot of warnings that parameters of custom as well as pre-defined functions were invalid. I reconciled the functions but as soon as you try to reconcile a pre-defined function the link to the target object is gone. This means that I have to walk through 40 or more mappings, reconcile everything and partially have to rebuild the mappings."
When links between objects and implementations in a mapping used to exist but get removed upon migration you are hitting a serious bug. Please do submit your case to metalink or work with me directly ([email protected]) to get these problems resolved.
You state: "Furthermore in the mappings all table aliasses have been replaced. For example I have used aliasses, such as 'CUSTOMERS_NEW_VERSION' and 'CUSTOMERS_OLD_VERSION' after a split object to quickly identify what happens during a slowly changing dimension type 2 build. Now the aliases have been renamed to 'CUSTOMERS' and 'CUSTOMERS_1'. The only option is to open the splitter to find out what is happening and to rename the aliases again to keep the documentation valid."
Again, if a rename takes place upon migration then you are hitting a bug.
You state: "After validation I also got some warnings that I should not set the schema name. But this means that the only option I have is to create an connection between locations (eq. database link), even if my source and target are on the same database but in different schemas."
In the 9.0.4 release we introduce new concepts locations and connectors that we recommend you use. The concepts introduce benefits that you may not see in the first place. Please take a look at a Runtime update whitepaper that has been posted to OTN.
With respect to set-based updates using OWB: our experts state that bulk row-based updates in general are quicker than comparable set-based updates. If you disagree for your business case(s) then I would like to understand your requirements better so that we can work on these. Please contact me directly.
Thanks.
Mark.