70-463 · Question #130
You are designing a fact table in a SQL Server database. The fact table must meet the following requirements: - Include a columnstore index. - Allow users to choose up to 10 dimension tables and up…
The correct answer is C. Design a fact table with 10 dimensional key columns and 5 measure columns. The requirements explicitly state: up to 10 dimension tables and up to 5 facts. A fact table's structure must reflect these cardinalities: it needs 10 dimensional key columns (foreign keys to each of the 10 dimension tables) and 5 measure columns (the 5 facts/metrics to…
Question
You are designing a fact table in a SQL Server database. The fact table must meet the following requirements:
- Include a columnstore index.
- Allow users to choose up to 10 dimension tables and up to five facts
at one time.
- Maximize performance of queries that aggregate measures by using any
of the 10 dimensions.
- Support billions of rows.
- Use the most efficient design strategy.
You need to design the fact table to meet the requirements. What should you do? (More than one answer choice may achieve the goal. Select the BEST answer.)
Options
- ADesign a fact table with 5 dimensional key columns and 10 measure columns.
- BDesign a fact table with 5 dimensional key columns and 10 measure columns.
- CDesign a fact table with 10 dimensional key columns and 5 measure columns.
- DDesign a fact table with 10 dimensional key columns and 5 measure columns.
How the community answered
(37 responses)- A3% (1)
- B5% (2)
- C84% (31)
- D8% (3)
Explanation
The requirements explicitly state: up to 10 dimension tables and up to 5 facts. A fact table's structure must reflect these cardinalities: it needs 10 dimensional key columns (foreign keys to each of the 10 dimension tables) and 5 measure columns (the 5 facts/metrics to aggregate). Reversing these numbers - 5 dimensional key columns and 10 measure columns - would mean only 5 dimensions could be joined, violating the requirement to support all 10 dimensions. Columnstore indexes perform best on wide tables with many rows, making this design well-suited for billions of rows and aggregate queries across multiple dimensions.
Topics
Community Discussion
No community discussion yet for this question.