4.13: Detailed Figure Captions - Chapter 4

Chapter 4: Data Cleaning and Preparation — Figure Specifications

Overview

• Chapter: 4 — Data Cleaning and Preparation
• Total Figures Proposed: 8
• Figure Types Used: Flowchart, Conceptual Illustration, Comparison Table, Data Chart, Infographic, Architecture Diagram

---

Figure 4.1.1

Title: The Garbage In, Garbage Out (GIGO) Pipeline 

Detailed Caption: Two horizontal pipelines stack on top of each other, sharing the same starting raw-data cylinder but ending at very different outputs. The top "Dirty Data Path" labels its raw-data source with a red warning ("⚠ Errors, NULLs, dupes"), then runs a red "No Cleaning" arrow straight into a navy "Analytics Model" tile, terminating in a red-bordered "Unreliable Insights" box marked with an X. The bottom "Clean Data Path" passes the same raw data through a teal "Data Cleaning · Filter · Fix · Validate" intermediate tile before reaching the navy Analytics Model and arriving at a teal-bordered "Trustworthy Insights" output marked with a checkmark. By keeping the analytics model identical in both rows and varying only the cleaning step, the figure isolates the chapter's GIGO premise: the model itself doesn't need to change to flip the outcome — only adding a deliberate cleaning stage between raw input and analysis distinguishes a reliable result from an unreliable one. 

Figure 4.2.1

Title: Strategies for Handling Missing Data (NULL Values) 

Detailed Caption: A four-column matrix sits beneath a teal header row (Strategy, Description, When to Use, Trade-offs), with four strategy rows alternating between white and pale-gray backgrounds. Omission (Deletion) pairs "Remove records or fields with NULLs" with "Few missing values; MCAR data" and "Can introduce bias if not MCAR." Imputation pairs "Fill with mean, median, mode, or model-predicted value" with "Moderate missingness; numeric fields" and "Preserves size but may reduce variability." Business-Rule Default pairs "Apply domain-specific default" with "Field has logical default interpretation" and "Requires domain knowledge." Flagging pairs "Create indicator column; fill separately" with "Missingness itself is informative" and "Adds complexity; retains info." A warm-gold accent line underscores the header row. By placing each strategy's mechanic, fitness, and downside on a single row, the matrix makes vivid the chapter's working argument: there is no single right answer to missingness — the choice depends on the missingness pattern (MCAR vs. MAR vs. MNAR), the data type, and whether the absence itself carries signal worth preserving. 

Figure 4.3.1

Title: Data Type Mismatch — Impact on SQL Operations 

Detailed Caption: Two side-by-side panels share an identical structure to isolate the single variable that matters. The left red-bordered panel, "✗ Incorrect: STRING type," shows a product_price column with quoted values ("19.99", "24.50", "15.00"), beneath which the SQL SELECT AVG(product_price) FROM Products; runs into a red "ERROR: Cannot average text" result tile. The right teal-bordered panel, "✓ Correct: DECIMAL type," shows the same three values without quotes, the same query, and a teal "Result: 19.83" success tile. A warm-gold "DECIMAL · CAST AS →" arrow bridges the two panels in the middle to indicate the type conversion. By holding everything else constant — same column, same values, same query — the figure isolates type as the determining factor between failure and correct output, and demonstrates that a single CAST statement is often the smallest possible fix between an unusable column and a working analytics dataset. 

Figure 4.4.1

Title: Primary Keys, Surrogate Keys, and Duplicate Detection 

Detailed Caption: A navy banner at the top reads "Surrogate keys (auto-IDs) guarantee key uniqueness but NOT entity uniqueness," anchoring the figure's central claim. Beneath it, a Customers table with columns CustomerID, Name, Email, Phone shows four rows: 1001 John Smith / 1002 Jon Smith share the same email and phone, and 1003 Jane Doe / 1004 Jane M. Doe share the same email and phone — left-side warm-gold brackets label both pairs "Logical Duplicate." Below the table, a three-step teal flow tile sequence runs left to right: 1. Detect (Compare Email/Phone) → 2. Decide (Keep most complete) → 3. Resolve (Merge or delete). The figure makes vivid the chapter's distinction between key uniqueness and entity uniqueness: every CustomerID is technically unique because it's auto-generated, but the underlying real-world entities aren't — and the only way to find true duplicates is to compare the natural attributes (email, phone) that identify the entity in the world rather than relying on the synthetic primary key. 

Figure 4.5.1

Title: Distribution of the Sum of Two Six-Sided Dice 

Detailed Caption: A vertical bar chart shows Combinations (y-axis, 0–6) against Sum (x-axis, 2–12). Eleven teal bars trace the classic triangular distribution of two-dice sums — 1, 2, 3, 4, 5 rising to a peak at 7, then falling through 5, 4, 3, 2, 1 — with the tallest bar at sum=7 highlighted in warm gold and topped by the label "Most likely (6/36)." The shape forms a perfectly symmetric triangle, with sums of 2 and 12 on either edge representing the rarest single-combination outcomes. By rendering the full sample space as bar heights, the figure converts an abstract probability rule into a visual sanity check: any data row claiming a sum below 2 or above 12 is impossible, and even within the valid range, the relative frequencies act as priors students can use to spot suspicious distributions — a real dataset of dice rolls that produced sum=7 only as often as sum=2 would be statistically unlikely enough to warrant investigation. 

Figure 4.5.2

Title: Right-Skewed Distribution with Mean vs. Median 

Detailed Caption: A right-skewed histogram plots Frequency (y-axis) against Value (x-axis, "e.g., Sales Amount $"). Teal bars cluster densely on the left side and rise to a peak slightly left of center, then taper into a long thin tail of progressively shorter bars (rendered in lightening shades to emphasize the tail) that stretches well to the right of the bulk. Two vertical dashed lines mark the central tendencies: a warm-gold "Median" line sits near the peak of the distribution, while a navy "Mean" line sits noticeably to the right, captioned "Skew pulls mean right." A gray callout in the upper-right notes "Long tail may contain: valid rare values OR data entry errors — investigate." The figure makes the chapter's diagnostic point visual: when the mean and median diverge significantly, the dataset is skewed, and the long-tail observations driving that gap deserve individual scrutiny — they could be real high-value outliers (legitimate large sales) or data-quality artifacts (decimal-point errors), and only investigation can tell which.

Figure 4.6.1

Title: Data Integrity Constraints in a Relational Database 

Detailed Caption: Two navy-headered tables sit side by side at the top — Customers (CustomerID PRIMARY KEY with a gold key icon, Name VARCHAR, Email UNIQUE) and Orders (OrderID PRIMARY KEY with a gold key icon, CustomerID FOREIGN KEY in teal, OrderDate DATE, ShipDate DATE) — connected by a teal "FOREIGN KEY" arrow running from Orders.CustomerID back to Customers.CustomerID. Below the Orders table, a warm-gold panel reads "CHECK (ShipDate >= OrderDate)." Beneath both tables, three summary tiles encode the three integrity disciplines: a navy "Entity Integrity" tile (Every record has a unique, non-null key), a teal "Referential Integrity" tile (Every FK references a valid parent), and a warm-gold "Domain Integrity" tile (Values satisfy defined rules and ranges). The two-table example operationalizes the abstract rules: the gold key glyphs anchor entity integrity, the teal arrow embodies referential integrity, and the gold CHECK constraint demonstrates domain integrity in action — together they show why a relational schema is more than data storage; it's a layered system of declarative rules that prevent classes of errors from being saved in the first place. 

Figure 4.7.1

Title: Data Cleaning Workflow — From Raw Data to Analysis-Ready Dataset 

Detailed Caption: Seven numbered steps stack vertically in a top-to-bottom flow, alternating navy and teal fills for visual rhythm, with a final warm-gold capstone. Step 1 Profile Raw Data (teal, "Summary stats, distributions, NULL counts"), Step 2 Handle Missing Values (navy, "Omit, impute, default, or flag"), Step 3 Fix Data Types (teal, "CAST, parse dates, convert units"), Step 4 Standardize & Transform (navy, "Trim, case normalize, recode values"), Step 5 Remove Duplicates (teal, "Identify by key fields, merge or delete"), Step 6 Validate Ranges & Rules (navy, "Check constraints, business logic, referential"), and finally Step 7 Document & Verify (warm gold, "Log changes, preserve raw data, quality tests"). A vertical "Iterate as needed" bracket runs down the left edge of the chain. The deliberate ordering encodes the chapter's pedagogical sequence — profiling first because every later decision depends on knowing the data, types before standardization because trimming text fields requires knowing they're text, validation late because integrity checks should run on already-cleaned data — and the gold final step reminds students that documentation isn't optional; without it, the cleaning is a one-shot operation rather than a reproducible procedure.