Hot-Swappable Dimensions - What's the next best approach?
2 posters
Page 1 of 1
Hot-Swappable Dimensions - What's the next best approach?
I am using OBIEE which does not appear to support hot-swappable dimensions. What is the next best approach?
RobLL- Posts : 7
Join date : 2013-12-09
Location : UK
Re: Hot-Swappable Dimensions - What's the next best approach?
I have a Product dimension, where some attributes have different values depending upon the country/organisation. With hot swappable dimensions the user would be able to select a particular country/organisation version of the Product dimension, or a version that of the Product Dimension that excluded the country/organisation dependent attributes, at query time. Oracle's OBIEE does not support this as far as I am given to understand.
RobLL- Posts : 7
Join date : 2013-12-09
Location : UK
Re: Hot-Swappable Dimensions - What's the next best approach?
Here's yet more detail of the requirements.
Most product attributes have a value that is set globally but some are set per country. An example of the latter is Price Band. For a produc, each country can specify it has a different price band. Queries made using country-specific attributes, only query country specific facts e.g. sales in that country. For example, if the user wants a report of sales by price band, it will be for sales in the country whose price bands are being used in the report.
My question is how to model the Product Dimension.
Alternatives I have thought of are:
1) Have a Product Dimension that has a row per combination of country and product. Each Fact would then have to be related to a row in the product dimension that identifies both the product and country it relates to. Disadvantages include the possibility that some facts may not be country specific (I don't have examples yet).
2) Have a Product Dimension with one row per product. Also have a Country Product Dimension that contains only the product attributes that are country specific. Thus, facts that are country related can have relationships to both these dimensions, whereas, facts that are not country specific can just be related to the Product Dimension.
3) Have a Product Dimension with one row per product that the facts relate to. Have a Country Product Table with one row per combination of country and product with a one to many relationship to it from the Product Dimension table and Fact tables do not relate directly to this Country Product table.
4) My favourite option was to have a hot swappable Product dimension but I am given to understand OBIEE does not support this so I am seeking an alternative approach.
Most product attributes have a value that is set globally but some are set per country. An example of the latter is Price Band. For a produc, each country can specify it has a different price band. Queries made using country-specific attributes, only query country specific facts e.g. sales in that country. For example, if the user wants a report of sales by price band, it will be for sales in the country whose price bands are being used in the report.
My question is how to model the Product Dimension.
Alternatives I have thought of are:
1) Have a Product Dimension that has a row per combination of country and product. Each Fact would then have to be related to a row in the product dimension that identifies both the product and country it relates to. Disadvantages include the possibility that some facts may not be country specific (I don't have examples yet).
2) Have a Product Dimension with one row per product. Also have a Country Product Dimension that contains only the product attributes that are country specific. Thus, facts that are country related can have relationships to both these dimensions, whereas, facts that are not country specific can just be related to the Product Dimension.
3) Have a Product Dimension with one row per product that the facts relate to. Have a Country Product Table with one row per combination of country and product with a one to many relationship to it from the Product Dimension table and Fact tables do not relate directly to this Country Product table.
4) My favourite option was to have a hot swappable Product dimension but I am given to understand OBIEE does not support this so I am seeking an alternative approach.
RobLL- Posts : 7
Join date : 2013-12-09
Location : UK
Re: Hot-Swappable Dimensions - What's the next best approach?
The various alternatives you listed are all viable options. It is also a common approach when dealing with multiple languages.
There are ways you can deal with swappable dimensions in an OBIEE environment. You would set up a central database for the OBIEE physical tables and a database for each country you support. In each country specific database, you define Synonyms to reference the tables in the central database. For country specific tables, the synonym would use the standard table name but reference the country specific version. User accounts would be set up to default to a specific database based on the appropriate country. The query environment would be unaware it is using country specific tables.
It is not exactly the same thing, as they would not be able to change country at query time, but it may be a workable solution in most cases.
There are ways you can deal with swappable dimensions in an OBIEE environment. You would set up a central database for the OBIEE physical tables and a database for each country you support. In each country specific database, you define Synonyms to reference the tables in the central database. For country specific tables, the synonym would use the standard table name but reference the country specific version. User accounts would be set up to default to a specific database based on the appropriate country. The query environment would be unaware it is using country specific tables.
It is not exactly the same thing, as they would not be able to change country at query time, but it may be a workable solution in most cases.
Re: Hot-Swappable Dimensions - What's the next best approach?
Thanks ngalemmo. We've opted for option 2. This was after considering the IBM Red Book at http://www.redbooks.ibm.com/redbooks/pdfs/sg247138.pdf. Section 5.3.12 (Heterogeneous Products) supports a more complex example of what we are after, so allowing for our simpler situation we end up with option 2.
RobLL- Posts : 7
Join date : 2013-12-09
Location : UK
Similar topics
» Measures as Dimensions: Banding Approach Help
» Hot Swappable Dimension -> best practice for implementation of swapping logic?
» SCD type 2 approach.
» Value Banding
» Fact table and a duplicate one, please clarify
» Hot Swappable Dimension -> best practice for implementation of swapping logic?
» SCD type 2 approach.
» Value Banding
» Fact table and a duplicate one, please clarify
Page 1 of 1
Permissions in this forum:
You cannot reply to topics in this forum