Data Mining Query Language (DMQL)

DMQL (Data Mining Query Language) was proposed by researchers (Han et al.) in the mid-1990s as an SQL-style language for specifying data mining requests, and it's easy to come away thinking it's essentially SQL with a different name — the syntax deliberately looks familiar to anyone who already knows SELECT/FROM/WHERE. But that similarity is only surface-level, and it's worth being precise about the actual difference: SELECT, FROM, WHERE, GROUP BY, and JOIN are standard SQL clauses for retrieving and aggregating existing data — they belong to ordinary database querying, not to DMQL specifically. What actually makes DMQL a mining language, distinct from a database query language, are a small number of clauses that don't exist in SQL at all, because they express something SQL was never designed to express: not "give me these rows," but "discover this kind of pattern."

What Those Distinguishing Clauses Actually Specify

DMQL's mining-specific clauses map directly onto the five data mining task primitives covered in the lesson on data mining task primitives — task-relevant data, the kind of knowledge to be mined, background knowledge, interestingness measures, and how results should be presented. A commonly illustrated DMQL structure looks roughly like this:

use database <database_name>
mine <kind_of_knowledge> [as <pattern_name>]
in relevance to <attribute_list>
from <relation>
[where <condition>]
[order by <order_list>]
with <interestingness_measure> threshold = <value>

Each clause corresponds to one of the five primitives: mine <kind_of_knowledge> (for example, mine associations, mine classification, or mine characteristics) specifies what kind of pattern to discover — there is no equivalent request in plain SQL, which has no concept of "discover a pattern" at all. in relevance to specifies the task-relevant attributes the mining operation should actually consider. from and where narrow the source data, functioning much like their SQL counterparts. And with <measure> threshold = <value> specifies the interestingness threshold a discovered pattern must clear to be returned at all — this is the clause that gives the mining operation its actual filtering criteria, and it is the clause most clearly absent from ordinary SQL.

A Worked Illustrative Query

Putting this together for an association-rule mining request — the same kind of task covered with a full worked support/confidence/lift example in the lesson on association rule mining — an illustrative DMQL-style query might look like:

use database Retail_db
mine associations as productAssociations
in relevance to item_name, quantity, price
from sales
where year(transaction_date) = 2025
with support threshold = 0.02
with confidence threshold = 0.60

Reading this against the primitives it encodes: mine associations requests association rules specifically, rather than a classifier or a clustering; in relevance to item_name, quantity, price restricts which attributes matter to the mining operation; from sales where year(transaction_date) = 2025 scopes the source data to a specific year, exactly like an ordinary SQL filter would; and the two with ... threshold clauses request only rules meeting a 0.02 support and 0.60 confidence — the same two measures defined precisely, with a full worked numeric example, in the lesson on association rule mining. A rule discovered by this query would need to appear in at least 2% of transactions and hold true at least 60% of the time whenever its antecedent is present, using exactly the formulas covered there.

An Important Practical Caveat

Unlike SQL, DMQL was proposed primarily as an academic and conceptual framework for expressing mining requests precisely, rather than as a single, universally implemented product with one standard engine a learner can install and run directly. In current practice, the closest real-world equivalent most people actually encounter is DMX (Data Mining Extensions), a genuine SQL-like query language built into Microsoft SQL Server Analysis Services specifically for querying and creating mining models — its existence confirms the same underlying idea (an SQL-style language purpose-built for mining operations, not just data retrieval) has carried through into real, deployed database software, even though its exact syntax differs from the illustrative DMQL structure above. Most other real-world data mining today, including everything covered elsewhere in this series, is instead done through general-purpose languages like Python and R rather than a dedicated mining query language at all.

Why the Distinction Is Worth Keeping Straight

Confusing DMQL's mine/with threshold clauses with SQL's SELECT/WHERE clauses misses the entire reason a separate mining language was proposed in the first place: SQL can retrieve every transaction over a given amount, exactly as covered in the query-versus-mining comparison in the lesson on the meaning of data mining, but it has no built-in way to ask a database to discover which item combinations occur together more often than chance alone would predict. That gap — a query language with no way to express "find me a pattern I haven't specified" — is precisely what DMQL's mining-specific clauses were designed to fill.