DATABASE MANAGEMENT SYSTEMS/Student Engineering Notebook
Page 09·notes
DATA WAREHOUSING & MULTIDIMENSIONAL MODELING—~30 MIN READ

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)

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.

mental model— Why Not Run Analytics Directly on OLTP?

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

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 / AspectStar SchemaSnowflake Schema
Dimension NormalizationCompletely denormalized (1 table per dimension)Fully normalized into 3NF/BCNF sub-dimensions
Query Join ComplexityMinimal (single join between fact and each dimension)High (requires multi-table snowflake chain joins)
Data RedundancyHigh (attributes repeated in dimension tables)Low (redundancy eliminated via normalization)
Fact Tables CountSingle central fact tableSingle central fact table
Typical UsageDepartmental Data Marts & high-speed reportingLarge data warehouses with complex hierarchies

4.OLAP Algebra: Roll-Up, Drill-Down, Slice, Dice & Pivot

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).

WORKED EXAM ANALYSIS · STEP-BY-STEP DERIVATION2 Marks (GATE DA)

5. GATE Worked Example: Dimensional Table Cardinality & Cube Sizing

⚠️ Pitfall Warning:

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.

SOURCE TRANSPARENCY & CITATIONS

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.

Primary Academic Texts
The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (3rd Edition)↗by Ralph Kimball, Margy Ross (Wiley) · The industry standard reference on dimensional modeling, star schemas, and fact tables
ACADEMIC STANDARD
Data Mining: Concepts and Techniques (3rd Edition)by Jiawei Han, Micheline Kamber, Jian Pei (Morgan Kaufmann) · Chapter 4: Data Warehousing and Online Analytical Processing
ACADEMIC STANDARD
RECOMMENDED YOUTUBE EDUCATORS & FULL-COURSE PLAYLISTS

Curated for clarity, rigorous numerical solving, and semester excellence:

Knowledge Gate · DBMS for GATE & Semester↗Instructor: Sanchit Jain · Covers: ER diagrams, normalization, SQL, transactions, concurrency control

GATE-focused numerical problem-solving with clear worked examples.

Open YouTube↗
Gate Smashers · DBMS Full Course↗Instructor: Varun Singla · Covers: Relational algebra, SQL queries, B/B+ trees, file organization

Fast conceptual coverage with step-by-step GATE numericals.

Open YouTube↗
Neso Academy · DBMS Complete Playlist↗Instructor: Neso Academy · Covers: Relational model, SQL, normalization theory, ACID properties

Systematic textbook-style explanations ideal for first-time learners.

Open YouTube↗
Ravindrababu Ravula · DBMS Lectures↗Instructor: Ravindrababu Ravula · Covers: Functional dependencies, BCNF, 3NF decomposition, transaction schedules

Deep theoretical rigor on normalization and transaction serializability.

Open YouTube↗