We've begun to get enough inquiries about how we are building sentencing support tools that it seemed time to share this information. As of March, 2001, here is a description of how we are doing what we are doing:
There are essentially three levels to the approach which we use; I believe all knowledgeable in the field agree that for the present, this is the only practical approach.
Level one is the data collected through the operation of the courts, law enforcement, corrections, and any other treatment or correctional or investigative activities that may reflect a) characteristics of offenders that may be significant in predicting which offenders are most likely to respond to which interventions; b) the criminal histories of defendants (which may be merely convictions, but may extend to police and parole/probation contacts -- for example, we're including domestic violence arrests for some uses); c) the correction and supervision histories and behaviors of defendants; or d) any other activities that might be related to criminal behavior. Critical here is that we are not creating new databases or expending energy to collect data just to serve the needs of analysis. In the long run, exploiting the data may have some implications for improving the accuracy and refining operational data collection, but does not contemplate separate acquisition of data -- is relies on operational data.
Level two is the "data warehouse," that collects in a unified form that portion of data extracted from the operational databases which is necessary to support the kinds of analyses we want to perform. Software of a variety of types performs extraction, transmission and transformation functions to gather the data we need from operational sources, transmit it to the warehouse, and translate it so that it has consistent meanings when considered in conjunction with all the other data resident in the warehouse. Our warehouse is designed to updated nightly; many data warehouses in business applications are updated weekly, some less often. That data warehouse data is not "real time" is a major distinction between operational data and data warehouse data; the lag might be significant, for example, in making a release decision, but is not a problem for the sort of correlations we're looking for in sentencing support. Data warehouse "architecture" determines the structures in which data is arranged in the warehouse; essentially, the data is arranged to make expected queries as fast as possible -- present levels of processing and transmission speeds make constructing all analyses anew for each query impractical. For example, when I see how similar defendants have performed after being sent to theft talk, a properly structured warehouse has already arranged data on what I might mean by "similar" so that it doesn't have to figure that out each time I run the query.
Level three is the query and data exhibition level -- the tools that routinize the routine queries that make up the uses you see in the sample screen shots and display the results in a meaningful way.
The great thing about modern data warehouse technology
is that it is able to work with databases in level one even when they are
running different software on different platforms - data warehouse technology
is a work-around for our persistent inability to achieve data integration,
and it means that we don't have to discard data sources just because we
can't afford the time or money to upgrade hardware and software and battle
out agreements about which to use for what.
Level two is performed by software designed for extraction/transfer/transformation operations. It is tremendously meticulous work to tell the software how to perform the transformation (translation) process. It requires technical people who become intimately familiar with the data in source databases, and who are also fluent in the architecture and design of the warehouse to which the data is transferred.
Level three starts with off the shelf software as well. OLAP and ROLAP (on-line and relational on-line analytical processing) tools are highly developed and competitive; statistical display functions are likewise heavily supported - with cubes, graphs, and bells and whistles in all colors (literally). Our technicians write quite a bit of custom code to perform the sentencing support functions, because off the sheft tools simply weren't flexible enough for our purposes.
Our technical project head, Gail McKeel, has provided historical background and more technical and practical details of DSS-Justice generally on the Multnomah County ISD site; more information is on the Local Public Safety Coordinating Council page on "DSS-J", and a paper by Suzanne Riles delivered to the 2000 Annual Meeting of the American Evaluation Association in Honolulu, Hawaii, describes the capacity of this data warehouse for evaluation, including and illustrating the place of Sentencing Support within DSS-Justice. (return with your browser's "back" button)