Data mining-primitives-languages-and-system-architectures2641

PP:31
Data Mining Primitives, Languages, and
System Architectures

Introduction
•

Popular Misconception about Data Mining
– Systems can autonomously dig out all valuable knowledge without human
intervention

•
•
•
•

Would uncover a overwhelmingly large set of patterns
Its like letting loose a data mining “monster”
Most of the patterns would be irrelevant to the analysis task of the
user
Many of them although relevant would be difficult to understand or
lack validity.

Introduction (2)
•

More realistic
– Users communicating with the system to make the process efficient and
gain some useful knowledge
– User directing the mining process
– Design primitives for the user interaction
– Design a query language to incorporate these primitives
– Design a good architecture for these data mining systems

Primitives
•
•
•
•
•

Task Relevant Data
Kinds of knowledge to be mined
Background knowledge
Interestingness measure
Presentation and visualization of discovered patterns

Task Relevant Data (1)
•
•
•
•
•
•

Database portion to be investigated
(Canadian example)
Can also specify the attributes to be investigated
Collect a set of task relevant data using relational queries –
SubTask
Initial Data Relation – Can be ordered, grouped, transformed
according to the conditions before applying the analysis
Minable view

example
•
•

Buying trends of customers in Canada , say items bought by
customers with respect to age and annual income
Task relevant data
–
–
–
–

Database name
Tables (Item, Customer, purchase, item sold)
Conditions for selecting data (purchases in Canada during the current year)
Relevant attributes (Item name, item price, age and annual income)

Task Relevant Data (3)
• If Data is in a Data Cube
– Data filtering (Slicing)
– Dicing

• Conditions can be specified in a higher concept level
• Concept type = “Home Entertainment” can represent lower level
concepts
{“TV”,”CD Player”,”VCR”}

• Specification of relevant attributes can be difficult
especially when they have strong semantic links to
them.
• Sales of certain items might be linked to festival times

• Techniques that search for links between attributes can
be used to enhance the Initial Data Set

Kind of Knowledge to be Mined (1)
• Determines the data mining function to be performed
• Kinds of Knowledge
–
–
–
–
–
–

•
•

Concept description (Characterization and discrimination)
Association
Classification
Clustering
Prediction
Evolution Analysis

User may also provide pattern templates (metapatterns or metarules
or metaqueries) that the discovered patterns must match
Examples:
–

Age(X, “30..39”)^income(X, “40K..49K”) => buys(X, “VCR)

–

Occupation(X, “Student”)^age(X, “30..39”) => buys(X, “computer”)

[2.2%, 60%]
[1.4%, 70%]

Background Knowledge (1)
•
•

It is the information about the domain to be mined
Concept Hierarchies (focused in this chapter)
–
–
–
–

Schema hierarchies
Set grouping hierarchies
Operation-derived hierarchies
Rule based hierarchies

Concept Hierarchies (1)
•
•
•
•

Defines a sequence of mappings from a set of low-level concepts to
higher-level (more general) concepts
Allow data to be mined at multiple levels of abstraction.
These allow users to view data from different perspectives, allowing
further insight into the relationships.
Example of locations (figure)

Example
•
•
•

Represented as set of nodes organized in a tree
Each node represents a concept
All (represents the root). Most generalized value

•

Consists of levels. Levels numbered top to bottom, with level 0 for
all node

.

• Rolling Up - Generalization of data
–
–
–
–

Allows to view data at more meaningful and explicit abstractions.
Makes it easier to understand
Compresses the data
Would require fewer i/o operations

• Drilling Down – Specialization of data
•

• Concept values replaced by lower level concepts
May have more than concept hierarchy for a given attribute or
dimension based on different user viewpoints
Regional manager may prefer the one in the fig but marketing manager might prefer
to see location with respect to linguistic lines.

•

Schema Hierarchies
–
–
–
–

Total or partial order among attributes
May express existing semantic relationships between attributes
Provides metadata information.
Eg. Location schema hierarchy
Street < city < province_or_state < country

• 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
– Eg. Set grouping hierarchy for age
{young, middle_aged, senior} c all(age)
{20…39} c young
{40…59} c middle_aged
{60…89} c senior

•

Operation-derived
– Based on operations specified.
– Operations may include
• Decoding of information-encoded strings
• Information extraction from complex data objects
• Data clustering

– Eg. Email or url contains hierarchy information
• abc@cs.iitb.in gives login-name < dept. < university < country

•

Rule-based
– Occurs when while 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
– Low_profit(X) <= price(X,P1) ^ cost(X,P2) ^ ((P1-P2) < $50)

Interestingness Measure (1)
•

Based on the structure of patterns and statistics underlying them

•

Associate a threshold which can be controlled

•

Rules not meeting the threshold are not presented to the user

•

Forms of measures
–
–
–
–

Simplicity
Certainty
Utility
Novelty

Interestingness.. (2)
•

Simplicity
– The more the simpler the rule is the more easier it is to understand to a
user
– Eg. Rule length is a simplicity measure

•

Certainty (confidence)
– Assesses the validity or trustworthiness of a pattern
– Confidence is a certainty measure
– Defined as:
# of tuples containing both A & B
# of tuples containing A

Interestingness (3)
•

Utility (Support)
– Usefulness of the pattern
– Defined as:
# of tuples containing both A & B
Total # of tuples

•

Strong Association Rules
• Rules satisfy the threshold for Support
• Rules satisfy the threshold for Confidence

•
•

Rules with low support likely represent noise or rare or exceptional
cases
Novelty
– Patterns contributing new information to the given pattern set are called
novel patterns (eg. Data exception)
– Used to remove redundant patterns

Presentation and Visualization
•

Should be able to display results in multiple forms like rules, tables,
crosstabs, pie or bar charts, decision trees, cubes

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

•
•

Adopts a SQL like syntax
Defined in BNF grammar
– [ ] represents 0 or one occurrence
– { } represents 0 or more occurrences
– Words in sans serif represent keywords

Syntax for Task Relevant Data
Specification
• 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

Syntax for Kind of Knowledge to be Mined
•

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

• Analyze clause specifies aggregate measures
• mine characteristics as customerPurchasing
analyze count%

•

Discrimination:
mine comparison [ as pattern_name]
for target_class where target_condition
{ versus contrast_class_i where contrast_condition_i}
analyze measure(s)
• Compare a given target class of objects with one or more other
contrasting classes
• Mine comparison as purchaseGroups
for bigspenders where avg(I.price) >= $100
versus budgetspenders where avg(I.price) < $100
analyze count

Syntax for Kind of Knowledge to be Mined
•

Association
mine associations [as pattern_name]
[matching metapattern]

• User can provide templates for matching thereby enforcing
additional syntactic constraints for the mining task.
• Mine associations as buyingHabits
matching P(X: customer, W) ^ Q(X,Y) => buys (X,Z)

•

Classification
mine classification [as pattern_name]
analyze classifying_attribute_or_dimension

• Specifies that classification is performed according to the values of
classifying_attribute_or_dimension
• Mine classification as classifyCustomerCreditRating
analyze credit_rating

Syntax for Concept Hierarchy Specification
•

Can have more than one concept hierarchy per attribute

•

Use hierarchy hierarchy_name for attribute_or_dimension

•

Defining Hierarchies:
– Schema (ordering is important)
• Define hierarchy location_hierarchy on address as
[street,city,province_or_state,country]

– Set-Grouping
• 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

Syntax for Concept Hierarchy Specification
•

Defining Hierarchies : (contd..)
– 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

Syntax for Interestingness Measure
•

with [interest_measure_name] threshold = threshold_value

•
•

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

Syntax for pattern presentation and
visualization specification
•

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

Putting it all together
use database AllElectronics_db
use hierarchy location_hierarchy for B.address
mine 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,
branch B

where 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 = 5%
display as table

Other Data Mining Languages and
Standardization of Primitives
• MSQL (Imielinski & Virmani’99) - uses SQL-like syntax and SQL
primitives including sorting and group-by.

• MineRule (Meo Psaila and Ceri’96) -

follows SQL-like syntax and
serves as rule generation queries for mining association rules.

• Query flocks based on Datalog syntax (Tsur, Ullman etc. ’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

Designing GUIs based on DMQL
•

Why do we need a good GUI?
– Syntax difficult to remember and can be confusing

•

Functional Components of a Data Mining GUI
– Data collection and data mining query composition (specify task relevant
data and compose queries. Similar to relational queries)

– Presentation of discovered patterns (display in various forms)
– Hierarchy specification and manipulation (specify and modify concept
hierarchies)

– Manipulation of data mining primitives (thresholds & modification of previous
queries or conditions)

– Interactive multilevel mining (roll-up and drill down)
– Other miscellaneous information (online-help manuals, indexed search,
debugging, other graphical features)

Architecture for Data Mining Systems
• What will a good system architecture facilitate
–
–
–
–
–

Make best use of the software environment
Accomplish data mining tasks in an efficient and timely manner
Interoperate and exchange information with other systems
Be adaptable to user’s diverse needs
Evolve with time

• Question?
– Should we couple or integrate a data mining system with a
database and/or data warehouse system?

Architecture of Data Mining Systems
• Coupling data mining system with DB/DW system
– No coupling (flat file processing, not recommended)
– Loose coupling
• Fetching data from DB/DW
• Storing results in either flat file or database/data warehouse
– 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.

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

Data mining-primitives-languages-and-system-architectures2641

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Data mining-primitives-languages-and-system-architectures2641 (20)

Recently uploaded (20)

Data mining-primitives-languages-and-system-architectures2641