You are modifying a star schema data mart that feeds order data from a SQL Azure
database into a SQL Server Analysis Services (SSAS) cube. The data mart contains two
large tables that include flags and indicators for some orders. There are 100 different flag
columns, each with 10 different indicator values. Some flags reuse indicators. The tables
both have a granularity that matches the fact table.
You have the following requirements:
Allow users to slice data by all flags and indicators.
Modify the date dimension table to include a surrogate key of a numeric data type and add
the surrogate key to the fact table.
Use the most efficient design strategy for cube processing and queries.
You need to modify the schema.
What should you do? (More than one answer choice may achieve the goal. Select the BEST
answer.)
A.
Define the surrogate key as an INT data type. Combine the distinct flag/indicator
combinations into a single dimension.
B.
Define the surrogate key as an INT data type. Create a single fact dimension in each
table for its flags and indicators.
C.
Define the surrogate key as a BIGINT data type. Combine the distinct flag/indicator
combinations into a single dimension.
D.
Define the surrogate key as a BIGINT data type. Create a single fact dimension in each
table for its flags and indicators.
BIGINT
INT is okay. No information is given about the length of the flag/indicators, so we don’t need a large length data type. I go for A.
https://msdn.microsoft.com/pt-pt/library/ms187745.aspx
A
“Modify the date dimension table to include a surrogate key of a numeric data type and add
the surrogate key to the fact table.”
DOesn’t ths mean that here should be a numeric indicator for each date? In that case, a int would suffice for holding date wouldn’t it?