Loading in 5 sec....

Polaris Query, Analysis, and Visualization of Large Hierarchical Relational DatabasesPowerPoint Presentation

Polaris Query, Analysis, and Visualization of Large Hierarchical Relational Databases

Download Presentation

Polaris Query, Analysis, and Visualization of Large Hierarchical Relational Databases

Loading in 2 Seconds...

- 72 Views
- Uploaded on
- Presentation posted in: General

Polaris Query, Analysis, and Visualization of Large Hierarchical Relational Databases

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

PolarisQuery, Analysis, and Visualization of Large Hierarchical Relational Databases

Pat Hanrahan

With Chris Stolte and Diane Tang

Computer Science Department

Stanford University

- Large databases have become very common
- Corporate data warehouses
- Amazon, Walmart,…

- Scientific projects:
- Human Genome Project
- Sloan Digital Sky Survey

- Corporate data warehouses
- Need tools to extract meaning from these databases

- Formalisms for graphics
- Bertin’s “Semiology of Graphics”
- Mackinlay’s APT
- Roth et al.’s Sage and SageBrush
- Wilkinson’s “Grammar of Graphics”

- Visual exploration of databases
- DeVise
- DataSplash/Tioga-2

- Visualization and data mining
- SGI’s MineSet
- IBM’s Diamond

Formalism

- UI interpreted as visual specification that defines:
- Table configuration
- Type of graphic in each pane
- Encoding of data as visual properties of marks
- Data transformations and queries

Market

State

Year

Quarter

Month

Product Type

Product

Profit

Sales

Payroll

Marketing

Inventory

Margin

COGS

...

Ordinal fields

(categorical)

Coffee chain data[Visual Insights]

Quantitative fields

(measures)

Principle of Importance Ordering: Encode the most important

information in the most effective way [Cleveland & McGill]

- Common interface to statistical packages/Excel
- Cross-tabulations

- Simple interface based on drag-and-drop

- Structure relation as n-dimensional cube

Each cell aggregatesall measures for those dimensions

Each cube axis

corresponds to a dimension

in the relation

- Ordinal fields: interpret domain as a set that partitions table into rows and columns:
- Quarter = {(Qtr1),(Qtr2),(Qtr3),(Qtr4)}
- Quantitative fields: treat domain as single element set and encode spatially as axes:
- Profit = {(Profit)}

- Ordered union of two sets
- Quarter + ProductType
- = {(Qtr1),(Qtr2),(Qtr3),(Qtr4)}+{(Coffee),(Espresso)}
- = {(Qtr1),(Qtr2),(Qtr3),(Qtr4),(Coffee),(Espresso)}
- Profit + Sales
- = {(Profit),(Sales)}

- Direct-product of two sets
- Quarter ProductType =
- {(Qtr1,Coffee), (Qtr1, Tea), (Qtr2, Coffee), (Qtr2, Tea),
- (Qtr3, Coffee), (Qtr3, Tea), (Qtr4, Coffee), (Qtr4,Tea)}
- ProductType Profit =

- Notes
- Aggregation operators applied after sort
- Only one layer is shown; additional z-sort

Sort

Relational Table

Tuples in Panes

Marks in Panes

Multiscale Visualization

- Challenge: these databases are very large
- Queries/Vis should not require all the records

- Augment database with hierarchical structure
- Provide meaningful levels of abstraction
- Derived from domain or clustering
- Provides metadata (missing data for context)

- Each dimension in the cube is structured as a tree
- Each level in tree corresponds to level of detail

Existence Table

Fact table

Location

Market

State

State

Month

Product

Profit

Sales

Payroll

Marketing

Inventory

Margin

...

Time

Year

Quarter

Month

Products

Product Type

Product Name

Measures

- Generalizations
- Snowflake schemas
- Lattices (DAGs)

- Quarter Month
- Direct product of two sets
- Would create twelve entries for each quarter, i.e. (Qtr1, December)

- Quarter / Month
- Based on tuples in database not semantics
- Would only create three entries per quarter
- Can be expensive to compute

- Quarter . Month
- Based on tuples in existence tables (not db)

Canterbury and East Kent

1:50,000

1:625,000

- Selection
- Simplification
- Exaggeration
- Regularization
- Displacement
- Aggregation

- Polaris
- Spreadsheet or table-based displays
- Simple drag-and-drop interface
- Built on a formalism that allows algebraic manipulation of visual mapping of tuples to marks
- Multiscale visualizations using data and visual abstraction
- Connects to SQL/MDX servers

- Seehttp://www.graphics.stanford.edu/projects/polaris

- Articulate full-set of multiscale design patterns
- Transition between levels of detail
- Develop system infrastructure for browsing VLDB
- Support layers/lenses/linking with tuple flow
- Device independence through graphical encodings
- Extend formalism to 3D
- Couple scientific and information visualization
- …