The fact SALES_AMOUNT has been enjoying a quiet life for the last five years until, one rainy day, the new QA guy called Eureka! and proudly informed everyone that according to the naming conventions the fact name should be SLS_AMT. Of course, he took the liberty of checking the source tables and discovered that they too should be updated to match the aforesaid conventions. Way to go, QA guy!

What do you do? You could swear the QA guy or, if you are more literary inclined you could write him a bitter limerick and post it on the Intranet. Seriously now, how do you go about accommodating this change? I’ll skip the whole ETL part and go directly to MicroStrategy, right after the source tables were updated.

What you can’t do is go to the Warehouse Catalog and update the source tables’ definition. The catalog would just throw a number of dependencies that need to be solved before performing the update. You can’t delete the fact either, as it is being used by several metrics which in turn are being used in reports, and so forth.

The thing to do is to make the fact independent of any table. There are some ways this can be achieved, and one of them is to clear the fact definition and map it manually to “1”. You can actually write anything in the definition field, as long as it is not “SALES_AMOUNT”.

Thus the fact is no longer related to any of its source tables. Now it’s the time to update the tables’ definition in the Warehouse Catalog. After that, just go back to the fact editor and map it automatically to “SLS_AMT” and perform a schema update.

A similar process can be applied to attributes. Rather than mapping an attribute element to “1”, you can try to temporarily map it to any other column in any other table. Most likely the relationships with other attributes will be lost because of this, but they can easily be restored when all work is finished.