In data warehousing design, what kind of relationship exists between a dimension table and the central fact table in a classic Star Schema (considering how keys link rows for analysis)?

Introduction / Context:
A Star Schema is a common dimensional modeling technique used in data warehousing for fast analytics. Understanding the cardinality between dimension tables (such as Date, Product, Customer) and the central fact table (such as Sales Fact) is fundamental to correct schema design and query performance.

Given Data / Assumptions:

• Fact table stores measurements (for example, sales_amount, quantity).
• Dimension tables store descriptive attributes (for example, product_name, customer_region).
• Foreign keys in the fact table reference primary keys in each dimension.

Concept / Approach:
Each dimension row (for example, a single product) can be associated with many events or transactions in the fact table (many sales). Therefore, from a dimension row to fact rows the cardinality is one-to-many. The reverse (from a specific fact row to a specific dimension row) is many-to-one by the foreign key relationship.

Step-by-Step Solution:

Verification / Alternative check:
Inspect sample data: one ProductID appears repeatedly in Sales Fact for multiple orders and days, confirming one-to-many from Product (dimension) to Sales Fact.

Why Other Options Are Wrong:

• Many-to-many: not directly; many-to-many is resolved via the fact table itself.
• One-to-one: unrealistic for transactional analytics; would severely limit facts per dimension value.
• All of the above: mutually exclusive cardinalities cannot all apply simultaneously.

Common Pitfalls:
Confusing the schema-wide many-to-many business reality (many customers buy many products) with the relational link between a single dimension table and the fact table, which is implemented as one-to-many via foreign keys.

Final Answer:
One-to-many