U4 F 3 B 59 D 1 A 85 CC

Data Warehouse Concepts
Avinash Kanumuru Diya Jana Debyajit Majumder
2009 Wipro Ltd - Confidential
Content
1 An Overview of Data Warehouse 2 Data Warehouse Architecture 3 Data Modeling for Data Warehouse 4 Overview of Data Cleansing
5 Data Extraction,Transformation, Load
2009 Wipro Ltd - Confidential 2009 Wipro Ltd - Confidential
Content
Content [contd]
6 Metadata Management 7 OLAP 8 Data Warehouse Testing
An Overview
Understanding What is a Data Warehouse
10
What is Data Warehouse?

Definitions of Data Warehouse A data warehouse is a subject-oriented, integrated, nonvolatile, time-variant collection of data in support of management's decisions. WH Inmon Data Warehouse is a repository of data summarized or aggregated in simplified form from operational systems. End user orientated data access and reporting tools let user get at the data for decision support Babcock A data warehouse is a relational database a copy of transaction data specifically structured for query and analysis Ralph Kimball In simple: Data warehousing is collection of data from different systems, which helps in Business Decisions, Analysis and Reporting.
11
Data Warehouse def. by WH Inmon

A common way of introducing data warehousing is to refer to the characteristics of a data warehouse as set forth by William Inmon: Subject Oriented Data that gives information about a particular subject instead of about a company's ongoing operations. Integrated Data that is gathered into the data warehouse from a variety of sources and merged into a coherent whole. Nonvolatile Data is stable in a data warehouse. More data is added but data is never removed. This enables management to gain a consistent picture of the business. Time Variant In order to discover trends in business, analysts need large amounts of data. This is very much in contrast to online transaction processing (OLTP) systems, where performance requirements demand that historical data be moved to an archive. All data in the data warehouse is identified with a particular time period.
12
Data Warehouse Architecture

What makes a Data Warehouse
13
Components of Warehouse
Source Tables: These are real-time, volatile data in relational databases for transaction processing (OLTP). These can be any relational databases or flat files. ETL Tools: To extract, cleansing, transform (aggregates, joins) and load the data from sources to target. Maintenance and Administration Tools: To authorize and monitor access to the data, set-up users. Scheduling jobs to run on offshore periods. Modeling Tools: Used for data warehouse design for high-performance using dimensional data modeling technique, mapping the source and target files. Databases: Target databases and data marts, which are part of data warehouse. These are structured for analysis and reporting purposes. End-user tools for analysis and reporting: get the reports and analyze the data from target tables. Different types of Querying, Data Mining, OLAP tools are used for this purpose.
14

This is a basic design, where there are source files, which are loaded to a warehouse and users query the data for different purposes.
This has a staging area, where the data after cleansing, transforming is loaded and tested here. Later is directly loaded to the target database/warehouse. Which is divided to data marts and can be accessed by different users for their reporting and analyzing purposes.
15
16

17
Data Modeling
Effective way of using a Data Warehouse
18
Data Modeling
Commonly E-R Data Model is used in OLTP, In OLAP Dimensional Data Model is used commonly. E-R (Entity-Relationship) Data Model
Entity: Object that can be observed and classified based on its properties and characteristics. Like employee, book, student Relationship: relating entities to other entities.
Different Perceptive of Data Modeling.

o Conceptual Data Model o Logical Data Model o Physical Data Model
Types of Dimensional Data Models most commonly used:

o Star Schema o Snowflake Schema
19
Terms used in Dimensional Data Model

To understand dimensional data modeling, let's define some of the terms commonly used in this type of modeling: Dimension: A category of information. For example, the time dimension. Attribute: A unique level within a dimension. For example, Month is an attribute in the Time Dimension. Hierarchy: The specification of levels that represents relationship between different attributes within a dimension. For example, one possible hierarchy in the Time dimension is Year Quarter Month Day. Fact Table: A table that contains the measures of interest. Lookup Table: It provides the detailed information about the attributes. For example, the lookup table for the Quarter attribute would include a list of all of the quarters available in the data warehouse. Surrogate Keys: To avoid the data integrity, surrogate keys are used. They are helpful for Slow Changing Dimensions and act as index/primary keys.
A dimensional model includes fact tables and lookup tables. Fact tables connect to one or more lookup tables, but fact tables do not have direct relationships to one another. Dimensions and hierarchies are represented by lookup tables. Attributes are the non-key columns in the lookup tables.
20

21
Data Modeling
Commonly E-R Data Model is used in OLTP, In OLAP Dimensional Data Model is used commonly. E-R (Entity-Relationship) Data Model
Entity: Object that can be observed and classified based on its properties and characteristics. Like employee, book, student Relationship: relating entities to other entities.
Different Perceptive of Data Modeling.

o Conceptual Data Model o Logical Data Model o Physical Data Model
Types of Dimensional Data Models most commonly used:

o Star Schema o Snowflake Schema
22
Terms used in Dimensional Data Model

To understand dimensional data modeling, let's define some of the terms commonly used in this type of modeling: Dimension: A category of information. For example, the time dimension. Attribute: A unique level within a dimension. For example, Month is an attribute in the Time Dimension. Hierarchy: The specification of levels that represents relationship between different attributes within a dimension. For example, one possible hierarchy in the Time dimension is Year Quarter Month Day. Fact Table: A table that contains the measures of interest. Lookup Table: It provides the detailed information about the attributes. For example, the lookup table for the Quarter attribute would include a list of all of the quarters available in the data warehouse. Surrogate Keys: To avoid the data integrity, surrogate keys are used. They are helpful for Slow Changing Dimensions and act as index/primary keys.
A dimensional model includes fact tables and lookup tables. Fact tables connect to one or more lookup tables, but fact tables do not have direct relationships to one another. Dimensions and hierarchies are represented by lookup tables. Attributes are the non-key columns in the lookup tables.
23
Star Schema
Dimension Table
product prodId p1 p2 name price bolt 10 nut 5
Dimension Table
store storeId c1 c2 c3 city nyc sfo la
Fact Table
sale oderId date o100 1/7/97 o102 2/7/97 105 3/8/97 custId 53 53 111 prodId p1 p2 p1 storeId c1 c1 c3 qty 1 2 5 amt 12 11 50
Dimension Table
customer custId 53 81 111 name joe fred sally address 10 main 12 main 80 willow city sfo sfo la
24
Snowflake Schema
Dimension Table Fact Table
store storeId s5 s7 s9 cityId sfo sfo la tId t1 t2 t1 mgr joe fred nancy sType tId t1 t2 size small large location downtown suburbs regId north south
Dimension Table
city cityId pop sfo 1M la 5M
The star and snowflake schema are most commonly found in dimensional data warehouses and data marts where speed of data retrieval is more important than the efficiency of data manipulations. As such, the tables in these schema are not normalized much, and are frequently designed at a level of normalization short of third normal form.
25
region regId name north cold region south warm region
Overview of Data Cleansing
26
The Need For Data Quality

Difficulty in decision making Time delays in operation Organizational mistrust Data ownership conflicts Customer attrition Costs associated with error detection error rework customer service fixing customer problems
27
Six Steps To Data Quality

Understand Information Flow In Organization
y Identify authoritative data sources y Interview Employees & Customers y Data Entry Points y Cost of bad data
Identify Potential Problem Areas & Asses Impact
Measure Quality Of Data
y Use business rule discovery tools to identify data with
inconsistent, missing, incomplete, duplicate or incorrect values

y Use data cleansing tools to clean data at the source y Load only clean data into the data warehouse
Clean & Load Data
Continuous Monitoring
y Schedule Periodic Cleansing of Source Data
Identify Areas of Improvement
y Identify & Correct Cause of Defects y Refine data capture mechanisms at source y Educate users on importance of DQ
28
Data Quality Solution

Customized Programs Strengths: Addresses specific needs No bulky one time investment Limitations Tons of Custom programs in different environments are difficult to manage Minor alterations demand coding efforts Data Quality Assessment tools Strength Provide automated assessment Limitation No measure of data accuracy
29
Data Quality Solution

Business Rule Discovery tools Strengths Detect Correlation in data values Can detect Patterns of behavior that indicate fraud Limitations Not all variables can be discovered Some discovered rules might not be pertinent There may be performance problems with large files or with many fields. Data Reengineering & Cleansing tools Strengths Usually are integrated packages with cleansing features as Add-on Limitations Error prevention at source is usually absent The ETL tools have limited cleansing facilities
30
Tools In The Market

Business Rule Discovery Tools Integrity Data Reengineering Tool from Vality Technology Trillium Software System from Harte -Hanks Data Technologies Migration Architect from DB Star Data Reengineering & Cleansing Tools Carlton Pureview from Oracle ETI-Extract from Evolutionary Technologies PowerMart from Informatica Corp Sagent Data Mart from Sagent Technology Data Quality Assessment Tools Migration Architect, Evoke Axio from Evoke Software Wizrule from Wizsoft Name & Address Cleansing Tools Centrus Suite from Sagent I.d.centric from First Logic
31
Data Extraction, Transformation, Load
32
ETL Architecture
Visitors
Web Browsers
The Internet
External Data Demographics, Household, Webographics, Income
Staging Area
Web Server Logs & E-comm Transaction Data Flat Files Clean Transform Match Merge
Meta Data Repository
Scheduled Extraction
RDBMS
Scheduled Loading
Enterprise Data Warehouse
Other OLTP Systems
Data Collection
Data Extraction
Data Transformation
Data Loading
Data Storage & Integration
33
ETL Architecture
Data Extraction:
Rummages through a file or database Uses some criteria for selection Identifies qualified data and Transports the data over onto another file or database
Data transformation
Integrating dissimilar data types Changing codes Adding a time attribute Summarizing data Calculating derived values Renormalizing data
Data Extraction Cleanup

Restructuring of records or fields Removal of Operational-only data Supply of missing field values Data Integrity checks Data Consistency and Range checks, etc...
Data loading
Initial and incremental loading Updation of metadata
34
Why ETL ?
Companies have valuable data lying around throughout their networks that needs to be moved from one place to another. The data lies in all sorts of heterogeneous systems,and therefore in all sorts of formats. To solve the problem, companies use extract, transform and load (ETL) software. The data used in ETL processes can come from any source: a mainframe application, an ERP application, a CRM tool, a flat file, and an Excel spreadsheet.
35
Major components involved in ETL Processing
36
Major components involved in ETL Processing

Design manager Lets developers define source-to-target mappings, transformations, process flows, and jobs Meta data management Provides a repository to define, document, and manage information about the ETL design and runtime processes Extract The process of reading data from a database. Transform The process of converting the extracted data Load The process of writing the data into the target database. Transport services ETL tools use network and file protocols to move data between source and target systems and in-memory protocols to move data between ETL run-time components. Administration and operation ETL utilities let administrators schedule, run, monitor ETL jobs, log all events, manage errors, recover from failures, reconcile outputs with source systems

37
ETL Tools
Provides facility to specify a large number of transformation rules with a GUI Generate programs to transform data Handle multiple data sources Handle data redundancy Generate metadata as output Most tools exploit parallelism by running on multiple low-cost servers in multi-threaded environment ETL Tools - Second-Generation PowerCentre/Mart from Informatica Data Mart Solution from Sagent Technology DataStage from Ascential
38
Metadata Management
39
What Is Metadata?
Metadata is Information...

That describes the WHAT, WHEN, WHO, WHERE, HOW of the data warehouse About the data being captured and loaded into the Warehouse Documented in IT tools that improves both business and technical understanding of data and data-related processes
40
Importance Of Metadata
Locating Information Time spent in looking for information. How often information is found? What poor decisions were made based on the incomplete information? How much money was lost or earned as a result? Interpreting information How many times have businesses needed to rework or recall products? What impact does it have on the bottom line ? How many mistakes were due to misinterpretation of existing How much interpretation results form too much metadata? How much time is spent trying to determine if any of the metadata is accurate? Integrating information How various data perspectives connect together? How much time is spent trying to figure out that? How much does the inefficiency and lack of metadata affect decision making documentation?
41
Requirements for DW Metadata Management

Provide a simple catalogue of business metadata descriptions and views Document/manage metadata descriptions from an integrated development environment Enable DW users to identify and invoke pre-built queries against the data stores Design and enhance new data models and schemas for the data warehouse Capture data transformation rules between the operational and data warehousing databases Provide change impact analysis, and update across these technologies
42
Consumers of Metadata
Technical Users Warehouse administrator Application developer Business Users -Business metadata Meanings Definitions Business Rules Software Tools Used in DW life-cycle development Metadata requirements for each tool must be identified The tool-specific metadata should be analysed for inclusion in the enterprise metadata repository Previously captured metadata should be electronically transferred from the enterprise metadata repository to each individual tool
43
44
Trends in the Metadata Management Tools

Third Party Bridging Tools Oracle Exchange
Technology of choice for a long list of repository, enterprise and workgroup vendors
Reischmann-Informatik-Toolbus
Features include facilitation of selective bridging of metadata
Ardent Software/ Dovetail Software -Interplay

Hub and Spoke solution for enabling metadata interoperability Ardent focussing on own engagements, not selling it as independent product
Informix's Metadata Plug-ins

Available with Ardent Datastage version 3.6.2 free of cost for Erwin, Oracle Designer, Sybase Powerdesigner, Brio, Microstrategy
45

Metadata Repositories IBM, Oracle and Microsoft to offer free or near-free basic repository services Enable organisations to reuse metadata across technologies Integrate DB design, data transformation and BI tools from different vendors Multi-tool vendors taking a bridged or federated rather than integrated approach to sharing metadata Both IBM and Oracle have multiple repositories for different lines of products e.g., One for AD and one for DW, with bridges between them
46

Metadata Interchange Standards CDIF (CASE Data Interchange Format)
Most frequently used interchange standard Addresses only a limited subset of metadata artifacts
OMG (Object Management Group)-CWM

XML-addresses context and data meaning, not presentation Can enable exchange over the web employing industry standards for storing and sharing programming data Will allow sharing of UML and MOF objects b/w various development tools and repositories
MDC (Metadata Coalition)

Based on XML/UML standards Promoted by Microsoft Along With 20 partners including Object Management Group (OMG), Oracle Carleton Group, CA-PLATINUM Technology (Founding Member),Viasoft
47

Third Party Bridging Tools Oracle Exchange
Technology of choice for a long list of repository, enterprise and workgroup vendors
Reischmann-Informatik-Toolbus
Features include facilitation of selective bridging of metadata
Ardent Software/ Dovetail Software -Interplay

Hub and Spoke solution for enabling metadata interoperability Ardent focussing on own engagements, not selling it as independent product
Informix's Metadata Plug-ins

Available with Ardent Datastage version 3.6.2 free of cost for Erwin, Oracle Designer, Sybase Powerdesigner, Brio, Microstrategy
48

Metadata Repositories IBM, Oracle and Microsoft to offer free or near-free basic repository services Enable organisations to reuse metadata across technologies Integrate DB design, data transformation and BI tools from different vendors Multi-tool vendors taking a bridged or federated rather than integrated approach to sharing metadata Both IBM and Oracle have multiple repositories for different lines of products e.g., One for AD and one for DW, with bridges between them
49

Metadata Interchange Standards CDIF (CASE Data Interchange Format)
Most frequently used interchange standard Addresses only a limited subset of metadata artifacts
OMG (Object Management Group)-CWM

XML-addresses context and data meaning, not presentation Can enable exchange over the web employing industry standards for storing and sharing programming data Will allow sharing of UML and MOF objects b/w various development tools and repositories
MDC (Metadata Coalition)

Based on XML/UML standards Promoted by Microsoft Along With 20 partners including Object Management Group (OMG), Oracle Carleton Group, CA-PLATINUM Technology (Founding Member),Viasoft
50
OLAP
51
Agenda
OLAP Definition Distinction between OLTP and OLAP MDDB Concepts Implementation Techniques Architectures Features Representative Tools
2/15/2012
52
52
OLAP: On-Line Analytical Processing

OLAP can be defined as a technology which allows the users to view the aggregate data across measurements (like Maturity Amount, Interest Rate etc.) along with a set of related parameters called dimensions (like Product, Organization, Customer, etc.) Used interchangeably with BI Multidimensional view of data is the foundation of OLAP Users :Analysts, Decision makers
2/15/2012
53
53
Distinction between OLTP and OLAP

OLTP System Source of data OLAP System
Operational data; OLTPs are Consolidation data; OLAP the original source of the data comes from the data various OLTP databases To control and run fundamental business tasks A snapshot of ongoing business processes Decision support Multi-dimensional views of various kinds of business activities Periodic long-running batch jobs refresh the data
54
Purpose of data What the data reveals
Inserts and Updates Short and fast inserts and updates initiated by end users
2/15/2012
54
MDDB Concepts
A multidimensional database is a computer software system designed to allow for efficient and convenient storage and retrieval of data that is intimately related and stored, viewed and analyzed from different perspectives (Dimensions). A hypercube represents a collection of multidimensional data. The edges of the cube are called dimensions Individual items within each dimensions are called members
55
RDBMS v/s MDDB: Increased Complexity...

Relational DBMS
MODEL MINI VAN MINI VAN MINI VAN MINI VAN MINI VAN MINI VAN MINI VAN MINI VAN MINI VAN SPORTS COUPE SPORTS COUPE SPORTS COUPE SPORTS COUPE SPORTS COUPE SPORTS COUPE SPORTS COUPE SPORTS COUPE SPORTS COUPE SEDAN SEDAN SEDAN ... COLOR BLUE BLUE BLUE RED RED RED WHITE WHITE WHITE BLUE BLUE BLUE RED RED RED WHITE WHITE WHITE BLUE BLUE BLUE DEALER Clyde Gleason Carr Clyde Gleason Carr Clyde Gleason Carr Clyde Gleason Carr Clyde Gleason Carr Clyde Gleason Carr Clyde Gleason Carr VOL. 6 3 2 5 3 1 3 1 4 3 3 3 4 3 6 2 3 5 4 3 2 ...
MDDB
Sales Volumes
M O D E L
Mini Van
Coupe Carr Gleason Clyde Blue Red White
Sedan
DEALERSHIP
COLOR
27 x 4 = 108 cells
56
3 x 3 x 3 = 27 cells
Benefits of MDDB over RDBMS

Ease of Data Presentation & Navigation A great deal of information is gleaned immediately upon direct inspection of the array User is able to view data along presorted dimensions with data arranged in an inherently more organized, and accessible fashion than the one offered by the relational table. Storage Space Very low Space Consumption compared to Relational DB Performance Gives much better performance. Relational DB may give comparable results only through database tuning (indexing, keys etc), which may not be possible for ad-hoc queries. Ease of Maintenance No overhead as data is stored in the same way it is viewed. In Relational DB, indexes, sophisticated joins etc. are used which require considerable storage and maintenance
2/15/2012
57
57
Issues with MDDB
Sparsity
- Input data in applications are typically sparse -Increases with increased dimensions
Data Explosion
-Due to Sparsity -Due to Summarization
Performance
-Doesnt perform better than RDBMS at high data volumes (>20-30 GB)
2/15/2012
58
58
Issues with MDDB - Sparsity Example

If dimension members of different dimensions do not interact , then blank cell is left behind.
Employee Age
21 19 63 31 27 56 45 41 19
31 41 23 01 14 54 03 12 33
LAST NAME EMP# AGE SMITH 01 21 REGAN 12 Sales Volumes 19 FOX 31 63 Miini Van WELD 14 6 5 31 4 M O KELLY 54 3 5 27 D Coupe 5 E L LINK 03 56 4 3 2 Sedan KRANZ 41 45 Blue Red White LUCUS 33 COLOR 41 WEISS 23 19
Smith
Regan
Fox
L A S T N A M E
Weld
Kelly
Link
Kranz
Lucas
Weiss
EMPLOYEE #
2/15/2012
59
59
OLAP Features
Calculations applied across dimensions, through hierarchies and/or across members Trend analysis over sequential time periods, What-if scenarios. Slicing / Dicing subsets for on-screen viewing Rotation to new dimensional comparisons in the viewing area Drill-down/up along the hierarchy Reach-through / Drill-through to underlying detail data
2/15/2012
60
60
Features of OLAP - Rotation
Complex Queries & Sorts in Relational environment translated to simple rotation.

Sales Volumes
M O D E L
Mini Van
6 3 4
Blue
5 5 3
Red
4 5 2
( ROTATE 90 )
White
o
Coupe
C O L O R
Blue
6 5 4
3 5 5
MODEL
4 3 2
Sedan
Red
Sedan
White
Mini Van Coupe
COLOR
View #1
View #2
2 dimensional array has 2 views.

2/15/2012
61
61
Features of OLAP - Rotation

Sales Volumes
M O D E L
Mini Van
Coupe Carr Gleason Clyde Blue Red White
Sedan
C O L O R
Blue
Red White Sedan Coupe Mini Van Carr Gleason Clyde
C O L O R
Blue
Red White Carr Gleason Clyde Mini Van Coupe Sedan
COLOR
( ROTATE 90 )
MODEL
DEALERSHIP
( ROTATE 90 )
o
( ROTATE 90 )
DEALERSHIP
DEALERSHIP
MODEL
View #1
D E A L E R S H I P D E A L E R S H I P
View #2
View #3
Carr
Carr Gleason Blue Red White Mini Van Coupe Sedan
Mini Van
Gleason Mini Van Coupe Sedan White Red Blue
Clyde
Clyde
M O D E L
Coupe Blue Red White Clyde Gleason Carr
Sedan
COLOR
( ROTATE 90 )
MODEL
DEALERSHIP
( ROTATE 90 )
o
MODEL
COLOR
COLOR
View #4
View #5
View #6
3 dimensional array has 6 views.

2/15/2012
62
62
Features of OLAP - Slicing / Filtering

MDDB allows end user to quickly slice in on exact view of the data required.
Sales Volumes
M O D E L
Mini Van Mini Van
Coupe Coupe Normal Metal Blue Blue
Carr Clyde
Carr Clyde
Normal Blue
Metal Blue
DEALERSHIP
COLOR
2/15/2012
63
63
Features of OLAP - Drill Down / Up
ORGANIZATION DIMENSION
REGION Midwest
DISTRICT
Chicago
St. Louis
Gary
DEALERSHIP
Clyde
Gleason
Carr
Levi
Lucas
Bolton
Sales at region/District/Dealership Level
Moving Up and moving down in a hierarchy is referred to as drill-up / roll-up and drill-down
2/15/2012
64
64
OLAP Reporting - Drill Down
Inflows ( Region , Year)

200 150 Inflows 100 ($M) 50 0 Year Year 1999 2000 Years
East West Central
2/15/2012
65
65
Inflows ( Region , Year - Year 1999)

90 80 70 60 50 Inflows ( $M) 40 30 20 10 0 1st Qtr 2nd Qtr 3rd Qtr Year 1999 4th Qtr
East West Central
Drill-down from Year to Quarter

2/15/2012
66
66
Inflows ( Region , Year - Year 1999 - 1st Qtr)

20 15 Inflows ( $M 10 ) 5 0 January February March Year 1999 East West Central
Drill-down from Quarter to Month
67
Implementation Techniques -OLAP Architectures
MOLAP - Multidimensional OLAP

Multidimensional Databases for database and application logic layer
ROLAP - Relational OLAP

Access Data stored in relational Data Warehouse for OLAP Analysis. Database and Application logic provided as separate layers
HOLAP - Hybrid OLAP

OLAP Server routes queries first to MDDB, then to RDBMS and result processed on-the-fly in Server
DOLAP - Desk OLAP

Personal MDDB Server and application on the desktop
2/15/2012
68
68
MOLAP - MDDB storage
OLAP
Cube
OLAP Calculation Engine
Web Browser
OLAP Tools
OLAP Appli cations

2/15/2012
69
69
MOLAP - Features
Powerful analytical capabilities (e.g., financial, forecasting, statistical) Aggregation and calculation capabilities Read/write analytic applications Specialized data structures for
Maximum query performance. Optimum space utilization.
2/15/2012
70
70
ROLAP - Standard SQL storage
MDDB - Relational Mapping
Relational DW
Web Browser
SQL
OLAP Tools
OLAP Applications
2/15/2012
71
71
ROLAP - Features
Three-tier hardware/software architecture:
GUI on client; multidimensional processing on midtier server; target database on database server Processing split between mid-tier & database servers
Ad hoc query capabilities to very large databases DW integration Data scalability
2/15/2012
72
72
HOLAP - Combination of RDBMS and MDDB

OLAP Cube
Any Client
Relational DW
Web Browser
SQL
OLAP Tools
OLAP Applications
2/15/2012
73
73
HOLAP - Features
RDBMS used for detailed data stored in large databases MDDB used for fast, read/write OLAP analysis and calculations Scalability of RDBMS and MDDB performance Calculation engine provides full analysis features Source of data transparent to end user
2/15/2012
74
74
Architecture Comparison
MOLAP
Definition
ROLAP
HOLAP
Hybrid OLAP = ROLAP + summary in MDDB Sparsity exists only in MDDB part To the necessary extent
MDDB OLAP = Relational OLAP = Transaction level data + Transaction level data + summary in MDDB summary in RDBMS Good Design 3 10 times High (May go beyond control. Estimation is very important) Fast - (Depends upon the size of the MDDB) No Sparsity To the necessary extent
Data explosion due to Sparsity Data explosion due to Summarization Query Execution Speed
Slow
Optimum - If the data is fetched from RDBMS then its like ROLAP otherwise like MOLAP. High: RDBMS + disk space + MDDB Server cost Large transactional data + frequent summary analysis
Cost
Medium: MDDB Server + large disk space cost
Low: Only RDBMS + disk space cost
Where to apply?
Very large transactional Small transactional data + complex model + data & it needs to be viewed / sorted frequent summary analysis
2/15/2012
75
75
Representative OLAP Tools:
Oracle Express Products Hyperion Essbase Cognos -PowerPlay Seagate - Holos SAS
Micro Strategy - DSS Agent Informix MetaCube Brio Query Business Objects / Web Intelligence
2/15/2012
76
76
Sample OLAP Applications
Sales Analysis Financial Analysis Profitability Analysis Performance Analysis Risk Management Profiling & Segmentation Scorecard Application NPA Management Strategic Planning Customer Relationship Management (CRM)
2/15/2012
77
77
Data Warehouse Testing
78
Data Warehouse Testing Overview

There is an exponentially increasing cost associated with finding software defects later in the development lifecycle. In data warehousing, this is compounded because of the additional business costs of using incorrect data to make critical business decisions The methodology required for testing a Data Warehouse is different from testing a typical transaction system
79
Difference In Testing Data warehouse and Transaction System

Data warehouse testing is different on the following counts: User-Triggered vs. System triggered Volume of Test Data Possible scenarios/ Test Cases Programming for testing challenge
80
Difference In Testing Data warehouse and Transaction System.

User-Triggered vs. System triggered In data Warehouse, most of the testing is system triggered. Most of the production/Source system testing is the processing of individual transactions, which are driven by some input from the users (Application Form, Servicing Request.). There are very few test cycles, which cover the system-triggered scenarios (Like billing,Valuation.)
81

Volume of Test Data The test data in a transaction system is a very small sample of the overall production data. Data Warehouse has typically large test data as one does try to fill-up maximum possible combination of dimensions and facts. Possible scenarios/ Test Cases In case of Data Warehouse, the permutations and combinations one can possibly test is virtually unlimited due to the core objective of Data Warehouse is to allow all possible views of data.
82

Programming for testing challenge In case of transaction systems, users/business analysts typically test the output of the system. In case of data warehouse, most of the 'Data Warehouse data Quality testing' and ETL testing is done at backend by running separate stand-alone scripts. These scripts compare pre-Transformation to post Transformation of data.
83
Data Warehouse Testing Process

Data-Warehouse testing is basically divided into two parts : 'Back-end' testing where the source systems data is compared to the end-result data in Loaded area 'Front-end' testing where the user checks the data by comparing their MIS with the data displayed by the end-user tools like OLAP. Testing phases consists of : Requirements testing Unit testing Integration testing Performance testing Acceptance testing
84
Requirements testing
The main aim for doing Requirements testing is to check stated requirements for completeness. Requirements can be tested on following factors. Are the requirements Complete? Are the requirements Singular? Are the requirements Ambiguous? Are the requirements Developable? Are the requirements Testable?
85
Unit Testing
Unit testing for data warehouses is WHITEBOX. It should check the ETL procedures/mappings/jobs and the reports developed. Unit testing the ETL procedures: Whether ETLs are accessing and picking up right data from right source. All the data transformations are correct according to the business rules and data warehouse is correctly populated with the transformed data. Testing the rejected records that dont fulfil transformation rules.
86
Unit Testing
Unit Testing the Report data: Verify Report data with source: Data present in a data warehouse will be stored at an aggregate level compare to source systems. QA team should verify the granular data stored in data warehouse against the source data available Field level data verification: QA team must understand the linkages for the fields displayed in the report and should trace back and compare that with the source systems Derivation formulae/calculation rules should be verified
87
Integration Testing
Integration testing will involve following: Sequence of ETLs jobs in batch. Initial loading of records on data warehouse. Incremental loading of records at a later date to verify the newly inserted or updated data. Testing the rejected records that dont fulfil transformation rules. Error log generation
88
Performance Testing
Performance Testing should check for : ETL processes completing within time window. Monitoring and measuring the data quality issues. Refresh times for standard/complex reports.
89
Acceptance testing
Here the system is tested with full functionality and is expected to function as in production. At the end of UAT, the system should be acceptable to the client for use in terms of ETL process integrity and business functionality and reporting.
90
Questions
91
Thank You
92
Content
94
Content [contd]
6 Metadata Management 7 OLAP 8 Data Warehouse Testing
95
An Overview
Understanding What is a Data Warehouse
96
What is Data Warehouse?

Definitions of Data Warehouse A data warehouse is a subject-oriented, integrated, nonvolatile, time-variant collection of data in support of management's decisions. WH Inmon Data Warehouse is a repository of data summarized or aggregated in simplified form from operational systems. End user orientated data access and reporting tools let user get at the data for decision support Babcock A data warehouse is a relational database a copy of transaction data specifically structured for query and analysis Ralph Kimball In simple: Data warehousing is collection of data from different systems, which helps in Business Decisions, Analysis and Reporting.
97
Data Warehouse def. by WH Inmon

A common way of introducing data warehousing is to refer to the characteristics of a data warehouse as set forth by William Inmon: Subject Oriented Data that gives information about a particular subject instead of about a company's ongoing operations. Integrated Data that is gathered into the data warehouse from a variety of sources and merged into a coherent whole. Nonvolatile Data is stable in a data warehouse. More data is added but data is never removed. This enables management to gain a consistent picture of the business. Time Variant In order to discover trends in business, analysts need large amounts of data. This is very much in contrast to online transaction processing (OLTP) systems, where performance requirements demand that historical data be moved to an archive. All data in the data warehouse is identified with a particular time period.
98

U4 F 3 B 59 D 1 A 85 CC

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

U4 F 3 B 59 D 1 A 85 CC

Diunggah oleh

Hak Cipta:

Format Tersedia

Data Warehouse Concepts

Avinash Kanumuru Diya Jana Debyajit Majumder

2009 Wipro Ltd - Confidential

2009 Wipro Ltd - Confidential

2009 Wipro Ltd - Confidential

Data Warehouse Concepts

Avinash Kanumuru Diya Jana Debyajit Majumder

2009 Wipro Ltd - Confidential

5 Data Extraction,Transformation, Load

2009 Wipro Ltd - Confidential 2009 Wipro Ltd - Confidential

2009 Wipro Ltd - Confidential

Data Warehouse Concepts

Avinash Kanumuru Diya Jana Debyajit Majumder

2009 Wipro Ltd - Confidential

5 Data Extraction,Transformation, Load

2009 Wipro Ltd - Confidential 2009 Wipro Ltd - Confidential

2009 Wipro Ltd - Confidential 2009 Wipro Ltd - Confidential

2009 Wipro Ltd - Confidential

What is Data Warehouse?

2009 Wipro Ltd - Confidential 2009 Wipro Ltd - Confidential

Data Warehouse def. by WH Inmon

2009 Wipro Ltd - Confidential 2009 Wipro Ltd - Confidential

Data Warehouse Architecture

2009 Wipro Ltd - Confidential

2009 Wipro Ltd - Confidential 2009 Wipro Ltd - Confidential

Data Warehouse Architecture

2009 Wipro Ltd - Confidential 2009 Wipro Ltd - Confidential

2009 Wipro Ltd - Confidential 2009 Wipro Ltd - Confidential

Data Warehouse Architecture

2009 Wipro Ltd - Confidential 2009 Wipro Ltd - Confidential

2009 Wipro Ltd - Confidential

 Different Perceptive of Data Modeling.

 Types of Dimensional Data Models most commonly used:

Terms used in Dimensional Data Model

Data Warehouse Architecture

2009 Wipro Ltd - Confidential 2009 Wipro Ltd - Confidential

 Different Perceptive of Data Modeling.

 Types of Dimensional Data Models most commonly used:

Terms used in Dimensional Data Model

2009 Wipro Ltd - Confidential 2009 Wipro Ltd - Confidential

region regId name north cold region south warm region

2009 Wipro Ltd - Confidential 2009 Wipro Ltd - Confidential

Overview of Data Cleansing

2009 Wipro Ltd - Confidential

The Need For Data Quality

2009 Wipro Ltd - Confidential 2009 Wipro Ltd - Confidential

Six Steps To Data Quality

Identify Potential Problem Areas & Asses Impact

Measure Quality Of Data

y Use business rule discovery tools to identify data with

inconsistent, missing, incomplete, duplicate or incorrect values

Clean & Load Data

y Schedule Periodic Cleansing of Source Data

Identify Areas of Improvement

Data Quality Solution

2009 Wipro Ltd - Confidential 2009 Wipro Ltd - Confidential

Data Quality Solution

Tools In The Market

2009 Wipro Ltd - Confidential 2009 Wipro Ltd - Confidential

Data Extraction, Transformation, Load

2009 Wipro Ltd - Confidential

External Data Demographics, Household, Webographics, Income

Different Perceptive of Data Modeling.

Types of Dimensional Data Models most commonly used:

Different Perceptive of Data Modeling.

Types of Dimensional Data Models most commonly used:

Ardent Software/ Dovetail Software -Interplay

Informix's Metadata Plug-ins

OMG (Object Management Group)-CWM

MDC (Metadata Coalition)

Ardent Software/ Dovetail Software -Interplay

Informix's Metadata Plug-ins

OMG (Object Management Group)-CWM

MDC (Metadata Coalition)