An understanding of the dependency of objects within Analysis Services is the key to figuring out what needs to be dropped or recreated in a cube database using WhereScape RED.
Changes to the underlying relational star schema can cause cube processing to fail as the star schema is frozen in the Data Source View (DSV) of the cube database. Minor changes such as the addition of table columns or altered data types (e.g. changing a char to varchar) does not break the cube, but renaming a source table or column that is used as a source to the cube invalidates the DSV and cause processing to fail.
The solution to this issue is to drop and recreate the Cube database from RED to recreate the DSV or manually update the DSV using Microsoft BIDS.
If an object needs to be dropped and recreated in RED, then these are two separate actions. For example, to drop the OLAP database, right-click an OLAP cube within that database in RED and select Drop Analysis Services Object, and then either double-click an object in the list or use the drop-down boxes in the Drop Analysis Services Object window to choose the object to drop and click Drop. This will drop the object from Analysis Services.
A Create action on an Analysis Services object in RED will be different depending on whether or not the object already exists in Analysis Services:
- If the object does not already exist in Analysis Services then RED will create the object (and any related objects e.g. OLAP database and DSV).
- If the object does already exist in Analysis Services then RED will try to detect any changes or additional features that need to be added to the object and add or alter the existing Analysis Services object.
Some objects need to be dropped and recreated in order to be changed (e.g. dimension structures), and some only need to be recreated (e.g. calculations).
Changes to cube runtime objects do not require the cube database to be dropped. For example a new or changed definition of a calculation or KPI will not require the cube to be dropped and recreated (so data is retained). Recreating the cube, updates the definition of these runtime objects and immediately becomes available to cube users.
A brief summary of the hierarchy of objects and the remedial action is shown below:
Cube Object | Change | Action |
|---|---|---|
Data Source | This changes the source database connection. It is defined in the Data Warehouse connection in RED. | OLAP database needs to be dropped and recreated. |
Data Source View (underlying relational star) | The DSV reflects the design of the relational star. Therefore, the DSV would need to be updated if any changes are made to tables or views that are used to build OLAP objects. | Changes to the underlying relational star that affect an existing OLAP Object requires that the OLAP Database is dropped and recreated to regenerate the DSV. |
OLAP Dimension | The addition or deletion of attributes or hierarchies to an existing OLAP dimension. | The OLAP dimension plus any OLAP cubes associated with the dimension need to be dropped and recreated. |
OLAP Cube Measure Group | Delete or Add a Measure Group based on a fact that already exists in the DSV. | Recreate the cube in RED and reprocess. |
OLAP Cube Measure Group | Add a Measure Group based on a fact that does not exist in the DSV. | Recreate the OLAP cube database and reprocess. |
OLAP Cube Measures | Delete or Add measures based on columns that already exist in the DSV. | Recreate the cube in RED and reprocess. |
OLAP Cube Measures | Add measures that are based on new columns that do not exist in the DSV. | Recreate the OLAP cube database and reprocess. |
OLAP Cube Calculations, KPIs, Actions | Add, change or delete definition on the cube. | Recreate the cube in RED (a reprocess is not necessary because just the calculation definition is stored in the cube—the result is calculated at query time). |