/wiki / comprehensive-report

business-intelligence

2026-09-19T00:00:00.000Z

The Problem

Stakeholders ask what happened but engineers hand them raw tables — how do you turn warehouse data into decisions?

Formal Definition

Per Wikipedia: “Business Intelligence is the layer of dashboards, KPIs and self-service queries that sit on top of a warehouse for decision making.”

Explanation

BI is the dashboard of a car — warehouse is the engine, but driver only sees speed and fuel on the dials.

How It Works

Define KPIs like CLV and RFM
Model marts for reporting
Build dashboards in BI tool
Schedule refresh via automation
Share insights with stakeholders

Visual Explanation

Semantic Network

Key Properties

Self-service reduces ticket load
Needs governance on metric definitions
Drill-down needs good dimensional model

Real-World Example

SELECT rfm_segment, COUNT(*) FROM mart GROUP BY 1

Connections

Built from: RFM Segmentation — BI visualizes RFM
Built from: Customer Lifetime Value — KPI source
Related: Data Warehouse — BI consumes warehouse
Related: Star Schema — BI queries star schema

Edge Cases & Gotchas

Vanity metrics — tracking visits not conversion
Dashboard sprawl — 50 dashboards nobody opens

report-automation

2026-09-19T00:00:00.000Z

The Problem

Manual reports take days to refresh — how do you keep dashboards live without emailing spreadsheets?

Formal Definition

Per Wikipedia: “Report automation schedules ETL pipelines to refresh fact and dimension tables and rebuild downstream reports on a cron or event trigger.”

Explanation

Like an alarm that fills your fridge before breakfast — pipeline runs nightly so dashboard is fresh in morning.

How It Works

Orchestrator triggers ETL at schedule
Extract pulls from sources
Transform joins facts/dims
Load into warehouse star schema
BI tool refreshes dashboard

Visual Explanation

Semantic Network

Key Properties

Reduces manual error
Requires idempotent loads
Needs monitoring for late data
Often built with Airflow

Real-World Example

from airflow import DAG
with DAG('daily_report'): pass # schedule ETL

Connections

Built from: ETL Pipeline — automation wraps ETL
Built from: Star Schema — loads into star schema
Related: Apache Airflow — orchestrator
Related: Data Warehouse — warehouse is target

Edge Cases & Gotchas

Backfills overwrite if not partitioned
Silent schema drift breaks loads

Comprehensive Report -- Map of Content

2026-09-02T00:00:00.000Z

Map of Content for Comprehensive Report — 10 concepts. Start here to navigate comprehensive-report.

Core Concepts

Apache Airflow — concept
Customer Lifetime Value — concept
Data Warehouse — concept
Dimension Table — concept
Docker Compose — concept
ETL Pipeline — concept
Fact Table — concept
Prophet Forecasting — concept
RFM Segmentation — concept
Star Schema — concept

Mechanisms & How Things Work

Pages that explain processes/flows.

business-intelligence — auto-linked orphan
report-automation — auto-linked orphan

Comparisons & Tradeoffs

(No synthesis yet — create via ingest or query —save)

apache-airflow

2026-04-14T00:00:00.000Z

The Problem

A data pipeline isn’t a one-time script—it’s a recurring process that must run daily, handle errors gracefully, retry on failure, and notify stakeholders. Building this orchestration logic from scratch is complex and error-prone.

Core Idea

Apache Airflow is a workflow orchestration platform that defines pipelines as directed acyclic graphs (DAGs) of tasks. It handles scheduling, execution, retry logic, monitoring, and alerting—everything needed to run reliable data pipelines in production.

How It Works

DAG definition: Python file defining tasks and their dependencies
Scheduler: Triggers DAG runs on schedule (cron expression like 30 21 * * *)
Executor: Runs tasks (LocalExecutor for single-machine, Celery/Kubernetes for distributed)
Task types: PythonOperator (Python code), BashOperator (shell commands), PostgresOperator (SQL)
Retries: Failed tasks automatically retry with configurable delay
Notifications: Email/Slack on failure via email_on_failure

Example DAG structure (FoodFlow daily ETL):

data_quality_check → run_etl_pipeline → refresh_aggregates → ml_order_volume_forecast → notify_success

Schedule: 30 21 * * * = 21:30 UTC = 03:00 IST (next day)—lowest traffic period

Key Properties

Python-defined DAGs: Code-as-configuration, version-controlled
Task dependencies: Explicit >> or set_upstream() defines execution order
Execution timeout: Maximum runtime per task/DAG prevents stuck pipelines
Catchup=False: Don’t backfill missed runs when DAG was paused
Connection abstraction: Database connections defined in Airflow UI, accessed by tasks

Visual Explanation

Semantic Network

Connections

Builds into: ETL Pipeline — Airflow orchestrates ETL execution
Related: Docker Compose — Airflow runs in containerized environment
Related: Data Warehouse — Airflow writes to warehouse

Edge Cases & Gotchas

LocalExecutor limitation: Single-threaded, not suitable for high parallelism
Pip install on startup: Adds 30-60 seconds to container startup time
Metadata database: Needs separate PostgreSQL for Airflow’s own state
No built-in data quality: Just file existence checks—need Great Expectations for deep validation

customer-lifetime-value

2026-04-14T00:00:00.000Z

The Problem

Not all customers are equal—a customer who spent ₹50,000 over 2 years is more valuable than one who spent ₹500. Marketing needs to identify high-value customers for retention efforts, but raw revenue totals don’t tell the whole story.

Core Idea

Customer Lifetime Value (CLV) is the total revenue expected from a customer over their entire relationship with the company. It combines order frequency, average order value, and tenure to create a single metric that enables customer segmentation, retention targeting, and acquisition budget allocation.

How It Works

Aggregate per customer: From fact_orders, sum net_total for each customer
Calculate metrics:
- Total orders: COUNT(order_id)
- Lifetime value: SUM(net_total)
- Average order value: AVG(net_total)
- Last order date: MAX(order_timestamp)
- Days since last order: CURRENT_DATE - last_order_date
Quartile ranking: Use NTILE(4) to divide into 4 groups by lifetime value
Segment assignment:
- Q1 (top 25%): Champions
- Q2: Loyal
- Q3: At-Risk
- Q4 (bottom 25%): Dormant

SELECT c.customer_id, c.full_name, c.city,
       COUNT(fo.order_id) AS total_orders,
       SUM(fo.net_total) AS lifetime_value,
       NTILE(4) OVER (ORDER BY SUM(fo.net_total) DESC) AS clv_quartile
FROM dim_customer c
LEFT JOIN fact_orders fo ON c.customer_id = fo.customer_id
GROUP BY c.customer_id, c.full_name, c.city

Key Properties

LEFT JOIN: Include customers with zero orders (new prospects who registered but never ordered)
Quartile segmentation: NTILE(4) creates equal groups for targeted marketing
Actionable tiers: Champions, Loyal, At-Risk, Dormant map to specific marketing actions
Combined with tenure: Premium + tenure_days creates customer_segment for richer analysis

Visual Explanation

Semantic Network

Connections

Related: RFM Segmentation — CLV monetary dimension is related to RFM
Related: Dimension Table — customer data stored in dim_customer
Related: Fact Table — order data in fact_orders used for CLV calculation

Edge Cases & Gotchas

Zero orders: LEFT JOIN includes customers who registered but never ordered—they have CLV = 0
Cancelled orders: Filter by status = 'Delivered' to exclude cancelled/refunded orders
Static calculation: CLV updates only when ETL runs—not real-time

data-warehouse

2026-04-14T00:00:00.000Z

The Problem

Transactional databases (OLTP) are optimized for row-level writes (INSERT, UPDATE, DELETE), not analytical queries that scan millions of rows. Running complex aggregations on production databases hurts performance and competes with live traffic.

Core Idea

A data warehouse is a separate analytical database optimized for read-heavy queries. It stores cleaned, transformed data from multiple sources in a structure optimized for aggregations—typically a star schema. It serves as the single source of truth for business intelligence and analytics.

How It Works

Separate from production: Warehouse runs on separate hardware/instances to not impact transactional performance
ETL populates warehouse: ETL pipeline extracts from sources, transforms, loads into warehouse
Star schema design: Fact tables at center, dimension tables surrounding—for minimal JOINs
Pre-aggregations: Aggregate tables (like agg_monthly_revenue) pre-compute common aggregations
Indexing: Composite indexes on foreign keys and frequently filtered columns

In FoodFlow:

PostgreSQL 15 with 5 dimensions, 2 facts, 1 aggregate
80,000 orders, ~200,000 order items, 731 dates
Queries complete in 50-500ms

Key Properties

OLAP optimized: Columnar storage, bitmap indexes, materialized views
Star schema: Denormalized dimensions for query simplicity
Surrogate keys: Integer keys for faster lookups
Pre-aggregated tables: Materialized summaries for BI dashboard performance
Foreign key constraints: Enforce data integrity

Visual Explanation

Semantic Network

Connections

Built from: Star Schema — warehouse uses star schema design
Built from: Dimension Table — warehouse contains dimensions
Built from: Fact Table — warehouse contains facts
Built from: ETL Pipeline — ETL populates warehouse
Related: SQL Database — warehouse is implemented on SQL database

Edge Cases & Gotchas

Separate database: Need connection string, credentials, network access
Data freshness: Batch-loaded data is inherently stale—in production consider streaming
Storage cost: Duplicate data (source + warehouse) doubles storage needs
Query performance: Without proper indexes, analytical queries can be slow

dimension-table

2026-04-14T00:00:00.000Z

The Problem

Fact tables contain quantitative metrics, but they need context—knowing that customer_id = CUST0001 isn’t useful without knowing the customer’s name, city, and preferences. Dimension tables provide this descriptive context.

Core Idea

A dimension table is a denormalized table containing descriptive attributes about a business entity. It has a primary key (often a surrogate key) that connects to foreign keys in fact tables. Each row represents one instance of a business entity (customer, restaurant, date, product).

How It Works

Primary key: Unique identifier for each entity (customer_id, restaurant_id, date_id)
Descriptive attributes: All related information in one table—no need to JOIN
Surrogate keys: Integer-based keys like date_id = 20240115 for performance
Computed attributes: Feature engineering adds derived fields like tenure_days, customer_segment, rating_band

In a food delivery warehouse:

dim_customer: customer_id, full_name, email, city, age_group, gender, is_premium, registration_date, tenure_days, customer_segment
dim_restaurant: restaurant_id, name, city, cuisine_type, rating, rating_band, avg_prep_time_min, is_veg_only
dim_date: date_id, full_date, day, month, year, quarter, week, day_of_week, day_name, is_weekend, is_holiday, is_peak_season

Key Properties

Denormalized: All attributes in one table for query simplicity
SCD Type 1: Overwrites on change (simpler, appropriate for static datasets)
Surrogate keys: Integer-based keys for faster lookups than natural keys
Computed bands: pd.cut() creates categorical bands (rating_band, price_band, performance_tier)
Foreign key in fact: Fact tables reference dimension primary keys

Visual Explanation

Semantic Network

Connections

Built from: Star Schema — dimension tables are a core component
Builds into: Fact Table — fact tables reference dimensions via foreign keys
Related: ETL Pipeline — ETL transforms raw data into dimension tables
Related: Data Warehouse — dimensions are part of the warehouse schema

Edge Cases & Gotchas

Hardcoded reference date: Using fixed reference date (2024-12-31) makes tenure_days stale over time
Type 1 limitation: Customer city change overwrites history—old orders appear in new city
Low-cardinality attributes: Attributes with 3-5 values (status, platform) belong in fact as degenerate dimensions, not separate dimension tables

docker-compose

2026-04-14T00:00:00.000Z

The Problem

A modern data platform requires multiple services—PostgreSQL, Airflow, Metabase, Redis—each with their own configuration, dependencies, and networking. Installing and configuring these manually on a development machine is error-prone and hard to reproduce.

Core Idea

Docker Compose is a tool for defining and running multi-container applications. A single docker-compose.yml file declares all services, their images, ports, volumes, environment variables, and dependencies. Running docker compose up -d starts everything with proper health checks and networking.

How It Works

Service definition: Each container (PostgreSQL, Airflow, Metabase) is defined with image, ports, volumes
Dependencies: depends_on ensures startup order; condition: service_healthy waits for health checks
Volumes: Named volumes persist data across restarts (postgres_data, airflow_db_data)
Health checks: pg_isready for PostgreSQL, curl for web services
Environment variables: Passed to containers for configuration
Network: Default bridge network allows container-to-container communication

Example (FoodFlow services):

foodflow_postgres: PostgreSQL 15 on port 5433
foodflow_airflow_db: Airflow metadata DB
foodflow_airflow: Airflow 2.8.4 web UI on :8080
foodflow_metabase_db: Metabase metadata DB
foodflow_metabase: BI tool on :3000

Key Properties

Single command startup: docker compose up -d starts entire stack
Health checks: Services wait for dependencies to be healthy before starting
Persistent volumes: Data survives docker compose down
Port mapping: Host ports (5433, 8080, 3000) map to container ports
Bind mounts: Local directories mounted into containers for code/data access

Visual Explanation

Semantic Network

Connections

Related: Apache Airflow — runs in Docker Compose environment
Related: Data Warehouse — PostgreSQL runs in Docker Compose
Related: ETL Pipeline — ETL scripts access DB via Docker networking

Edge Cases & Gotchas

Volume persistence: docker compose down keeps volumes; docker compose down -v deletes
Startup order: Even with depends_on, fast-starting services may fail if slow starters aren’t ready
Resource limits: No CPU/memory limits by default—containers can consume host resources
Secrets: Credentials in docker-compose.yml visible to anyone with file access—use Docker secrets in production

etl-pipeline

2026-04-14T00:00:00.000Z

The Problem

Raw source data (CSV files, JSON APIs, transactional databases) arrives in various formats with quality issues—duplicates, inconsistent casing, missing values. Business analysts need clean, structured data in a warehouse schema to run analytical queries.

Core Idea

ETL (Extract, Transform, Load) is a three-phase data pipeline that reads raw data, applies transformations (cleaning, deduplication, feature engineering), and loads it into a data warehouse. It bridges the gap between source systems and analytical consumption.

How It Works

Extract Phase

Read source files (7 CSVs: customers, restaurants, menu_items, delivery_agents, orders, order_items, payments)
Validate file existence and minimum row counts
Load into pandas DataFrames
Log quality metrics (null percentages, duplicate counts)

Transform Phase

Deduplication: drop_duplicates(subset="id") removes exact duplicates
String normalization: .str.strip().str.title() for names, .str.lower() for emails
Date parsing: pd.to_datetime() converts string dates
Feature engineering: Creates computed columns like tenure_days, customer_segment, rating_band
Flag creation: is_delivered = (status == "Delivered").astype(int)

Load Phase

Bulk insert: SQLAlchemy to_sql() with chunksize=5000, method="multi" for batch inserts
Load order: Dimensions first (independent), then facts (depend on dimensions)
Post-load indexing: Create performance indexes after data is loaded

Key Properties

** idempotent**: Same input produces same output—run repeatedly without side effects
Full REPLACE strategy: DROP and recreate tables on each run (simple, suitable for small datasets)
Logging: _log_quality() function logs nulls and duplicates without blocking
Reference date: Fixed reference date (2024-12-31) for computing tenure/experience days

Visual Explanation

Semantic Network

Connections

Builds into: Data Warehouse — ETL populates the warehouse
Builds into: Dimension Table — ETL creates dimension tables
Builds into: Fact Table — ETL creates fact tables
Related: Apache Airflow — orchestration runs ETL on schedule
Related: Star Schema — ETL transforms data into star schema format

Edge Cases & Gotchas

Partial failure: If load fails midway, inconsistent data remains—use transactions
Reference date staleness: Hardcoded 2024-12-31 makes tenure values incorrect over time
Full refresh limitation: Doesn’t scale to millions of rows—in production use incremental UPSERT
No watermark tracking: Simple REPLACE loses ability to process only new records

fact-table

2026-04-14T00:00:00.000Z

The Problem

Business analysts need to answer questions like “total revenue by city” or “orders per day.” Storing this data in normalized transactional tables requires expensive JOINs across multiple normalized tables. Fact tables centralize the quantitative metrics for fast analytical queries.

Core Idea

A fact table is the central table in a star schema, containing measurable business events (orders, clicks, transactions) with foreign keys to dimension tables. Each row represents one event, and columns contain quantitative measures (revenue, quantity, delivery_time).

How It Works

Foreign keys: References to dimension primary keys (customer_id, restaurant_id, date_id)
Measures: Quantitative metrics that can be aggregated (net_total, delivery_time_min, quantity)
Degenerate dimensions: Low-cardinality attributes (status, platform, payment_method) kept directly in fact
Binary flags: Integer flags (is_delivered, is_cancelled) stored as SMALLINT for easy SUM()

In food delivery:

fact_orders: order_id, customer_id, restaurant_id, agent_id, date_id, net_total, delivery_time_min, is_delivered (SMALLINT), status, platform, method
fact_order_items: order_item_id, order_id, item_id, quantity, unit_price, revenue

A query to find top restaurants by revenue:

SELECT r.name, SUM(o.net_total) AS revenue
FROM fact_orders o
JOIN dim_restaurant r ON o.restaurant_id = r.restaurant_id
GROUP BY r.name
ORDER BY revenue DESC

Key Properties

Grain: The level of detail—one row per order, one row per line item
Additive measures: Can be summed (revenue), non-additive (ratings must be averaged)
Foreign key constraints: Enforce referential integrity with dimensions
Composite indexes: On frequently filtered columns (date_id, customer_id, status)
Denormalization: customer_id and date_id included in fact_order_items to avoid JOINs

Visual Explanation

Semantic Network

Connections

Built from: Star Schema — fact tables are the center
Builds into: Data Warehouse — fact tables are core warehouse components
Related: Dimension Table — fact tables reference dimensions
Related: SQL Database — fact tables are implemented in SQL
Related: ETL Pipeline — ETL populates fact tables

Edge Cases & Gotchas

Inconsistent grain: Mixing row-per-order with row-per-line-item in same table causes double-counting
NULL in measures: Aggregations like SUM() ignore NULLs—use COALESCE or fill nulls with 0
Integer flags vs boolean: Using SMALLINT (0/1) instead of BOOLEAN enables SUM(is_delivered) directly
Degenerate dimension misuse: Creating separate tables for 3-5 value attributes adds overhead with no benefit

prophet-forecasting

2026-04-14T00:00:00.000Z

The Problem

Business users need to know future demand—how many orders will arrive tomorrow, next week, next month. Traditional statistical methods (ARIMA, SARIMA) require manual parameter tuning, handle missing data poorly, and don’t automatically detect changepoints.

Core Idea

Facebook Prophet is a time-series forecasting library designed for business data with strong seasonal patterns. It automatically detects trend changes, models weekly/yearly seasonality, and handles missing data gracefully—unlike ARIMA which requires complete data series.

How It Works

Training data: Aggregate daily counts (delivered orders) with dates as ds and counts as y
Model configuration:
- changepoint_prior_scale: Controls trend flexibility (higher = more adaptive)
- seasonality_mode="multiplicative": Seasonal patterns scale with trend level
- Enable weekly and yearly seasonality
Custom regressors: Add is_weekend flag as external regressor
Forecast generation: m.make_future_dataframe(periods=30) creates future dates
Output: Point estimates (yhat) with confidence intervals (yhat_lower, yhat_upper)
Evaluation: MAPE, MAE, RMSE on in-sample fit

m = Prophet(
    changepoint_prior_scale=0.15,
    seasonality_mode="multiplicative",
    weekly_seasonality=True,
    yearly_seasonality=True,
)
m.add_regressor("is_weekend")
m.fit(df)
future = m.make_future_dataframe(periods=30)
forecast = m.predict(future)

Key Properties

Automatic changepoint detection: Finds where trend changes significantly
Handles missing data: Unlike ARIMA which requires complete series
Multiplicative seasonality: Seasonal effects scale with trend—realistic for growing businesses
Interpretable components: Trend, weekly seasonality, yearly seasonality
Confidence intervals: Provides uncertainty bounds for decisions

Visual Explanation

Semantic Network

Connections

Related: Data Warehouse — forecasts stored in warehouse
Related: ETL Pipeline — ML forecast runs after ETL
Related: Apache Airflow — Airflow orchestrates forecast scheduling

Edge Cases & Gotchas

In-sample evaluation only: MAPE/MAE/RMSE on training data overestimates quality—need holdout set
No baseline comparison: Can’t tell if Prophet beats naive forecast without comparison
Limited regressors: Only is_weekend used—could benefit from holidays, promotions
Single model: No model versioning or A/B testing

rfm-segmentation

2026-04-14T00:00:00.000Z

The Problem

Marketers need to segment customers into actionable groups—like “champions” who buy frequently and recently, or “at-risk” who used to buy but haven’t ordered recently. Simple counts aren’t enough—they need behavioral segmentation based on purchase patterns.

Core Idea

RFM (Recency, Frequency, Monetary) is a customer segmentation technique that scores each customer on three dimensions:

Recency: Days since last order (lower is better)
Frequency: Number of orders (higher is better)
Monetary: Total spending (higher is better)

Each dimension is scored 1-5 using NTILE(5), then combined into 9 actionable segments.

How It Works

Aggregate customer metrics: From fact_orders, get recency_days, frequency (count), monetary (sum)
NTILE scoring: Divide customers into 5 equal groups per dimension
- Recency: 5 = most recent, 1 = least recent
- Frequency: 5 = most frequent, 1 = least frequent
- Monetary: 5 = highest spend, 1 = lowest spend
Segment assignment: Decision tree based on R/F/M scores

Segment	R Score	F Score	M Score
Champions	4+	4+	4+
Loyal Customers	3+	3+	3+
New Customers	4+	≤2	≤2
Potential Loyalists	3+	3+	2+
Recent Customers	4+	4+	≤2
At-Risk Customers	≤2	4+	4+
About to Sleep	≤2	3+	3+
Lost	≤2	≤2	≤2
Can’t Lose Them	3+	≤2	3+

Key Properties

NTILE(5): Equal-frequency binning—each quintile has ~20% of customers
9 segments: Standard marketing framework with actionable insights
SQL implementation: Uses window functions (NTILE) and CASE expressions
Business value: Directs marketing resources to highest-value segments

Visual Explanation

Semantic Network

Connections

Related: Customer Lifetime Value — CLV is closely related to RFM monetary dimension
Related: Data Warehouse — RFM queries run against warehouse
Related: ETL Pipeline — customer data prepared by ETL

Edge Cases & Gotchas

Zero orders: Customers with no orders require LEFT JOIN, result in NULL/zero values
Equal-frequency binning: NTILE creates equal groups, not equal ranges—outliers affect scores
Static segmentation: Updates only when ETL runs—not real-time

star-schema

2026-04-14T00:00:00.000Z

The Problem

Relational databases are optimized for transactional operations (INSERT, UPDATE, DELETE), not analytical queries that aggregate millions of rows. A normalized transactional schema requires multiple JOINs to answer business questions, which becomes slow and complex at scale.

Core Idea

Star schema is a denormalized data modeling approach where a central fact table (containing measurable business events) is surrounded by dimension tables (containing descriptive attributes). This design minimizes JOINs for analytical queries—a query typically joins only the fact table with one or more dimension tables.

How It Works

Fact tables sit at the center, containing quantitative metrics (orders, revenue, quantities) and foreign keys to dimensions
Dimension tables surround the facts, containing descriptive attributes (customer names, restaurant cuisines, dates)
Each dimension has a primary key (surrogate key) that joins to the fact table
Dimensions are denormalized—all related attributes live in a single table rather than being split across normalized tables

For example, a food delivery schema might have:

fact_orders: 80,000 rows with order_id, customer_id, restaurant_id, agent_id, date_id, net_total
dim_customer: 5,000 rows with customer_id, name, city, age_group, is_premium
dim_restaurant: 200 rows with restaurant_id, name, city, cuisine_type, rating
dim_date: 731 rows with date_id, full_date, day, month, year, is_weekend, is_holiday

A query like “total revenue by city for Q1 2024” only needs:

SELECT r.city, SUM(o.net_total)
FROM fact_orders o
JOIN dim_date d ON o.date_id = d.date_id
JOIN dim_restaurant r ON o.restaurant_id = r.restaurant_id
WHERE d.year = 2024 AND d.quarter = 1
GROUP BY r.city

Key Properties

Denormalized dimensions: All attributes in one table—no need to JOIN dimension tables together
Surrogate keys: Integer-based keys (like date_id = YYYYMMDD) for faster range scans than DATE comparisons
Degenerate dimensions: Low-cardinality attributes (status, platform, payment method) kept in fact table rather than separate dimensions
Foreign key constraints: Enforce referential integrity between fact and dimension tables
Composite primary keys: Aggregate tables use composite keys (year, month, city, cuisine_type) for uniqueness

Visual Explanation

Semantic Network

Connections

Built from: SQL Database — star schema is implemented on top of relational databases
Builds into: Data Warehouse — star schema is the standard schema design for OLAP warehouses
Builds into: Dimension Table — dimension tables are a core component of star schema
Builds into: Fact Table — fact tables are the center of star schema
Related: ETL Pipeline — ETL populates star schema tables from source data

Edge Cases & Gotchas

SCD Type 1 only: Overwrites on change—historical orders show new city if customer moves
Full refresh: For small datasets, full REPLACE (DROP + INSERT) is simpler than incremental loads
Integer vs DATE: Using INTEGER date_id (YYYYMMDD) performs faster than DATE type for range scans in PostgreSQL

/wiki / comprehensive-report

business-intelligence

The Problem

Formal Definition

Explanation

How It Works

Visual Explanation

Semantic Network

Key Properties

Real-World Example

Connections

Edge Cases & Gotchas

report-automation

The Problem

Formal Definition

Explanation

How It Works

Visual Explanation

Semantic Network

Key Properties

Real-World Example

Connections

Edge Cases & Gotchas

Comprehensive Report -- Map of Content

Core Concepts

Mechanisms & How Things Work

Comparisons & Tradeoffs

Suggested Reading Order

apache-airflow

The Problem

Core Idea

How It Works

Key Properties

Visual Explanation

Semantic Network

Connections

Edge Cases & Gotchas

customer-lifetime-value

The Problem

Core Idea

How It Works

Key Properties

Visual Explanation

Semantic Network

Connections

Edge Cases & Gotchas

data-warehouse

The Problem

Core Idea

How It Works

Key Properties

Visual Explanation

Semantic Network

Connections

Edge Cases & Gotchas

dimension-table

The Problem

Core Idea

How It Works

Key Properties

Visual Explanation

Semantic Network

Connections

Edge Cases & Gotchas

docker-compose

The Problem

Core Idea

How It Works

Key Properties

Visual Explanation

Semantic Network

Connections

Edge Cases & Gotchas

etl-pipeline

The Problem

Core Idea

How It Works

Extract Phase

Transform Phase

Load Phase