mediumMultiple SelectObjective-mapped
Designing a Star Schema in BigQuery: Denormalize Dimensions, Use Primary Keys, Partition Fact Tables
A company uses BigQuery to run business intelligence reports. The data engineer needs to implement a star schema for a sales data warehouse. Which THREE are best practices when designing the tables?
Quick Answer
The answer is to partition fact tables by date and cluster by frequently filtered columns, alongside denormalizing dimensions and using primary keys. This combination is correct because BigQuery’s architecture thrives on reducing data scanned: date partitioning limits queries to relevant time slices, while clustering on high-cardinality filter columns like customer_id or product_id further narrows I/O. Denormalizing dimensions avoids costly joins in BI tools, and defining primary keys—even though BigQuery doesn’t enforce them natively—enables the query engine to optimize join deduplication and MERGE operations, ensuring data integrity in your star schema. On the Google Professional Cloud Database Engineer exam, this tests your understanding that BigQuery is a columnar, serverless warehouse where traditional normalization hurts performance; a common trap is over-normalizing or forgetting that primary keys are advisory, not enforced. Memory tip: think “Partition to prune, cluster to sort, denormalize to skip the join.”
⚠ Common exam trap
Google Cloud often tests the misconception that dimension tables should be highly normalized or contain pre-aggregated data, but the PCDE exam emphasizes denormalizing dimensions for BI readability and storing aggregates only in fact tables or materialized views.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Use a primary key on fact tables to enforce uniqueness
In BigQuery, fact tables should have a primary key to enforce uniqueness of each sales transaction, preventing duplicate rows that would skew aggregations like SUM or COUNT. BigQuery does not enforce primary keys natively, but defining them in the schema (e.g., using PRIMARY KEY constraint in DDL) allows the query engine to optimize joins and deduplication, especially when using MERGE statements. This ensures data integrity in the star schema.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use natural keys in dimension tables for simplicity
Why it's wrong here
Natural keys can change and cause issues; surrogate keys are preferred.
- ✓
Use a primary key on fact tables to enforce uniqueness
Why this is correct
Ensures each row is unique and allows efficient joins.
- ✗
Store pre-aggregated data in dimension tables
Why it's wrong here
Aggregated data should be in fact tables or separate aggregation tables.
- ✓
Denormalize dimension tables to include descriptive attributes
Why this is correct
Reduces number of joins needed for BI queries.
- ✓
Partition fact tables by date and cluster by frequently filtered columns
Why this is correct
Optimizes query performance and cost.
Go deeper
Related to this question
About these practice questions
Courseiva writes every PCDE question from scratch — 1,446 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
3 more ways this is tested on PCDE
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Which TWO are best practices for designing a star schema in BigQuery for BI? (Choose two.)
medium- ✓ A.Store dimension attributes in a single denormalized dimension table instead of multiple normalized tables.
- B.Partition fact tables by low-cardinality columns like gender.
- C.Pre-aggregate all measures at every possible grain in the fact table.
- D.Avoid using joins entirely by storing all data in one wide table.
- ✓ E.Use surrogate keys for dimension tables instead of natural keys.
Why A: In BigQuery, storing dimension attributes in a single denormalized dimension table (star schema) reduces the number of joins required in BI queries, improving query performance and simplifying SQL. BigQuery's columnar storage and distributed architecture handle denormalized dimensions efficiently, avoiding the overhead of multiple normalized tables that would require complex joins and slow down analytical queries.
Variation 2. A company is designing a BigQuery data model for a business intelligence dashboard that shows sales by region and product. The data is refreshed daily. Which schema design is MOST cost-effective and performant for this use case?
easy- A.A table with nested repeated columns for regions and products within each sale.
- ✓ B.A star schema with a fact table for sales and separate dimension tables for region and product.
- C.A fully normalized schema with separate tables for each attribute.
- D.A single flat table containing all sales, region, and product columns.
Why B: A star schema with a fact table for sales and dimension tables for region and product is optimized for analytical queries in BigQuery, providing a balance of query performance and storage efficiency for daily refreshes. Option A is wrong because nested repeated columns can complicate queries and are less efficient for the simple dimensional analysis required by a BI dashboard. Option C is wrong because a fully normalized schema with many joins increases query complexity and latency, making it less performant for BI workloads. Option D is wrong because a single flat table leads to higher storage costs and slower queries due to scanning unnecessary columns and data duplication.
Variation 3. Which TWO of the following are best practices when designing data structures for business intelligence in BigQuery?
easy- ✓ A.Partition tables on a column that aligns with common filter criteria
- B.Store raw logs directly in fact tables without any aggregation
- C.Use NULLable columns extensively to save storage
- D.Use a single wide table for all data to simplify schema
- ✓ E.Denormalize dimension attributes into fact tables to reduce joins
Why A: Partitioning tables on a column that aligns with common filter criteria (e.g., a date or timestamp column) allows BigQuery to prune partitions during query execution, drastically reducing the amount of data scanned and improving query performance and cost efficiency. This is a core best practice for optimizing BI workloads in BigQuery.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This PCDE practice question is part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the PCDE exam.