Data Warehousing, Multidimensional OLAP Models & Star/Snowflake Schemas
GATE 2027 DA core
“ETL staging, dimension vs fact tables, star vs snowflake normalizations, and OLAP slicing/dicing operations.”
1.The Architectural Divide: OLTP vs Data Warehousing (OLAP)
§ 9.1.Operational database systems (OLTP — On-Line Transaction Processing) are engineered for high-concurrency, short write transactions that insert, update, and delete individual records (e.g., ATM withdrawals, e-commerce checkouts). OLTP databases prioritize ACID transactions and 3NF/BCNF normalization to eliminate write update anomalies.
In contrast, a Data Warehouse (OLAP — On-Line Analytical Processing) is an enterprise repository constructed for consolidated decision-support queries scanning millions of historical records (e.g., 'What was the year-over-year revenue growth across electronics in the Southern region?').
The Three-Tier Architecture:
1. Bottom Tier (Data Sources & Staging): Heterogeneous operational databases (SQL, ERP, flat files) undergo ETL (Extract, Transform, Load) to clean, reconcile, and format data into persistent staging areas.
2. Middle Tier (OLAP Server): An analytical engine organizing data into multidimensional cubes (ROLAP, MOLAP, or HOLAP).
3. Top Tier (Front-End Clients): Business intelligence dashboards, report generators, and data mining algorithms.
A massive analytical aggregate query on an OLTP database would lock entire tables, exhaust buffer pools, and block real-time customer transactions. Decoupling analytics into a Data Warehouse isolates operational throughput from reporting overhead.
2.Multidimensional Modeling: Facts, Dimensions & Measures
§ 9.2.A Multidimensional Data Model views data in the form of a data cube defined by Dimensions and Measures.
Fact Table: A central table storing quantitative numerical metrics of a business process (e.g., quantity sold, revenue, shipping cost). Its primary key is a composite key consisting of foreign keys referencing all connected dimension tables.
Dimension Tables: Surrounding tables containing descriptive attributes and hierarchical categorization levels (e.g., Time: day -> month -> quarter -> year; Location: street -> city -> state -> country; Product: item -> brand -> category).
Taxonomy of Measures:
1. Additive Measures: Can be summed meaningfully across all dimensions (e.g., sales_amount, units_sold).
2. Semi-Additive Measures: Can be summed across some dimensions but not others (e.g., account_balance can be summed across accounts or branches, but NOT across time).
3. Non-Additive Measures: Cannot be summed across any dimension (e.g., unit_price, percentage_discount, temperature). Must be aggregated using ratios of sums rather than sum of ratios.
3. Schema Architecture Comparison: Star vs Snowflake vs Constellation
Comparing the three primary multidimensional database schema paradigms in analytical engineering.
| Feature / Aspect | Star Schema | Snowflake Schema |
|---|---|---|
| Dimension Normalization | Completely denormalized (1 table per dimension) | Fully normalized into 3NF/BCNF sub-dimensions |
| Query Join Complexity | Minimal (single join between fact and each dimension) | High (requires multi-table snowflake chain joins) |
| Data Redundancy | High (attributes repeated in dimension tables) | Low (redundancy eliminated via normalization) |
| Fact Tables Count | Single central fact table | Single central fact table |
| Typical Usage | Departmental Data Marts & high-speed reporting | Large data warehouses with complex hierarchies |
4.OLAP Algebra: Roll-Up, Drill-Down, Slice, Dice & Pivot
§ 9.4.OLAP engines provide five core interactive operations to navigate multidimensional data cubes:
1. Roll-up (Drill-Up / Aggregation): Performs data aggregation either by climbing up a dimension hierarchy (e.g., aggregating daily sales into monthly totals) or by dimension reduction (dropping a dimension entirely from the cube).
2. Drill-down (Roll-Down): The reverse of roll-up: introduces finer detail by stepping down a dimension hierarchy (e.g., expanding quarterly revenue into monthly figures) or by adding a new dimension.
3. Slice: Performs a selection on one dimension of the cube, resulting in a sub-cube of lower dimensionality (e.g., selecting Time = 'Q1' produces a 2D slice across Product and Location).
4. Dice: Defines a sub-cube by applying selection conditions on two or more dimensions (e.g., Location in ('CA', 'NY') AND Time in ('Q1', 'Q2') AND Item in ('Laptop')).
5. Pivot (Rotate): Visual rotation of axes to view the data from different perspectives (e.g., swapping row and column dimensions in a cross-tabulated spreadsheet).
5. GATE Worked Example: Dimensional Table Cardinality & Cube Sizing
Remember that an n-dimensional data cube has 2^n cuboids (including the 0-D apex cuboid and 1-D base cuboids).
Problem Statement (Modeled on GATE DA Pattern):
A data warehouse contains a Star Schema with a central Fact table and 4 Dimension tables: Date, Store, Customer, and Product.
Given parameters:
- Date dimension has 365 rows (1 year).
- Store dimension has 50 rows.
- Customer dimension has 10,000 rows.
- Product dimension has 200 rows.
- The Fact table contains 2,000,000 transaction records.
- Each Fact record stores: 4 foreign keys (4 bytes each) and 2 measures: 'units_sold' (4 bytes) and 'total_amount' (8 bytes).
Calculate: (a) Total number of possible cuboids in the data cube, (b) The maximum possible theoretical cell capacity in the base cuboid, and (c) The raw storage size of the Fact table.
Step 1: Compute total number of cuboids:
A data cube with n dimensions has 2^n distinct cuboids (each corresponding to a subset of dimensions).
Here n = 4.
Total cuboids = 2^4 = 16 cuboids.
Step 2: Compute theoretical maximum cell capacity of base cuboid:
The base cuboid represents all combinations of all 4 dimensions:
Max cells = |Date| |Store| |Customer| * |Product|
Max cells = 365 50 10,000 * 200 = 36,500,000,000 cells (36.5 billion cells).
Notice: since the actual Fact table has 2,000,000 records, the data cube density is: 2,000,000 / 36.5 billion ≈ 0.0055% (an extremely sparse data cube, typical of real OLAP engines).
Step 3: Calculate Fact table storage size:
Bytes per record = (4 FKs * 4 bytes) + 4 bytes (units) + 8 bytes (amount)
Bytes per record = 16 + 4 + 8 = 28 bytes.
Total Fact table raw size = 2,000,000 records * 28 bytes = 56,000,000 bytes = 56 MB.
Conclusion: 16 cuboids; theoretical capacity = 36.5B cells; Fact table size = 56 MB.
Primary Academic References & Exam Sources
Every concept in Notes From a B.Tech Brain is synthesized from authoritative academic texts, seminal peer-reviewed research, verified exam archives, and renowned university lectures.
Curated for clarity, rigorous numerical solving, and semester excellence:
GATE-focused numerical problem-solving with clear worked examples.
Fast conceptual coverage with step-by-step GATE numericals.
Systematic textbook-style explanations ideal for first-time learners.
Deep theoretical rigor on normalization and transaction serializability.