OLAP and Semantic Layers

Introduction and Context

Data warehousing converts operational data into an environment suitable for analysis. However, storing integrated historical data is not sufficient by itself. Analysts and managers must also be able to interpret that data consistently, navigate it at different levels of detail, compare performance across business perspectives, and formulate questions without repeatedly reconstructing complex SQL logic. Online analytical processing (OLAP) and semantic layers address these needs.

OLAP provides structures and operations for examining multidimensional data. A sales manager may want revenue by region and quarter, then drill into a particular region, compare product categories, or examine monthly trends. A semantic layer provides a business-oriented interpretation of the underlying warehouse. It defines measures such as revenue, gross margin, active customer, and on-time delivery using governed logic that can be reused across reports, dashboards, notebooks, and analytical applications.

At postgraduate level, OLAP should not be viewed merely as a reporting interface. It is a design discipline involving grain, dimensional modelling, aggregation behavior, query performance, metadata, security, and governance. Similarly, a semantic layer is not simply a collection of aliases for database columns. It is an institutional agreement about how an organization defines and uses analytical concepts.

Learning Objectives

After completing this chapter, the reader should be able to:

1. Explain cubes, facts, measures, dimensions, attributes, and hierarchies.

2. Distinguish additive, semi-additive, and non-additive measures.

3. Explain aggregation and the conditions under which it is valid.

4. Perform and interpret roll-up, drill-down, slice, dice, pivot, drill-through, and related OLAP operations.

5. Compare major OLAP implementation approaches.

6. Design a semantic or metrics layer with reusable, governed definitions.

7. Evaluate semantic-layer security, performance, lineage, and maintenance issues.

8. Apply these concepts to a realistic data-warehouse scenario.

1. The Multidimensional View of Data

1.1 Facts and grain

A fact table records measurable events or periodic states. Its grain specifies exactly what one row represents. For example, a fact table may have the grain “one product sold on one invoice line,” while another may have the grain “one daily inventory balance for one warehouse and product.” Measures and valid aggregations cannot be designed correctly until grain is explicit.

A fact table commonly contains foreign keys to dimensions and numerical measures. A sales fact may reference Date, Product, Customer, Store, and Promotion dimensions and contain quantity, unit price, discount, and sales amount. Dimensions provide descriptive context; facts provide observations or events.

A cube is a conceptual model in which measures are analyzed by dimensions. A three-dimensional sales cube might use time, product, and region. In practice, a cube need not be physically stored as a literal multidimensional array. It may be implemented using relational tables, columnar storage, materialized aggregates, or a query engine that constructs results dynamically.

1.2 Measures

A measure is a numerical or otherwise aggregatable property associated with a fact. Measures may be:

• Fully additive: validly summed across all relevant dimensions. Sales amount and units sold are typical examples.
• Semi-additive: valid across some dimensions but not others. An account balance can be summed across accounts, but summing balances across dates usually has no direct meaning.
• Non-additive: cannot be meaningfully summed. Ratios, percentages, rates, and unit prices are common examples.

Non-additive measures can often be reconstructed from additive components. Instead of summing margin percentages, a governed layer should calculate total margin divided by total revenue, subject to the business definition. In general, an average should not be calculated as the unweighted average of averages unless equal weighting is justified. A weighted average can be expressed as

weighted average = Σ(wᵢxᵢ) / Σwᵢ,

where xᵢ is an observed value and wᵢ is its appropriate weight. The formula applies when the weights represent the relevant exposure, volume, population, or other justified basis and the denominator is non-zero.

1.3 Dimensions and attributes

A dimension is a business perspective used to classify and filter facts. Typical dimensions include Date, Product, Customer, Geography, Organization, Supplier, and Channel. Attributes are descriptive properties within a dimension. Product may contain product identifier, name, brand, category, and department. Geography may contain city, state, country, and sales territory.

Dimensions may be shared across fact tables. A conformed Date dimension allows sales, inventory, and returns to use the same fiscal calendar and reporting periods. Conformed dimensions are essential for comparing facts across processes. Without them, apparently similar measures may use incompatible definitions of time, customer, or product.

Dimensions can also contain special structures:

• A role-playing dimension is used multiple times for different roles, such as order date, shipment date, and delivery date.
• A degenerate dimension is a transaction identifier retained in the fact table without a separate dimension table.
• A junk dimension groups low-cardinality flags and indicators into a managed dimension.
• A slowly changing dimension preserves or updates historical attribute values according to an explicit policy.

1.4 Hierarchies

A hierarchy organizes dimension members into levels. A calendar hierarchy may be Year → Quarter → Month → Day. A geography hierarchy may be Country → Region → City → Store. Hierarchies enable navigation and aggregation.

A hierarchy should be semantically valid, not merely convenient. A strict hierarchy has one parent for every child at each level. A balanced hierarchy has the same number of levels for all branches. A ragged hierarchy contains branches with different depths, as often occurs in organizational structures. A parent-child hierarchy represents recursive relationships such as employee-supervisor or account-category structures.

The phrase “drill down” is sometimes used loosely. Moving from year to quarter is a hierarchy navigation operation, while opening individual transaction records from an aggregate is more accurately called drill-through. The distinction matters because drill-through crosses from summarized analytical data to detailed operational or fact-level records.

2. Aggregation and OLAP Semantics

2.1 Aggregation functions

Common aggregation functions include SUM, COUNT, COUNT DISTINCT, MIN, MAX, and average. Their validity depends on measure meaning, grain, dimensional relationships, and missing-value policy.

For a fully additive measure x, aggregation over a set of rows R is:

SUM(R) = Σᵢ₌₁ⁿ xᵢ.

This operation assumes that the rows represent non-overlapping contributions at the intended grain. Double counting can occur if a join duplicates fact rows, if snapshots are summed across time, or if a fact table mixes grains.

A ratio should generally be calculated from its numerator and denominator. For example:

margin percentage = total margin / total revenue × 100,

provided that total revenue is non-zero and margin and revenue use compatible filters and currencies. Summing row-level margin percentages is not equivalent to calculating the overall margin percentage.

Distinct counts require particular care. The number of distinct customers in two periods cannot generally be obtained by adding the distinct-customer counts of each period because the same customer may occur in both periods. Exact distinct-count aggregation is therefore not additive across time. Some systems use approximate algorithms, such as sketches, when a controlled estimation error is acceptable.

2.2 Aggregation paths and summarizability

A measure is summarizable when it can be aggregated correctly along a dimension hierarchy. Summarizability may fail for three principal reasons:

1. Many-to-many relationships: one fact may relate to multiple dimension members, causing duplication.

2. Unbalanced or incomplete hierarchies: members may not map uniquely to a parent.

3. Incorrect measure behavior: for example, summing inventory balances over time.

Bridge tables can represent many-to-many relationships, but allocation weights or explicit counting rules are needed to prevent misleading totals. If a sale is associated with two sales representatives, the organization must decide whether the sale is credited fully to both, divided between them, or reported separately as an association rather than a contribution.

2.3 Time aggregation

Time is especially sensitive. Flow measures such as sales during a period can usually be summed across days. Snapshot measures such as inventory at a point in time require a selected-period rule, such as ending balance, beginning balance, or average daily balance. The correct rule depends on the analytical question.

A semantic layer should expose these rules explicitly. A metric called “quarterly inventory” is ambiguous unless it specifies whether it means inventory at quarter end, average daily inventory, or the sum of daily balances. Names, descriptions, metadata, and tests must make the behavior visible.

3. OLAP Operations

OLAP operations support interactive exploration of a multidimensional model.

3.1 Roll-up

Roll-up moves from detailed data to a higher level of aggregation. A user may move from city-level sales to country-level sales or from month to quarter. Roll-up may use a hierarchy or remove a dimension entirely. It reduces detail and supports executive summaries.

3.2 Drill-down

Drill-down moves from a summary to more detailed levels, such as year to quarter to month. It is useful for identifying the source of a trend or variance. Drill-down should preserve the analytical context, including filters, currency, calendar, and security rules.

3.3 Slice

A slice fixes one dimension at a particular value, such as viewing sales only for fiscal year 2025. The resulting view has fewer active dimensions.

3.4 Dice

A dice operation selects a subcube using multiple filters, such as products in two categories, three regions, and a specified time interval. In SQL-based systems, slicing and dicing are usually expressed with WHERE conditions, grouping, and selected dimensions.

3.5 Pivot

Pivot changes the arrangement of dimensions in a result. For example, regions may become rows and quarters columns. Pivoting changes presentation rather than the underlying facts.

3.6 Drill-through

Drill-through navigates from an aggregate to the records supporting it. It requires a defined relationship between the semantic result and accessible detail. Security, privacy, and performance controls are essential because aggregate access does not automatically imply entitlement to personally identifiable transaction data.

3.7 Compare and variance analysis

Analytical interfaces often compare periods, plans, or cohorts. A variance may be expressed as:

absolute variance = actual − reference,

and, when the reference is non-zero,

percentage variance = (actual − reference) / reference × 100.

The denominator and treatment of negative or zero reference values must be documented. A percentage variance against zero is undefined, not zero.

4. OLAP Architectures

4.1 MOLAP, ROLAP, and HOLAP

MOLAP stores data in multidimensional structures, often with precomputed aggregates. It can provide fast navigation for known dimensional patterns but may require specialized processing, storage, and refresh management.

ROLAP retains data in relational tables and generates SQL or similar queries. It benefits from relational scalability, detailed data access, and integration with warehouse technologies, although complex queries may require careful optimization.

HOLAP combines approaches, keeping some summaries in multidimensional or materialized structures and detailed data in relational storage. The division should be driven by workload, latency, data volume, update frequency, and governance requirements.

Modern cloud platforms frequently blur these categories. Columnar warehouses, caching, materialized views, aggregate awareness, semantic query engines, and vectorized execution can provide OLAP performance without a traditional proprietary cube. The conceptual requirements—grain, dimensions, measures, hierarchies, and aggregation rules—remain applicable.

4.2 Physical and logical cubes

A physical cube materializes some or all multidimensional structures. A logical cube is a metadata and query model that presents a cube-like experience over underlying tables. Logical models can reduce duplication and support changing analytical questions, but their performance depends on SQL generation, warehouse design, clustering, partitioning, caching, and query governance.

5. Semantic and Metrics Layers

5.1 Purpose and scope

A semantic layer translates technical structures into business concepts. It may define entities, dimensions, measures, relationships, filters, joins, access policies, synonyms, and descriptions. A metrics layer is a focused form of semantic layer that centralizes metric definitions and their computation.

The central principle is “define once, use consistently.” If one dashboard defines revenue as invoiced sales and another defines it as cash received, both may be technically correct but organizationally incompatible. A governed semantic layer makes the distinction explicit and enables users to select the appropriate metric.

5.2 Components of a semantic layer

A mature semantic layer commonly includes:

• Business entities: customer, order, subscription, product, employee, or account.
• Dimensions: descriptive fields and their allowed hierarchies.
• Measures: governed aggregations with data types, units, and filters.
• Relationships: join paths, cardinality, and fan-out controls.
• Time logic: fiscal calendars, period comparisons, current-period definitions, and time zones.
• Metric metadata: owner, definition, formula, source, refresh time, certification state, and lineage.
• Security policies: row-level, column-level, role-based, and attribute-based access.
• Quality tests: uniqueness, non-nullness, referential integrity, accepted values, and reconciliation checks.
• Presentation metadata: labels, descriptions, formatting, synonyms, and default behavior.

5.3 Metric contracts

A metric contract specifies what a metric means and how it is produced. At minimum it should identify:

1. Name and business definition.

2. Grain and population.

3. Numerator and denominator, where applicable.

4. Inclusion and exclusion rules.

5. Dimensions across which it is additive or non-additive.

6. Currency, unit, and time-zone conventions.

7. Null, zero, cancellation, and late-arriving-data treatment.

8. Owner, steward, source tables, and lineage.

9. Refresh expectation and known limitations.

10. Validation tests and approval status.

For example, “Monthly Active Customers” may be defined as the distinct count of customers with at least one qualifying transaction during the calendar month. The contract must specify whether refunds, test transactions, cancelled orders, and anonymous customers qualify. It must also state that the metric is not additive across months.

5.4 Reusable measures and safe calculations

The semantic layer should prefer governed atomic measures and derived measures. For example, it may define Net Revenue and Gross Profit as additive components, then define Gross Margin Percentage as Gross Profit divided by Net Revenue. This supports correct aggregation at different grains.

A semantic layer must also prevent fan-out errors. Suppose an order joins to several order-line records and several payment records. Joining both child tables before aggregation can multiply rows. The model should aggregate each child process separately, use distinct keys only when logically justified, or establish a controlled relationship. A DISTINCT operation is not a universal remedy: it may conceal genuine multiplicity and produce incorrect totals.

5.5 Semantic layer design process

A disciplined design process includes:

First, discover business questions. Interview users, inspect existing reports, and identify decisions rather than merely collecting column names.

Second, establish grain and processes. Document the business process, fact grain, event timing, and dimensional keys.

Third, standardize dimensions. Create conformed definitions for date, product, customer, geography, and organizational structures.

Fourth, define atomic measures. Record source, unit, aggregation behavior, and null policy.

Fifth, define derived metrics. Build ratios and classifications from governed components rather than copying report-specific formulas.

Sixth, model relationships. Document cardinality, join paths, many-to-many bridges, and valid exploration paths.

Seventh, add governance and tests. Apply access policies, ownership, lineage, freshness checks, reconciliations, and certification workflows.

Eighth, validate with users. Compare results against trusted examples and investigate differences instead of silently changing definitions.

Ninth, monitor usage and performance. Identify unused fields, expensive queries, popular metrics, and conflicting definitions.

6. Illustrative Case: A Retail Enterprise Metrics Layer

Background

This fictional case describes Northstar Retail, a company operating stores and an online channel. Its warehouse contains sales, returns, inventory, promotion, and customer-support facts. Different departments publish conflicting revenue and customer metrics.

Problem

Finance reports net revenue after returns, while marketing reports gross order value before returns. Store operations counts transactions, whereas digital operations counts orders. A dashboard joins sales lines to promotion records and overstates revenue when an order has multiple promotions. Executives therefore receive different answers to apparently identical questions.

Analysis

The design team inventories existing reports and discovers three major causes. First, fact grains are not documented. Second, revenue definitions and return treatments differ. Third, the reporting tool allows users to join tables without understanding many-to-many relationships. The team also finds that inventory is being summed by month, producing meaningless totals.

Approach and solution

The team establishes separate processes and grains: one row per order line for sales, one row per return line for returns, and one daily product-store balance for inventory. A conformed Date dimension supports calendar and fiscal reporting. Product, Customer, Store, and Channel dimensions are standardized.

The semantic layer defines:

• Gross Sales: sum of qualifying sales-line amounts before returns.
• Returns: sum of approved return amounts, represented as a separate negative contribution or separate measure according to the reporting contract.
• Net Revenue: Gross Sales minus approved returns, with currency conversion rules documented.
• Units Sold: sum of qualifying quantities.
• Order Count: distinct qualifying order identifiers, not sum of line counts.
• Active Customer: distinct customer with at least one qualifying order in the selected period.
• Ending Inventory: inventory balance on the final valid date in the selected period.
• Gross Margin Percentage: gross margin divided by net revenue when net revenue is non-zero.

Promotion attribution is handled through an explicit bridge and an agreed allocation policy. Reports cannot freely combine incompatible measures and dimensions without warnings. Certified metrics carry owners, descriptions, lineage, and tests. Row-level policies restrict store managers to authorized stores, while customer-level personal information is hidden from general analysts.

Outcome

Finance and marketing retain distinct metrics where their purposes differ, but the differences are now visible and intentional. Executive dashboards use certified net revenue and order count. Inventory trends use ending or average balance rather than summed snapshots. Query tests detect duplicate joins and reconcile daily totals against the financial ledger.

Learning points

The case demonstrates that semantic consistency is not achieved by naming fields attractively. It requires explicit grain, conformed dimensions, aggregation rules, relationship governance, ownership, testing, and communication. It also shows that a semantic layer should preserve legitimate business distinctions rather than forcing every department into one ambiguous metric.

7. Governance, Security, and Professional Responsibility

Semantic layers influence managerial decisions, compensation, regulatory reporting, and public claims. Incorrect metrics can therefore create material organizational harm. Governance should include a metric council or equivalent process representing data engineering, business ownership, finance, risk, and privacy stakeholders.

Definitions should be versioned. If the inclusion rule for active customers changes, historical comparability may be affected. The organization should record effective dates, communicate changes, and, where appropriate, provide restated history or parallel versions.

Security must operate at every relevant layer. Row-level security may restrict regions or business units; column-level security may mask salary or personally identifiable information; purpose limitation may restrict customer data to approved uses. Aggregate results can still disclose sensitive information through small-cell inference, differencing, or repeated queries. Minimum group-size rules, suppression, auditing, and controlled drill-through may therefore be necessary.

Data quality and lineage are also governance requirements. A metric should identify upstream sources, transformation logic, refresh status, and known limitations. “Certified” should mean that a defined review and testing process has been completed, not that the metric is permanently correct.

8. AI and Contemporary Developments

Natural-language interfaces increasingly translate questions into semantic queries. They can improve access for nontechnical users, but their reliability depends on the semantic model. An AI system may generate syntactically valid SQL that uses the wrong measure, joins incompatible grains, or misunderstands a fiscal calendar. Governed metric definitions, restricted query generation, visible assumptions, result citations, and human review are therefore essential.

Emerging platforms support metric stores, semantic APIs, data contracts, lineage graphs, and reusable transformation projects. Organizations are also adopting data products and domain-oriented ownership. These approaches can improve autonomy, but they increase the need for shared standards for identifiers, calendars, units, access, and metric names.

Semantic layers should support both centralized control and responsible self-service. Excessive centralization creates bottlenecks and encourages shadow spreadsheets; excessive decentralization creates conflicting definitions. A practical balance is to govern core entities and enterprise metrics centrally while allowing domain teams to publish clearly labelled, versioned local metrics.

9. Challenges and Limitations

OLAP and semantic layers do not eliminate underlying data problems. They may expose inconsistent source systems, missing history, ambiguous business rules, or poorly designed fact tables. Performance can degrade when users request high-cardinality dimensions, distinct counts, or unconstrained combinations. Pre-aggregation improves speed but increases storage, refresh complexity, and risk of stale results.

Semantic abstraction can also hide important assumptions. Analysts may trust a metric without understanding its population or exclusions. Conversely, exposing every technical detail overwhelms users and encourages direct table access. Good design provides simple defaults while making definitions, lineage, and advanced controls discoverable.

Another limitation is organizational: definitions are contested. “Customer,” “revenue,” and “on time” may legitimately have multiple meanings. The goal is not always one universal metric, but a controlled vocabulary in which each approved variant has a clear purpose and relationship to other variants.

Best Practices

1. Declare fact grain before defining measures.

2. Use conformed dimensions and governed calendars.

3. Classify every measure as additive, semi-additive, or non-additive.

4. Calculate ratios from appropriate aggregated components.

5. Treat distinct counts and many-to-many relationships explicitly.

6. Make metric definitions, owners, units, and limitations visible.

7. Separate business definitions from presentation formatting.

8. Test joins, reconciliations, freshness, and security policies.

9. Version definitions and communicate semantic changes.

10. Optimize only after correctness and workload patterns are understood.

11. Support self-service through certified paths rather than unrestricted joins.

12. Use AI as an assisted interface, not as a substitute for governance.

Chapter Summary

OLAP represents warehouse data through measures, dimensions, attributes, and hierarchies, enabling users to navigate business information through roll-up, drill-down, slice, dice, pivot, and drill-through operations. Correct analysis depends on explicit fact grain and on understanding whether measures are additive, semi-additive, or non-additive. Summarizability can fail because of many-to-many relationships, incomplete hierarchies, duplicated joins, or inappropriate time aggregation.

MOLAP, ROLAP, and HOLAP represent alternative implementation strategies, while modern cloud systems often combine their characteristics. A semantic or metrics layer provides a governed business interpretation of the warehouse. It should define reusable measures, relationships, calendars, security, metadata, lineage, quality tests, and metric contracts. Particularly important are correct ratio calculations, distinct-count behavior, snapshot measures, and fan-out prevention.

A professional semantic architecture balances consistency with legitimate domain variation. It requires ownership, versioning, privacy protection, validation, and performance monitoring. AI and natural-language analytics can extend self-service, but their results depend on the quality and governance of the semantic model. Ultimately, OLAP and semantic layers are socio-technical systems: their success depends as much on definitions, accountability, and trust as on query technology.

Key Terms

Cube: A multidimensional conceptual representation of measures analyzed by dimensions.

Fact table: A table recording measurable business events or states.

Grain: The precise meaning of one row in a fact table.

Measure: A numerical or aggregatable property associated with a fact.

Dimension: A business perspective used to classify, filter, and analyze facts.

Attribute: A descriptive property within a dimension.

Hierarchy: An ordered structure of levels used for navigation and aggregation.

Conformed dimension: A shared dimension with consistent meaning across fact tables.

Additive measure: A measure that can be summed across relevant dimensions.

Semi-additive measure: A measure that can be aggregated across some dimensions but not others.

Non-additive measure: A measure that cannot be meaningfully summed.

Summarizability: The ability to aggregate data correctly along dimensions and hierarchies.

Roll-up: Moving from detailed data to a higher aggregation level.

Drill-down: Moving from summary data to more detailed hierarchy levels.

Slice: Fixing one dimension to a selected value.

Dice: Selecting a multidimensional subcube using multiple filters.

Semantic layer: A governed business-oriented abstraction over technical data structures.

Metrics layer: A semantic component that centralizes reusable metric definitions.

Metric contract: A documented specification of a metric’s meaning, logic, scope, and governance.

Drill-through: Navigating from an aggregate result to supporting detailed records.

Review Questions

Short Answer Questions

1. What is the significance of declaring the grain of a fact table?

2. Distinguish additive, semi-additive, and non-additive measures.

3. What is the difference between a slice and a dice operation?

4. Why should a ratio generally be calculated from aggregated numerator and denominator values?

5. What information should a metric contract contain?

Long Answer Questions

1. Explain the role of dimensions and hierarchies in OLAP, using a time or geography example.

2. Compare MOLAP, ROLAP, and HOLAP, including their major strengths and limitations.

3. Discuss the causes of summarizability failure and methods for preventing double counting.

4. Describe a complete process for designing and governing a semantic layer.

5. Explain how security, lineage, testing, and versioning contribute to trust in analytical metrics.

Analytical / Application Questions

1. A company stores daily inventory balances and reports the sum of monthly balances as “monthly inventory.” Diagnose the problem and propose at least two valid alternative metrics.

2. An order has four line items and three associated promotion records. A query joins both tables and reports revenue three times higher than the ledger. Explain the mechanism of fan-out and design a correction.

3. Design a metric contract for “Quarterly Active Customers.” State its population, time basis, aggregation behavior, exclusions, data-quality tests, and security considerations.

Multiple Choice Questions with Answers

Question 1

Which property defines the exact meaning of one row in a fact table?

A. Cardinality

B. Grain

C. Hierarchy

D. Lineage

Correct Answer: B. Grain

Question 2

Which measure is typically semi-additive?

A. Units sold

B. Sales amount

C. Ending account balance

D. Order-line quantity

Correct Answer: C. Ending account balance

Question 3

What does a roll-up operation do?

A. Moves from detail to a higher aggregation level

B. Deletes historical records

C. Adds a new source system

D. Opens individual transaction records

Correct Answer: A. Moves from detail to a higher aggregation level

Question 4

Why is summing monthly distinct-customer counts generally invalid for a quarterly count?

A. Customers have no dimensions

B. Distinct counts are always non-numerical

C. The same customer may occur in multiple months

D. Months cannot belong to quarters

Correct Answer: C. The same customer may occur in multiple months

Question 5

Which layer primarily provides governed business definitions over warehouse structures?

A. Operating-system layer

B. Semantic layer

C. Network layer

D. Backup layer

Correct Answer: B. Semantic layer

Question 6

If revenue is 800 and gross margin is 200, what is the gross margin percentage?

A. 20%

B. 25%

C. 40%

D. 60%

Correct Answer: B. 25%

Question 7

Which operation selects a subcube using multiple dimension filters?

A. Dice

B. Pivot

C. Drill-through

D. Roll-up

Correct Answer: A. Dice

Question 8

What is the preferred general method for calculating an overall margin percentage?

A. Sum all row-level percentages

B. Average the percentages without weights

C. Divide aggregated margin by aggregated revenue

D. Multiply revenue by the number of rows

Correct Answer: C. Divide aggregated margin by aggregated revenue

Question 9

What causes fan-out in a warehouse query?

A. A conformed date dimension

B. Joining multiple child tables with repeated parent keys

C. Using a fiscal calendar

D. Applying row-level security

Correct Answer: B. Joining multiple child tables with repeated parent keys

Question 10

Which statement best describes drill-through?

A. Changing rows into columns

B. Moving from a summary to supporting detailed records

C. Combining two unrelated dimensions

D. Replacing a measure with a dimension

Correct Answer: B. Moving from a summary to supporting detailed records