Fundamental Concepts

Fundamental Concepts 1. What is Data Modeling, and why is it important?

Answer: Data modeling is the process of creating a visual blueprint or conceptual structure of an enterprise’s data assets. It defines how data is stored, organized, accessed, and updated within a database or analytical framework.

Why it matters: ●​ Prevents data redundancy and inconsistencies. ●​ Establishes clear business rules and data governance across engineering and business teams. ●​ Improves query performance and optimizes storage costs.

2. What are the 3 stages of Data Modeling?

Answer: Data models evolve through three distinct phases, transitioning from high-level business concepts to low-level physical code: Stage

Main Target Audience

Primary Focus

Technology Dependence

Conceptual Model

Business Stakeholders & Analysts

High-level entities (e.g., Customer, Order) and high-level relationships.

Agnostic

Logical Model

Data Architects & Data Engineers

Entities, attributes, primary/foreign keys, and data types, independent of execution tech.

Agnostic

Physical Model

DBAs & Database Developers

Actual tables, columns, indexes, partitioning keys, views, and target DB engine constraints.

Vendor-Specific (e.g., Postgres, Snowflake)

3. What is the difference between OLTP and OLAP systems?

Answer:

Feature

OLTP (Online Transaction Processing)

OLAP (Online Analytical Processing)

Purpose

Day-to-day transactional application backends.

Reporting, business intelligence, and complex analytics.

Operations

Fast, frequent INSERT, UPDATE, DELETE queries.

High-volume SELECT, aggregation, and scan queries.

Data Design

Highly Normalized (3NF) to guarantee write speed and integrity.

Denormalized (Star/Snowflake schema) for rapid read performance.

Typical Engines

PostgreSQL, MySQL, SQL Server.

Snowflake, Databricks, BigQuery, AWS Redshift.

Relational & Data Warehouse Design 4. Explain Normalization (1NF, 2NF, 3NF) vs. Denormalization.

Answer: ●​ Normalization is the process of decomposing a database into multiple related tables to reduce data redundancy and eliminate update/delete anomalies. ○​ 1NF (First Normal Form): Atomic values (no multi-valued/repeating groups in a cell). ○​ 2NF (Second Normal Form): Must be in 1NF, and all non-key attributes must be fully dependent on the primary key (eliminates partial dependency). ○​ 3NF (Third Normal Form): Must be in 2NF, and no non-key attribute can depend on another non-key attribute (eliminates transitive dependency). ●​ Denormalization intentionally introduces redundancy by re-combining normalized tables. ○​ When to use it: In read-heavy OLAP workloads to minimize costly JOIN operations and speed up analytics queries.

5. What are Fact and Dimension Tables in a Data Warehouse?

Answer: ●​ Fact Table: Contains quantitative numeric measurement data (metrics) representing business events (e.g., Sales Amount, Quantity Sold, Timestamp). It typically holds foreign keys linked to surrounding dimension tables.

●​ Dimension Table: Contains descriptive context surrounding business events (e.g., Customer Name, Product Category, Store Location). Dimensions allow users to slice, filter, and group facts in analytical dashboards.

6. Compare Star Schema vs. Snowflake Schema.

Answer: STAR SCHEMA

SNOWFLAKE SCHEMA

[Dim_Product] [Dim_SubCategory] \ | \ [Dim_Category] [Dim_Customer]--[Fact_Sales] \ / \ / [Dim_Product]--[Fact_Sales] [Dim_Store] ●​ Star Schema: Fact table sits in the center directly joined to denormalized dimension tables. ○​ Pros: Simple queries, faster reads/aggregations. ○​ Cons: Redundancy within dimension tables. ●​ Snowflake Schema: Dimensions are broken out into normalized sub-tables (e.g., Product links to SubCategory, which links to Category). ○​ Pros: Minimal data redundancy and smaller storage footprint. ○​ Cons: Slower read performance due to multiple JOIN operations required for complex analytical queries.

Advanced Dimensional Modeling Patterns 7. What are Slowly Changing Dimensions (SCD), and how do you handle them?

Answer: SCDs occur when attribute values in a dimension change over time (e.g., a customer changes their shipping address).

Common types used in data engineering: ●​ SCD Type 0: Retain original value (never updates). ●​ SCD Type 1: Overwrite old data with new data (no history retained). ●​ SCD Type 2: Append a new record with effective dates (valid_from, valid_to) and an is_current boolean flag (full historical audit trail). ●​ SCD Type 3: Add a new column to track previous values (e.g., current_city and previous_city).

8. What is a Surrogate Key, and why is it preferred over a Natural Key? Answer: ●​ A Natural Key is a business-derived identifier (e.g., SSN, Email, ISBN). ●​ A Surrogate Key is a system-generated, synthetic key (usually an auto-increment integer or UUID) created specifically for data modeling.

Why use Surrogate Keys?

1.​ Source system independence: Natural keys can change upstream (e.g., a user changes their email).

2.​ Performance: Joining on simple numeric surrogate keys is faster than joining on string-based natural keys.

3.​ SCD Support: Essential for SCD Type 2 tracking, where a single natural key must exist across multiple temporal rows.

9. What is a Junk Dimension?

Answer: A Junk Dimension is a single dimension table created to group unrelated high-cardinality flags, indicators, or status codes (e.g., is_shipped, payment_status, is_discounted). Instead of adding multiple foreign keys or text flags directly to the Fact table, you combine discrete flag combinations into one consolidated dimension table to preserve dimensional clarity and reduce fact table width.

Practical & Scenario-Based Questions 10. Scenario: How would you design a data model for an E-Commerce Platform (e.g., Amazon)?

Answer Strategy: Walk the interviewer through the steps systematically: 1.​ Identify Business Process: Tracking Customer Purchases.

2.​ Determine Grain: One row per individual line-item on an order receipt.

3.​ Define Dimensions: ○​ Dim_Customer (Name, Tier, Address) ○​ Dim_Product (Title, Category, Price) ○​ Dim_Date (Year, Quarter, Month, Day) ○​ Dim_Payment_Method (Credit Card, PayPal) 4.​ Identify Facts: ○​ Fact_Order_Lines: order_id (Degenerate), customer_key (FK), product_key (FK), unit_price, quantity, discount_amount, total_cost.

11. How do you handle many-to-many ($N:M$) relationships in a Relational Model?

Answer: Relational engines cannot directly implement many-to-many relationships cleanly without data duplication anomalies.

Solution: Insert a Junction/Bridge Table between the two main entities. ●​ Example: A Student can enroll in many Courses, and a Course has many Students. ●​ Create a junction table Enrollments containing student_id (FK) and course_id (FK), converting the $N:M$ relationship into two separate $1:N$ relationships.

12. How do you approach scaling a data model when table sizes grow into billions of rows?

Answer: ●​ Partitioning: Divide large tables into smaller physical chunks based on logical keys (e.g., partition Fact_Logs by created_date year/month).

●​ Clustering / Sorting Keys: In modern cloud data warehouses (Snowflake, BigQuery), define cluster keys to optimize query pruning. ●​ Aggregated / Materialized Views: Pre-compute summarized rollups (e.g., daily sales aggregations) so users don't scan billions of raw transaction rows for high-level reporting. ●​ Archiving / Cold Storage: Move historical data older than a specified retention window (e.g., 3+ years) to object storage (AWS S3/GCS Parquet formats).