Data Mining Task Primitives

Telling a data mining system "find patterns in my data" is not a specification a system can act on — it does not say which data, what kind of pattern, or how to know whether a discovered pattern is worth reporting at all. Data mining task primitives are the building blocks that turn a vague mining goal into a precise, executable request. A data mining query — whether typed into a query language or assembled through menus in a graphical tool — is built entirely out of these primitives.

The Five Primitives

Every data mining task specification answers five separate questions:

1. What data should be mined? (task-relevant data)
2. What kind of pattern is being looked for? (kind of knowledge)
3. What domain knowledge should guide the search? (background knowledge)
4. How should a discovered pattern be judged as worth reporting? (interestingness measures)
5. How should the results be shown? (representation of discovered patterns)

Each is independent of the others — the same task-relevant data can be mined for association rules or for clusters, and the same discovered rules can be displayed as a table or as a decision tree. Specifying all five together is what fully defines a mining task.

1. Task-Relevant Data

This primitive narrows the mining task down to a specific slice of the available data — particular attributes (columns), particular dimensions from a data warehouse, or records matching specific conditions. In a relational database, this slice is assembled with familiar query operations: selection (choosing rows), projection (choosing columns), join (combining tables), and aggregation.

The result of these operations is a new dataset, the initial data relation. It does not have to be physically stored — when it exists only as a query result computed on demand, it is a view, and in data mining specifically this is called a minable view, because its entire purpose is to serve as the input to the mining step that follows.

2. Kind of Knowledge to Be Mined

This primitive specifies what type of pattern the mining task is searching for. Several distinct data mining tasks exist precisely because "pattern" can mean structurally different things:

• Data characterization — summarizing the general properties of a target class of data.
• Discrimination — comparing a target class against one or more contrasting classes.
• Association rule mining — finding items that co-occur frequently, such as products bought together.
• Correlation analysis — measuring whether and how strongly two attributes are related.
• Classification and prediction — assigning category labels or estimating numeric values (covered in depth in their own lesson).
• Clustering — grouping similar records with no predefined labels.
• Outlier detection — finding records that deviate sharply from the rest of the data.
• Evolution analysis — describing how patterns in the data change over time.

Choosing the wrong one of these for a given business question wastes the whole mining run: association rule mining will never surface a customer segmentation, and clustering will never produce a classification rule a bank can apply to a new loan applicant. This primitive is where the mining goal gets pinned down to one of these concretely different techniques.

3. Background Knowledge

Background knowledge is domain knowledge fed into the mining process to guide it and to make the resulting patterns more useful. The most common form is a concept hierarchy — an ordering of an attribute's values from specific to general, such as:

City → State → Country

A concept hierarchy makes it possible to mine at different levels of abstraction using two opposite operations:

• Rolling up (generalization) — moving from detailed values to broader ones. Chennai → Tamil Nadu → India converts a specific city into its state and then its country, which reduces the number of distinct values and can reveal a pattern too sparse to see at the city level (a rule about "India" might hold even when no single city has enough transactions to support it on its own).
• Drilling down (specialization) — moving in the opposite direction, from a general value toward more specific ones, when a pattern found at the country level needs to be checked for whether it holds uniformly across the states and cities inside it, or is actually driven by just one of them.

Because concept hierarchies encode domain-specific structure, different users may reasonably build different hierarchies for the same attribute depending on what their analysis needs — there is no single correct hierarchy for "location" independent of the question being asked.

4. Interestingness Measures and Thresholds

A mining algorithm run over a large dataset can surface an enormous number of technically valid patterns, most of which are useless. This primitive specifies how to separate the useful ones from the noise, using measures the user can set thresholds against.

Support and Confidence: A Worked Example

The two most common measures come from association rule mining. Take a rule of the form A → B (customers who buy A also tend to buy B) and a small basket of 10 transactions:

transactions = [
    {"bread","milk","eggs"}, {"bread","milk"}, {"bread","butter"},
    {"milk","eggs"}, {"bread","milk","butter"}, {"bread"},
    {"milk","butter"}, {"bread","milk","eggs","butter"}, {"eggs"}, {"bread","milk"},
]
n = len(transactions)
count_bread = sum(1 for t in transactions if "bread" in t)
count_both = sum(1 for t in transactions if "bread" in t and "milk" in t)

support = count_both / n
confidence = count_both / count_bread
print(f"support(bread→milk) = {support}")
print(f"confidence(bread→milk) = {confidence:.3f}")

Output:

support(bread→milk) = 0.5
confidence(bread→milk) = 0.714

Support measures how often the pattern occurs across the entire dataset: bread and milk appear together in 5 of the 10 transactions, so support is 0.5. A rule with very low support, however striking, applies too rarely to be worth acting on — it might describe two customers out of ten thousand.

Confidence measures reliability conditional on the first item already being present: of the 7 transactions containing bread, 5 also contain milk, giving a confidence of 0.714 (about 71%). This is a different question from support — a rule can have high confidence while covering very few transactions overall, which is exactly why both numbers, not just one, are checked against a threshold before a rule is reported.

Two further measures round out how a pattern gets judged:

• Simplicity — a rule with fewer attributes and fewer conditions is easier for a person to interpret and act on; a support-40%-confidence-90% rule with fifteen conditions is far less useful in practice than a simpler one with similar numbers.
• Novelty — a pattern earns attention by providing information not already known or trivially implied by other reported patterns; a system that reports both "A → B" and "A, C → B" as separate findings when C adds nothing is reporting redundancy, not two discoveries.

5. Representation of Discovered Patterns

The final primitive specifies the form the results take when shown to the user: rules, tables, cross-tabulations, charts, graphs, decision trees, or data cubes. This choice is not cosmetic — it should match the kind of knowledge mined in primitive 2. Descriptive summaries read naturally as charts and tables; classification results read naturally as decision trees or as explicit if-then rules, because a decision tree's branching structure directly mirrors how a classification decision was reached.

Putting All Five Together: A Complete Example

Suppose a marketing manager at a company wants to identify customers worth targeting with a promotion. The manager sets each primitive explicitly:

• Task-relevant data: customers with income of at least $40,000, drawn from transactions where total purchase value exceeds $1,000 and each item costs at least $100.
• Kind of knowledge: classification — the manager wants a rule that assigns each customer to a "promising" or "not promising" category.
• Background knowledge: a location hierarchy (branch → region → country) and an age hierarchy, so the resulting rule can be expressed at whichever level of granularity turns out to matter.
• Interestingness measure: an implicit threshold — the $40,000 income and $100 item-price conditions themselves function as filters on which data even enters the analysis.
• Representation: classification rules, so the result is directly readable as an if-then statement a marketing team can act on.

Expressed as a Data Mining Query Language (DMQL) query, all five primitives appear as distinct clauses in a single statement:

use database AllElectronics_db
use hierarchy location_hierarchy for T.branch, age_hierarchy for C.age
mine classification as promising_customers
in relevance to C.age, C.income, I.type, I.place_made, T.branch
from customer C, item I, transaction T
where I.item_ID = T.item_ID
  and C.cust_ID = T.cust_ID
  and C.income >= 40000
  and I.price >= 100
group by T.cust_ID

Reading this query against the five primitives above makes its structure legible line by line: use database and the from/where clauses define the task-relevant data; mine classification names the kind of knowledge; use hierarchy supplies the background knowledge; the income and price conditions act as the interestingness filter; and naming the result promising_customers under mine classification fixes the representation as classification rules. A query language exists precisely so that a request this specific can be issued once, unambiguously, instead of being described informally and reinterpreted differently by whoever runs it.