How to cope with surrogate id's after migrating to OWB10gR2

Question

We are busy converting an OWB 9.2 environment to OWB 10gR2.
I already had problems with the way dimensions and cubes are used in OWB 10gR2.
Some of my dimensions will have a steep growth curve because of the level rows that are inserted into the new dimensions. These new rows exist to enable you to link cubes to dimensions at all levels and not only to the lowest level.
But when building the new mappings surrogate keys will also be used to make the join between dimension and cube but this again causes problems for existing reports.
In OWB 9.2 we prepared the cubes and dimensions in the staging area and then loaded them into the data warehouse.
We can still keep the existing columns in the newly defined dimensions we have to add the surrogate keys. But when loading data with the new dimensions and cubes the cubes will refer to the dimension with the new surrogate id’s and not with the old id’s which the business keys are now. So we are losing the relation between cube and dimension based on the business key and we have it now based on the surrogate key.
But the reports we have (made with Information Builders) are still working with the relationships based on the business id’s but since the foreign keys in the cube refer to the surrogate id’s instead of the bushiness id’s the reports will return without results.
I know I can resolve it by redesigning the reports but this is a lot of work and not the way we want to go.
My alternative solutions are
1.keep the new dimensions
but rename them
make views with the old dimension names
in the views switch the old business id and surrogate
the reports will then work with the views and the old joins will keep
on working
2.do not use dimensions and cubes
migrate the mappings to use tables , as a matter of fact this is what
you get after importing a 9.2 MDL into 10.2
no change in table names
the reports keep on working
Alternative solution 1 is rather dangerous because the column names are switched; this makes the model more difficult to understand
Alternative solutions can become a problem if we want to use slowly changing dimensions, we have to build them as we would have done in OWB 9.2, this leads to complex mappings.
Are there any other alternatives, can somebody advise for the best answer to these challenges

Answer 1

Well, couple of ideas here.
First off, do you HAVE to use levels in the dimension? For some of our dimensions, we just define a single "default" level, and tie all attributes to it. For example, with a time dimension, we'd define a default level, and then tie month_id, month_name, quarter_id, quarter_name, year_id, and year_name to that default level. This works out well - you basically get a "flat" dimension with all attributes on the row, thus preventing the generation of keys for the other levels. You'll still get a DEFAULT_LEVEL_KEY, but it will always equal the dimension key and you can just ignore the column.
FYI - I've just started playing with OWB 11gR1, and I discovered a few minutes ago that when setting up a dimension level, you don't appear to have to have the surrogate_id attribute turned on. Not sure if this works yet, will let you know.
Last and not least, I read your problem re: the business keys vs. surrogate keys to be "we used business keys instead of surrogate keys as the dimension PKs and fact table FKs on our initial DW, and now we have to migrate that...where OWB of course wants to use surrogates. Couple of thoughts. First off, I don't think you're going to get any auto-magic way to do this - using business keys instead of surrogate keys is definitely non-standard.
The one suggestion I would have is to do this: keep the original business IDs on the fact table as their own columns. Set them us as "measures" with a data type of varchar2 or whatever they already are. OWB will still of course create the "proper" FK columns based on the surrogate keys, but your users will still be able to join based on the "old" business id joins. The only real price you'd have to pay for this option is a) it takes more space per row on the fact table, and b) you'll probably have to do some indexing. OWB will build the proper bitmap indexes on the surrogate keys, but you'll probably want to add bitmap indexes on the business ID columns.
Hope this helps,
Scott