Data Mining for Business Intelligence

The lesson on business intelligence versus data mining already established the core distinction — BI reports on measures someone already decided to track, while data mining discovers patterns nobody specified in advance — and walked through BI's four-layer architecture (data sources, ETL, data warehouse, presentation layer), noting that predictive analytics is precisely where the two technologies overlap. This lesson picks up exactly there: the concrete mechanism by which a data mining technique's output actually becomes part of a BI system, rather than staying a one-off analysis sitting outside it.

The Integration Mechanism: Mining Output Becomes a New Dimension

The pattern is the same across nearly every technique: a data mining algorithm's output — a cluster label, a predicted risk score, a discovered association — gets written back into the data warehouse as a new column on an existing table, after which it behaves exactly like any measure a BI tool already knows how to report on. This is the step that actually connects the two systems, and it's worth tracing through concretely. Take six customers, each with an average order value and number of orders per year:

Customer  Avg Order Value  Orders/Year
C1        $20              12
C2        $22              10
C3        $150             3
C4        $160             2
C5        $45              6
C6        $50              5

Running a clustering algorithm — the mechanics covered in the clustering lessons elsewhere in this series — on this data groups customers by purchasing behavior rather than by any single measure: {C1, C2} form one cluster (frequent, small purchases), {C3, C4} form another (rare, large purchases), and {C5, C6} form a third (moderate on both dimensions). The mining step ends here — but the BI integration step is what happens next: each customer's cluster assignment gets written into the data warehouse as a new customer_segment column on the customer dimension table. Once that column exists, it can be used in a standard OLAP query exactly like region or signup_date always could:

Segment                       Avg Order Value  Orders/Year  Annual Revenue/Customer
Frequent Small Shoppers        $21              11           $21 x 11  = $231.00
Occasional Big Spenders        $155             2.5          $155 x 2.5 = $387.50
Moderate Shoppers               $47.50           5.5          $47.50 x 5.5 = $261.25

This single table is a genuinely useful business finding that a standard BI dashboard could never have produced on its own: despite buying least often, the "Occasional Big Spenders" segment generates the highest annual revenue per customer — a pattern invisible until the mining-derived segment existed as a queryable column, but immediately visible to any dashboard once it does. This is the concrete answer to "how does data mining feed business intelligence": not by replacing the dashboard, but by giving it a new column to slice by.

The Same Pattern Across Other Techniques

Classification integrates the same way: a churn-prediction model's output (covered in the lesson on classification by backpropagation) becomes a churn_risk_score column on the customer table, letting a standard report filter for "customers flagged high-risk this quarter" — a report a BI tool can run and refresh on its normal schedule once the column exists, without re-running the mining algorithm interactively each time. Association rule mining integrates slightly differently, typically populating a separate lookup table of "customers who bought X also bought Y" pairs (covered with a full worked example in the lesson on association rule mining), which a BI or e-commerce presentation layer queries directly to power a recommendation widget.

Why This Order of Operations Matters

Notice that in every case above, the data mining step happens first, against the clean, integrated historical data the BI warehouse's ETL process already produced — mining doesn't build its own separate data pipeline, it consumes the one BI already maintains, exactly as the architecture lesson noted. The output then flows back into that same warehouse as new columns, which is what allows a single BI presentation layer to show both "known" measures (revenue by region) and "discovered" measures (revenue by mining-derived segment) side by side in the same dashboard, without the person viewing it needing to know or care which category a given column originally came from.

What This Lesson Leaves to Others

The general advantages, disadvantages, cost, and privacy obligations that come with running data mining at all are covered in full in the lesson on the challenges of data mining, and the question of how to measure whether a mining-derived segment or score actually produced measurable value is covered in the lesson on the strategic value of data mining — both deliberately not repeated here as a shorter third pass through the same ground.