Chapter 4: Data Mining Primitives, Languages, and System Architectures

April 22, 2023Data Mining: Concepts and

Techniques 1

Chapter 4: Data Mining Primitives, Languages, and System Architectures

Data mining primitives: What defines a data

mining task?

A data mining query language

Design graphical user interfaces based on a

data mining query language

Architecture of data mining systems

Summary


Techniques 2

Unit II

Data Mining Primitive, Languages, and System Architecture : Data mining primitive, Data Mining Query Languages, Designing Graphical User Interfaces

Based on a Data Mining Query Language Architecture of Data Mining Systems


Techniques 3

Misconception: Data mining systems can autonomously dig out all of the valuable knowledge from a given large database, without human intervention.

If there was no user intervention then the system would uncover a large set of patterns that may even surpass the size of the database. Hence, user interference is required.

This user communication with the system is provided by using a set of data mining primitives.


Techniques 4

Why Data Mining Primitives and Languages?

A popular misconception about data mining is to expect that data mining systems can autonomously dig out all of the valuable knowledge and patterns that is embedded in large database, without human intervention or guidance.

Finding all the patterns autonomously in a database? — unrealistic because the patterns could be too many but uninteresting

Data mining should be an interactive process User directs what to be mined

Users must be provided with a set of primitives to be used to communicate with the data mining system

Incorporating these primitives in a data mining query language

More flexible user interaction Foundation for design of graphical user interface Standardization of data mining industry and practice


Techniques 5

Data Mining Primitives :What Defines a Data Mining Task ?

Task-relevant data : What is the data set I want to mine?

Type of knowledge to be mined : What kind of

knowledge do I want to mine ?

Background knowledge : What background knowledge could be useful here ?

Pattern interestingness measurements : What

measures can be useful to estimate pattern interestingness ?

Visualization of discovered patterns : How do I want the discovered patterns to be presented ?


Techniques 6

Primitives for specifying a data mining task


Techniques 7

Task-Relevant Data (Minable View)

The first primitive is the specification of the data on which mining is to be performed.

Typically, a user is interested in only a subset of the database. It is impractical to mine the entire database, particularly since the number of patterns generated could be exponential w.r.t the database size.

Furthermore, many of the patterns found would be irrelevant to the interests of the user.

In a relational database, the set of task relevant data can be collected via a relational query involving operations like selection, projection, join and aggregation.

This retrieval of data can be thought of as a “subtask” of the data mining task. The data collection process results in a new data relational called the initial data relation


Techniques 8

The initial data relation can be ordered or grouped according to the conditions specified in the query.

The data may be cleaned or transformed (e.g. aggregated on certain attributes) prior to applying data mining analysis.

This initial relation may or may not correspond to physical relation in the database.

Since virtual relations are called Views in the field of databases, the set of task-relevant data for data mining is called a minable view

If data mining task is to study associations between items frequently purchased at AllElectronics by customers in Canada, the task relevant data can be specified by providing the following information


Techniques 9

Task-Relevant Data (Minable View)

Database or data warehouse name

Database tables or data warehouse cubes

Condition for data selection

Relevant attributes or dimensions

Data grouping criteria


Techniques 10

Task relevant data

Data portion to be investigated.

Attributes of interest (relevant attributes) can be specified.

Initial data relation

Minable view


Techniques 11

Example

If a data mining task is to study associations between items frequently purchased at All Electronics by customers in Canada, the task relevant data can be specified by providing the following information: Name of the database or data warehouse to be used (e.g., AllElectronics_db) Names of the tables or data cubes containing relevant data (e.g., item, customer, purchases and items_sold) Conditions for selecting the relevant data (e.g., retrieve data pertaining to purchases made in Canada for the current year) The relevant attributes or dimensions (e.g., name and price from the item table and income and age from the customer table)


Techniques 12

The kind of knowledge to be mined

It is important to specify the kind of knowledge to be mined, as this determines the data mining functions to be performed.

The kinds of knowledge include concept description (characterization and discrimination), association, classification, predication, clustering, and evolution analysis.

In addition to specifying the kind of knowledge to be mined for a given data mining task, the user can be more specific and provide pattern templates that all discovered patterns must match


Techniques 13

The kind of knowledge to be minedThese templates, or metapatterns (also called metarules or metaqueries), can be used to guide the discovery process. The use of metapatterns is illustrated in the following example.

A user studying the buying habits of Allelectronics customers may choose to mine association rules of the form:

P (X:customer,W) ^ Q (X,Y) => buys (X,Z)

Here X is a key of the customer relations, P & Q are predicate variables and W,Y and Z are object variables

[1.4%, 70%]


Techniques 14

The kind of knowledge to be mined

The search for association rules is confined to those matching the given metarule, such as

age (X, “30…..39”) ^ income (X, “40k….49K”) => buys (X, “VCR”) [2.2%, 60%] and

occupation (X, “student ”) ^ age (X, “20…..29”)=> buys (X, “computer”) [1.4%, 70%]

The former rule states that customers in their thirties, with an annual income of between 40K and 49K, are likely (with 60% confidence) to purchase a VCR, and such cases represent about 2.2.% of the total number of transactions.

The latter rule states that customers who are students and in their twenties are likely (with 70% confidence) to purchase a computer, and such cases represent about 1.4% of the total number of transactions.


Techniques 15

Types of knowledge to be mined

Characterization

Discrimination

Association

Classification/prediction

Clustering

Outlier analysis

Other data mining tasks


Techniques 16

The data mining functionalities and the variety of knowledge they discover are briefly presented in the following list:Characterization: Data characterization is a summarization of general features of objects in a target class, and produces what is called characteristic rules. The data relevant to a user-specified class are normally retrieved by a database query and run through a summarization module to extract the essence of the data at different levels of abstractions. For example, one may want to characterize the OurVideoStore customers who regularly rent more than 30 movies a year. With concept hierarchies on the attributes describing the target class, the attribute-oriented induction method can be used, for example, to carry out data summarization. Note that with a data cube containing summarization of data, simple OLAP operations fit the purpose of data characterization.


Techniques 17

Discrimination: Data discrimination produces what are called discriminant rules and is basically the comparison of the general features of objects between two classes referred to as the target class and the contrasting class. For example, one may want to compare the general characteristics of the customers who rented more than 30 movies in the last year with those whose rental account is lower than 5. The techniques used for data discrimination are very similar to the techniques used for data characterization with the exception that data discrimination results include comparative measures.


Techniques 18

Association analysis: Association analysis is the discovery of what are commonly called association rules. It studies the frequency of items occurring together in transactional databases, and based on a threshold called support, identifies the frequent item sets. Another threshold, confidence, which is the conditional probability than an item appears in a transaction when another item appears, is used to pinpoint association rules. Association analysis is commonly used for market basket analysis. For example, it could be useful for the OurVideoStore manager to know what movies are often rented together or if there is a relationship between renting a certain type of movies and buying popcorn or pop. The discovered association rules are of the form: P -> Q [s,c], where P and Q are conjunctions of attribute value-pairs, and s (for support) is the probability that P and Q appear together in a transaction and c (for confidence) is the conditional probability that Q appears in a transaction when P is present.


Techniques 19

For example, the hypothetic association rule: RentType(X, "game") AND Age(X, "13-19") -> Buys(X, "pop") [s=2% ,c=55%]would indicate that 2% of the transactions considered are of customers aged between 13 and 19 who are renting a game and buying a pop, and that there is a certainty of 55% that teenage customers who rent a game also buy pop.


Techniques 20

Classification: Classification analysis is the organization of data in given classes. Also known as supervised classification, the classification uses given class labels to order the objects in the data collection. Classification approaches normally use a training set where all objects are already associated with known class labels. The classification algorithm learns from the training set and builds a model. The model is used to classify new objects. For example, after starting a credit policy, the OurVideoStore managers could analyze the customers’ behaviours vis-à-vis their credit, and label accordingly the customers who received credits with three possible labels "safe", "risky" and "very risky". The classification analysis would generate a model that could be used to either accept or reject credit requests in the future.


Techniques 21

Prediction: Prediction has attracted considerable attention given the potential implications of successful forecasting in a business context. There are two major types of predictions: one can either try to predict some unavailable data values or pending trends, or predict a class label for some data. The latter is tied to classification. Once a classification model is built based on a training set, the class label of an object can be foreseen based on the attribute values of the object and the attribute values of the classes. Prediction is however more often referred to the forecast of missing numerical values, or increase/ decrease trends in time related data. The major idea is to use a large number of past values to consider probable future values.


Techniques 22

Clustering: Similar to classification, clustering is the organization of data in classes. However, unlike classification, in clustering, class labels are unknown and it is up to the clustering algorithm to discover acceptable classes. Clustering is also called unsupervised classification, because the classification is not dictated by given class labels. There are many clustering approaches all based on the principle of maximizing the similarity between objects in a same class (intra-class similarity) and minimizing the similarity between objects of different classes (inter-class similarity).


Techniques 23

Outlier analysis: Outliers are data elements that cannot be grouped in a given class or cluster. Also known as exceptions or surprises, they are often very important to identify. While outliers can be considered noise and discarded in some applications, they can reveal important knowledge in other domains, and thus can be very significant and their analysis valuable.


Techniques 24

Evolution and deviation analysis: Evolution and deviation analysis pertain to the study of time related data that changes in time. Evolution analysis models evolutionary trends in data, which consent to characterizing, comparing, classifying or clustering of time related data. Deviation analysis, on the other hand, considers differences between measured values and expected values, and attempts to find the cause of the deviations from the anticipated values.


Techniques 25

Background Knowledge: Concept Hierarchies It is the information about the domain to be mined

Concept hierarchy: is a powerful form of background knowledge. It allows the discovery of knowledge at multiple level of abstraction.

Concept hierarchy defines a sequence of mappings from a set of low – level concepts to higher – level, more general concepts. A concept hierarchy for the dimension location is shown in figure, mapping low-level concepts (i.e. cities) to more general concepts (i.e. countries)

Concept hierarchy consists of four levels. In our example, level 1 represents the concept country, while levels 2 and 3 represents the concepts province_or_state and city resp


Techniques 26

all

CanadaUSA

British Columbia

Ontario

VictoriaVancouver Toronto Ottawa

New York Illinois

New York Buffalo Chicago

Level 0

Level 3

Level 2

Level 1

Example


Techniques 27

Four major types of concept hierarchies:Schema hierarchiesSet-grouping hierarchiesOperation-derived hierarchiesRule-based hierarchies


Techniques 28

Background Knowledge: Concept Hierarchies

Schema hierarchy E.g., street < city < province_or_state < country

Set-grouping hierarchy E.g., {20-39} = young, {40-59} = middle_aged

Operation-derived hierarchy email address: [email protected]

login-name < department < university < country

Rule-based hierarchy low_profit_margin (X) <= price(X, P1) and cost

(X, P2) and (P1 - P2) < $50


Techniques 29

Concept hierarchies (2) Rolling Up - Generalization of data

Allows to view data at more meaningful and explicit abstractions.

Makes it easier to understandCompresses the dataWould require fewer input/output operations

Drilling Down - Specialization of dataConcept values replaced by lower level concepts

There may be more than concept hierarchy for a given attribute or dimension based on different user viewpoints

Example:Regional sales manager may prefer the previous concept hierarchy but marketing manager might prefer to see location with respect to linguistic lines in order to facilitate the distribution of commercial ads.


Techniques 30

Schema hierarchies Schema hierarchy is the total or partial order

among attributes in the database schema. Schema hierarchy may formally express existing

semantic relationships between attributes. Typically a schema hierarchy specifies a data

warehouse dimension Example: location hierarchy

street < city < province/state < country This means that street is at conceptually lower

level than city, which is lower than province_or_state, which is conceptually lower than country.

A schema hierarchy provides metadata information.

DWM 3.1 30


Techniques 31

Set-grouping hierarchies

Organizes values for a given attribute into groups or sets or range of values.

Total or partial order can be defined among groups.

Used to refine or enrich schema-defined hierarchies.

Typically used for small sets of object relationships.

Example: Set-grouping hierarchy for age{young, middle_aged, senior} all (age){20….29} young{40….59} middle_aged{60….89} senior


Techniques 32

Operation-derived hierarchies

Operation-derived: An operation derived hierarchy is based on operations specified by users, experts, or the data mining system. Operations may includedecoding of information-encoded strings, information extraction from complex data objects, and data clusteringExample: URL or email [email protected] gives login name < dept. < univ. < country


Techniques 33

Rule-based hierarchies Rule-based:

Occurs when either whole or portion of a concept hierarchy is defined as a set of rules and is evaluated dynamically based on current database data and rule definition

Example: Following rules are used to categorize items as low_profit, medium_profit and high_profit_margin.low_profit_margin(X) <= price(X,P1)^cost(X,P2)^((P1-P2)<50)medium_profit_margin(X) <= price(X,P1)^cost(X,P2)^((P1-P2)≥50)^((P1-P2)≤250)high_profit_margin(X) <= price(X,P1)^cost(X,P2)^((P1-P2)>250)

DWM 3.1 33


Techniques 34

Interestingness measure (1) Although specification of the task relevant data and of

the kind of knowledge to be mined (e.g. characterization, association, etc.) may substantially reduce the number of pattern generated, a data mining process may still generate a large number of patterns

Typically, only a small fraction of these patterns will actually be of interest to the given user. Thus, users need to further confine the number of uninteresting patterns returned by the process. This can be achieved by specifying interestingness measures that estimate the simplicity, certainty, utility, and novelty of patterns

We will see some objective measures of pattern interestingness. In general, each measure is associated with a threshold that can be controlled by the user.

Rules that do not meet the threshold are considered uninteresting, and hence are not presented to the user as knowledge


Techniques 35

Interestingness measure (1)Simplicity : A factor contributing to the interestingness of a pattern is the pattern’s overall simplicity for human comprehension.

Objective measures of pattern simplicity can be viewed as functions of the pattern structure, defined in terms of the pattern size in bits, or the number of attributes or operators appearing in the pattern.

For example, the more complex the structure of a rule is, the more difficult it is to interpret, and hence, the less interesting it is likely to be

Rule Length : It is a simplicity measure


Techniques 36

Interestingness measure (1)Certainty (Confidence) : Each discovered pattern should have a measure of certainty associated with it that assesses the validity or “trustworthiness” of the pattern.

A certainty measure for association rules of the form “A =>B” where A and B are sets of items, is confidence. Confidence is a certainty measure. Given a set of task-relevant data tuples the confidence of “A => B” is defined as

confidence (A=>B) = # tuples containing both A and B # tuples containing A

A confidence of 85% for the rule buys(X, “computer”) => buys (X,“software”) means that 85% of all customers who purchased a computer also bought software


Techniques 37

Interestingness measure (1)Utility (Support) : The potential usefulness of a pattern is a factor defining its interestingness. It can be estimated by a utility function, such as support. The support of an association pattern refers to the percentage of task relevant data tuples (or transactions) for which the pattern is true.

Utility (support) : usefulness of a patternsupport (A=>B) = # tuples containing both A and B

total # of tuples A support of 30% for the above rule means that 30% of all customers in the computer department purchased both a computer and software.

Association rules that satisfy both the minimum confidence and support threshold are referred to as strong association rules.


Techniques 38

Interestingness measure (1)Novelty : Novel patterns are those that contribute new information or increased performance to the given pattern set. For ex. A data exception. Another strategy for detecting novelty is to remove redundant patterns.


Techniques 39

Presentation and visualization

For data mining to be effective, data mining systems should be able to display the discovered patterns in multiple forms, such as rules, tables, cross tabs (cross-tabulations), pie or bar charts, decision trees, cubes, or other visual representations.

User must be able to specify the forms of presentation to be used for displaying the discovered patterns.


Techniques 40

DMQL

Adopts SQL-like syntax

Hence, can be easily integrated with relational query languages

Defined in BNF grammar [ ] represents 0 or one occurrence { } represents 0 or more occurrences Words in sans serif represent keywords


Techniques 41

Motivation A DMQL can provide the ability to support ad-hoc

and interactive data mining By providing a standardized language like SQL

Hope to achieve a similar effect like that SQL has on relational database

Foundation for system development and evolution

Facilitate information exchange, technology transfer, commercialization and wide acceptance

Design DMQL is designed with the primitives described

earlier


Techniques 42

Syntax for DMQL

Syntax for specification of task-relevant data the kind of knowledge to be mined concept hierarchy specification interestingness measure pattern presentation and

visualization Putting it all together — a DMQL query


Techniques 43

DMQL-Syntax for task-relevant data specification

Names of the relevant database or data warehouse, conditions and relevant attributes or dimensions must be specified

use database ‹database_name› or use data warehouse ‹data_warehouse_name›

from ‹relation(s)/cube(s)› [where condition] in relevance to ‹attribute_or_dimension_list› order by ‹order_list› group by ‹grouping_list› having ‹condition›


Techniques 44

Example


Techniques 45

Syntax for Kind of Knowledge to be Mined Characterization :

‹Mine_Knowledge_Specification› ::= mine characteristics [as ‹pattern_name›] analyze ‹measure(s)›

Example: mine characteristics as customerPurchasing analyze count%

Discrimination: ‹Mine_Knowledge_Specification› ::=

mine comparison [as ‹ pattern_name›] for ‹target_class› where ‹target_condition› {versus ‹contrast_class_i where ‹contrast_condition_i›} analyze ‹measure(s)›

Example: Mine comparison as purchaseGroups

for bigspenders where avg(I.price) >= $100versus budgetspenders where avg(I.price) < $100analyze count


Techniques 46

Syntax for Kind of Knowledge to be Mined (2)

Association:‹Mine_Knowledge_Specification› ::= mine associations [as ‹pattern_name›]

[matching ‹metapattern›] Example: mine associations as buyingHabits

matching P(X: customer, W) ^ Q(X,Y) => buys (X,Z)

Classification:‹Mine_Knowledge_Specification› ::= mine classification [as ‹pattern_name›] analyze ‹classifying_attribute_or_dimension›

Example: mine classification as classifyCustomerCreditRating analyze credit_rating


Techniques 47

Syntax for concept hierarchy specification

More than one concept per attribute can be specified Use hierarchy ‹hierarchy_name› for ‹attribute_or_dimension› Examples:

Schema concept hierarchy (ordering is important) define hierarchy location_hierarchy on address as

[street,city,province_or_state,country]

Set-Grouping concept hierarchy define hierarchy age_hierarchy for age on customer as

level1: {young, middle_aged, senior} < level0: all

level2: {20, ..., 39} < level1: younglevel2: {40, ..., 59} < level1:

middle_agedlevel2: {60, ..., 89} < level1: senior


Techniques 48

Syntax for concept hierarchy specification (2)

operation-derived concept hierarchy define hierarchy age_hierarchy for age on customer as

{age_category(1), ..., age_category(5)} := cluster (default, age, 5) < all(age)

rule-based concept hierarchy define hierarchy profit_margin_hierarchy on item as

level_1: low_profit_margin < level_0: all

if (price - cost)< $50

level_1: medium-profit_margin < level_0: all

if ((price - cost) > $50) and ((price - cost) <= $250))

level_1: high_profit_margin < level_0: all

if (price - cost) > $250


Techniques 49

Syntax for interestingness measure specification with [‹interest_measure_name›]

threshold = ‹threshold_value›

Example: with support threshold = 5% with confidence threshold = 70%


Techniques 50

Syntax for pattern presentation and visualization specification

display as ‹result_form›

The result form can be rules, tables, cubes, crosstabs, pie or bar charts, decision trees, curves or surfaces.

To facilitate interactive viewing at different concept levels or different angles, the following syntax is defined:

‹Multilevel_Manipulation› ::= roll up on ‹attribute_or_dimension›

| drill down on ‹attribute_or_dimension›

| add ‹attribute_or_dimension› | drop ‹attribute_or_dimension›


Techniques 51

Architectures of Data Mining System With popular and diverse application of data mining, it

is expected that a good variety of data mining system will be designed and developed.

Comprehensive information processing and data analysis will be continuously and systematically surrounded by data warehouse and databases.

A critical question in design is whether we should integrate data mining systems with database systems.

This gives rise to four architecture: - No coupling- Loose Coupling- Semi-tight Coupling- Tight Coupling


Techniques 52

Cont. No Coupling: DM system will not utilize any

functionality of a DB or DW system

Loose Coupling: DM system will use some facilities of DB and DW system like storing the data in either of DB or DW systems and using these systems for data retrieval

Semi-tight Coupling: Besides linking a DM system to a DB/DW systems, efficient implementation of a few DM primitives.

Tight Coupling: DM system is smoothly integrated with DB/DW systems. Each of these DM, DB/DW is treated as main functional component of information retrieval system.


Techniques 53

Designing Graphical User Interfaces based on a data mining query language

What tasks should be considered in the design

GUIs based on a data mining query language?

Data collection and data mining query

composition

Presentation of discovered patterns

Hierarchy specification and manipulation

Manipulation of data mining primitives

Interactive multilevel mining

Other miscellaneous information


Techniques 54

Summary

Five primitives for specification of a data mining task task-relevant data kind of knowledge to be mined background knowledge interestingness measures knowledge presentation and visualization

techniques to be used for displaying the discovered patterns

Data mining query languages DMQL, MS/OLEDB for DM, etc.

Data mining system architecture No coupling, loose coupling, semi-tight coupling,

tight coupling


Techniques 55

Measurements of Pattern Interestingness

Simplicitye.g., (association) rule length, (decision) tree size

Certaintye.g., confidence, P(A|B) = #(A and B)/ #(B), classification reliability or accuracy, certainty factor, rule strength, rule quality, discriminating weight, etc.

Utilitypotential usefulness, e.g., support (association), noise threshold (description)

Noveltynot previously known, surprising (used to remove redundant rules, e.g., Canada vs. Vancouver rule implication support ratio)


Techniques 56

Visualization of Discovered Patterns

Different backgrounds/usages may require different forms of representation E.g., rules, tables, crosstabs, pie/bar chart etc.

Concept hierarchy is also important Discovered knowledge might be more understandable

when represented at high level of abstraction Interactive drill up/down, pivoting, slicing and dicing

provide different perspectives to data Different kinds of knowledge require different

representation: association, classification, clustering, etc.


Techniques 57


Data mining primitives: What defines a

data mining task?


Design graphical user interfaces based on

a data mining query language


Summary


Techniques 58

A Data Mining Query Language (DMQL)

Motivation A DMQL can provide the ability to support ad-hoc and

interactive data mining By providing a standardized language like SQL

Hope to achieve a similar effect like that SQL has on relational database

Foundation for system development and evolution Facilitate information exchange, technology

transfer, commercialization and wide acceptance Design

DMQL is designed with the primitives described earlier


Techniques 59

Syntax for DMQL

Syntax for specification of task-relevant data the kind of knowledge to be mined concept hierarchy specification interestingness measure pattern presentation and

visualization Putting it all together—a DMQL query


Techniques 60

Syntax: Specification of Task-Relevant Data

use database database_name, or use data

warehouse data_warehouse_name

from relation(s)/cube(s) [where condition]

in relevance to att_or_dim_list

order by order_list

group by grouping_list

having condition


Techniques 61

Specification of task-relevant data


Techniques 62

Syntax: Kind of knowledge to Be Mined

Characterization

Mine_Knowledge_Specification ::= mine characteristics [as pattern_name] analyze measure(s)

Discrimination

Mine_Knowledge_Specification ::= mine comparison [as pattern_name] for target_class where target_condition {versus contrast_class_i where contrast_condition_i}

analyze measure(s)

E.g. mine comparison as purchaseGroups

for bigSpenders where avg(I.price) >= $100

versus budgetSpenders where avg(I.price) < $100

analyze count


Techniques 63

Syntax: Kind of Knowledge to Be Mined (cont.)

Association Mine_Knowledge_Specification ::=

mine associations [as pattern_name] [matching <metapattern>] E.g. mine associations as buyingHabits matching P(X:custom, W) ^ Q(X,

Y)=>buys(X, Z) Classification Mine_Knowledge_Specification ::=

mine classification [as pattern_name] analyze classifying_attribute_or_dimension

Other Patterns clustering, outlier analysis, prediction …


Techniques 64

Syntax: Concept Hierarchy Specification

To specify what concept hierarchies to use

use hierarchy <hierarchy> for <attribute_or_dimension> We use different syntax to define different type of hierarchies

schema hierarchies

define hierarchy time_hierarchy on date as [date,month quarter,year]

set-grouping hierarchies

define hierarchy age_hierarchy for age on customer as

level1: {young, middle_aged, senior} < level0: all

level2: {20, ..., 39} < level1: young

level2: {40, ..., 59} < level1: middle_aged

level2: {60, ..., 89} < level1: senior


Techniques 65

Concept Hierarchy Specification (Cont.)

operation-derived hierarchies

define hierarchy age_hierarchy for age on customer as

{age_category(1), ..., age_category(5)} := cluster(default, age, 5) < all(age)

rule-based hierarchies

define hierarchy profit_margin_hierarchy on item as

level_1: low_profit_margin < level_0: all

if (price - cost)< $50

level_1: medium-profit_margin < level_0: all

if ((price - cost) > $50) and ((price - cost) <= $250))

level_1: high_profit_margin < level_0: all

if (price - cost) > $250


Techniques 66

Specification of Interestingness Measures

Interestingness measures and thresholds can be specified by a user with the statement:

with <interest_measure_name> threshold = threshold_value

Example:

with support threshold = 0.05

with confidence threshold = 0.7


Techniques 67

Specification of Pattern Presentation

Specify the display of discovered patterns

display as <result_form>

To facilitate interactive viewing at different concept

level, the following syntax is defined:

Multilevel_Manipulation ::= roll up on attribute_or_dimension

| drill down on

attribute_or_dimension

| add attribute_or_dimension

| drop

attribute_or_dimension


Techniques 68

Putting it all together: A DMQL query

use database AllElectronics_db use hierarchy location_hierarchy for B.addressmine characteristics as customerPurchasing analyze count% in relevance to C.age, I.type, I.place_made from customer C, item I, purchases P, items_sold S,

works_at W, branchwhere I.item_ID = S.item_ID and S.trans_ID =

P.trans_ID and P.cust_ID = C.cust_ID and P.method_paid = ``AmEx'' and P.empl_ID = W.empl_ID and W.branch_ID = B.branch_ID and B.address = ``Canada" and I.price >= 100

with noise threshold = 0.05 display as table


Techniques 69

Other Data Mining Languages & Standardization Efforts

Association rule language specifications

MSQL (Imielinski & Virmani’99)

MineRule (Meo Psaila and Ceri’96)

Query flocks based on Datalog syntax (Tsur et al’98)

OLEDB for DM (Microsoft’2000)

Based on OLE, OLE DB, OLE DB for OLAP

Integrating DBMS, data warehouse and data mining

CRISP-DM (CRoss-Industry Standard Process for Data Mining)

Providing a platform and process structure for effective data

mining

Emphasizing on deploying data mining technology to solve

business problems


Techniques 70



data mining task?





Summary


Techniques 71

Designing Graphical User Interfaces Based on a Data Mining Query Language

What tasks should be considered in the design

GUIs based on a data mining query language?

Data collection and data mining query

composition

Presentation of discovered patterns

Hierarchy specification and manipulation

Manipulation of data mining primitives

Interactive multilevel mining

Other miscellaneous information


Techniques 72



data mining task?


Design graphical user interfaces based

on a data mining query language


Summary


Techniques 73

Data Mining System Architectures

Coupling data mining system with DB/DW system No coupling—flat file processing, not recommended Loose coupling

Fetching data from DB/DW Semi-tight coupling—enhanced DM performance

Provide efficient implement a few data mining primitives in a DB/DW system, e.g., sorting, indexing, aggregation, histogram analysis, multiway join, precomputation of some stat functions

Tight coupling—A uniform information processing environment

DM is smoothly integrated into a DB/DW system, mining query is optimized based on mining query, indexing, query processing methods, etc.


Techniques 74



data mining task?





Summary


Techniques 75

Summary

Five primitives for specification of a data mining task task-relevant data kind of knowledge to be mined background knowledge interestingness measures knowledge presentation and visualization

techniques to be used for displaying the discovered patterns

Data mining query languages DMQL, MS/OLEDB for DM, etc.

Data mining system architecture No coupling, loose coupling, semi-tight coupling,

tight coupling


Techniques 76

References E. Baralis and G. Psaila. Designing templates for mining association rules. Journal of

Intelligent Information Systems, 9:7-32, 1997. Microsoft Corp., OLEDB for Data Mining, version 1.0,

http://www.microsoft.com/data/oledb/dm, Aug. 2000. J. Han, Y. Fu, W. Wang, K. Koperski, and O. R. Zaiane, “DMQL: A Data Mining Query

Language for Relational Databases”, DMKD'96, Montreal, Canada, June 1996. T. Imielinski and A. Virmani. MSQL: A query language for database mining. Data Mining

and Knowledge Discovery, 3:373-408, 1999. M. Klemettinen, H. Mannila, P. Ronkainen, H. Toivonen, and A.I. Verkamo. Finding

interesting rules from large sets of discovered association rules. CIKM’94, Gaithersburg, Maryland, Nov. 1994.

R. Meo, G. Psaila, and S. Ceri. A new SQL-like operator for mining association rules. VLDB'96, pages 122-133, Bombay, India, Sept. 1996.

A. Silberschatz and A. Tuzhilin. What makes patterns interesting in knowledge discovery systems. IEEE Trans. on Knowledge and Data Engineering, 8:970-974, Dec. 1996.

S. Sarawagi, S. Thomas, and R. Agrawal. Integrating association rule mining with relational database systems: Alternatives and implications. SIGMOD'98, Seattle, Washington, June 1998.

D. Tsur, J. D. Ullman, S. Abitboul, C. Clifton, R. Motwani, and S. Nestorov. Query flocks: A generalization of association-rule mining. SIGMOD'98, Seattle, Washington, June 1998.


Techniques 77

www.cs.uiuc.edu/~hanj

Thank you !!!Thank you !!!

Chapter 4: Data Mining Primitives, Languages, and System Architectures

Documents

data mining taskdata

set of data mining primitives

data mining query languages

practicedata mining

uninterestingdata mining

set of task relevant

unit iidata mining primitive

user intervention