Hi everyone. I've looked around and haven't seen this, so here goes.
I'm creating a Fact table of customer transactions where approximately 5 - 10% of the transactions belong to a "promotion" - type event, and get an alphanumeric Promotion Code for the transaction. I update all the other records with a '0' in the field because they were not part of a promotion and are not analyzed by that dimension.
I don't know if this is new (I'm using SQL Server 2005), but now the Cube Wizard is forcing me to create a '0' entry record in the Promotion Dimension or the cube won't process (the Promotional Code is the Foreign key in the Fact Table). I know from a relational stand point orphaned records are a bad thing, but they truly do not belong in the Promotion Dimension.
Unfortunately, when the cube DOES process I now have a huge Dimension member for all the '0' records, which needlessly consists of millions of records now aggregated...
Is this a design issue? Is there a way to tell BI Studio I don't want to include the '0' Dimension member in the cube or aggregations? I do NOT want to have two fact tables - a Promotion one which is just a subset of the real one. I could create a Promotion Dimension which is joined by Account number and Transaction ID - technically incorrect, but I think I'd get rid of the '0' dimension by not having a Promotion Code column.
Any insights or comments would be greatly appreciated. Thanks!
I'm creating a Fact table of customer transactions where approximately 5 - 10% of the transactions belong to a "promotion" - type event, and get an alphanumeric Promotion Code for the transaction. I update all the other records with a '0' in the field because they were not part of a promotion and are not analyzed by that dimension.
I don't know if this is new (I'm using SQL Server 2005), but now the Cube Wizard is forcing me to create a '0' entry record in the Promotion Dimension or the cube won't process (the Promotional Code is the Foreign key in the Fact Table). I know from a relational stand point orphaned records are a bad thing, but they truly do not belong in the Promotion Dimension.
Unfortunately, when the cube DOES process I now have a huge Dimension member for all the '0' records, which needlessly consists of millions of records now aggregated...
Is this a design issue? Is there a way to tell BI Studio I don't want to include the '0' Dimension member in the cube or aggregations? I do NOT want to have two fact tables - a Promotion one which is just a subset of the real one. I could create a Promotion Dimension which is joined by Account number and Transaction ID - technically incorrect, but I think I'd get rid of the '0' dimension by not having a Promotion Code column.
Any insights or comments would be greatly appreciated. Thanks!