It depends on the volatility of the attribute values. For example, Suppose Product is a type 2 dimension with three attributes: Size,
Price, Quantity. I am assuming that:
- Size: Changes rarely
- Price: Changes every now and then
- Quality: Changes rapidly.
A solution could be:
Size: Store in the Product Dimension Table and create a new dimension
record with a different Surrogate key when it changes
Price:Store in the dimension and fact table, and apply a type 1
dimension update (Ovewrite value)
Quantity: Store in fact table
Re: So a Dimension 2400 is worthless, huh.... ... I've resold at least a half dozen Dimension 2400s to various people who have not ... expressed any ill will towards their machines.... it is a great deal at the price.... >> that there is no upgrade path for CPU, ... (alt.sys.pc-clone.dell)
Re: about star schema and surrogate keys ... What do I gain by having a surrogate integer time_key in my table dim_time ... Is there really a performance gain in modern DBs? ... The biggest dimension has 9000 rows, and about 2M rows for facts. ... and one of the attributes of product is price.... (comp.databases)
Re: Rapidly Changing Dimension ... I still have the issue on reporting the sales price over a ... Unless I do you a complete full blown type 2 on the product dimension... limiting the possibilities for reporting price over time. ... (microsoft.public.sqlserver.datawarehouse)
Rapidly Changing Dimension ... I'm having a SKU dimension... In addition I'm willing to track changes of the sales ... and purchase price.... A second option would be to have a separate fact table (and olap cube) ... (microsoft.public.sqlserver.datawarehouse)
Re: "Group By" Aggregation in Cube? ... We dont actually have business reqs and you are suggesting rolups?... if he wants to get each and every distinct price that the product ... Price as an attribute in a separate dimension would completely fail ... product 100 sold at $5.99 produced a net sales number of $2005. ... (microsoft.public.sqlserver.olap)
