# Presentation: 318177

## VIEWS

**VIEWS**

- The

- Backend Information System

**V****isibility**** I****nformation**** E****xchange**** W****eb**** S****ystem**

- A look behind the scenes of the

## Import

- Source Data

- Source Data

- Source Data

- Validation

- Database
- Rules

- Program
- Logic

- Storage

- Retrieval

- Presentation

- Analysis

- Interpretation

- Transformation

- Information System

- Requirements of the

- Back End

- Front End

_**Import:**_  Getting the data into the system

_**Validation:**_  Ensuring data accuracy

_**Storage:**_  Managing the data, backup, archival

_**Transformation:**_  Sorting, joining, aggregating

_**Retrieval:**_  Getting the data out

_**Presentation:**_  Displaying the data

_**Analysis:**_  Making the data understandable

_**Interpretation:**_  Making the data usable

- Evaluating 

## Evaluating the existing architecture...

|  |
| --- |
|  |
|  |
|  |
|  |
|  |

- Represents data in a way easily dealt with by _people_

- Database organization resembles a _**star**_

_**Strengths:**_
-   Easier to understand and access by direct users
-   Queries are simplified and tend to be faster
-   _**Ideal for front-end functions**_

_**Weaknesses:**_
-   Harder to manipulate programmatically
-   Harder to import, validate, and transform data
-   _**Cumbersome for back-end functions**_

-   Supporting _Dimension_ tables
-   Contain metadata and other support data
-   Networks, Sites, Parameters, Methods, Time

- Intentionally “flat”  one level of relationships
- Redundant data and redundant relationships
- Decision Support System (DSS) design

-   Central _Fact_ table
-   Contains actual air observation values
-   Maintains links to all dimension tables

- Networks

- Sites

- Parameters

- Methods

- Time

- Air_Obs

- Options 

## Assessing the options...

_**Leverage the Existing Architecture**_

- _Pros:_
-   Less up-front time and effort
-   Reuses the existing design

- _Cons:_
-   Not easily scalable
-   Programmatic manipulation is harder
-   Doesn’t address back-end functions

_**Extend and Enhance the Existing Architecture**_

- _Pros:_
-   Realizes more back-end functions
-   Still involves only one database design

- _Cons:_
-   A specialized, unconventional design
-   Harder to understand, maintain, & scale

_**Implement a Separate Architecture for Back-end Support**_

- _Pros:_
-   Full Support of back-end functions
-   Machine-friendly, easier to automate
-   Allows both designs to be optimized
-   Keeps logical operations separate
-   Long-term scalability and flexibility

- _Cons:_
-   Requires greater initial development effort
-   Two distinct architectures to maintain *****

** Not Really ****  stay tuned...*

- Analyzing 

## Analyzing the problem...

- geographical locations, with particular instruments, on
- specific dates and at given times, which are then analyzed,
- recorded, and disseminated as data.

-   What _sentence_ best describes the _data_ and _data flows_ of the system?

-   What is the “common currency” of the system ?
-   The Sample

-   What is the “primary mediator” of the system ?
-   The Instrument

-   What are the “entities” of the system ?
- Locations (Sites), Parameters, Methods, Date/Time

-   What are the “primary actions” of the system ?
-   Analyzing, Recording

- Implementing 

## Implementing a solution...

- Represents data in a way easily dealt with by _machines_

- The _Online Transaction Processing System  (__OLTP__) ..._

-   Technical Characteristics
-   Fully _relational_ and completely _normalized_
-   Optimized for insert, update, and delete
-   Allows more efficient indexing
-   Larger number of tables and relationships
-   Automatically enforces referential integrity

-   Description and Functional Characteristics
-   Facilitates _importing_ data into the system
-   Promotes data integrity and facilitates _validation_
-   Makes _storage_ more efficient
-   Speeds and simplifies _transformation_

-   Additional Benefits and Considerations
*  *_Scalability_:  Will handle more data and users without changing the design
-   _Interoperability_:  Interacts more easily with other systems and datasets
-   _Maintenance_:  Facilitates modification, upgrade, and enhancement
-   _Security_:  Facilitates backup, recovery, archival, and integrity

- Leveraging 

## Leveraging the benefits...

- The front-end _DSS_ is automatically generated by the back-end _OLTP_

-   Final Notes
*  *_Map Projection Analogy:_  Base system (globe) and derived views (projections)
-   _Optimization_:  Allows each architecture to do _what it does best_ without compromise
-   _Data Transparency_:  User doesn’t need to know how data is stored, only how to use it
-   _Exchangeability_:  A wide variety of diverse schemas can be generated from OLTP

|  |
| --- |
|  |
|  |
|  |
|  |
|  |

- Networks

- Sites

- Parameters

- Methods

- Time

- Air_Obs

- SQL Script

- Front End

- Back End

- _Generation of the Front End__:_
-   Periodically
-   On Demand

- Future 

## Looking to the future...

-   Fully automate data import and validation
-   Provide data products as _web services_ for users, models, and programs
-   Reduce the need for local data storage and maintenance
-   Promote the free exchange of data and ideas
-   Provide enhanced metadata browsing
-   Facilitate GIS integration
-   Provide presentation-ready data products
-   _Facilitate RPO support of the Regional Haze Rule_

*Thank you for your attention...*