Accessing the Data Warehouse

Introduction
Purpose of building a DW
To provide user access to a set of data

Requires Tools Aim

Aid the readers to understand accessing DW and the major issues associated with it

Choosing an access tool

Golden rules
Never design the DW to suit a specific tool Make no assumptions about the type of tool that will be used

DW must be designed for

Efficiency of query access Ease of management

Types of Tool
Data dipping
Basic business tools Generates standard business reports

Data mining
Specialist tools designed for finding trends and patterns

Data analysis
Performs complex analysis of data

Data dipping tools

Perform basic analysis Answers standard business questions
What were the sales last month? How many new customers joined last month?

Have reasonable drill-down capabilities Use meta data to present a business friendly schema to the user

Data mining tools

Use techniques like AI and NN Identifies common behavioral trends
Customer buying pattern, customer groups to root out market segmentss

Users of this tool

Analyst who have good knowledge of the business data

Data analysis tools

Performs sophisticated analysis Understand common business metrics
Market share, profitability

Types
ROLAP
Traditional SQL-oriented tools that have tight integration to the relational model

MOLAP
Tools that use matrix arithmetic and sparse matrix optimization

Multidimensional analysis
Data can be analyzed in many dimensions Advantage of MD tools
Fast on predefined set of data Operations like time series analysis, top-ten and bottom-ten selection are faster Dimensional slicing is good

Disadvantages
Loading the cube is very slow

Analyzing the user query requirements

Key step in the analysis stage To understand ad-hoc queries
Understand the user requirements well before the design of DW

To understand users requirement

gain a general understanding of all aspects of the business Key periods, Business dates, business times, meaningful levels of data, and important summary fields

Key periods
Important reporting and financial periods Does your business require short term analysis or long term

Key business dates

Need to be documented Set of holidays, Start of companys business year, Start of the local tax year

Business times
Business week day working hours, Weekend working practices, Starting day of business week

Capture all the time, period and business date information as they crucially affect the DW design Period information must be captured by department, group and many other organizational divisions

Meaningful level of data

How much detailed information is required on each key dimension? What level of details does data need to go?

Document the answers Get the level of detail at which data must be stored correct If this decision is made incorrectly the DW will need to be completely reorganized Having understood all these details will
Round out the query requirements Query sort estimates can be calculated

Query categories
Batch reports
Well understood requirements Run offline and scheduled around any daily access and overnight process

Canned queries
Predefined queries Run online Data set size they access vary

Ad hoc queries
Unpredictable elements DW must run any query when desired and expect a reasonable response

Designing to the query requirements

To make a DW to be query efficient even for ad hoc access
Star schemas Denormalization Query parallelism Data partitioning

Avoiding inefficient queries

To avoid query occupying the entire resource and that runs for ever
Use profiles
Limits the amount of resource a user process can use If the limit exits stop processing the query DISADV: can be build only after wasting lot of resource

Queuing of queries
All queries must be submitted via query manger Degree of parallelism increases Other resources of the query can be controlled