Title: Tucson Police Department Agenda
1Tucson Police Department Agenda
Sgt. Jennifer Schroeder, T.P.D.
- Accomplishments of the last two years
- Collaborative opportunities
- TPDs Commitment to COPLINK and
- plans for the future
- Interest fostered by COPLINK extending
- through all levels of LE
2TPDs Commitment to COPLINK
- Deployment at TPD-High Priority
- Committing up to 245,000 additional funding to
fully deploy Concept Space and integrate with
COPLINK Database - Forming partnerships with other agencies
3TPD Deployment
- COPLINK Team ready to implement
- Additional development to fully operationalize
and provide live update capability complete - Full Deployment subject to TPD upgrade timeline
4TPD Upgrade
- TPD adding better hardware and upgrading software
in preparation for Y2K - Real-time update strategy was designed for use on
new system that includes upgrade from Oracle 6 to
Oracle 7.3
5TPD Upgrade Timeline
- Initially was scheduled for completion July 1999
- Now scheduled for December 1999
- Test RMS system to be available by beginning
November 1999 - Deployment of COPLINK can effectively begin when
test RMS is running
6Test TPD System
- Will allow phased deployment/testing on new
hardware - Network configuration can be tested and refined
- Installation management issues can be refined
- Can begin training and use of system -- System
will be a reality to users
7Full Deployment
- By December 1999, testing will be complete on
both the new TPD RMS and the TPD COPLINK system - Final build process will occur, adding real-time
updates to RMS information - Rollout of interface and training will already
have begun, so users will be live on the system
already
8Concept Space Deployment
- TPD has committed approximately 245,000 to
deploy Concept Space at TPD - This includes deployment, user evaluations,
refinement based on real-life usage - Integration of the COPLINK Concept Space and
COPLINK Database
9Concept Space Timeline
- Initial deployment, user studies, January 2000
- Refinement, modification, integration
- Deployment of fully integrated system by May 2000
10COPLINK Interest
Interest at all levels Municipal, County, State,
Federal
11COPLINK Interest Other Agencies
- Municipal Phoenix Police Department, Mesa,
Avondale, Chandler, Glendale, Peoria, Paradise
Valley, Scottsdale, Tempe - County Maricopa County Sheriffs Office, Pima
County Sheriffs Office
12COPLINK Interest Other Agencies
- Federal High Intensity Drug Trafficking Area
(HIDTA) Center - State Government Information Technology Agency,
Arizona Criminal Justice Commission - State Law Enforcement Arizona DPS
13Partnerships
- National Institute of Justice
- University of Arizona AI Group
- Phoenix Police Department
14Next Presentation Link
15AI Lab Research Overview
- Hsinchun Chen
- Director, AI Lab
- McClelland Professor of MIS
16AI Lab Summary
- Research areas digital libraries, data mining,
intelligent retrieval, and knowledge management - Funding NSF, DARPA, NIJ, NIH, NLM, HP, IBM, SAP,
etc - UA/MIS Top 5 in nation, 30M funding
- AI Lab 7M funding, 35 members, 1M in computing
equipment
17Major AL Lab Projects
- NSF Digital Library Initiative 2,
High-Performance Digital Library Classification
Systems - NSF CISE, Collaborative Visualization
- DARPA Information Management, Interspace
Semantic Interoperability - NIH NLM, Concept Mapping for Medical Informatics
18Major AL Lab Research Directions
- Go deep! (Deep Semantic Parsing)
- Get personal! (Spiders/Agents)
- Get pretty! (Visualization)
- Go international! (Multilingual)
- Go to applications! (Law Enforcement, Medicine,
Business Intelligence)
19Next Presentation Link
20COPLINK Project StatusOverview
- Homa Atabakhsh, Ph.D.
- University of Arizona, MIS Dept.
- COPLINK Project Manager
21Design Criteria
- Platform independent, portable
not all agencies use same HW/OS - Stable and scalable (possibility for system
expansion) - Intuitive and easy to use UI
- Strong performance and response time
- Industry strength applications TCP/IP, Java,
Oracle - Low cost maintenance and training
22Design Architecture
- Design Criteria gt
- Three-tier architecture was proposed
- Java front-end,
- Middle ware application server (OAS),
- Back-End Oracle Relational Database Management
System
23Project Components
- COPLINK Database Application
- Shantel Ekman
- Emily Werner
- Harsh V. Gupta
- COPLINK Concept Space Application
- Harsh Gupta
- User Interface and Evaluations
- Rosie Hauck User Interface Evaluations
- Dan Chen Interface Coding
- Distributed COPLINK
- Chris Boarman
24Relationship between Components
COPLINK Concept Space Application
COPLINK Database Application
- GUI - GUI - User Evaluations - User
Evaluations - Distributed Application -
Distributed Application
25Data Base Design and Testing Background
- COPLINK Database application provides the user
with - An easy-to-use and intuitive interface for
retrieving and analyzing information - The integration of different databases for info
sharing - Performance and flexibility (i.e., portable to
different agencies)
26Data Base Design and Testing Goals and Status
- Design and develop database refresh strategy to
allow frequent updates to the database and
provide current data - Stress testing of the database and OAS Test
loads that simulate simultaneous users requesting
info from database
27Concept Space Background
- Analysis Tool
- Finds relationships between entities in the
database (e.g. people, locations, incidents) - Shows these relationships to users in an
easy-to-use graphical user interface
28Concept Space Goals and Status
- Goal Allow the user to do fast and accurate
analysis of the data - The new GUI is robust
- Future Goals
- Deployment at TPD
- Fully integrate COPLINK Concept Space application
with COPLINK Database application - Adapt to other law enforcement agencies
29User Interface and User Evaluations
- User Interface (GUI)
- Robust, easy-to-use and intuitive
- Categorizes information for better organization
of the information - Object-oriented (modular, easily enhanced),
portable and web-based Java - User Evaluations
- Conduct thorough user testing
- Study the technological impact on users
30Distributed COPLINK Background
- Goal Develop a prototype system to allow
multiple agencies with similar implementations of
COPLINK to share information - Communication between physically separated
databases
31Distributed COPLINK Status
- The distributed COPLINK system has been shown to
be feasible - Has been tested on three COPLINK nodes using
different versions of data sets from TPD - Future Test between Tucson and Phoenix
32COPLINK Components
COPLINK Concept Space Application
COPLINK Database Application
- GUI - GUI - User Evaluations - User
Evaluations - Distributed Application -
Distributed Application
33Next Presentation
34COPLINK Database Design Presentation
- Harsh Gupta
- Research Assistant
- October 20, 1999
35Agenda
- Overview of Application Architecture
- Design Improvements
- Performance and Stress Testing
36Search Sequence
37Three Tier Architecture
Listener Dispatcher
Server Processes
Server Processes
Java URL Classes
PL/SQL Cartridges
.
.
PL/SQL Cartridges
PL/SQL Cartridges
PL/SQL Cartridges
.
Connection to DB
Connection to DB
Query Results
Requests
Database
Summary Views
38Three Tier Architecture
- Front End User Interface
- JAVA Platform independent!
- Web Based Thin Client
- Set of screens based on five search categories
- Formats the information in a very intuitive/user
friendly fashion
39Three Tier Architecture
- Middleware Oracle Application Server (OAS)
- Supports multi-platforms
- Can work with non-Oracle Databases
- Responsible for
- Communication between interface and database
- Query distribution
- Load balancing
40Three Tier Architecture
- Back-End Database
- Oracle 8 Server
- Back-End consists of data maintained in clusters,
tables, indicies and views - Stored Procedures (handle application queries)
41Scalability
Clients
Middleware
Databases
42Portability
Stored Procedures
Stored procedures work on views
Views
Views
Views
Standard views remain same
Tables
Tables
Underlying tables can be mapped to standard views
Tables
Tables
Tables
43Initial Testing Problems
- Long wait for some queries
- Various reasons including
- Front-End Undesired timeout
- Middleware Multiple connections
for the same query - Back-End Needs more optimization
44Design Improvements
- Redesigned front end Java connection classes
- Upgraded the current version of OAS from 3.0 to
4.0 and Reconfigured - Backend Design Modified
- Logical and Physical Database structure
- Oracle Instance re-configuration
- Query Analysis
45Logical design changes
Regular Tables data access time consuming
Person Based Queries
Incident Based Queries
46 Logical design changes
Clustered Tables Faster access to data
Person Based Queries
Incident Based Queries
Initial Query
BUFFER
Subsequent queries from Buffer
Incident Cluster
Person Cluster
47Oracle Instance re-configuration Larger Buffer!
Instance
System Global Area (SGA)
Shared Pool
Library Cache
Redo log buffer
Database Buffer Cache
Data Dictionary Cache
48Stress Testing Overview
- Determining a baseline (benchmark) for existing
system - Test system under different controlled conditions
- Track performance behavior
- Information to be used for further tuning
49Stress Testing Components
- Automatic Test Generator
- Can create any number of test queries
- Multi-threaded Java User Application
- Simulates users querying the database
- Can simulate to any number of users constantly
making queries
50Stress Testing Results
- 150 simultaneous users testing
- Testing up to 4 to 6 times actual number of users
- No wait time between queries
- Significant stress on OAS proved very stable
- Back-End Complete Performance check
- Remarkable decrease in query response time!
51Thanks!
52Next Presentation
53COPLINKConcept Space
- Harsh Gupta
- Research Assistant
- October 20, 1999
54COPLINK Concept Space
- Analysis Tool
- Provides associations between search terms
- More specific users investigators, detectives,
analysts - With COPLINK Database Application it makes a more
powerful and complete solution
55Search Sequence
Enter one or more search terms
Get associations between terms
Add/Delete terms for further analysis
Get detailed information on term(s)
Get more associations!
56Architecture
Java URL Classes
Query Results
Summary Views
57Database Design
- Relevant information extracted from Coplink
database - Comparatively fewer tables 4-5
- Contains
- Key words
- Associations
- Stored Procedures
58Database Creation Process
Loaded in Oracle tables
COPLINK Database
Output flat file
Processing Associations
Extracted information as flat files
59Future Integration
Common Interface
60Thanks!
61Next Presentation
62COPLINK
Tucson Police Department
The University of Arizona
Integrating Law Enforcement Databases In a Secure
Web-Based Intranet
63COPLINK Database User Evaluation
- Rosie Hauck
- Research Associate
- Artificial Intelligence Lab
64User Centered Design Model for COPLINK
Implementation
Task Analysis/ Functional Analysis
Prototyping
Evaluation
Requirements specification
Conceptual design/ Formal design
65Purpose of Research Study
- Conduct a evaluation of the COPLINK DB
- Looking at aspects of usability
- Use feedback to continue the development efforts
- Compare to current TPD systems
- RMS
- ELVIS (Mug shot DB)
- Gangs
66Research Strategy
- Experimental Design
- Comparison between RMS and COPLINK DB
- Want real work to evaluate
- Data Collection
Quantitative and Qualitative - Questionnaires
- In-Depth Interviews
- Direct observation
67Participants
- 52 Law Enforcement Personnel
- Job classifications
- Sergeants 13
- Detectives 50
- Crime analysts 13
- Patrol Officers 24
- Police units
- Homicide, Adult Sex Assault, Aggravated Assault,
Auto Theft, Robbery, Burglary, Gangs, Patrol,
General Crime - Comfort level with computers
- Very comfortable 10 , Comfortable 48, Neither
30, Uncomfortable 10, Very uncomfortable 2
68Data Collection
- Demographic information
- RMS questionnaire on perceived usability
- COPLINK DB
- Introduction/Training
- Trials (at least 2 searches)
- COPLINK Questionnaire
- Final interview
69Results
- Usability Questionnaire
- Comparison between RMS and COPLINK DB
- Statistical analysis
- Interviews
- Finding general themes
- Suggestions for further system development
70Defining usability
- Effectiveness
- Impact on Job Performance Productivity
- Accuracy of system
- Effectiveness of information
- Ease of Use
- Effort to use system to learn
- Navigation through the system
- Efficiency
- Interface design
- Speed
- Ability to find info and info organization
71Questionnaire ResultsEfficiency
Scale 1 Strongly disagree 5 Strongly
agree
Statistically different (p lt 0.00)
72Questionnaire ResultsEase of Use
Scale 1 Strongly disagree 5 Strongly
agree
Statistically different (p lt 0.00)
73Questionnaire ResultsEffectiveness
Scale 1 Strongly disagree 5 Strongly
agree
Statistically different (p lt 0.00)
74Interview Results
- Participants asked to
- Comment on the COPLINK DB system
- Compare RMS to COPLINK DB
- General Themes
- Speed
- Ease of use
- Interface
- Information
75Interview Theme Speed
- 100 quicker
- Speed is the main strength
- Lead to more work efficiencies
- Saves time
- Get information quicker
76Interview Theme Ease of Use
- Easier to read/search
- User-friendly
- A lot easier to use
- I could use it without training
77Interview Theme Interface
- Get bulk of information on one screen
- Less steps to get information
- Flexible to organize sort
- I like colors
- Navigation is easier
78Interview Theme Information
- A lot more information than RMS
- Enter less information, the more you get
- More effective and efficient
- Interlink between information
- Ties information together
79Interesting notes
- Notion of increased information
- More an issue of ability to access information in
usable form - Ability for all participants to use COPLINK
- COPLINK on the street - A different perspective
- At substations
- Identification purposes
80Conclusions
- Results of study
- Support the design and functionality incorporated
into COPLINK DB - Shows the strengths of the system
- From an end user point of view
- As compared to currently available TPD systems
- Generate interest in COPLINK system
81Future Directions
- Development of deployment plan
- Training issues
- Hardware requirements
- Emphasis on stress testing
- Refining functionality and design
82COPLINK Concept Space Revisited
83Results Qualitative Investigative Tasks
- Strengths
- Linking known information
- Finding associations with unknown information
- Summary information/quick picture
- Problem area
- Not a records management system
84Results Qualitative Interface
- Strengths
- Organization and efficiency
- Less cognitive/memory overload
- Speed getting hits and mistakes less crucial
- Problem areas
- Entry format
- Misunderstandings of output
- Incomplete returns
- Updating data
85Current Direction
- Modification of Interface
- Three-Phase Evaluation Plan
- Phase I - Internal usability and info
verification - Phase II - User evaluation sessions
- Phase III.A - Stress-testing (simulation)
- Phase III.B - Limited deployment testing
- Looking towards integration with the DB system
86 87Next Presentation
88Coplink Refresh Strategy
- Shantel Ekman
- Emily Werner
- October 20, 1999
89Material to be Covered
- Background Information
- Previous Database Setup
- Problems
- The Refresh Solution
90Background Information
- Combination of TPDs
- Record Management System (RMS)
- Gang Database and
- Elvis system (mugshots)
- Small set of denormalized tables from the three
databases - Refresh involves only the Record Management System
91Bulk Load
- A bulk load is a loading process in which the
data is loaded all at one point and then remains
static until reloaded.
92Bulk Load
- Copy RMS data
- Run a series of scripts containing PL/SQL Blocks
- Information is populated to Coplink tables
- Result Static Coplink database
93Bulk Load Diagram
Coplink Tables
Copy of RMS tables
DATA
PL/SQL Blocks
DATA
DATA
DATA
DATA
DATA
DATA
94Bulk Load Problems
Once loaded the data was static
- Usefulness
- Reliability
- Reload strains
95Additional Problem
- RMS maintains its database relationships using a
set of twelve random characters - Oracle Web Application Server would have problems
with some of the characters in these sets
96Refresh Strategy
- To allow the system to be refreshed more
frequently, the back-end database had to be
redesigned. This is referred to as the Refresh
Strategy.
97Base Design Elements
- Source Table
- Triggers
- Snapshots
- Stored PL/SQL procedures
98Source Table
- Gateway to record where data came from and when
it entered the system - Developed in response to Character key problems
- Provides for a global primary key
- Tracking of data back to original source
99Source Table Example
- All primary keys are directly loaded into the
Source table
100Source Table Use
Original Table
Source
Originalpk
Originalpk
Coplinkpk
DATA
Internal Coplink Table
Coplinkpk
DATA
101Triggers
- Triggers are a form of stored PL/SQL code that is
implicitly fired (executed) by Oracle when a
triggering event occurs, no matter which user is
connected or which application is being used.
102Using Triggers
- Automatically populate the change from one table
to another table - Done when an insert, update or delete occurs
- Controlled by Oracle and becomes part of the
transaction
103Trigger Example
RMS Tables
TRIGGER
Primary Key
DATA
Primary Key Procedure Insert Procedure Update
Procedure Delete Procedure
Coplink Tables
New Primary Key
DATA
104Problem
- Since a trigger is considered part of the
transaction - And the trigger would have to fire over a network
connection - If the network connection fails, the transaction
would fail to be processed on the RMS system
105Snapshots
- A snapshot is a local copy of table data
originating from one or more remote master
tables. An application can query the data in a
snapshot, but cannot insert, update, or delete
rows in the snapshot.
106Using Snapshots
- Maintain a separate copy of the RMS tables that
are used - Oracle would update the copy through snapshot
refresh - Solves the problem of losing data as the result
of network failure
107Snapshot Diagram
RMS Tables
Snapshot of RMS Tables
Primary Key
Primary Key
DATA
DATA
TRIGGER
Coplink Tables
New Primary Key
DATA
108Problems
- Oracle currently does not support the application
of triggers on snapshots - Structure was maintained
- For future use when Oracle does support triggers
on Snapshots - Still good design for the system
109Snapshot Procedures(Stored PL/SQL Procedures)
- A group of procedures were written to simulate
the idea of a snapshot system so that triggers
could be used. These procedures are referred to
as Snapshot Procedures.
110Purpose of procedures
- Execution of procedures would
- Fetch a list of changes made to the targeted RMS
tables. - Perform the changes to Snapshot copies
- Delete the changed item from the list
111Additional Objects
- There is a need to collect the RMS table changes.
- Local triggers on the RMS tables
- Snapshot log to store changes
T3
T2
T1
Trigger
T4
T5
Trigger
Trigger
LOG
112Complete Refresh System
Coplink DB
TPDs RMS
Source
Snapshot Procedure
T2
T3
T1
Snapshot Table
Trigger
Snapshot Table
Snapshot Table
LOG
113Complete Refresh Strategy
Coplink DB
Source
Trigger
Snapshot Table
Coplink Table
Snapshot Table
Coplink Table
Snapshot Table
Coplink Table
114Benefits of Refresh Strategy
- More frequent updates
- Primary key problems solved
- Procedure can be placed in a queue or run when
necessary - Incoming data can be tracked
- Minimal hit on TPDs RMS, most processing on
Coplink machine
115Summary
- Previous system of bulk loading
- Problems
- Refresh solution
116Questions?
117Next Presentation
118Internet Spiders
- David Hendriawan
- (Spider Group)
- October 20, 1999
119Agenda
- Internet Spiders Overview
- Demonstration
- Competitive Intelligence (CI) Spider
- Meta Spider
- Future Directions
- COPLINK Self-Organizing Map
120What are Internet Spiders?
- Internet Spiders are small programs that crawl
the web, jumping from one page to another by
following Internet hyperlinks, to gather specific
information.
Starting URL
Level 1
Level 2
121Overall Architecture
122Demonstration
123Future Directions
- Use of database or Intranet as the search space
- Constant monitoring of web sites
- Collaborative spiders for information sharing
124COPLINK Self-Organizing Map
- Key Components
- Limit to a subset of documents
- Select output terms (crime type, person,
location, etc.) - Color (serious, liquor, traffic, less serious)
- COPLINK SOM Demo
125Next Presentation
126Distributed Coplink
127Project Goals
- To allow multiple agencies with similar
implementations of Coplink to share information
between each agency - DBMS platform independence
128Description
- An expanded distributed system of multiple
Coplink nodes includes a distributed version of
the Coplink system, a modified set of queries
that automatically query multiple Coplink nodes,
and the underlying system architecture to support
a distributed database system.
129Description
Single Node Coplink Three-Tier Architecture
Java URL Classes
Query Results
Summary Views
130Description
High Level Conceptual Diagram
Local Application Server
Sends Query Requests to
1
1
Client
1
Executes Stored Procedure in
1
Local Node Node
1
Queries Data From
Local Coplink Node
1
Queries Data From
Local Coplink Schema
1
Note The Node Manager and Coplink Schema
objects are part of a Coplink Node Instance
1..
Remote Coplink Schema
Remote Coplink Node(s)
131Description
Distributed Coplink Three-Tier Architecture
(LOCAL)
(REMOTE)
Client
Client
Remote OAS
Local OAS
REMOTE Coplink Server Node
LOCAL Coplink Server Node
Coplink
Node
Coplink
Node
Schema
Schema
Manager
Manager
132Technology
Networking Layers and Protocols
133Technology
- Oracle application server
- Highly scalable, supports redirection
- Oracle enterprise database server
- PL/SQL (dynamic), security
- Java
- Networking
- Three-tier architecture
- Scalable in number of nodes
134Current Status
- Prototype
- Fundamental infrastructure complete
- Four distributed procedures
- Number of nodes/servers used for prototype
system 2 - Development and testing within secure LAN