FIT3003 Unit Cheatsheet

Context: FIT3003_MOC · the whole unit W1–W12 in one re-read — design a star → build and clean it → bend it for special cases → aggregate it → query it (OLAP) → analyse it → keep it live · SQL syntax lives in Oracle SQL Toolkit (Cheatsheet) · links for depth only. Read order: ⛔ = precondition / trap where marks die · ⚙️ Procedure = build or computation to run by hand · Route: A1 quiz ⟵ §1–§2 · A2 assignment ⟵ §2–§8 · A3 OLAP quiz ⟵ §9 · Exam ⟵ §1–§8, §10–§11 — Ch19 OLAP (§9) is excluded from the exam (assessed by A3), Ch15–17 are out of the unit · §12 is the W12 emerging-topics deck, examinability not stated.

Quick Revision

• 🎯 Objective: read the case → derive fact, grain, dimensions from the analysis questions → run the router below for anything that will not fit a plain star → build from the operational tables → validate by predicted row counts.
• ⚡ Key Constraint: design questions are marked on the justification — name the source feature (an m–m, a min/max measure, a changing attribute) that forces the shape, never just draw it.

🧭 Design Router — the case shows… ➔ use…

The case shows	Pattern	§
a measure some dimension cannot sensibly carry	split into two facts (different subject)	§2, §7
the same measure needed at a coarser level of a dimension	second fact by granularity / levels of aggregation	§7, §8
a many-many in the source between the fact’s owner entity and a wanted dimension	bridge table (snowflake)	§4
two dimensions in a many-1 relationship	separate · combined · hierarchy · linked — usually not a hierarchy	§4
an attribute whose value changes over time and history is reported	SCD type 2 / 4 / 6	§5
measures meaningless unless one dimension is named (min/max/avg per type)	determinant dimension (dashed box) → pivot or enforce in the UI	§6
several tiny, unrelated flag dimensions	junk dimension	§6
a dimension holding nothing but its key	one-attribute dimension → move into the fact or keep	§6
one transaction with two participants from one pool (pilot + co-pilot)	multi-role → one star per role	§3, §7
two stars that look combinable	combining — classify by pools × shared transaction record	§7
several operational sources answering the same questions	multi-input → vertical or horizontal stacking	§8
the warehouse must reflect inserts immediately	active warehouse → view or table + trigger per object	§11

1️⃣ Warehousing Fundamentals (W1)

• Operational DB vs warehouse ➔ current, detailed, normalised, many small reads/writes vs historical, integrated, pre-designed, precomputed at a fixed granularity, few queries over huge sets · both are relational — the cube is the logical view, the star is the physical layout.
• Why not ER + normalisation ➔ normalised operational design does not serve advanced analysis, so dimensional modelling was needed.
• Delivery chain ➔ operational DBs $\stackrel{\text{ETL}}{\to }$ warehouse $\stackrel{\text{OLAP}}{\to }$ BI reports → analytics · ETL $=$ extraction, transformation, load · OLAP retrieves, BI presents.
• Four warehouse features ➔ Integrated · Subject-oriented · Time-variant · Non-volatile.
• Five reasons a warehouse is still needed ➔ no direct access to operational DBs (you receive extracts) · data and process quality · precomputed measures · granularity · project scope.
• Data Engineering ➔ the product is data; modularise the pipeline for specialisation · quality assurance · abstraction — ad-hoc cleaning is not repeatable.
• Granularity is irreversible ➔ nothing finer than the stored grain can be reported without reloading.
• Old-style joins ➔ FIT3003 writes comma joins with conditions in where · $n$ tables need $n-1$ conditions ⛔ a missing one gives a Cartesian product ➔ SQL Joins (ANSI).

2️⃣ Star Schema: Design and Build (W2)

• Star Schema ➔ fact $=$ numeric measures · dimensions $=$ qualifying perspectives · attributes $=$ what you group by · ⛔ derive dimensions from the analysis questions, never guess.
• Fact shape ➔ $\text{FACT}(\underline{{\text{DimID}}_1^{\ast },\dots ,{\text{DimID}}_n^{\ast }},\text{measures})$ — the composite PK is the dimension FKs; the fact is the $n$-ary relationship standing for the source transaction.
• Notation ➔ XxxDIM / XxxFACT · dimension ID is the dimension’s PK and the fact’s FK $+$ PK (bold italic above the line) · measures numeric only · dashed box $=$ determinant dimension · an un-keyed attribute on its own band in the fact $=$ dimension-less key · one hop from fact to every dimension (snowflake is the exception).
• Two-column test ➔ imagine category | measure per dimension; every table must make sense for every measure ⛔ one failing pairing invalidates the star → split the measure into its own fact.
• Grounding check ➔ write literal cube rows · name the source record · say what one record contributes (a count measure has no source column) · read two real questions back off the draft.

Measure	Store it?	Roll-up
count(*) / count(col) / count(distinct col)	✅	additive — sum the fact rows
sum	✅	additive
min / max	✅ separately	global value survives · ⛔ never max(Min_X)
avg	❌ store total $+$ count, divide at query time	average of averages loses the weights · legal only if every dimension is always used (§6)

⚙️ Procedure — build dimensions, then the fact

• Dimension ➔ one select per dimension, select distinct from a transaction source (⛔ else the FK matches many rows) · manufacture keys with || (Year || Quarter) and to_char · a derived or banded attribute: stage a temp dimension → alter add → one update per band → select distinct.
• Fact ➔ select <dimension keys>, <aggregate> … group by <the same keys> from the operational tables, never the dimension tables · a derived key: stage a TempFact (unaggregated join), band the key onto it, then the single group by.
• Two populations (openings vs placements) ➔ left outer join $+$ count(attribute) ⛔ count(*) counts the NULL padding.
• Latest-per-entity ➔ rank() over (partition by … order by … desc) then where rank = 1, before joining.
• ⛔ CTAS copies rows only — no PK/FK comes across ➔ Populating Tables from Queries (INSERT-SELECT, CTAS).

• Group on the code, join for the label ➔ grouping on a shared description merges members (USELOG: $722$ vs $773$ rows).

3️⃣ Validation, Cleaning and Multi-Role Facts (W3)

⚙️ Procedure — validate by row counts

① count(*) every source table ② predict the join: a 1–$m$ join returns exactly the $m$-side count ③ count the TempFact and compare ④ explain every difference · source → TempFact must not change size; TempFact → fact is expected to shrink.

Symptom	Cause	Probe
TempFact $>$ $m$-side	duplicate PK on the 1 side	group by key having count(*) > 1 on both join sides
TempFact $<$ $m$-side	orphan FKs on the $m$ side	rows with no matching parent
fact row count right, measures wrong	duplicates absorbed by the group by	⛔ a fact row count proves nothing — check upstream

• Five dirty-data types ➔ duplicates · relationship/constraint violation (orphan FK) · inconsistent values (attributes contradicting) · incorrect values (outside the domain) · NULLs in mandatory attributes · each as check select first, then repair — never repair blind.
• Three cleaning routes ➔ select distinct at the join (read-only source; removes byte-identical rows only) · copy the source, then clean it (orphans, near-duplicates, out-of-range) · document a defect the fact never reads ⛔ A2 requires every issue addressed.
• Clean before aggregating ➔ once group by runs, the defect is fused into the measure.
• Multi-Role Facts ➔ one table read in two roles (pilot, co-pilot) ⟹ one star per role, not a fact with two keys (that changes the grain) · union-merge only per-person measures with the other dimensions dropped ⛔ trip measures (fuel, revenue) double-count when both roles share a transaction.

4️⃣ Snowflakes: Hierarchies and Bridges (W4)

	Hierarchy	Bridge
Middle table	a full dimension with attributes	a key pair only
Source cardinality	many-1 all the way	many-many
Optional?	yes — can always be flattened	no — the fact cannot hold the far key
Buys	3NF dimensions, nothing analytical	answers an otherwise unanswerable question

• Default is still one hop ➔ a snowflake decomposes one dimension into a chain and needs a reason; “it reaches 3NF” is not one (flat $=$ 2NF, the warehouse never pays the update-anomaly cost) · each extra hop is an extra join.
• Many-1 dimensions: four shapes ➔ separate (both keys in the fact) · combined (one flat dimension) · hierarchy (chained, fact keeps the finest key) · linked (chained and both keys) · ⛔ many-1 is necessary, not sufficient — the two must be the same kind of thing ($\text{Course}\to \text{Campus}$ is a bad hierarchy) · ⛔ never key the fact at the coarse level · hierarchies do not improve roll-up/drill-down.
• When a bridge is forced ➔ no direct relationship · an m–m in the source · history to keep (SupplyDate, QtySupplied live in the bridge) · ⛔ adding the far key to the fact repeats every row once per partner.
• The measure belongs to the parent ➔ a per-store share of a trip’s cost is an estimate, never a stored fact.

⚙️ Procedure — build a bridge snowflake

① create table XxxBridge as select * from <associative table> ② parent dimension gains 1.0/count(D.StoreID) as WeightFactor ⛔ 1/count floors to $0$ ③ and LISTAGG(D.StoreID, '_') within group (order by D.StoreID) as StoreGroupList ④ both computed by grouping the parent against the associative table — never the bridge or the fact ⑤ per-member estimate $=\sum (\text{measure}\times \text{WeightFactor})$ across the bridge · ⛔ an inner join silently drops parents with no members.

5️⃣ Slowly Changing Dimensions (W5)

• Problem ➔ overwriting a changed attribute re-prices the past — report every fact at the value true when it happened ➔ Slowly Changing Dimensions (SCD).

Type	History lives	Rows per member	Recovers the past?
0	nowhere — initial value frozen	1	❌
1	nowhere — overwritten	1	❌
2	dimension, extra rows (StartDate, EndDate, CurrentFlag)	many	✅
3	dimension, extra column (PreviousPrice)	1	⚠️ one step back only
4	a separate history dimension keyed $(\text{ID},\text{StartDate},\text{EndDate})$	1 $+$ history rows	✅
6	both (2 $+$ 3)	many	✅ $+$ fast “current”

• Temporal attribute ➔ its value has a life-time · temporal dimension ➔ its record has a life-time · ⛔ SCD is for slowly changing data, not rapidly changing data.
• Reading rules ➔ Type 2 appends a sequence number to the ID (C1_1…C1_4) and the fact’s FK points at the version, so the join is plain equality; CurrentFlag finds “now” · current row carries EndDate = Dec9999 · Type 4 reaches the price by a range join on the sale month (to_date both sides), listagg when two periods overlap one month · Type 4 also versions a changed business rule (semester end date) (W11).
• Type 6 trap ➔ the BookID repeats per version ⟹ dimension–fact is $m$–$m$ ⛔ fix with ① a surrogate key ② StartDate/EndDate in the fact ③ a bridge table.

6️⃣ Determinant, Pivoted, Junk and One-Attribute Dimensions (W6)

• Determinant dimension ➔ must appear in every retrieval or the measure is meaningless; its key is the determinant attribute · drawn dashed · SQL cannot enforce it — pivot it into the fact, or force it in the user interface.
• The test ➔ ask of the fact’s aggregate function, not the dimension’s “Type” label: min/max per petrol type ⟹ determinant · count of medals per type ⟹ not (summing over type is still meaningful) · a non-type dimension can be determinant (YearDIM) · ⛔ omitting it over-counts ($5\times$ in Lab 6).
• Pivoted fact ➔ the determinant dimension’s members become measure columns (Total_Students_Listening, …) and the dimension disappears · build the determinant version first, then the full grid: Cartesian product of surviving dimensions $+$ (+) outer join $+$ nvl(…, 0), then trim all-zero surplus rows · one surviving dimension ⟹ CTAS zeroed columns from that dimension $+$ correlated update with nvl.
• Pivot without determinacy ➔ legal when membership is small and fixed (5 taxis), but queries need one dimension alias per pivoted member.
• Junk dimension ➔ several low-cardinality, unrelated dimensions → one table, the Cartesian product of their members, $|\text{Junk}|={\prod }_i|{\text{Dim}}_i|$ (Real-Estate $2\times 2\times 4\times 2=32$), keyed by one JunkID · ⛔ a combined key (year‖semester) or a hierarchy is not junk.
• One-attribute dimension ➔ nothing to look up, so no join is needed · move to the fact: column-based (values become measure columns) or row-based (stays as a dimension-less key, safe for universal codes like M/F, Q1–Q4) · keep: combine into a junk dimension, or into a related normal dimension · ⛔ never absorb a determinant dimension or one hanging off a bridge.
• Surrogate Key ➔ local PK per dimension via create sequence $+$ .nextval (or a before insert trigger filling :new.ID) · the TempFact must be re-keyed too · optional if the operational PK is already unique across sources.

7️⃣ Multi-Fact, Combining and Slicing (W7)

• Second fact ➔ exactly two causes: a different subject (different dimension set) or a different granularity · ⛔ different units of measure are not a cause — km, litres and dollars on the same dimensions are one fact · dimensions are shared, not duplicated.
• Subject test ➔ the measure × dimension applicability grid: Num_of_Reviews fails Store and Time (purchase date ≠ review date) ⟹ separate ReviewFACT · route each report to the fact that owns its measure.

Combining case	Pools	Same transaction row?	Base dimension	Pivot / type dim legal?
Flight Charter (pilot / co-pilot)	one	yes	determinant	✅ / ✅
Bachelor / Master projects	one	no	normal	✅ / ✅
Lecturer / Tutor	two	no	normal, common attributes only	❌ / ❌

• Easy verdicts ➔ different dimension sets ⟹ never combine · same dimensions, different measures ⟹ join on the full key · same dimensions and measures ⟹ union (they differ only in period).
• Slicing a Fact ➔ vertical splits the measure columns (≡ distributed partitioning) · horizontal splits the rows by an attribute’s range/value (≡ parallel partitioning) · a pivoted fact forces vertical, a type dimension forces horizontal, neither ⟹ cannot slice.

8️⃣ Levels of Aggregation and Multi-Input (W8)

• The ladder ➔ Level-0 $=$ highest granularity, no aggregation · higher level $=$ more aggregated · no rule on how many levels; several stars may share a level · from one diagram you can only decide Level-0 or not.
• Two ways to lower a level ➔ add a dimension (breaks each value across its members — “who”) · replace a dimension with a finer one (Semester → LoginDate) — a replacement may absorb two dimensions.
• Draw Level-1 and Level-0 from Level-2 ➔ list the dimensions that bucket something finer · Level-1 lowers one, Level-0 lowers all · Level-1 has no unique answer; Level-0 does.
• Level-0 test ➔ ① find the transaction (the m–m relationship) in the E/R diagram ② read which entity the measure counts/sums ③ Level-0 iff one fact row $=$ one row of that entity · ⛔ an Oracle date hides time — store full date and time · a count measure in the build SQL proves it is not Level-0.
• At Level-0 ➔ a count measure is all $1$s ⟹ drop it · a sum keeps real values ⟹ keep it.
• Fact Constellation ➔ splitting a hierarchy into one fact per level; $h$ hierarchies of lengths ${\ell }_i$ give ${\prod }_i{\ell }_i$ facts (3 locations × 2 times $=6$) · levels form a lattice, not a chain ⛔ facts from different hierarchies are incomparable.
• Multi-input ➔ one star per source, then stack · vertical (same dimensions and measures) ⟹ union · horizontal (each source owns different measures) ⟹ zero-padded TempFacts $+$ union $+$ outer sum · ⛔ agree each source’s measure definition first; union needs identical column lists.

9️⃣ OLAP (W9 · A3 quiz)

Report asks for	Clause ➔ OLAP
a total per category	sum(…) group by
drill down / roll up	add / remove a dimension attribute in select and group by
totals $+$ subtotals $+$ grand total	group by cube (…) / rollup (…) ➔ OLAP Cube and Rollup
top / bottom, best per group	rank() over (…), Top-N inline view ➔ OLAP Ranking and Top-N
running total / moving average	sum(sum(m)) over (…) windows ➔ OLAP Cumulative and Moving Aggregates
a share of the total	plain group by; the percentage is the BI tool’s job

Clause ($N$ = columns inside the parentheses)	Grouping sets	Example sets for $(P,L,T)$
cube (P, L, T)	$2^N=8$	every subset, incl. $()$
rollup (P, L, T)	$N+1=4$	$(P,L,T),(P,L),(P),()$ — drops right to left
P, cube (L, T)	$2^2=4$	$(P,L,T),(P,L),(P,T),(P)$ — no grand total
P, rollup (L, T)	$2+1=3$	$(P,L,T),(P,L),(P)$

⚙️ Procedure — predict a cube / rollup row count

① list the grouping sets ② rows per set $=$ value combinations of its columns that actually occur (sparse data: $(T,P)$ gave $7$, not $3\times 3$) ③ $()$ is $1$ row ④ sum · dense $2\times 2\times 2$: cube $27$, rollup $15$, partial cube $18$, partial rollup $14$ · CHARTER (sparse): cube $28$, rollup $18$.

• rollup (A, B) ≠ rollup (B, A) ➔ order sets the drill path · cube ⊇ rollup.
• Constant column ➔ inside the parentheses it doubles every set with an identical “All” twin ⟹ move it outside (CHARTER cube $28\to 14$, rollup $18\to 11$).
• Label subtotals ➔ decode(grouping(col), 1, 'All …', col) · grouping is $1$ when the column is rolled up · (null) in a result means “all”, not missing · ⛔ qualify ambiguous columns (S.LocationID, else ORA-00918).

Function	Ties	Sequence after a tie
rank()	share a rank	skips — $1,2,2,4$
dense_rank()	share a rank	no gap — $1,2,2,3$
row_number()	never tie (arbitrary order)	$1,2,3,4$
percent_rank()	—	$\frac{\text{rank}-1}{n-1}\in [0,1]$

• Top-N ➔ select * from (… rank() over (order by sum(m) desc) as r …) where r <= N ⛔ the alias does not exist in the inner where · with a tie, rank/dense_rank return extra rows, row_number (and W7’s rownum) drops one arbitrarily · top $p$: percent_rank >= 1 - p (ascending) · desc inside over decides who is $1$; the outer order by only sorts the display.
• Rank within groups ➔ partition by restarts numbering per partition; several over clauses coexist independently.
• Windows ➔ sum(sum(m)) over (order by t rows unbounded preceding) running total · avg(sum(m)) over (order by t rows k-1 preceding) $k$-period moving average · the window counts result rows, so the first rows average fewer values ⛔ a missing month breaks ”$k$ months”.
• Two running totals in one query ➔ each over gets its own partition by, ordered along the other column ⛔ partition by X order by X leaves the order undefined.
• Power BI ➔ Data → Model (dimension 1 → fact *) → Report · check each visual’s default aggregation · filter scope: visual / page / report · publish Desktop work to the Service · DAX queries need EVALUATE.

🔟 Data Analytics on a Warehouse (W10)

• Why not classic mining ➔ association rules need item baskets, no numeric measure, one dimension · decision trees need categorical attributes and a categorical target ⟹ a star’s numeric measures need regression, clustering, regression trees · rule confidence is directional (Bread→Cereal $75\%$, Cereal→Bread $100\%$).
• Columns each technique uses ➔ time-series regression: timestamp dimension $+$ one measure · non-time-series: two measures · clustering and regression trees: measures only.
• Regression by hand ➔ $b_1=\frac{\sum (x_i-\bar{x})(y_i-\bar{y})}{\sum (x_i-\bar{x}{)}^2}$, $b_0=\bar{y}-b_1\bar{x}$ · shortcut $\sum (x_i-\bar{x})(y_i-\bar{y})=\sum (x_i-\bar{x})y_i$ · e.g. $(\mathrm{1..7})$: $b_1=235/28=8.3929$, $b_0=6.2857$.
• In SQL ➔ three layers: means → slope → intercept · get $\bar{x},\bar{y}$ onto every row with a cross-joined one-row view or avg(x) over () · carry them up as max(x_bar).
• Rolling window vs regression ➔ the window tracks every turn but gives no equation; regression is one global equation (a line misses curvature).
• k-means ➔ assign each object to the nearest centroid, recompute, repeat until no member moves · 1-D boundaries are midpoints $\frac{m_a+m_b}{2}$ · 2-D: Voronoi regions · ⛔ normalise measures first (Glucose $64$–$218$ swamps Albumin $2$–$5$).
• DBSCAN ➔ chains dense neighbourhoods (MaxDist, MinPts) · core / border / outlier · no preset $k$, not every object clustered — vs k-means: preset $k$, every object assigned, no outliers.
• Regression tree (trees) ➔ try every attribute at every midpoint of adjacent distinct values, keep the lowest $SSR=\sum (r_i-\bar{r}{)}^2+\sum (s_j-\bar{s}{)}^2$ · recurse left then right; attributes may be reused · leaf $=$ mean target, not a class.

1️⃣1️⃣ Active Data Warehousing and PL/SQL (W11)

• Passive vs active ➔ passive never changes (PK–FK constraints unnecessary; often built top-down) · active reflects operational inserts immediately (PK–FK constraints matter; built bottom-up, each level maintained from the level immediately below).

Object	Make it a view when…	Make it a table $+$ trigger when…
Dimension	select distinct over the source keeps it current	it must be kept as a table — after insert trigger copies :new
Level-0 fact, no measure	always — a view over the join	—
Fact with a stored measure	—	it stores a value the source lacks (a count, a band) — find-or-insert trigger, decrement from :old on expiry
Upper-level fact	it only re-aggregates the level below — ⛔ re-aggregating a stored count is sum, not count(*)	it stores a value the level below lacks — find-or-insert $+$ decrement triggers on the lower fact

• Trace one insert ➔ the Level-1 trigger fires on the Level-0 fact, never on the operational table ⛔ break one link and every level above freezes.
• Evolution ➔ a change propagates along build dependencies, not level numbers — draw the dependency map, follow every arrow out of the changed object · operational change ⟹ update the existing stars, or build new ones and merge.
• Triggers ➔ timing before/after/instead of (views) × level statement / for each row × event insert/update [of col]/delete · only row-level sees :old/:new · insert: :new only · update: both · delete: :old only · veto with raise_application_error.
• SQL ➔ declare … begin … exception … end; · := assigns · col%type anchors a variable’s type · if … elsif … else … end if · loops with your own exit · cursor for rec in c loop · select … into must return exactly one row (else NO_DATA_FOUND) · procedure (a statement) vs function (returns a value, used in an expression) vs trigger (fires automatically) · parameters IN / OUT / IN OUT.

1️⃣2️⃣ Modern Platforms (W12 emerging topics — not a book chapter)

• Invariant ➔ same star schema, different engine — facts, dimensions, SCD, slicing and aggregation (Ch 2–18) carry over; storage, compute and tooling change ➔ Data Lakehouse.
• Cloud DW ➔ provider-managed, capacity on demand, usage pricing · storage $\perp$ compute (retain years of data, scale compute for peaks) · IaaS ➔ managed ➔ serverless · ⛔ cloud does not guarantee lower cost or better performance; Oracle ADW automates operations, never modelling, SQL or governance.
• Platforms ➔ Snowflake: decoupled multi-cluster shared data, multi-cloud, per-second billing · Redshift: MPP on PostgreSQL, node types, distribution styles, Spectrum over S3 · BigQuery: serverless, pay per data scanned, streaming inserts.
• Warehouse vs lake ➔ schema-on-write (curated, structured, governed BI metrics) vs schema-on-read (raw, any format, object storage, ML) ⛔ a lake still needs metadata, security, quality and lifecycle controls.
• Lakehouse mapping ➔ Temp DB ≈ Raw/Bronze · ETL in progress ≈ Cleaned/Silver · warehouse ≈ Facts & Dims/Gold · layers: Parquet (file) · Iceberg/Delta (table, ACID) · catalog · Spark (engine).
• ETL vs ELT ➔ ETL transforms before load (Model 3: Temp DB ➔ PL/SQL ➔ star) · ELT loads raw, transforms inside the target (lakehouse) · complementary · extraction: batch pull (JDBC $+$ incremental filter) · file landing (Auto Loader) · CDC (Debezium ➔ Kafka) · conflict rule: latest timestamp wins, then source priority.
• Batch vs stream ➔ scheduled intervals, simple, cheap vs continuous, low latency ⛔ stream must handle ordering, late arrivals, duplicates, recovery · conformed dimensions change slowly, a streamed fact is upserted every minute (WHEN MATCHED adds) ➔ Distributed Processing and Map-Reduce.
• Spark ➔ in-memory successor to MapReduce (Hadoop = HDFS $+$ MapReduce $+$ YARN) · costs: shuffle, skew, fault recovery, infrastructure ➔ Hadoop and Spark.
• Power BI over a lakehouse ➔ CSV export = frozen copy · Import = scheduled refresh · DirectQuery = live, costs compute ➔ Power BI.
• Governance at scale ➔ least privilege, encryption at rest/in transit, auditing, masking · quality checks · ownership, lineage, retention · provider supplies features, organisation stays responsible ➔ Data Management and Data Governance.
• AI-ready ➔ sources ➔ ingestion ➔ processing ➔ storage ➔ AI preparation ➔ consumption · NL-to-SQL (validate it) · vector search/RAG · predictive ML · data products/mesh · ⛔ AI is only as reliable as its data.