11.5: Detailed Figure Captions - Chapter 11

Last updated
Save as PDF

Page ID: 60921

Felix Amoruwa
De Anza College

$ \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } $

$ \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} $

$ \newcommand{\dsum}{\displaystyle\sum\limits} $

$ \newcommand{\dint}{\displaystyle\int\limits} $

$ \newcommand{\dlim}{\displaystyle\lim\limits} $

$ \newcommand{\id}{\mathrm{id}}$ $ \newcommand{\Span}{\mathrm{span}}$

( \newcommand{\kernel}{\mathrm{null}\,}\) $ \newcommand{\range}{\mathrm{range}\,}$

$ \newcommand{\RealPart}{\mathrm{Re}}$ $ \newcommand{\ImaginaryPart}{\mathrm{Im}}$

$ \newcommand{\Argument}{\mathrm{Arg}}$ $ \newcommand{\norm}[1]{\| #1 \|}$

$ \newcommand{\inner}[2]{\langle #1, #2 \rangle}$

$ \newcommand{\Span}{\mathrm{span}}$

$ \newcommand{\id}{\mathrm{id}}$

$ \newcommand{\Span}{\mathrm{span}}$

$ \newcommand{\kernel}{\mathrm{null}\,}$

$ \newcommand{\range}{\mathrm{range}\,}$

$ \newcommand{\RealPart}{\mathrm{Re}}$

$ \newcommand{\ImaginaryPart}{\mathrm{Im}}$

$ \newcommand{\Argument}{\mathrm{Arg}}$

$ \newcommand{\norm}[1]{\| #1 \|}$

$ \newcommand{\inner}[2]{\langle #1, #2 \rangle}$

$ \newcommand{\Span}{\mathrm{span}}$ $ \newcommand{\AA}{\unicode[.8,0]{x212B}}$

$ \newcommand{\vectorA}[1]{\vec{#1}} % arrow$

$ \newcommand{\vectorAt}[1]{\vec{\text{#1}}} % arrow$

$ \newcommand{\vectorB}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } $

$ \newcommand{\vectorC}[1]{\textbf{#1}} $

$ \newcommand{\vectorD}[1]{\overrightarrow{#1}} $

$ \newcommand{\vectorDt}[1]{\overrightarrow{\text{#1}}} $

$ \newcommand{\vectE}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash{\mathbf {#1}}}} $

$ \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } $

$\newcommand{\longvect}{\overrightarrow}$

$ \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} $

$\newcommand{\ket}[1]{\left| #1 \right>}$
$\newcommand{\bra}[1]{\left< #1 \right|}$
$\newcommand{\braket}[2]{\left< #1 \vphantom{#2} \right| \left. #2 \vphantom{#1} \right>}$
$\newcommand{\braopket}[3]{\left< #1 \vphantom{#2}\vphantom{#3} \right| #2 \vphantom{#1}\vphantom{#3} \left| #3 \vphantom{#1}\vphantom{#2} \right>}$
$\newcommand{\qmvec}[1]{\mathbf{\vec{#1}}}$
$\newcommand{\op}[1]{\hat{\mathbf{#1}}}$
$\newcommand{\expect}[1]{\langle #1 \rangle}$
$\newcommand{\dfn}[1]{\emph{\textbf{#1}}}$

$\newcommand{\avec}{\mathbf a}$ $\newcommand{\bvec}{\mathbf b}$ $\newcommand{\cvec}{\mathbf c}$ $\newcommand{\dvec}{\mathbf d}$ $\newcommand{\dtil}{\widetilde{\mathbf d}}$ $\newcommand{\evec}{\mathbf e}$ $\newcommand{\fvec}{\mathbf f}$ $\newcommand{\nvec}{\mathbf n}$ $\newcommand{\pvec}{\mathbf p}$ $\newcommand{\qvec}{\mathbf q}$ $\newcommand{\svec}{\mathbf s}$ $\newcommand{\tvec}{\mathbf t}$ $\newcommand{\uvec}{\mathbf u}$ $\newcommand{\vvec}{\mathbf v}$ $\newcommand{\wvec}{\mathbf w}$ $\newcommand{\xvec}{\mathbf x}$ $\newcommand{\yvec}{\mathbf y}$ $\newcommand{\zvec}{\mathbf z}$ $\newcommand{\rvec}{\mathbf r}$ $\newcommand{\mvec}{\mathbf m}$ $\newcommand{\zerovec}{\mathbf 0}$ $\newcommand{\onevec}{\mathbf 1}$ $\newcommand{\real}{\mathbb R}$ $\newcommand{\twovec}[2]{\left[\begin{array}{r}#1 \\ #2 \end{array}\right]}$ $\newcommand{\ctwovec}[2]{\left[\begin{array}{c}#1 \\ #2 \end{array}\right]}$ $\newcommand{\threevec}[3]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \end{array}\right]}$ $\newcommand{\cthreevec}[3]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \end{array}\right]}$ $\newcommand{\fourvec}[4]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \\ #4 \end{array}\right]}$ $\newcommand{\cfourvec}[4]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \\ #4 \end{array}\right]}$ $\newcommand{\fivevec}[5]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \\ #4 \\ #5 \\ \end{array}\right]}$ $\newcommand{\cfivevec}[5]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \\ #4 \\ #5 \\ \end{array}\right]}$ $\newcommand{\mattwo}[4]{\left[\begin{array}{rr}#1 \amp #2 \\ #3 \amp #4 \\ \end{array}\right]}$ $\newcommand{\laspan}[1]{\text{Span}\{#1\}}$ $\newcommand{\bcal}{\cal B}$ $\newcommand{\ccal}{\cal C}$ $\newcommand{\scal}{\cal S}$ $\newcommand{\wcal}{\cal W}$ $\newcommand{\ecal}{\cal E}$ $\newcommand{\coords}[2]{\left\{#1\right\}_{#2}}$ $\newcommand{\gray}[1]{\color{gray}{#1}}$ $\newcommand{\lgray}[1]{\color{lightgray}{#1}}$ $\newcommand{\rank}{\operatorname{rank}}$ $\newcommand{\row}{\text{Row}}$ $\newcommand{\col}{\text{Col}}$ $\renewcommand{\row}{\text{Row}}$ $\newcommand{\nul}{\text{Nul}}$ $\newcommand{\var}{\text{Var}}$ $\newcommand{\corr}{\text{corr}}$ $\newcommand{\len}[1]{\left|#1\right|}$ $\newcommand{\bbar}{\overline{\bvec}}$ $\newcommand{\bhat}{\widehat{\bvec}}$ $\newcommand{\bperp}{\bvec^\perp}$ $\newcommand{\xhat}{\widehat{\xvec}}$ $\newcommand{\vhat}{\widehat{\vvec}}$ $\newcommand{\uhat}{\widehat{\uvec}}$ $\newcommand{\what}{\widehat{\wvec}}$ $\newcommand{\Sighat}{\widehat{\Sigma}}$ $\newcommand{\lt}{<}$ $\newcommand{\gt}{>}$ $\newcommand{\amp}{&}$ $\definecolor{fillinmathshade}{gray}{0.9}$

Chapter 11: Business Intelligence and Embedded Analytics — Figure Specifications

Overview

Chapter: 11 — Business Intelligence and Embedded Analytics
Total Figures Proposed: 8
Figure Types Used: Architecture Diagram, Conceptual Illustration, Comparison Table, Flowchart, Network Diagram, Infographic

Figure 11.1.1

Title: Three-Tier BI Architecture Pipeline

Detailed Caption: A left-to-right horizontal pipeline spans three tiers separated by vertical dashed dividers, each tier labeled in gray above it. Tier 1 (Data Sources & Storage) shows navy source boxes for ERP DB, CRM DB, and CSV/APIs feeding a teal ETL Process box, which in turn feeds a warm-gold cylinder representing the Data Warehouse. A teal arrow carries data rightward into Tier 2 (Analytics Engine), where a large teal OLAP Server rectangle carries the sub-labels Slice, Dice, Drill, and Roll Up. Another teal arrow delivers results into Tier 3 (Front-End Tools), where three warm-gold tiles — Dashboards, Reports, and Self-Service Analytics — surface the output for end users shown in a gray box at the far right; a light-gray Metadata Repository bar spans the full width at the bottom. By placing the complete data journey on a single canvas, the figure makes abstract architectural language concrete: each tier has a distinct job — acquiring and warehousing, aggregating and pivoting, and presenting — and the pipeline metaphor conveys that data must complete each stage before the next one becomes meaningful, giving students a navigational map they can return to throughout the chapter as individual components are introduced in depth.

Figure 11.1.2

Title: Star Schema Design for a Sales Data Warehouse

Detailed Caption: A central warm-gold bordered rectangle labeled Sales_Fact occupies the middle of the canvas, listing its foreign-key fields (product_id, time_id, customer_id, region_id) in dark text and its measure fields (sales_amount, cost, quantity) in warm gold to visually distinguish lookup keys from analytical values. Four teal-bordered dimension tables radiate outward in a star pattern — Product_Dim at the top left with product_id PK, product_name, and category; Time_Dim at the top right with time_id PK and day/month/quarter/year; Customer_Dim at the bottom left with customer_id PK and customer_name/segment; and Region_Dim at the bottom right with region_id PK and region_name/country — each connected to the fact table by a teal line annotated 1:N to indicate cardinality. The spatial arrangement does the pedagogical work that prose alone cannot: the star shape makes the naming convention self-evident, the 1:N annotations anchor cardinality before any formal definition is given, and placing the measure fields in a contrasting color immediately communicates that the fact table holds what you measure while the dimension tables hold how you slice it — a distinction central to every OLAP query students will encounter in the chapter.

Figure 11.1.3

Title: OLAP Cube with Three Dimensions

Detailed Caption: An isometric three-dimensional cube dominates the left side of the figure, its three faces rendered in translucent teal with navy edges and internal grid lines dividing each face into a 3×3 matrix; the X-axis running along the base is labeled Product with values Laptops, Bikes, and Phones, the Y-axis on the left face is labeled Region with values NA, EU, and Asia, and the Z-axis receding to the upper right is labeled Year with values 2023, 2024, and 2025. One cell at the intersection of Bikes, NA, and the front face is highlighted in warm gold and contains the measure label $1.2M, demonstrating that each cell stores a pre-aggregated value. Two small inset panels to the right illustrate OLAP operations: a teal-bordered panel labeled Slice: Year=2025 shows a flat Product × Region grid, and a warm-gold-bordered panel labeled Dice: Subset shows a smaller sub-region of the cube covering two products, two regions, and two years. The highlighted cell and the two insets together convert the cube from a static geometry exercise into a functional diagram: students can trace exactly what happens when a Year filter is applied (Slice collapses the cube to one teal grid) versus when multiple dimension ranges are selected (Dice retains a smaller warm-gold sub-cube), making the abstract OLAP vocabulary of slicing and dicing visually unambiguous.

Figure 11.1.4

Title: OLTP vs. OLAP Systems Comparison

Detailed Caption: A two-column comparison table with navy header bars — OLTP on the left, OLAP on the right — organizes six dimensions of contrast across alternating white and pale-teal rows, with a thin vertical rule separating the two systems. Row by row the table reveals a systematic inversion: Purpose contrasts day-to-day operations with historical analysis and reporting; Users contrasts clerks and front-line staff with analysts and managers; Queries contrasts simple INSERT/UPDATE statements with complex aggregations using GROUP BY; Model contrasts a highly normalized third-normal-form schema with a denormalized star or snowflake schema; Currency contrasts current real-time data with historical time-stamped data; and Optimize contrasts high write throughput with fast complex reads. By collapsing six dimensions of contrast onto a single scannable canvas, the table makes the design trade-off visible as a coherent whole rather than a list of disconnected facts: every row reinforces the same underlying tension — OLTP optimizes for the speed of individual writes while OLAP optimizes for the depth of historical reads — and students who internalize that one principle can reconstruct every row in the table from first principles.

Figure 11.1.4.2

Title: OLAP Data Cube with Multiple Dimensions

Detailed Caption: The diagram depicts a three-dimensional cube rendered in perspective against a black grid background, representing an OLAP (Online Analytical Processing) data cube — a multidimensional data structure used for fast analytical querying.

The three dimensions (axes) of the cube are: 1. Products (labeled on the top face, running left-to-right) — represents the product dimension (e.g., Bike, Laptop, Phone, etc.) 2. Cities (labeled on the front-right face, running along the depth axis) — represents the geographic/regional dimension (e.g., cities or regions like North America). 3. Time (labeled on the top-right edge, running diagonally upward) — represents the temporal dimension (e.g., Year=2025, quarters, months).

What each cell represents: Each cell within the cube holds a pre-aggregated measure (such as total sales). For example, the cell at the intersection of Product=Bike, Region=North America, Year=2025 might hold the total sales of bikes in North America in 2025. Key concept: Analysts can slice the cube (fix one dimension to see a 2D view, like all Products vs. Regions for a specific Year) or drill down (expand the Time dimension into quarters or months) to explore data in detail. OLAP cubes overcome the performance limitations of relational databases for complex multi-dimensional queries by trading off storage space for computation speed — pre-computing and storing aggregates in advance.

Figure 11.2.1

Title: Enterprise BI Platform Comparison Matrix

Detailed Caption: A six-row, four-column comparison matrix with navy header tiles identifies the platforms — Tableau, Power BI, Qlik Sense, and SAS BI/Viya — across the top, with row labels along the left margin in navy bold text. Alternating white and pale-teal rows carry short cell entries for Strength, Users, Differentiator, Deploy, Ecosystem, and Pricing; the Differentiator row uses a warm-gold background to draw the eye to each platform's single most distinctive claim: intuitive drag-and-drop for Tableau, Microsoft ecosystem integration for Power BI, the associative engine for Qlik Sense, and built-in ML and statistics for SAS. The warm-gold highlight on the Differentiator row is a deliberate pedagogical signal: when every platform supports dashboards, reports, and cloud deployment, the question that matters is not what each tool does but what it does that the others do not — and singling out that row in a contrasting color ensures students leave the figure with a clear mental anchor for each platform rather than a blur of overlapping capabilities.

Figure 11.2.2

Title: Open-Source BI Tools Comparison

Detailed Caption: A three-column, six-row table with navy header tiles labels the tools — Metabase, Apache Superset, and Redash — across the top, and carries row labels for Audience, Query, Viz Depth, Setup, Strength, and Best For down the left margin. Alternating white and pale-teal rows fill in each cell in small sans-serif text, while the Strength row uses warm-gold text on a pale-gold background to call out each tool's defining advantage: Ease & quick setup for Metabase, Feature breadth for Superset, and Collaborative SQL for Redash — rendered in warm gold on pale gold so that row stands apart from the surrounding white-and-teal pattern. The table's column sequence traces a progression in technical demand from left to right — non-technical point-and-click through hybrid no-code/SQL Lab to SQL-first — so that the three tools are implicitly ranked by the skill level they assume, giving students an immediate heuristic for matching tool to team: if the audience cannot write SQL, reach for Metabase; if the team needs 40-plus chart types and extensibility at scale, choose Superset; if analysts want a fast collaborative SQL scratchpad, choose Redash.

Figure 11.2.3

Title: Cloud-Native BI in the Modern Data Stack

Detailed Caption: Three gray delivery tiles — Browser Dashboards, Mobile Access, and Embedded in Apps — sit at the top of the figure, receiving upward teal arrows from two warm-gold BI tool boxes below them: Looker (sub-labeled LookML Semantic Layer) on the left and QuickSight (sub-labeled Serverless / SPICE Engine) on the right. Bidirectional teal connectors descend from each BI tool box down to a large pale-teal Cloud Data Platform rectangle at the bottom, which contains three navy tiles for Snowflake, BigQuery, and Redshift; the connector between Looker and the platform is annotated In-database queries (SQL). The vertical flow — cloud platform at the bottom, BI tools in the middle, delivery channels at the top — inverts the conventional left-to-right pipeline from Figure 11.1.1 and in doing so captures the defining feature of cloud-native BI: rather than pulling data up and out into a separate server, the BI tool pushes SQL queries down into the data platform and returns only results, eliminating the extract-and-load step that dominated traditional architectures and allowing the cloud warehouse to serve simultaneously as the storage layer and the computation layer.

Figure 11.2.4

Title: Embedded Analytics Integration Patterns

Detailed Caption: Four quadrants arranged in a 2×2 grid each carry a navy bold title, a small schematic, and a one-line trade-off note. The top-left IFrame Embedding quadrant shows a Host Application rectangle containing a warm-gold dashed iframe region labeled BI Dashboard, annotated Quick setup, limited customization. The top-right JavaScript SDK quadrant shows a Host App box connected by bidirectional teal lines to a warm-gold BI Server box, annotated Deep integration, programmatic control. The bottom-left API-Driven quadrant shows a Host App box sending a teal REST API arrow to a warm-gold BI Platform box and receiving a return JSON + token arrow, annotated Maximum flexibility, more dev effort. The bottom-right White-Label quadrant shows a host application window with the BI content rendered in a seamlessly matching teal-tinted region bearing no vendor branding, annotated Premium licensing, best UX. The 2×2 layout forces a two-dimensional reading: scanning horizontally across the top row reveals that both iframe and SDK approaches sit inside the host application but differ in control depth, while scanning vertically down the left column reveals that both iframe and API approaches involve a clear boundary between host and BI platform but differ in how that boundary is crossed — and the consistent format of schematic plus trade-off note in every quadrant makes the figure a portable reference that developers and product managers can use to match integration pattern to project constraints.

Search

Text Color

Text Size

Margin Size

Font Type