IEEE ICDE 98 Tutorial: Mobile Computing and Databases Margaret H. Dunham Southern Methodist...

IEEE ICDE ‘98 Tutorial:Mobile Computing and Databases

Margaret H. Dunham

Southern Methodist University

Dept of Computer Science and Engineering

Dallas, Texas 75275

mhd@seas.smu.edu

http://www.seas.smu.edu/~mhd

2/24/98 ICDE/SMU - Dunham 2

Outline

Introduction & Data Management IssuesQuery ProcessingCachingData BroadcastingTransaction ProcessingAgentsProjects & ProductsConclusion

Mobile Computing Architecture

Terminology

Fixed Network (FN)Base Station (BS) (Mobile Support Station -

(MSS))Fixed Hosts (FH)Cell - Area covered by BS (1-2 miles)Handoff - Changing BS by intercell moveMobile Host (MH) (Mobile Unit (MU))

Wireless Networks

Cellular High Cost Scalability Issue Limited Bandwidth: 10 Kbps

Wireless LAN Traditional LANs with wireless interface Low Cost Limited range: 10-100 meters Bandwidth: 10Mbps NCR Wavelan, Motorola ALTAIR

Wireless Networks (cont’d)

Satellite Services Wide Coverage Very Expensive Low Bandwidth: 1-2Mbps

Paging Networks Wide Coverage Sky Tel, Motorola

Slow: (Ethernet: 10Mbps; FDDI or switched Ethernet: 100Mbps; ATM: 155Mbps)

Handoff

Changing BS due to movement between cells

State information transferred

Current handoffs in cellular phones may take up to a few seconds with breaks in conversation of 100-300 ms.

Soft - Temporarily connected to two BSsHard - Only connected to one BS

Location Management

Tracking mobile userUser associated with home location

server (Home Agent)May augment by searching in local

area firstMay augment with user profilesMobile IP [11,14]

Triangle Routing Route Optimization Location Control (Routing Agent)

Location Management (cont’d)

Active Badge (Cambridge,[2]) Track employees and route telephone calls Unique code emitted every 15 seconds Sensors placed in offices and corridors

Location Information Replications No HLR Hierarchy of Location Servers Each server maintains information about its subtree

Mobile Applications

Information Services (Yellow Pages)Law Enforcement and Medical EmergenciesSales and Mobile OfficesWeather, Traffic, Sports, EntertainmentTruckingCellular Subscribers in the United States:

90,000 in 1984;4.4 million in 1990;13 million in 1994

Handheld computer market will grow to $1.77 billion by 2002

Technology Push

Internet: ftp, telnet, email, http,htmlAdvancing Wireless Communication

TechnologiesLaptop, Notebook, and Palmtop Computers

Classification of Mobile Database Systems

Data Management Issues

Speed of wireless linkScalabilityMobility Location dependent data; Location specific queriesLimited by battery powerDisconnection (Voluntary, Involuntary)Replication/CachingHandoff

Insurance Example

Medical Example

911 CallAmbulance arrives/departsClosest hospitalAccess patient recordsSend vital signsUpdate patient recordsPage hospital personnelOrder medical supplies

MC/DB Research

Transaction ProcessingCaching - ReplicationBroadcast DisksAgentsMobilityLocation Dependent DataRecoveryACID (?)

Outline

Introduction & Data Management Issues Query Processing

Location Dependent Queries and DataNew Query TypesQuery Optimization

CachingData BroadcastingTransaction ProcessingAgentsProjects & ProductsConclusion

Location Dependent Data

Value of data depends on locationTemporal Replication - One consistent value at one

timeSpatial Replication - Multiple different correct data

values at one timeTemporal Consistency - All data objects satisfy a

given set of integrity constraints.Spatial Consistency - Consistency constraints

satisfied within Data Region.SMU/University of Missouri at Kansas City, [17]

Location Dependent Queries

Result depends on locationDifferent from traditional distributed goal of

location independenceEx: Yellow Pages, Directions, MapPredicates based on location: “Find the

cheapest hotel in Dallas.”Location constraints: “Find the nearest hotel (to

me).”

Similarity to Spatial Queries

Spatial Data: Data associated with space occupied by object.

Types of spatial queries: contains, contained in, intersects, neighboring, east of, etc.

Spatial data structuresSpatial operators Spatial selects and joinsPSQL - extend SQL, [18,20]

Differences from Spatial Queries

Client is actually movingLocation of client may be

part of the query itselfMay depend on direction of movementData may not directly contain location

information Includes temporal features as well

Spatial data is dynamic

Querying Moving Objects

Moving Objects Spatio-Temporal (MOST) data model Dynamic Attributes - Change over time Queries over temporal history:

Instantaneous - Ex: “Find all restaurants I’ll reach in the next half hour. ”

Continuous - Ex: “Find all restaurants within 5 miles.” The answer continuously changes as the MU moves.

Persistent - Ex: “Find the cars that travel greater than 10 miles in the next half hour.”

Future Temporal Logic (FTL) language University of Illinois, [20]

Query Optimization

How best to satisfy the information request made by the client?

Different Cost Factors: I/O, networkDifferent Access Options: cache, FN, broadcastDynamic and Adaptable - environment changesAlternative plans include deciding (based on state

of MH and environment) whether to access in the cache at the MH, to request a mobile transaction, or to obtain from a broadcast disk.

Outline

Introduction & Data Management IssuesQuery Processing Caching

OverviewTypes

Research Data BroadcastingTransaction ProcessingAgentsProjects & ProductsConclusion

Caching

Placing data at MU. Usually on disk.Faster to access from MU than from DBMS in

fixed network.Facilitates disconnected operation.Adaptive to connection mode.Not just another replicaPull basedMost work on files not databases

Caching Functions

Data fetching Granularity (Page, file, table, semantic)

ReplacementCoherency

Callback - Servers send invalidation messages to clients.

Detection - Clients send queries to servers to.

Updating during disconnectData integration when reconnected

Connectivity and File Systems

Table 3.2 from [15]

MU Replica Control Protocols

Traditional Replication Protocol problems: May hinder mobility Quorum Consensus: Can’t get quorum if

disconnected; Avoid using MU replicas to make up quorum

Location information not always readily availablePrimary Copy: Should not be stored at MUFirst class/Second class replicas

Checkpointing

Table 3.4 from [15]

Prefetching vs.. Hoarding

Both prefetch data in anticipation of future use.Prefetching

Objective is to improve performance (throughput or response time).

Cache miss not catastrophic.

Hoarding Objective is to fetch all needed data into MU cache prior to

disconnect. Thus the goal is to facilitate disconnected operation.

Cache miss is catastrophic. OK to overfetch

Hoarding/Spying

Listening to and recording file accessesPerformed during a snapshot intervalMay be combined with user profiles. Results limited to the snapshot.

Disconnected Issues

Table 3.1 from [15]

First project to demonstrate disconnected operation.Optimistic LockingGranularity - sets of files.Coherency - callbacksHoard Walking: Periodically (every 10 min) evaluate

contents of cache. Recalculate priorities.On a callback break, object is purged, refetching on

demand or during next hoard walk.Venus - cache manager at MU

Coda (cont’d)

Venus states: hoarding,emulating,write disconnected (earlier reintegrating).

Cache misses during disconnection are treated as failures.

During disconnection, a log (Change Modify Log) of operations is created.

Hoarding

WriteDisconnected

Emulating

Adapted from Fig 2 in [34]

Disconne cti on

Strong Connection

Weak Connection

Discon

Coda (cont’d)During integration, log applied. Conflicting updates are

determined and user assists in resolutionTimestamps at volume and object level used to determine

conflicts.Trickle Reintegration used to asynchronously propagate

updates. Hoard Profile - list of files and priorities.Lowest priority objects chosen for replacement.Weak Connectivity - low bandwidth, high latency, high cost, or

intermittentCMU, [29,34]

Little Work

Disconnected AFSCache operations depends on type of connection

Connected - Continuous; High bandwidth; Normal operation

Partially Connected - Continuous; Dialup; Delayed writes

Fetch Only - On demand; Cellular; Optimistic replication

Disconnected - Fail if cache miss

Little Work (cont’d)

Caches 64KB chunks of files Fetch only modeModifications sent back to primary file serverConflicts stored separately and user notifiedMichigan, [25,26]

FicusUses semantic information to determine contents of

cache.Semantic distance between files measured in number

of file accesses on average between two files.Access is defined as open-close.Distance measure used to cluster files. Fetching of a

cluster based on user hints and LRU information.UCLA, [24,30]

Summary

Table 3.1 from [15]

Sleepers and Workaholics

Cache invalidation reportPeriodically (synchronous) the server broadcasts

report of changed data.MU waits for next report prior to answering query.Sleepers - frequently disconnected; cache invalidation

based on signatures.Workaholics - rarely disconnected; periodic broadcast

of changes.False InvalidationMITL and Rutgers, [21]

Transparent Analytic Spying

File Working SetsContinually observe and

record (in a log) file access. At hoard time, reference the log to determine hoard.

Trees for a process are created reflecting file access pattern. One tree per program execution is generated.

Access Tree

Transparent Analytic Spying (cont’d)

Hoard all files or only those in in the most recent execution.

Tracing adds about 2% CPU overhead. Average space for file log record is 100 bytes.

Implemented on Unix, NFS, MachCache miss rate over wireless slightly higher than on

wired.Prefetching overall reduced cache misses and

elapsed timeColumbia, [36]

Predictive File Caching

Analyze file access patterns in different environments: Personal productivity, Programming, Commercial

Working Set Statistics: Mean working-set sizes small (18MB per day)

Attention Shift Statistics: 0.6 per user per weekConflict Statistics: Depends on environmentConclusion:

Hoarding is possible due to small working set size LRU caching insufficient

UCLA, [31]

Virtual Primary Copy

Mobile Primary Copy (MPC) at MUVirtual Primary Copy (VPC) at BSGlobal transactions access VPCConsistency of VPC maintained by BSBS monitors MU disconnectMultilayered approach is transparent to other

sites Monash, [23]

MC Replication SystemMU Peer to Peer communication

allowedWard Model:

Ward: Grouping of replicas for locations that frequently communicate

Ward Set: Set of replicated data stored in a ward.

Ward Master: Doorway into ward. Maintains consistency between wards.

Roam (cont’d)

Ward members are “close”No “pre-motion” operations Intra-ward synchronization easier than inter-

wardReconciliation- Synchronization processSelective replication at file levelScales wellUCLA, [33]

Semantic Cache

Caching granularity at a predicate levelSPJ query - Materialized viewAdvantages: reduces network overhead,

reduces cache spaceDisadvantages: Indexing, query trimmingSemantic Cache - C = {Si}Semantic Segment - Si=<Sr,Sa,Sp,Sc>SMU

Outline

Introduction & Data Management IssuesQuery ProcessingCaching Data Broadcasting

OverviewIndexingResearch

Transaction ProcessingAgentsProjects & ProductsConclusion

Data Broadcasting

Server continually broadcasts data to MUs. Scalability: Cost does not depend on number of users

listening.Mobile Unit may/may not have cache.Facilitates data access during disconnected periods.Allows location dependent data access.No need to predict with 100% accuracy the future data needs.Broadcast based on probability of access.Periodic broadcasting of all data.

Data Broadcasting (cont’d)

Classification: Coverage - Everything, Subset Content - Static, Dynamic Indices - Index, Self Descriptive Data Stream - Flat, Skewed, Multiple Disks Client - Passive, Active

For uniform page access, flat disk has best expected performance.

With skewed page access, nonflat disks are better.Push based.

Broadcast Disks

Simulate multiple disks of varying sizes and speeds. Data of higher interest on smaller faster disks (broadcast more frequently).

Each “disk” contains data with similar access behavior.

Combination of caching and broadcast disks.

Figure 4.1 from [15]

Broadcast Disks (cont’d)

Don’t want to store hottest pages. They may be broadcast frequently.

Store in cache if probability of access (P) is greater than the frequency of broadcast (X).

Cost based page replacement.Replace cache page with smallest P/X - PIX. Too

expensive to implement.LIX - PIX approximation. Works well particularly with

noise.Brown, MITL, Maryland, [37,38,39]

Air-Cache

Dynamic - Adapts to system workload.Define temperature of data:

Vapor (Steamy) Hot - Accessed frequently and broadcast.

Liquid Warm - Accessed often, not broadcast, but kept in server’s main memory.

Frigid (Icy) Cold - Accessed infrequently and stored on secondary storage.

Air-Cache (cont’d)

Three level memory hierarchy based on temperature.

Sparks (access) to data can increase temperature. No sparks, results in a reduction of temperature.

Simulation results predict very good performance.

Maryland, [43]

Adaptive Protocols

Dynamically modify broadcast contents.Constant Broadcast Size (CBS) Server Protocol:

Limited size and periodic Priority Popularity Factor (PF) Ignore Factore (IF)

Variable Broadcst Size (VBS) Server Protocol: Aperiodic All data above threshold PF included.

Arizona and UMKC, [40]

Outline

Introduction & Data Management Issues Query Processing Caching Data Broadcasting

Transaction ProcessingOverviewTransaction ModelConcurrencyRecoveryResearch

Agents Projects & Products Conclusion

Mobile Transaction (MT)

Database transaction requested from a MU. May execute in FN or MU

IssuesDisconnect/HandoffMobilityLocation Dependent DataError ProneMU Resources/ PowerRecovery/Restart Management

MT Requirements

Keep autonomy of local DBMSLLT InteractiveAdvanced transaction models

Nested Multidatabase

Request from MUExecute anywhereCapture movementACID (?)

MT Approaches

No consensus on accepted approachMU may not have primary copy of data [45]:

Transaction Proxy: MU does no transaction processing Read Only Transaction: MU only reads data Weak Transaction: Read and update cached data;

Must synchronize updates with primary copy on FN.

MU may have primary copy of dataMU may access data on other MUsFirst class and second class transactions

MT RecoveryTransaction, site, media, network failure - More frequent

than in wired network.Different types of failures (partial)

Handoff Voluntary disconnection Battery problems Lose computer??

Checkpoint data at MU to BSCheckpoint at handoffDatabase log plus transaction logMay need compensating transactions

Atomicity for MT

Weaken or provide different types of atomicityMay decompose transaction into

subtransactionsMay require atomicity at lower than transaction

levelAtomic commitment difficult (expensive)Global commit/Local Commit

Consistency for MT

Weakening isolation and atomicity may weaken this as well.

May divide data into clusters with consistency within clusters.

Reintegration of updates after reconnect may cause many conflicts.

May use bounded inconsistency. Impacted by location dependent data

Isolation for MT

May be too restrictiveCan’t always do at MU (disconnection) Isolation at lower levels in transactionCommitment at different levels of transactionCooperating transactions

Durability for MT

Durability for partial resultsMay want durability for parts of transactions.Due to conflicts at reconnect, even durability of

subtransactions may not be guaranteed.Local commit vs.. Global commit

MT Concurrency Control

Mobility of MUs may increase message traffic for lock management

MU failure may leave some data locked /unlocked

6) T1: Unlock(Xa); Commit;

Server ACell A

Server BCell B

Server CCell C

XcYcZc

1) T1: Lock(Xa); Read(Xa)

2) T1 moves to B

3) T1: Lock(Yb); Read(Yb)

4) T1 moves to C

5) T1: Lock(Zc); Write(Zc);

Unlock(Zc); Commit

6) T1: Unlock(Yb); Commit;

Fig 2 from [48]

Revised Optimistic Locking

O2PL-MT Read locks may be

executed at multiple servers.

Read unlock can be executed at any site

Benefit shown using analytic model

Purdue, [48]

LOCK HELD

LOCKREQUEST

W_INTEND R_LOCK W_LOCK

W_Intend No Yes No

R_Lock No Yes No

W_Lock No No No

Figure 3 from [48]

Kangaroo Transaction (KT)

Built on top of global transactionsCaptures data and movement behaviorDAA as BS - Maintains logging and transaction

statusLogging at BSFlexible atomicityRestart after disconnectManagement moves

Kangaroo Transaction (cont’d)

Local Transaction - Sequence of read and write operations ending in commit or abort

Global Transaction - Sequence of global or local transactions

Joey Transaction - Sequence of global and local transactions ending in commit, abort, or split

Kangaroo Transaction - Sequence of one or more Joeys with last one ending in commit or abort. All earlier end in split

SMU, [47]

KT and Movement

Reporting and Co-Transactions

Mobile transaction is a special type of multidatabase transactions.

GDMS exists at each base station.Subtransactions of the mobile transaction will

commit or abort independently.Atomic and non-compensatable transactions.Reporting and co-transactions.Pittsburgh, [46]

Clustering Model

Views mobile transaction as beginning on mobile and nonmobile hosts.

Transaction migrationTransaction model is designed to maintain

consistency of the database.Database is divided into clusters.Data is divided into core and quasi copies.Mobile transactions and operations are decomposed

into a set of weak and strict transactions.

Clustering Model (cont’d)

Weak operations access only data in the same cluster. Strict operations allowed database wide access. Two copies of data can be maintained (strict and weak).

Clusters defined based on location and user profile.Transaction Proxy: dual transaction of one executed

at mobile host which includes only the updates. Purdue, [51,52]

Mobile Transactions and Ambulatory Care

Medical Personal Digital Assistant (MPDA)Battlefield - Cache copy of soldiers’ medical records in

MPDADistributed Medical Database - EMT obtains patient’s

medical record and updates.BSA (Base Station Agent) is responsible for logging

and recovery.Recovery based on sagas with save-points.Mailboxes used to save information.Purdue, [49,50]

Semantics-Based Mobile Transaction Processing

Views mobile transaction processing as a concurrency and cache coherency problem.

A stationary database server dishes out the fragments of an object on a request from a Mobile Unit.

On completion of the transaction, the Mobile Units return the fragments to the server.

These fragments are put together again by the merge operation at the server.

Pittsburgh, [54]

Multidatabase Transaction Processing Manager

Mobile transactions built on top of multidatabase global transactions.

Timestamps used to enforce orderingAllows voluntary disconnections.MU part of MDSMessage Queuing Facility (MQF)MU sends request to designated coordinating

node on FN.Monash, [56]

PRO-MOTION

MC/Database Transaction Processing approachMultiple transaction types

Controlled divergence ACID Update cache and later DB at FH

Compact - Compact Agent at MU, Mobility Manager at BS, Compact Manager at Server

Pittsburgh, [55]

MT Research Limitations

Architectural AssumptionsNo support for location dependent dataFew Implementations

MT Management Options

MUBSCombinationFixed/Relocatable/Moving

Outline

Introduction & Data Management IssuesQuery ProcessingCachingData BroadcastingTransaction Processing Agents

OverviewClient-Agent-Server ModelMobile Agent

Projects & ProductsConclusion

Application dispatched by and working for the client.

Agent: Solves disconnect problem Solves slow bandwidth problem

Client-Agent-ServerAgent Classification:

Type - Client,Server,Application,UserMovement - Static, Relocatable, Migrating (Mobile)Number - Single, Multiple, Clonable

Client Server

Client Agent Server

Itinerant Agent (Mobile Agent)

Program dispatched from mobile unit that roams through the fixed network to satisfy client’s data request.

At a server the agent is sent to an Agent Meeting Point (AMP) where desired server functions are determined and requested.

Client, Migrating, Single IBM, [58]

Migrating User Agent

User process that mimics MU.Process migrates as user moves.Client, Migrating, SingleMassachusetts, AT&T, [63]

Remote Programming

Language for communication required.User and server communication without using

network.Places - Meeting points for agents and serversAgents - Application is set of agents. Agent is

either at a place or travelling between places.Travel - Go instructionMeetings - Agents communicating at a place.General Magic Telescript, [59]

Concordia

Mitsubishi Electra ITAJava Objects; JDBCCollaborating AgentsAgent Server - FNUser Agent - MU to BSQuery Agents- BS to ServerCollaborator - BSMitsubishi Electric ITA,

[60,61] Adapted from Fig 6 in [61]

UserAgent

Query Agent

Collaboration

OracleServer

NotesServer

Concordia

Outline

Introduction & Data Management IssuesQuery ProcessingCachingData BroadcastingTransaction ProcessingAgents Projects & Products

Conclusion

Some DB/MC Projects URLs MobiDick - Monash Univ. (Australia);

http://www.ct.monash.edu.au/~mobidick Mobisaic - Univ. of Washington;

http://www.cs.washington.edu/homes/voelker/mobisaic Purdue; http://www.cs.purdue.edu/research/cse/mobile SMU; http://www.seas.smu.edu/~mhd/mobile.html MCC - Collaboration Managment Infrastructure;

http://www.mcc.com/projects/transaction University of Ioanina; http://zeus.cs.uoi.gr/ Michigan - CITI; http://www.citi.umich.edu/projects/mobile.html UCLA - Ficus; http://ficus-www.cs.ucla.edu/ficus Columbia; http://www.mcl.cs.columbia.edu

Figure 6.1 from [15]

Oracle Mobile Agent

Commercial ProductApplication, Static,

MultipleMessage Manager - MUMessage Gateway - BSAgent - FN (Server) [67,69]

Message Manager

Gateway

Corporate Network

Database Server

Sybase - SQL Anywhere

Designed for Windows, (95, 3.x, NT), OS/2, DOS

Limited memory requirements

Full TP capabilities Includes SQL RemoteCompatible with Sybase

SQL Server [68]

Remote DatabaseSQL Anywhere standalone engine

Message agent

Consolidated DatabaseSQL Anywhere network server

Message agent

Sybase (cont’d) - SQL RemoteTwo way replication based on

message passing.Remote database are synchronized

with consolidated DBMessage Agent required at DB serverReplication of subscribed fragmentsPeriodic changes sent from consolidated

DB to remote DBsUpdates from committed transactions at remote submitted to

consolidated database. Conflicts: Consolidated is master; Triggers used.

ConsolidatedDB

Remote Databases

Informix

I-Mobile 1.0 discontinued: No replication Three tier approach appropriate for long term, but in the

short term users wanted to be able to use existing client-server applications (not rewrite).

Small DBMS server to run on mobile client Only dial up needed for now

Informix Dynamic Server/Personal Edition (IDS/PE) for Windows 95/NT. Mobiles and desktop clients

[64,66]

Outline

Introduction & Data Management IssuesQuery ProcessingCachingData BroadcastingTransaction ProcessingAgentsProducts Conclusion

Future

Combine different approachesSemantic cachingQuery OptimizationAdaptive Data BroadcastingPerformance BenchmarksSecurityLocation Dependent Queries

Acknowledgements and URL Bibliographies

Earlier version of this tutorial presented at the 1996 Brazilian Database Symposium.

We particularly want to thank Evaggelia Pitoura for providing several tables and figures from her recent book [15].

Some slide information obtained from slides presented at a database class at the University of Massachusetts, http://www-ccs.cs.umass.edu/mobile.

Online bibliographies http://www.seas.smu.edu/~mhd/mobile.html http://www.ct.monash.edu.au/~mobidick

IEEE ICDE 98 Tutorial: Mobile Computing and Databases Margaret H. Dunham Southern Methodist...

Documents

Transcript of IEEE ICDE 98 Tutorial: Mobile Computing and Databases Margaret H. Dunham Southern Methodist...

African Virtual University and ICDE

3/11/10, BYU1 The Magnificent EMM Margaret H. Dunham Michael Hahsler, Mallik Kotamarti, Charlie Isaksson CSE Department Southern Methodist University Dallas,

Dunham (Tales of Dunham: The Past) Excerpt

Icde ossiannlisson oer_oct2011

Discrete Mathematics CSE 2353 Fall 2007 Margaret H. Dunham Department of Computer Science and Engineering Southern Methodist University Some slides provided.

DATA MINING Part I IIIT Allahabad Margaret H. Dunham Department of Computer Science and Engineering Southern Methodist University Dallas, Texas 75275,

4/24/09 - KSU Spatiotemporal Stream Mining Using EMM Margaret H. Dunham Southern Methodist University Dallas, Texas 75275 mhd@engr.smu.edu This material.

2015 ICDE Open Educational Practice

10/30/021 ME DATA MINING OVERVIEW Margaret H. Dunham CSE Department Southern Methodist University Dallas, Texas 75275 mhd@engr.smu.edu.

Dunham-Bush Centrifugal Liquid Chiller - Jmaterialsjmaterials.com/download/Chiller-Dunham-Bush/Dunham-Bush Centrif… · 1 Dunham-Bush Centrifugal Liquid Chiller DCLC 46 47 F53 CM

CSE 5330/7330 Database Introduction Fall 2009 Margaret H. Dunham Department of Computer Science and Engineering Southern Methodist University POBox 750122.

ICDE Consulting future strategies

MateriaMedica Dunham

1 DATA MINING Source : Margaret H. Dunham Department of Computer Science and Engineering Southern Methodist University Companion slides for the text by.

VoIP Data IIIT Allahabad Margaret H. Dunham Department of Computer Science and Engineering Southern Methodist University Dallas, Texas 75275, USA mhd@lyle.smu.edu.

CSE 8392 SPRING 1999 DATA MINING: PART I Professor Margaret H. Dunham Department of Computer Science and Engineering Southern Methodist University Dallas,

© Prentice Hall1 DATA MINING Introductory and Advanced Topics Part III Margaret H. Dunham Department of Computer Science and Engineering Southern Methodist.

© Prentice Hall1 DATA MINING Introductory and Advanced Topics Part II Margaret H. Dunham Department of Computer Science and Engineering Southern Methodist.

11/05/05SMU Homecoming1 DATA MINING AND TERRORISM Margaret H. Dunham CSE Department Southern Methodist University Dallas, Texas 75275 mhd@engr.smu.edu.

STIFF: A Forecasting Framework for Spatio-Temporal Data Zhigang Li, Margaret H. Dunham Department of Computer Science and Engineering Southern Methodist.