In data warehousing and business intelligence, what is the best description of a Fact, a Dimension, and a Measure in a star schema?

Introduction / Context:
Data warehousing and business intelligence systems often use star schemas or snowflake schemas to organize data for reporting and analysis. Three key concepts in this design are Facts, Dimensions, and Measures. Understanding what each of these terms means is essential for designing cubes, reports, and dashboards that answer business questions. This question asks you to identify the best description of Facts, Dimensions, and Measures in a typical star schema.

Given Data / Assumptions:

• We are working with a data warehouse, not an operational transactional database.
• A star schema consists of a central Fact table connected to multiple Dimension tables.
• Business users want to aggregate numeric values such as sales amount or quantity.
• Dimensions describe the context of those numeric values, such as who, what, where, and when.

Concept / Approach:
In a star schema, the Fact table holds records of business events or transactions. Each row usually contains foreign keys pointing to Dimension tables and several numeric columns known as Measures. Measures are the values you add, count, or average in reports, for example sales_amount or units_sold. Dimension tables store descriptive attributes such as product name, customer segment, or calendar date that allow you to slice and filter the Measures along various business perspectives. Together, Facts, Dimensions, and Measures support fast and flexible analytic queries.

Step-by-Step Solution:
Step 1: Look for a definition that clearly assigns quantitative data to Facts and descriptive context to Dimensions. Step 2: Option a states that the Fact table stores quantitative event data, Dimensions provide descriptive context such as time or product, and Measures are the numeric values in the Fact table that are aggregated. This matches standard data warehousing terminology. Step 3: Option b reverses text and numeric roles, calling Facts textual, which is incorrect. Step 4: Option c claims Facts and Dimensions are only used in operational databases, which is wrong because they are central to data warehouses. Step 5: Option d mislabels user interface screens and network bandwidth as core warehouse concepts. Step 6: Option e claims all three terms mean the same thing, which ignores their distinct roles.

Verification / Alternative check:
Kimball style data warehousing literature consistently describes Facts as tables that store measurements of business process events, with Measures being numeric fields within those tables. Dimensions are described as tables that store the descriptive attributes used for filtering and grouping, such as product hierarchies or customer segments. Reports and OLAP cubes aggregate Measures by Dimension attributes. This widely accepted understanding matches option a exactly.

Why Other Options Are Wrong:
Option b incorrectly assigns data types and purposes to Facts and Dimensions. Option c confuses operational databases with analytical warehouses, even though star schemas are typical in the latter. Option d describes system components unrelated to data modeling. Option e removes the distinction that makes star schemas powerful and understandable.

Common Pitfalls:
Beginners sometimes confuse Measures with Dimensions because both appear as columns in queries. Another pitfall is to put too many descriptive attributes into the Fact table instead of normalizing them into Dimension tables, which can bloat the Fact table and slow queries. Keeping clear mental models of what belongs in Facts, Dimensions, and Measures helps maintain a clean and efficient warehouse design.

Final Answer:
In a star schema, a Fact table stores quantitative event data, Dimensions supply descriptive context, and Measures are the numeric values in the Fact table that you aggregate in reports, as stated in option a.